Операции и Комплаенс → AML-политика и контроль транзакций

AML-политика и контроль транзакций

1) Цель и область действия

Цель AML-политики — предотвратить использование платформы для отмывания средств и финансирования терроризма, минимизируя ложные срабатывания и операционную нагрузку. Политика распространяется на весь жизненный цикл игрока: регистрация → депозиты → игра/переводы → вывод; а также на аффилиатов, провайдеров и платежных партнеров.

2) Принципы (risk-based & evidence-by-design)

1. Risk-Based Approach (RBA): проверки и пороги зависят от профиля риска (страна, метод оплаты, поведение, суммы).
2. Layered Controls: комбинация KYC/санкций/PEP, поведенческой аналитики и ручных расследований.
3. Evidence-by-Design: каждое решение имеет артефакты: источники данных, скриншоты, логи, экспортируемые отчеты.
4. Privacy-first: минимизация ПДн, маскирование, доступ по ролям, контролируемая ретеншн-политика.
5. Explainability: правила и модели интерпретируемы; для ML — фичи/важности/пример кейсов.
6. Continuous Improvement: настройка порогов, обратная связь от MLRO и ретро по кейсам.

3) Роли и ответственность

MLRO (Money Laundering Reporting Officer): владелец AML-процесса, окончательные решения по SAR/STR, связь с регуляторами/банками.
AML Ops: расследования, коммуникации с игроками/банками, контроль SLA кейсов.
Data/BI & Risk Analytics: поддержка правил/моделей, мониторинг качества детекции.
Payments/Ops: соблюдение лимитов и процедур hold/реверсов, трассировка транзакций.
Security/DPO: защита данных, доступы, инциденты приватности.

4) Модель риска игрока и сегментов

• Гео/IP/резидентство, документ и способ KYC.
• Методы депозитов/выводов, множественность платежных инструментов.
• Активность: суммы, частота, винрейт/лоссрейт, ночные сессии, корреляция с другими аккаунтами.
• Устройства/фингерпринт, пересечения IP/устройств/платежных реквизитов.

Сегменты: Low / Medium / High / Prohibited.
Движок маршрутизации: Low — упрощенные проверки; High — EDD/hold/ограничения.

5) KYC, санкции и PEP

Tiered KYC: `KYC1 (личность) → KYC2 (адрес) → EDD (доп. документы/SoF)`.
Санкции/PEP: проверка при регистрации, при значимых порогах депозитов/выводов и при изменении реквизитов.
SoF/SoW: по триггерам (высокие обороты, несоответствие профиля, VIP).
Ретеншн: хранение документов в соответствии с требованиями юрисдикции; доступ через vault/контроль выдач.

6) Контроль транзакций (правила и сигналы)

• Velocity: быстрые шипы депозитов/выводов; серия мелких депозитов → крупный вывод.
• Multi-instrument: много разных карт/кошельков за короткий период.
• Source/Destination mismatch: депозит с одного инструмента, вывод на другой.
• Circularity: пополнение → минимальные ставки/отмывка бонусов → вывод.
• Split/Structuring: дробление сумм под пороги.
• Affiliate abuse: аномальный приток с канала + типовые паттерны злоупотреблений.
• Device/IP risk: смены устройств/прокси/высокорисковые ASN.

• Нереалистичный винрейт на низкой дисперсии, ставки у «контент-партнера» с жалобами, игры с минимальным риском ради оборота.

7) Controls-as-Code (фрагменты)

yaml control_id: AML-VELOCITY-DEP-01 scope: deposits risk_weight: 0. 8 trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3
OR count_unique(payment_method, 1h) >= 3
OR count(amount < threshold_structuring, 24h) >= 5 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- request: "KYC2_or_EDD"
evidence:
store: s3://evidence/aml/velocity/{player_id}/{ts}
fields: [amounts_1h, methods_1h, ip, device, kyc_level]
owner: mlro review_sla_days: 180

yaml control_id: AML-SRC-DST-02 scope: withdrawals trigger:
expr: payout_method!= last_successful_deposit_method actions:
- limit: withdrawals "require_same_source"
- notify: payments_team
- flag: aml_review exceptions:
- condition: method_type=="bank_transfer" AND policy. allow_bank_payouts==true evidence:
fields: [payout_method, last_deposit_method, policy_ref]

yaml control_id: AML-GAMING-PATTERN-03 scope: gameplay trigger:
expr: turnover_24h / deposits_24h > 10
AND avg_bet_risk_index < 0. 2
AND session_count_24h > 8 actions:
- flag: aml_review
- limit: bonuses "freeze"
- request: "source_of_funds"

yaml control_id: AML-RISK-SCORE inputs: [AML-VELOCITY-DEP-01, AML-SRC-DST-02, AML-GAMING-PATTERN-03, sanctions, pep]
score:
expr: w1velocity + w2srcdst + w3gaming + w4sanctions + w5pep thresholds:
- high: score>=0. 8 -> EDD + hold
- medium: score>=0. 5 -> review
- low: score<0. 5 -> auto_clear

8) Модели и правила: совместное использование

Rules-first на старте (быстро, объяснимо) + ML для приоритизации (градиентный бустинг/логрег/извлекаемые фичи).
Champion/Challenger: сравнение текущих порогов с новыми моделями в тени.
Drift-мониторинг: контроль сдвига фич, доли флагов/hold, FPR/TPR.
Explainability: SHAP/feature importance, кейсы-эталоны.

9) SOP (фрагменты)

SOP: Триаж AML-срабатывания

