# Часть 17. Витрина платежей и риск-сигналов

Платёжные данные опасны тем, что технически простая агрегация может выглядеть
как риск-решение. В учебнике `mart_payment_risk_signals` — не скоринговый
движок. Это витрина наблюдения: какие операции помечены риск-флагом и какие
суммы/каналы требуют внимания.

## Grain

Для витрины риска уровня операции grain:

```text
одна строка на `transaction_id`
```

Если витрина агрегирует по клиенту или дню, это другой дата-продукт. Нельзя
тихо менять mart уровня операции на уровень клиента, даже если SQL становится
короче.

## Что проверять

- `transaction_id` not null и unique;
- сумма не `null`;
- риск-флаг трактуется как учебный сигнал источника;
- прямые PII не появляются;
- операции без риск-флага не удаляются из вышестоящего слоя без спецификации;
- ревьюер видит, где порог — учебное правило.

## Плохой подход

```sql
where risk_flag = true
```

Такой фильтр может быть допустим для конкретного mart, но только если спецификация
говорит: «витрина содержит только рисковые события». Если потребитель ожидает все
операции с признаком риска, фильтр ломает полноту.

## Qwen-запрос

```text
Прочитай stg_card_transactions, mart_payment_risk_signals и specs.
Определи grain, какие операции включены, какие исключены и какие факты проверки
нужны для витрины риска. Файлы не меняй.
```

## Минимальный выход

Составьте заметку о витрине риска:

```markdown
Витрина:
Гранулярность:
Источник риск-флага:
Включённые строки:
Исключённые строки:
Проверочные факты:
Ручные вопросы ревьюера:
```

## Разбор для читателя

Витрина риск-сигналов кажется простой: взять операции с `risk_flag`, добавить
крупные суммы, отдать список. Но именно здесь агент чаще всего начинает
придумывать бизнес. Он может решить, что риск — это только флаг источника. Или
что риск — это сумма выше порога. Или что нужно агрегировать по клиенту, потому
что так удобнее для отчёта. Все эти решения возможны, но ни одно не должно
появляться без спецификации.

В учебном проекте `mart_payment_risk_signals` не является скоринговой моделью.
Это принципиально. Скоринг требует методологии, объяснимости, контроля
качества, юридических и риск-процедур. Здесь же витрина нужна для обучения SDD:
показать, как отделить источник сигнала от решения, grain уровня операции от
агрегации уровня клиента, наблюдение от вывода.

Порог крупной суммы тоже является учебным правилом, а не банковской истиной.
Если порог записан только в SQL, ревьюер не поймёт, является ли он временным
упрощением, требованием продукта или догадкой агента. Поэтому порог должен
появиться в спецификации, заметке о проверке и отчёте ревьюера. Тогда будущий автор
сможет заменить его на другую методологию без скрытого дрейфа.

Эта глава учит важному вопросу: «какую строку представляет витрина?» Если строка —
операция, то `transaction_id` — ключ, а клиент может повторяться. Если
строка — клиент, нужны другие поля, другие тесты и другая спецификация. Нельзя
считать эти варианты взаимозаменяемыми только потому, что оба помогают говорить
о риске.

## Практика

Опишите два варианта витрины риска: уровень операции и уровень клиента. Для каждого
укажите grain, потребителя и почему SQL одного варианта нельзя тихо заменить
другим.

## Типичная ошибка

Превращать учебный `risk_flag` в реальное решение. В банковском домене такое
решение требует отдельной модели, объяснимости, процедур управления и юридического ревью. В
этом томе риск-флаг — сигнал для SDD-процесса, а не продукт скоринга.

## Контрольные вопросы

1. Почему витрины риска уровня операции и уровня клиента нельзя смешивать?
2. Когда фильтр `risk_flag = true` является ломающим изменением?
3. Какой ручной факт должен проверить ревьюер?