GH GambleHub

AML-политика и борьба с отмыванием денег

1) Назначение и охват

Цель AML-политики — предотвратить отмывание преступных доходов и финансирование терроризма, обеспечить соответствие требованиям регуляторов и защитить платформу, игроков и партнеров. Политика применяется ко всем юрлицам группы, сотрудникам, аутсорс-командам, а также к третьим сторонам (PSP, аффилиаты, провайдеры контента), взаимодействующим с денежными потоками и данными клиентов.

Охват:
  • Продукты: казино/ставки, P2P-переводы, турниры, бонусы/кэшбек, маркетплейсные услуги.
  • Каналы: веб, мобильные приложения, API-интеграции, крипто-он/офф-рамп.
  • Географии: все обслуживаемые страны/штаты с учетом локальных требований.

2) Нормативная опора и принципы

Основа политики — рекомендации FATF (риск-ориентированный подход, KYC/KYB, санкции, мониторинг, отчетность), локальные законы AML/CFT (Европа — директивы AMLD, Великобритания — MLR, США — BSA/Patriot Act и т. п.), а также требования по защите данных (GDPR/аналогичные).

Базовые принципы:
  • RBA (Risk-Based Approach): ресурсы фокусируются на более высоких рисках.
  • Proportionality: меры соответствуют риску клиента/транзакции/продукта.
  • Accountability: фиксация решений, аудит и трассируемость.
  • Privacy by Design: минимум данных, законность обработки, безопасность.

3) Роли и ответственность (управление)

Board/Совет директоров: утверждает политику, риск-аппетит, периодический отчет.
Senior Management: обеспечивает ресурсы, KPI, внедрение.
MLRO/AML Officer: владелец процесса, отчетность регуляторам, SAR/STR, методология мониторинга, взаимодействие с LEA.
Compliance Team: KYC/KYB, санкции/PEP, кейс-менеджмент, обучение.
Risk & Analytics: модели скоринга, сценарии, калибровка правил.
Engineering/Security: интеграции провайдеров, логи, контроль доступа, шифрование.
Operations/Payments: контроль выводов, ручные проверки, качество данных.

RACI (упрощенно): Board — A, MLRO — R/A, Compliance — R, Risk — R, Eng — C/R, Ops — C/R, Internal Audit — I/C.

4) RBA: модель рисков

Компоненты профиля:
  • Клиент (страна, резидентство, профессия, PEP/санкции, поведенческий риск).
  • Продукт (казино/ставки, P2P, крипто, высокие лимиты, кросс-бордер).
  • Канал (онлайн-онбординг, без присутствия, анонимные инструменты).
  • География (высокорисковые юрисдикции, режимы санкций).
  • Транзакции (объем, скорость оборота, схемы обналичивания).

Оценка: стартовый скор по онбордингу + динамические факторы (история, устройства, платежные паттерны) ⇒ сегментация на низкий / средний / высокий риск и выбор уровня мер: CDD / EDD / SOW.

5) KYC/KYB и санкционный скрининг (связь с AML)

KYC для физических лиц: документ + liveness, адрес, возраст, санкции/PEP, Adverse Media.
KYB для компаний/аффилиатов/провайдеров: регистрация, UBO/директора, санкции/PEP, проверка деятельности и источников средств.
Санкции/PEP: первичный и периодический скрининг, фуззи-матч, ручной клиринг.
SOW/SOF: при высоких лимитах и аномалиях — подтверждение происхождения средств/богатства.
Re-KYC: по расписанию и событийно (триггеры).

6) Мониторинг транзакций и поведенческая аналитика

Сценарии (rules):
  • Быстрый цикл депозит → вывод без реального игрового риска.
  • Спайки по суммам/частоте, дробление платежей («smurfing»).
  • Несовпадение страны IP/BIN/адреса, частая смена методов оплаты.
  • Нетипичный ночной/массовый трафик, кластеры устройств (device graph).
  • Использование анонимайзеров/VPN, прокси-ферм, подмены ОС/браузера.
  • Подозрительные бонусные паттерны, мультиаккаунтинг, чарджбек-циклы.

