GH GambleHub

Звітність по AML і KYC

1) Призначення та охоплення

Мета: забезпечити відтворювану, перевіряється і своєчасну звітність по AML/KYC для всіх юрисдикцій і партнерів (банки, PSP, провайдери KYC/KYB), знизити ризик штрафів/блокувань і зміцнити контрольні функції.
Охоплення: онбординг гравців і партнерів (KYC/KYB), санкції/РЕР, моніторинг транзакцій, EDD, SAR/STR, джерела коштів (SoF/SoW), RG-сигнали, зберігання і доступ до PII, інциденти і повідомлення.


2) Класифікація звітів і частоти

1. Регуляторні: зведення щодо онбордингу, алертів санкцій/РЕР, SAR/STR, скарг, вжитих заходів.

Частоти: щомісяця/квартально; інцидентні звіти - у встановлені терміни (наприклад, ≤72 ч).

2. Банки/PSP: обсяги транзакцій, чарджбеки, підозрілі патерни, EDD-кейси.

Частоти: щотижня/щомісяця, за запитом - ad hoc.

3. Внутрішні: KRIs/KPIs, воронки KYC, FPR/FNR, SLA провайдерів, статуси кейсів AML.

Частоти: денні дашборди, тижневі комітети, місячні ретроспективи.

4. Вендори/аутсорс: якість і SLA КУС/санкційних провайдерів, відмовостійкість, хибнопозитивні.

Частоти: щомісяця, квартальні огляди.


3) Єдина структура даних (мінімум полів)

Cubject (гравець/партнер): subject_id, тип (player/partner), країна, віковий статус (18 +), risk_score, kyc_level, pep_flag, sanctions_flag, soe/sow_status.
Документи KYC: doc_type, doc_number_hash, issuer_country, expiry_date, liveness_passed, verification_provider, verification_result, confidence_score.
Транзакції: tx_id, ts, amount, currency, method, psp, device_id, ip_geo, velocity_flags, rule_hits[].
Алерти AML: alert_id, rule_id, severity, reason_codes[], owner, status, opened_at, closed_at, action_taken (EDD/SAR/STR/block/none).
Санкції/РЕР: list_version, hit_type (sanctions/pep/adverse media), match_score, disposition (true/false positive), reviewer_id.
Журнал доступу до PII: actor, action (view/export/delete), dataset, ts, purpose, ticket_id.

💡 Вимога: поле data_lineage для кожного звітного набору (джерело → трансформації → споживач), контроль версій схем.

4) KRIs/KPIs для звітності

KYC:
  • KYC pass rate, KYC fail%, Liveness dropout%, Avg TAT (хв/год), FPR/FNR моделей.
Санкції/РЕР:
  • Hit-rate на 1k онбордингів, FPR%, Dispo TAT, частка вторинних перевірок.
AML/Транзакції:
  • Alerts per 10k tx,% ескалацій в EDD, SAR/STR per 10k active, Conversion alert→action.
Вендори та SLA:
  • Аптайм провайдера, середній latency API,% ретраїв, частка недоступності> X хв.
Якість даних:
  • % пропусків обов'язкових полів, дублі, розбіжності otchet↔bukhuchet, success rate денного ETL.

5) Контроль якості та звірки

DQ-правила: not null/формат/діапазони/референси; SLA по виправленню.

Звірки (reconciliation):
  • Регістри онбордингу vs KYC-провайдер,
  • Транзакції DWH vs звіти PSP/банк,
  • SAR/STR реєстр vs відправлені повідомлення,
  • Списки санкцій версія N vs N-1 (дельти).
  • Доказовість: хеш-суми вивантажень, журнали перерахунків, незмінні логи (WORM/об'єктне сховище).

6) Стандартні форми звітів (шаблони)

6. 1 Регуляторне зведення AML/KYC (щомісяця)

ПоказникЗначенняΔ до минулого місяцяПорігСтатус
Нові онбординги48,210+7%
KYC fail %11. 2%+1. 3 п.п.12%
Sanctions/PEP hit-rate2. 1%+0. 4 п.п.3%
Alerts per 10k tx37−5≤50
EDD share of alerts14%+ 2 п.п.≤20%
SAR/STR filed28+6
Avg TAT (KYC)9. 6 хв−1. 1≤12

