Модуль 16. Бизнес-аналитика в банке и финтехе
Картина домена: из чего состоит «банковский сквозняк»
Слои и системы
- Каналы и процессинг: карты (Auth→Clearing→Settlement), переводы (P2P, P2B), интернет/мобайл, банкоматы/терминалы, платежные шлюзы, ISO 8583/ISO 20022.
- Корсчет/учёт (Core Banking, GL): счета, договоры, проводки, баланс/оборот, справочники.
- Риск и модели: скоринг (PD/LGD/EAD), лимиты, лимит-менеджмент, коллекшн.
- AML/KYC/санкции: Customer Due Diligence, санкционные и PEP-списки, мониторинг транзакций, кейс-менеджмент.
- Антифрод: real-time правила/модели, устройство/поведение, velocity-чекеры, кейс-менеджмент.
- Отчётность: XBRL/финрег, управленческая, ALM/ликвидность, IFRS 9.
- DWH/BI/логирование: сырые логи, нормализованный слой, витрины, семантика, аудит.
BA-задача: согласовать событийную модель, метрики, NFR, политику приватности/доступов и приёмку (UAT/алерты) так, чтобы и AML/Compliance, и бизнес, и ИТ говорили на одном языке.
Модель данных: минимально достаточные витрины
Факты (core)
-
fact_txn — транзакция (grain: уникальная операция/проводка).
Поля (пример): txn_id, parent_txn_id, posted_ts, auth_ts, channel, instrument_id (card/account), amount, currency, amount_local, mcc/merchant_id, counterparty_iban, country, status (approved/declined/reversed), fee, chargeback_flag. - fact_balance_daily — остатки по счетам (дневной снапшот).
- fact_alert — алерты (fraud/AML): alert_id, rule/model, score, threshold, status, case_id.
- fact_kyc_event — KYC/санкции: результаты проверок клиента/контрагента по спискам (hit/no_hit, источник, версия списка).
- fact_case — кейс-менеджмент: case_id, type (fraud/AML/complaint), opened_ts, owner, SLA, disposition.
- fact_model_score — выходы моделей: PD/LGD/EAD/фрод-скоры по событию/клиенту.
- fact_xbrl_cell — попадания в таксономию: report, cell, value, period, dimensionality.
Измерения
- dim_customer (SCD2) — KYC-статус, риск-рейтинг, сегмент, страна резидентства, FATCA/CRS флаги.
- dim_account — тип счёта, продукт, валюта, договор, RLS-область.
- dim_instrument — карта/устройство/токен, BIN, PAN_masked (PCI!), expiry.
- dim_device — device fingerprint, os/browser, риск-сигналы.
- dim_counterparty — IBAN/BIC, резидентность, санкционный риск.
- dim_geo — страна/город/гео-риск.
- dim_rule — правила/версии, владелец, контрольные тесты.
- dim_calendar — банковские дни, cut-off.
Ключевые связи и «острые углы»
- auth_txn ↔ clearing_txn ↔ ledger_entry (сверки, частичные клиринги).
- Реверсалы, чарджбеки, частичные возвраты.
- Дедупликация событий из нескольких источников (шлюз, процессинг, core).
- Синхронизация часов (UTC + локаль клиента; логирование ingestion_time vs event_time).
Приватность и безопасность: что BA обязан зафиксировать
- PII/PCI/фин.тайна: список полей (ФИО, адрес, IBAN, PAN, CVV/CVC — не хранить в логах, PAN — маска/токен), источник согласия/правовое основание.
- RLS/ABAC: доступ по роли (филиал/регион/функция), атрибуты клиента (VIP/сотрудник).
- Шифрование: at rest (KMS/TDE), in transit (TLS 1.2+), секреты — в Vault/KMS.
- Маскирование/токенизация: PAN токен, IBAN частично маскирован, детерминированное шифрование для join по телефону/паспортному номеру (строго по политике).
- Аудит: кто смотрел карточку клиента/алерт, кто выгружал, правила минимизации выгрузок (разрешён только обезличенный экспорт по умолчанию).
- Retention: логи/алерты/кейсы — по политике регулятора; удалить/анонимизировать по сроку.
KYC/AML: типологии, витрины и триггеры
KYC и риск-рейтинг клиента
- CDD/EDD (базовая/углублённая проверка): документ, адрес, источники средств, бенефициар, санкции/PEP/адверз-медиа.
- Risk score клиента: страна резидентства, отрасль, продукт/канал, поведенческие признаки.
- Пересмотр: при изменениях профиля/событиях (change in circumstances) + периодический обзор (12/24/36 мес по риску).
AML-мониторинг (транзакции)
Базовые сценарии (иллюстративно):
- Structuring/Smurfing: частые депозиты/переводы чуть ниже порога за короткое время на одного бенефициара.
- Rapid movement: входящие→быстрые исходящие на новый счёт/криптобиржу.
- Unusual geography: резкий сдвиг стран/часовых поясов по клиенту.
- Dormant to active: «спящий» счёт внезапно активен высокими суммами.
- High-risk MCC/NAICS: частые операции с высокой риск-оценкой мерчанта.
Витрины AML:
- mart_aml_customer_profile — профиль клиента (KYC, риски, поведение).
- mart_aml_txn_window — агрегаты по окнам (1ч/24ч/7д/30д): суммы, счетчики, контрагенты, страны.
- mart_aml_alerts — алерты, статусы, время до «SAR/сообщения о подозрительной операции» и disposition.
Пример SQL (наивный «structuring» для наличных/порог N):
SELECT customer_id, beneficiary_id, date_trunc('day', posted_ts) AS d,
COUNT(*) AS ops, SUM(amount_local) AS amt
FROM fact_txn
WHERE txn_type='cash_deposit'
AND amount_local BETWEEN :threshold*0.8 AND :threshold*1.0
AND posted_ts >= now() - interval '7 day'
GROUP BY 1,2,3
HAVING COUNT(*) >= 3
OR SUM(amount_local) >= :threshold*3;
В реальности правила сложнее (исключения, профили, риск клиента, гео, «свои»/«касса» и т.д.). BA фиксирует логику и исключения, источники и пороги, владельца правила.
Санкции/PEP
- Screening: on-boarding и при каждой исходящей транзакции (real-time/near-real-time согласно политике).
- Версия списков, fuzzy-matching, скоуп hit (имя/дата рождения/страна).
- Case-flow: hit→review→resolve (false/true positive)→SAR при необходимости.
Антифрод: real-time поток, кейсы и метрики
Сигналы:
- Поведенческие: скорость/паттерн нажатий, типичные шаблоны входа, «невозможная перемена» гео/устройства.
- Контент/данные: попытки сменить реквизиты перед переводом, несоответствие device fingerprint профилю.
- Транзакционные: velocity-правила, необычные суммы/гео/MCC, новые получатели.
Архитектура (упрощённо):
- Стрим (events) → реальное время правил/моделей → fact_alert (decision: approve/step-up/decline) → кейс-менеджмент → обратная связь на обучение.
Пример SQL (для офлайн-анализа velocity):
SELECT customer_id,
COUNT(*) FILTER (WHERE posted_ts > now() - interval '10 minute') AS txn_10m,
COUNT(DISTINCT counterparty_iban) FILTER (WHERE posted_ts > now() - interval '1 hour') AS uniq_rcp_1h,
SUM(amount_local) FILTER (WHERE posted_ts > now() - interval '1 day') AS amt_1d
FROM fact_txn
WHERE channel IN ('web','mobile') AND status='approved'
GROUP BY customer_id
HAVING txn_10m >= 5 OR uniq_rcp_1h >= 3 OR amt_1d > :daily_limit;
Метрики качества:
- AUC/Gini/KS (для моделей), TPR/FPR/precision/recall (для правил/портфеля).
- Вред-метрики: доля ложных отклонений (customer friction), время «до денег» (time-to-cash).
- Drift-мониторинг: распределения фич/скор, доля алертов по каналам, «новые» причины.
UAT-наборы: позитивные/негативные сценарии, реплеи исторических инцидентов, «адверсариальные» примеры.
Кредитный риск: PD/LGD/EAD и IFRS 9 (для BA «ровно сколько надо»)
- PD (Probability of Default) — вероятность дефолта за горизонт (12 мес/весь срок).
- LGD (Loss Given Default) — доля потерь при дефолте (после взыскания).
- EAD (Exposure At Default) — экспозиция на момент дефолта (остаток долга, невыбранная линия с CCF).
- ECL (ожидаемые кредитные потери) = PD × LGD × EAD × дисконт-фактор.
- IFRS 9 стадирование: Stage 1 (12м PD), Stage 2 (significant increase in credit risk → lifetime PD), Stage 3 (кредит-импейрмент).
BA-ответственность:
- Зафиксировать источники PD/LGD/EAD, версии моделей, период их обновления, квалификацию ограничений (для какой популяции применимы).
- Обеспечить трассируемость: договор→счёт→модель→ECL→XBRL-ячейки.
- В UAT — регрессы на ECL: сверка на эталонах, пороги допусков.
XBRL/регуляторная отчётность: как не «попасть»
- Таксономия: справочники регулятора (именованные клетки/оси).
- Map: GL/витрины → XBRL-факты (консистентность, валюта, знак, период).
- Контроли: арифметические равенства, кросс-формы (BAL ↔ P&L), валидации.
- Процесс: freeze данных на дату, версия таксономии, протокол правок, аудит.
- BA делает: матрицу соответствий, тест-наборы, «красные флажки» (внезапные deltas).
NFR/операционные требования (что критично)
- Latency: фрод-решения ≤ 300–500 мс end-to-end; AML batch — EOD (+near-real-time на high-risk сценарии по политике).
- Freshness: fact_txn near-real-time (≤1–5 мин), витрины управленческие — D+1 07:00.
- Uptime: антифрод/санкции — ≥ 99.9% в часы операций.
- Аудит: 100% решений (approve/decline/step-up) логируются с причинами/фичами (explainability для моделей).
- RLS/PII: карточки клиентов/алертов — строго по ролям, выгрузки по умолчанию обезличены.
- Chaos/DR-drill: тренировки переключения (RTO/RPO) квартально.
Приёмка: acceptance-кейсы (минимум 12)
- KYC-сквозной: новый клиент → screening → risk score присвоен, карточка полная.
- Санкции: исходящий перевод на контрагента в списке → alert с кейсом, блокировка до расследования.
- Structuring: серия суб-пороговых кеш-депозитов → AML-алерт согласно правилу.
- Unusual geo: логин из страны X + перевод в страну Y, не свойственные → антифрод step-up (2FA/biometric).
- Rapid movement: входящий крупный перевод → исходящий в ≤10 мин новому получателю → алерт.
- Device mismatch: смена устройства + перевод свыше лимита → decline/step-up.
- PD/LGD/EAD: витрина ECL на 10 эталонных договорах совпадает (±допуск).
- XBRL: выгрузка формы проходит арифм. контроли, дисбалансов нет.
- PII-маскинг: PAN/IBAN/PIN нигде не проявляется в открытом виде.
- RLS: сотрудник региона A не видит клиентов региона B; суммы инвариантны.
- Latency: 95-й перцентиль решения фрода ≤ 500 мс на стенде с 100 RPS.
- Audit: по decision_id притягиваются фичи/правила/версии модели.
Риски и как их снимать
|
Риск |
Симптом |
Меры |
|---|---|---|
|
Высокий FPR (ложные срабатывания) |
Жалобы, падение NPS |
Калибровка порогов, сегментные пороги, пост-решенческие апелляции |
|
«Дыры» в транзакционном потоке |
Пропущенные списания |
Идентификаторы корреляции, дедуп-стратегия, reconcile-отчёты |
|
Несогласованные часы/таймзоны |
Неверный on-us/off-us разбор, окна |
UTC + локаль, правка DST, event vs ingestion time |
|
Непрозрачные модели |
«Чёрный ящик», регулятор недоволен |
Документация MRM, explainability (SHAP/переменные), контроль дрейфа |
|
Утечки PII/PCI |
Полевые дампы в BI |
Ролевые доступы, маскирование, запрет выгрузок, аудит/ретеншн |
|
Конфликты AML-и антифрода |
Дубли кейсов |
Единый case-hub, уникальность по txn/customer, оркестрация |
|
Несогласованные формулы ECL |
Финансы vs риск спорят |
Единая методика, версия модели, тест-наборы в UAT |
|
XBRL «краснеет» в последний день |
Валидации не проходят |
Ранний dry-run, авто-контроли, change-freezes |
Вопрос–ответ (FAQ)
Q: Реал-тайм AML обязателен?
A: Обычно да для санкций/доказуемых блоков, а поведенческий AML часто работает батчами с near-real-time для high-risk. Политика определяется риском и регулятором.
Q: Почему столько ложных фрод-срабатываний?
A: Недокалиброванные пороги, отсутствие сегментации, drift данных, старые фичи. Введите сегментные пороги и мониторинг дрейфа.
Q: Можно ли «склеить» PAN/телефон без хранения открытого значения?
A: Да: детерминированное шифрование/токенизация по политике; соль/ключи — в KMS; в BI — только токены.
Q: PD из скоринга «не бьётся» с дефолтами?
A: Нужна калибровка/рефит, контроль стабильности популяции (PSI), ревью cut-off; BA фиксирует процесс и версии.
Q: Чем антифрод отличается от лимитов?
A: Лимиты — грубый барьер; антифрод — риск-оценка события с контекстом (поведение/устройство/гео) и решением (approve/step-up/decline).
Q: Что важнее — правила или модели?
A: И то, и другое: правила ловят рег-критичные/интерпретируемые паттерны, модели — сложные. Делайте «rule-first» для требований и «model-assist» для качества.
Практика (что сдать по итогу модуля)
A. Витрина транзакций (скелет)
- Факты: fact_txn, fact_alert, fact_model_score, fact_kyc_event.
- Измерения: dim_customer/account/instrument/device/counterparty/geo/rule.
- Метрики: объём/кол-во, отклонения, refund/chargeback rate, velocity-агрегаты (10м/1ч/1д), on-us/off-us, риск-сигналы.
- DQ-правила: уникальность txn_id, связность auth↔clearing↔ledger, лаги событий, доля событий без geo/device < 5%.
B. Сценарии сегментации и алертов антифрода (по 3–5 шт.)
- Новые получатели + высокий чек + ночь → step-up.
- Смена устройства + крупный P2P → decline/step-up.
- Burst переводов < X минут > N шт → алерт.
- Необычный MCC/страна по клиентскому профилю → пониженная доверенность.
- Velocity по карте в оффлайн-терминалах → возможный скимминг.
Для каждого: описание, порог/окно, исключения, владелец, метрики качества (TPR/FPR), UAT-набор.
C. Политика триггеров инцидентов
- Критерии: санкционный hit (block), массовый drift модели, SLA антифрода > X мин, всплеск FPR > Y п.п., дыра в транзакциях.
- Реакции: инцидент P1/P2, эскалации, временные пороги, rollback, коммуникации клиентам.
D. Паспорт дашборда «Risk & Compliance»
- Цель, аудитория, метрики (отдельно AML/фрод/скоринг/XBRL), методология и версии, владельцы, Freshness по потокам, RLS, NFR, release notes.
Чек-листы готовности
Методология/губернанс
- Определения PD/LGD/EAD/ECL зафиксированы; версии моделей и владельцы есть.
- AML типологии и правила документированы, исключения и пороги ясны.
- Санкционный screening: источник списков, частота обновления, SLA.
Данные/интеграции
- Сквозные ID auth↔clearing↔ledger; reconcile-отчёты зелёные.
- device/geo собираются стабильно; доля «пустых» записей в норме.
- PII/PCI правильной степени маскинга; токены/ключи в KMS.
NFR/приёмка
- Latency real-time антифрода ≤ 500 мс (p95), AML EOD готов к D+1.
- RLS по функциям/региону; аудиты просмотров.
- UAT-наборы для санкций/фрода/AML/ECL/XBRL пройдены.
Вы связываете транзакционные потоки с риск- и комплаенс-метриками: строите витрины, утверждаете приватность/доступы, проектируете правила/модели для AML/антифрода, фиксируете PD/LGD/EAD/ECL и обеспечиваете XBRL-сопоставления. Результат — управляемые алерты, прозрачная приёмка, измеримое качество решений и минимум сюрпризов у регулятора.