ML/поведенческие модели: вероятностные аномалии, графовые связи, риск-скор игроков/аффилиатов, сегментация high-roller.

Кейс-менеджмент: генерация алерта → квалификация → запрос документов/объяснений → решение (эскалация/блокировка/SAR).

7) «Красные флаги» (iGaming-специфика)

Регулярные депозиты от третьих лиц/много единичных карт на одного игрока.
P2P/турнирные переводы между связанными аккаунтами.
Сильное рассогласование профилей (возраст, профессия vs оборот).
Миграция между юрисдикциями без объяснимой причины.
Систематическое обналичивание без игровой активности или с минимальной маржей.
Попытки обойти лимиты KYC/выводов/бонусов, «фермы» аккаунтов.
Афилиаты с неясным источником трафика или аномально высоким CR→WD.

8) SAR/STR: внутренние расследования и отчетность

Порог подозрения: «обоснованное подозрение» независимо от суммы.
Процесс: алерт → сбор фактов → решение MLRO → подача SAR/STR в срок, без «tipping-off».
Эскалации: временная блокировка, заморозка средств по требованию LEA/регулятора, план коммуникации с клиентом.
Документирование: таймлайн событий, источники данных, действия команды, решения и обоснование.

9) Хранение данных и безопасность

Сроки: как правило, не менее 5 лет после прекращения отношений (уточняются локально).
Целевое хранение: профили, документы, алерты, SAR/STR, журнал доступа, доказательная база.
Безопасность: шифрование at-rest/in-transit, HSM/секрет-хранилище, RBAC/ABAC, неизменяемые журналы (WORM), мониторинг доступа и действий сотрудников.

10) Обучение, контроль качества и аудит

Обучение: ежегодное для всех, углубленное — для сотрудников риск-функций; тесты и сертификация.
QA/диагностика: выборочные ревью кейсов, двойные проверки (4-eyes), ретро по ошибочным решениям.
Внутренний аудит: независимая оценка соответствия политике, регуляторным требованиям и эффективности процессов.
Stress-tests: упражнения по инцидентам (санкции, большая типология, массовые алерты).

11) Крипто и VASP (если применимо)

Travel Rule: обмен атрибутами отправителя/получателя между провайдерами.
Blockchain-аналитика: риск-скор адресов, кластера, санкционные/миксер-метки.
Он/офф-рамп контроль: соответствие владельца кошелька, совпадение данных, лимиты и журнал внешних адресов.
Динамика цен/волатильность: специальные правила по суммам, маркировка «необычных» конвертаций.

12) Взаимодействие с третьими сторонами

PSP/банки/провайдеры KYC: договоры, SLA, DPIA, тест-планы отказоустойчивости.
Аффилиаты: KYB, мониторинг качества трафика, запрет риск-источников, аудит пост-клика.
Корреспондентские отношения: углубленная проверка партнеров, периодический обзор.

13) Архитектура AML-решения (рекомендации)

Интеграции: провайдеры KYC/санкций, PSP, антифрод, блокчейн-аналитика.
Шина событий: все транзакции/события попадают в поток (Kafka/аналог) с неизменяемым хранилищем.
Движок правил + ML: онлайн-скоринг (миллисекунды) и офлайн-пересмотры (батч/near-real-time).
Кейс-система: очереди с приоритизацией, шаблоны запросов клиенту, SLA, интеграция с почтой/мессенджерами.
Наблюдаемость: логи, метрики, трассировки; версия правил/моделей и их эффект.
Деградация: безопасное упрощение (fail-open/close по политике), бэкап-провайдеры, ретраи/кворум.

14) Метрики и KPI эффективности