Порушення/інциденти: 0 критичних, 1 середній (латентність KYC-провайдера 18 хв).
Вжиті заходи: активований fallback, оновлені velocity-правила.

6. 2 Звіт для банку/PSP (щомісяця)

Обсяг депозитів/висновків по платіжних каналах, chargeback rate, підозрілі патерни, список заблокованих акаунтів/пристроїв (хеші), заходи EDD/hold.

6. 3 Внутрішній звіт по санкціях/РЕР (щотижня)

ТижденьОнбордингиHit-rate %FPR %Dispo TAT (м)Версія списків
2025-W4311,9822. 09. 142OFAC 2025. 10. 21 / EU 2025. 10. 18

7) Робочі процеси (SOP) і RACI

7. 1 SOP: Щомісячний регуляторний звіт

1. Старт ETL T + 1 02:00 → 2) DQ-валідації → 3) Звірки з PSP/DWH → 4) Підготовка PDF/CSV/JSON → 5) Юридичний рев'ю → 6) Підпис/відправка → 7) Архів/хеш/журнал.
RACI: Responsible — Compliance Analyst; Accountable — Head of Compliance; Consulted — Legal, DPO, Payments, Security; Informed — C-level.

7. 2 SOP: SAR/STR

Тригери (rule/machine-learning/ручний), EDD-перевірка, рішення (file/not), файлінг, підтвердження отримання, оновлення реєстру, наступні заходи (hold/блок/повідомлення банку/регулятору).

7. 3 SOP: Інцидент КУС/санкцій

FPR> порогу або деградація SLA → інцидент-бридж → включення другого провайдера → калібрування правил → звіт про інцидент (TTR/причина/заходи).


8) Автоматизація: архітектурний контур

Збір: CDC/стрім з прод-БД, webhooks КУС/санкцій, PSP-SFTP, лог-колектори.
Сховище: Data Lake (RAW → CURATED), DWH (reporting marts: aml_alerts, kyc_events, sanctions_hits, psp_recon).
Обробка: оркестратор (Airflow/Argo) з SLA/ретраями, policy-as-code для агрегатів.
SOAR: плейбуки for SAR/EDD, авто-ескалації при порогах, тікети і повідомлення.
Каталог даних/lineage: автоматичне покоління схем і залежностей, версії звітів.


9) Агрегації та приклади реалізацій

9. 1 SQL-приклад (псевдо)

sql
-- Sanctions/PEP weekly hit-rate with FPR
SELECT date_trunc('week', screening_ts) AS week,
COUNT() FILTER (WHERE hit = true) 100.0 / COUNT() AS hit_rate_pct,
COUNT() FILTER (WHERE hit = true AND disposition = 'false_positive') 100.0
/ NULLIF(COUNT() FILTER (WHERE hit = true),0) AS fpr_pct
FROM sanctions_screenings
WHERE screening_ts >= current_date - interval '90 day'
GROUP BY 1
ORDER BY 1 DESC;

9. 2 JSON-схема вивантаження SAR/STR (спрощено)

json
{
"report_id": "SAR-2025-000128",
"filed_at": "2025-11-01T10:42:12Z",
"subject": {"id":"player_9f4a", "country":"EE", "risk_score":82},
"transactions": [{"tx_id":"T123", "amount":950.00, "currency":"EUR", "ts":"2025-10-28T21:10:00Z"}],
"reasons": ["velocity_withdrawals", "device_cluster"],
"actions": ["hold","EDD","bank_notification"],
"attachments": ["/evidence/aml/SAR-2025-000128.pdf"],
"confidentiality":"restricted"
}

10) Порогові значення та ескалації (орієнтири)

