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

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

Grain

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

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

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

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

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

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

where risk_flag = true

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

Qwen-запрос

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

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

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

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

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

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

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

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

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

Практика

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

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

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

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

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