1. Проверить карточку игрока (гео, KYC, риск-скоры, историю).
2. Верифицировать источники данных (логи платежей/игры, связи по устройствам).
3. Принять решение: `clear / request_info / hold / EDD / SAR`.
4. Зафиксировать действия в системе кейсов и обновить статус.
5. Коммуникация с игроком (шаблон, сроки ответа).
6. Пересмотр порога/правила (если много FPs).

SOP: EDD/SoF запрос

1. Запрос документов (выписки/зарплата/налоговые).
2. Сопоставить суммы/частоты/источники с поведением на платформе.
3. Обновить риск-профиль, снять/подтвердить ограничения.
4. Сохранить evidence и решение (подпись MLRO).

SOP: SAR/STR подача

1. Собрать фактологию (таймлайн, суммы, связи, скрины).
2. Проверить дедлайны и форматы юрисдикции/банка.
3. Подать SAR/STR, зафиксировать идентификатор/время/канал.
4. Обновить внутренние статусы и ограничения на аккаунт.
5. Фоллоу-ап до закрытия/инструкций регулятора/банка.

10) Коммуникации с игроками и партнерами

Тон: нейтральный и фактологичный, без раскрытия внутренних правил/моделей.
Сроки: четкие ETA на ответ, напоминания, фиксация в тикете.
Платежные партнеры: синхронизация hold/реверсов, обмен кейс-ID, единый канал AML.

11) Интеграции и данные

Payments Gateway: статусы транзакций, метод и реквизиты, возвраты, chargeback.
Game Platform: оборот/винрейт/сессии/дисперсия, аномалии.
Device Graph: фингерпринт/связи устройств/сессий/IP.
KYC/PEP/Sanctions: провайдер-скрининг по событиям и расписанию.
Case Management: статусы, SLA, журнал решений, упаковка SAR/STR.

12) Показатели качества (KPI/OKR)

• TPR/Recall по подтвержденным кейсам, FPR (ложные флаги) ↓ QoQ.
• Precision по High-risk > X%; Auto-clear Rate для Low-risk > Y%.
• Case Prioritization Accuracy (верхние N% дают M% находок).

• Time-to-Triage (P95), EDD Turnaround, Hold Duration (медиана).
• SAR/STR SLA (подача ≤ сроков), возвраты/chargeback после AML-мер ↓.
• Model/Rule Drift — в пределах допустимых коридоров.

• Потери от фрода/отмывания ↓, операционные часы/кейс ↓.
• Player Experience: жалобы на AML-процессы, NPS по честным игрокам.

13) Говернанс и безопасность

Политики доступа: только AML/MLRO видят чувствительные поля; аудиты чтений.
Ретеншн: сроки хранения кейсов/документов; автоматическая очистка.
Журналирование: все действия по кейсам и правкам правил/моделей.
Dual Control: критичные изменения правил/порогов требуют 2-х подтверждений.
Тесты в CI: синтаксис правил, конфликтность порогов, регрессионные сценарии.

14) Чек-листы

• Верифицированы данные транзакций/игры/устройства.
• Сопоставлены методы депозит/вывод.
• Проверены санкции/PEP/гео.
• Выбран корректный тип решения (`clear/hold/EDD/SAR`).
• Зафиксирован ETA и коммуникация игроку.

• Полный таймлайн и суммы, связи с другими аккаунтами.
• Подтверждающие артефакты (скрины/логи/выписки).
• Формат и канал соответствуют требованию.
• Внутренние статусы и ограничения обновлены.
• Контроль последующих инструкций.

• Порог/окно времени обоснованы.
• Есть оценка FP/TP, бизнес-эффект.
• Настроен мониторинг дрейфа и автотесты.
• Обновлен playbook триажа.
• Проведено ревью MLRO/Compliance.

15) Анти-паттерны

Универсальные пороги «для всех стран» без RBA.
Hold без ETA/коммуникации, «висящие» кейсы.
ML-модели без объяснимости и журнала версий.
Ручные выгрузки/SAR без evidence-шаблонов и контроля сроков.
Отсутствие связи депозит↔вывод, слабая интеграция с платежами.
Нет регулярного ретро по ложным срабатываниям.

16) 30/60/90 — план внедрения

• Утвердить AML-политику, роли (MLRO/AML Ops) и RBA-матрицу.
• Запустить базовые Controls-as-Code (velocity, src/dst mismatch, gaming pattern).
• Включить KYC tiers + санкции/PEP, создать шаблоны SOP (триаж/EDD/SAR).
• Ввести evidence-хранилище и ретеншн-политику.

• Подключить агрегатор риск-скора, авто-маршрутизацию кейсов и отчетность по SLA.
• Запустить champion/challenger для порогов и ML-помощник приоритизации.
• Интегрировать payments/game/device граф в единый профиль игрока.
• Обучить команды, отладить шаблоны коммуникаций, включить автотесты правил.

• Снизить FPR ≥ 20% без потери Recall; сократить Time-to-Triage на ≥ 30%.
• Достичь SLA SAR/STR = 100% в срок; закрыть все «залежавшиеся» кейсы.
• Провести внутренний аудит дизайна и эффективности контролей; зафиксировать OKR на следующий квартал.

17) FAQ

Q: Как балансировать безопасность и UX?
A: RBA-маршрутизация: для low-risk — авто-очистка, для medium — легкие запросы, для high — EDD/hold. Прозрачные ETA и коммуникации.

Q: Что делать с VIP и высокими лимитами?
A: Обязательный EDD, периодический пересмотр SoF/поведения, жесткий связанный вывод (source-to-source), дополнительные лимиты.

Q: Когда эскалировать в банк/регулятора?
A: При подтвержденных красных флагах/подозрениях согласно юрисдикционным срокам; после консультации MLRO и фиксации evidence.