Sanctions/PEP hit-rate: > 3% - ескалація; FPR%: > 12% - інцидент калібрування.
KYC fail %: > 15% добу - включити fallback/ручний потік VIP.
Dispo TAT: > 48 год - перерозподіл кейсів і пріоритизація high-value.
SAR/STR per 10k active: стрибок> × 2 до медіани - термінова ревізія правил/кампаній.
ETL success: <99% - аналіз причин, звіт SRE/Compliance.


11) Зберігання, доступ і аудит

Retention: звіти та реєстри - не менше X років (встановлюється політикою); SAR/STR - відповідно до юрисдикції (зазвичай довше).
PII-контроль: мінімізація полів, псевдонімізація subject_id, доступ за принципом найменших привілеїв, обов'язкові audit logs переглядів/експортів.
Експорт: білі списки одержувачів; всі вивантаження підписуються і хешуються; WORM-сховище для фінальних версій.


12) Управління змінами (Change/CAB)

Зміни у звітних метриках/правилах проходять CAB: бізнес-опис, вплив на KRIs, тестові вибірки, A/B на sandbox, дата включення, план відкату.
Версійність звітів: report_version, changelog, порівняльні таби (v-1 vs v).


13) Вендори та договірні зобов'язання

Перед онбордингом: due diligence (санкції/РЕР на бенефіціарів, ISO/SOC2, DPIA/DTIA, DPA/SCCs).
В експлуатації: квартальні перевірки SLA, тестові алерти, звірка логів, фіксація субпроцесорів.
Offboarding: відкликання ключів/доступів, видалення/повернення даних, акт закриття та звіт про повноту видалення.


14) Ролі та взаємодія

Head of Compliance (A): затвердження звітів, ризик-апетит.
Compliance Analyst (R): збір/валідація/звірки/формування звітів.
DPO/Legal (C): законність обробки, повідомлення.
Payments/FRM (C): транзакції, chargebacks, антифрод.
Security/SRE (C): інциденти, доступи, логування, стабільність ETL.
Data/BI (R): моделі, вітрини, дашборди.
Support/VIP (I): комунікації за кейсами RG/EDD.


15) Дашборди і візуалізація (мінімум віджетів)

KYC Funnel: реєстрації → KYC init → pass/fail → SoF/SoW пройдено.
Sanctions/PEP: hit-rate/FPR/TAT, версія списків, частка вторинних перевірок.
AML Alerts: за правилами/сегментами/регіонами; conversion alert→action; EDD частка.
SAR/STR: динаміка filings, причини, share за платіжними методами.
SLA провайдерів: аптайм, latency, ретраї, інциденти.
DQ & ETL: помилки, пропуски, успіхи пайплайнів, «світлофор» якості.


16) Чек-лист готовності звіту

  • Сформовано набір даних з lineage і версіями схем
  • Пройдені DQ-валідації і звірки
  • Підтверджені KRIs/KPIs і пороги
  • Рев'ю Legal/DPO завершено
  • Підписано/захешовано/заархівовано
  • Розісланий адресатам, логи доставки збережені

17) Додатки (шаблони)

17. 1 Картка SAR/STR (реєстр)

ID, дата, суб'єкт, країни/методи, сума, причини (rule_ids), EDD-заходи, рішення, дата файлінгу, підтвердження, відповідальні, посилання на докази.

17. 2 Шаблон щомісячного звіту KYC (CSV)


month;country;onboardings;kyc_pass;kyc_fail;avg_tat_min;liveness_dropout_pct;provider_sla_uptime;notes
2025-10;EE;14320;12688;1632;9.6;3.1;99.92;fallback activated 10/21

17. 3 Шаблон звіту по санкціях/РЕР (CSV)


week;onboardings;screened;hits;fpr_pct;dispo_tat_min;list_ofac;list_eu;list_uk
2025-W43;11982;11982;252;9.1;42;2025-10-21;2025-10-18;2025-10-19

TL; DR

Стабільна AML/KYC-звітність = стандартизована схема даних + строгі DQ/звірки + зрозумілі KRIs/KPIs і пороги + автоматизація ETL/SOAR + прозорий RACI і зберігання/аудит. Це знижує регуляторні ризики, прискорює реакції на загрози і підтримує стійкість iGaming-бізнесу.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.