SAR Conversion Rate: доля алертов, ставших SAR/STR.
Time-to-Alert / Time-to-Decision: скорость детекта и решения.
False Positive Rate / Precision-Recall в алертах.
Coverage: доля транзакций, прошедших мониторинг/скрининг.
Rework/Appeals: доля кейсов с пересмотром решения.
Training Completion: % сотрудников с актуальным обучением.
Vendor SLA: аптайм провайдеров, TTV по KYC/санкциям.

15) Чек-листы

Онбординг клиента:
  • KYC/KYB, возраст/гео, санкции/PEP, Adverse Media.
  • RBA-скоринг, базовые лимиты, фингерпринт устройства.
  • Согласия, приватность, информирование о проверках.
Перед крупным выводом/высоким лимитом:
  • Повторный санкционный скрининг, SOF/SOW при необходимости.
  • Сопоставление владельца платежного инструмента.
  • Поведенческая проверка и история транзакций.
SAR/STR-процесс:
  • Сбор фактов и документов.
  • Внутреннее заключение MLRO.
  • Подача отчета в срок; запрет tipping-off.
  • Пост-морем, обновление правил/моделей.

16) Типичные ошибки и как их избегать

Слепая «галочка» KYC без RBA: усиливайте динамическую аналитику и лимиты.
Отсутствие обратной связи в моделях: внедрите петлю обучения (decision → outcome).
Сверхжесткое «дерискинг» вместо управления риском: используйте EDD/SOW и контролируемые лимиты, а не тотальные баны.
Неучет региональных правил/санкций: поддерживайте «гео-профили».
Слабый журнал решений: стандартизируйте обоснования и хранение артефактов.

17) Шаблон структуры AML-политики (для вашей wiki)

1. Введение и область действия

2. Определения и термины (AML/CFT, CDD/EDD, SOF/SOW, PEP и т. д.)

3. Нормативная база и ссылки на локальные законы

4. Управление и роли (Board, MLRO, RACI)

5. RBA-методология и риск-аппетит

6. KYC/KYB и санкционный скрининг

7. Мониторинг транзакций (rules + ML) и кейс-менеджмент

8. «Красные флаги» и сценарии iGaming

9. SAR/STR-процедуры и взаимодействие с регуляторами/LEA

10. Хранение данных, приватность, безопасность

11. Обучение персонала и осведомленность

12. Вендоры и третьи стороны (SLA, аудит)

13. Аудит, QA и непрерывное улучшение

14. Приложения: чек-листы, формы, шаблоны писем, метрики

18) Пример матрицы рисков (фрагмент)

ФакторНизкийСреднийВысокий
ГеоНизкорисковая юрисдикцияСмешанный профильВысокорисковая/санкционная
ПродуктF2P/низкие лимитыКазино/ставки со средними лимитамиP2P/крипто/высокие лимиты
КлиентСтабильные доходы, без PEPНесоответствия, тонкий файлPEP/Adverse Media/аномалии
ТранзакцииРовныеСпайки, дроблениеБыстрые циклы cash-out, третьи лица

Результат: низкий/средний/высокий риск → меры: CDD / EDD + SOF/SOW / ограничения/выход.

19) План внедрения и поддержания

Определить владельцев процессов и SLA.
Карта интеграций (PSP, KYC, санкции, аналитика).
Запуск с базовым набором правил + контроль FP/FN.
Ежеквартальная калибровка сценариев, ежегодный пересмотр политики.
Учебные программы и контроль прохождения.
Регулярные отчеты Board/менеджменту (KPI, инциденты, изменения в рисках).

Итог

Эффективная AML-политика — это не «документ на полке», а живой цикл: рисковая оценка → меры контроля → мониторинг → расследование → отчетность → улучшения. Постройте процесс вокруг RBA, обеспечьте сильный KYC/KYB и санкционный контур, внедрите качественный мониторинг транзакций с кейс-менеджментом и соблюдайте дисциплину хранения данных, обучения и аудита — так вы снизите регуляторные и репутационные риски, сохранив при этом конверсию и устойчивость бизнеса.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.