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

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

1) Мета і область дії

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

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

1. Risk-Based Approach (RBA): перевірки і пороги залежать від профілю ризику (країна, метод оплати, поведінка, суми).
2. Layered Controls: комбінація КУС/санкцій/РЕР, поведінкової аналітики та ручних розслідувань.
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)».
Санкції/РЕР: перевірка при реєстрації, при значущих порогах депозитів/висновків і при зміні реквізитів.
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) Чек-листи

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

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

• Поріг/вікно часу обґрунтовані.
• Є оцінка FP/TP, бізнес-ефект.
• Налаштований моніторинг дрейфу і автотести.
• Оновлено playbook тріажу.
• Проведено рев'ю MLRO/Compliance.

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

Універсальні пороги «для всіх країн» без RBA.
Hold без ЕТА/комунікації, «висять» кейси.
ML-моделі без пояснюваності і журналу версій.
Ручні вивантаження/SAR без evidence-шаблонів і контролю термінів.
Відсутність зв'язку depozit↔vyvod, слабка інтеграція з платежами.
Немає регулярного ретро по помилкових спрацьовувань.

16) 30/60/90 - план впровадження

• Затвердити AML-політику, ролі (MLRO/AML Ops) і RBA-матрицю.
• Запустити базові Controls-as-Code (velocity, src/dst mismatch, gaming pattern).
• Включити KYC tiers + санкції/РЕР, створити шаблони 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.