Операції та Комплаєнс → Санкційний скринінг та PEP-фільтрація

Санкційний скринінг і PEP-фільтрація

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

Знизити юридичні/фінансові ризики та забезпечити відповідність ліцензіям: відсіяти санкційних осіб/організації, виявляти PEP і пов'язаних осіб, враховувати негативні медіа і вживати пропорційних заходів. Застосовується до гравців (KYC), партнерів (KYB), провайдерів і співробітників з доступом до ПДн/фінансів.

2) Терміни та охоплення

Sanctions (санкції): заборони/обмеження на взаємодію з особами/організаціями/судами/судами.
PEP (Politically Exposed Person): публічні посадові особи та їх найближчі пов'язані особи (RCA).
Adverse media: суттєво негативні публікації (фінзлочини, корупція тощо).
Match: збіг запису профілю з елементом списку (точний/імовірнісний).
RCA (Relatives & Close Associates): чоловік (а), діти, партнери по бізнесу та ін.

3) Принципи

1. Risk-Based Approach (RBA): глибина перевірки і частота залежать від профілю ризику (країна, метод оплати, суми, роль).
2. Explainable Matching: правила порівняння прозорі; зберігається обґрунтування рішення.
3. Evidence-by-Design: кожне «попадання/непотрапляння» супроводжується артефактами.
4. Privacy-first: мінімум ПДн, суворі доступи, ретеншн за законом.
5. Continuous Screening: події → негайний рескрининг; періодично - батч-перевірки.
6. One Source of Truth: єдиний реєстр результатів скринінгу та рішень (audit trail).

4) Джерела та оновлення

Санкційні та контрольні списки: глобальні/регіональні/національні; галузеві/територіальні; списки перевізників/суден (при необхідності).
PEP/RCA: багаторівневі (національні/регіональні/міжнародні).
Adverse media: агреговані джерела з категоризацією ризиків.
Оновлення: щоденні/щотижневі; зберігайте версію довідника і час завантаження.

5) Політика скринінгу (каркас)

Коли перевіряємо: реєстрація, перед першим депозитом/висновком, при зміні платіжних реквізитів, досягненні порогів обороту, при зміні профілю/адреси/документа, при оновленні списків.
Кого перевіряємо: гравці (KYC), партнери/провайдери (KYB), співробітники з доступами (HR/KC).
Що робимо при збігах: тріаж → підтвердження/виключення/ескалація → заходи: відмова/hold/EDD/закриття.

yaml policy_id: SANC-PEP-POL-001 scope: players, partners, employees triggers:
- on_event: signup, pre_deposit, pre_payout, kyc_update, payout_destination_change
- on_list_update: sanctions    pep    adverse_media risk_bands:
low: [EU_ trusted methods]
high: [high_risk_geo, multiple_payment_methods, turnover>threshold]
actions_by_match:
sanctions_confirmed: block_all & report & freeze_payouts pep_confirmed: edd & enhanced_monitoring adverse_media_high: manual_review & edd review_sla_days: 180 owner: head_of_compliance

6) Алгоритми зіставлення (matching)

Точне зіставлення: ПІБ + ДР/документ/країна.
Fuzzy-зіставлення: токенізація, нормалізація, транслітерація/аліаси, відстані рядків; фонетика (наприклад, Soundex/Metaphone-подібні).
Контекстні ваги: дата народження> громадянство> адреса> аліаси> країна.
Зниження помилкових збігів: «must-have» поля, пороги схожості за типами імен, ігнор частих слів.
Чутливість по гео: для high-risk гео - нижче поріг на fuzzy-швидкому.
Білі списки із закінченням: тимчасові виключення (whitelist) з причиною і терміном.

7) Тригери рескринінгу

Оновлення версії списків.
Події профілю: зміна ПІБ/адреси/документа, новий метод виводу.
Порогові суми/оборот, підвищення лімітів, VIP-статус.
Сигнали AML/Risk: velocity, невідповідність source-to-source, device/IP аномалії.

8) Інтеграції та дані

KYC/KYB: провайдери IDV/док-перевірок/реєстрів; UBO/директора у партнерів.
Payments: блок «pre-payout» і узгодження hold/реверсів.
Case-management: картки матчів, статус і журнал рішень.
DWH/BI: вітрини по hit-rate/precision/дрейфу якості.

9) Controls-as-Code (фрагменти)

yaml control_id: SANC-PEP-SIGNUP scope: player_profile trigger:
expr: event in {signup, pre_deposit, pre_payout}
actions:
- screen: sanctions    pep    adverse_media
- block: payout if match_score>=0. 85 until triage_done evidence:
fields: [list_version, query_payload, top_matches]
owner: compliance_ops

yaml control_id: SANC-PEP-RESCREEN scope: population trigger:
expr: sanctions_list. version_changed==true OR pep_list. version_changed==true actions:
- enqueue: rescreen_batch(population_segments=[high_risk, active_payouts])
- notify: compliance_channel

yaml control_id: PEP-MONITOR-01 scope: players trigger:
expr: pep_status==confirmed actions:
- require: edd & source_of_funds
- monitor: payouts frequency>=weekly
- set: limits=pep_limits_schema

yaml control_id: ADV-MEDIA-HI scope: players    partners trigger:
expr: adverse_media. severity in {high, severe}
actions:
- flag: manual_review
- limit: payouts "hold_24h"
- collect: additional_evidence

10) SOP (фрагменти)

SOP: Тріаж збігу санкцій/РЕР

1. Перевірити контекст: ПІБ/ДР/громадянство/аліаси/документ.
2. Звірити джерела (id записи, дата оновлення, правовий статус).
3. Рішення: `confirmed / false_positive / inconclusive`.
4. Для'confirmed': застосувати заходи (block/EDD/report), зафіксувати обґрунтування.
5. Для «inconclusive»: запитати додаткові дані (документ/підтвердження адреси).
6. Закрити кейс, оновити whitelist/blacklist (якщо застосовується), додати evidence.

SOP: Рескринінг при оновленні списків

1. Автоматичний запуск батча, сегменти: активні виплати, high-risk.
2. Звіт про нові матчі, SLA розподілу кейсів.
3. Побічно пов'язані акаунти (RCA) - в окрему чергу.

SOP: Комунікація з гравцем/партнером

1. Нейтральні формулювання, без розкриття внутрішніх критеріїв.
2. Терміни та перелік запитуваних документів (якщо потрібен EDD).
3. Фіксація комунікацій в кейсі, нагадування і дедлайни.

11) Приватність, безпека, аудит

RBAC/ABAC: доступ до деталей матчів і документів - тільки у Compliance/MLRO.
Ретеншн: зберігати результати та evidence за юрисдикційними термінами; авто-очищення.
Шифрування: in transit/at rest; ключі в HSM/Vault.
Аудит: журнал читань/рішень, версії правил/порогів, результати автотестів.

12) Дашборди і метрики

Screening Overview: обсяг перевірок, hit-rate за сегментами, частка fuzzy.
Quality: Precision/Recall підтверджених кейсів, False Positive Rate, Time-to-Triage (P50/P95).
Latency: час відповіді провайдерів, черга рескринінгу.
Drift: зміна розподілів імен/гео, зростання частки невпевнених збігів.
Compliance: дотримання SLA за звітами та ескалаціями.

• Precision по санкціях ≥ 95%, по PEP ≥ 90%.
• Time-to-Triage (P95) ≤ 24 ч (санкції), ≤ 48 ч (PEP/adverse).
• False Positive Rate ↓ QoQ без втрати Recall.
• SLA рескринінгу при оновленні списків ≥ 98% вчасно.
• Evidence Completeness ≥ 98%.

13) Чек-листи

• Джерела списків підключені, версії логуються.
• Політика RBA затверджена, пороги fuzzy узгоджені.
• Тріаж-процес і ролі (Compliance/MLRO) призначені.
• Інтеграції: KYC/KYB/Payments/Case-tool.
• Дашборди і алерти розгорнуті.

• Зіставлені ключові поля (ПІБ/ДР/громадянство/аліаси).
• Перевірені джерела і дата запису.
• Рішення та заходи зафіксовані; повідомлення надіслано.
• Evidence додані, whitelist/blacklist оновлений (якщо потрібно).

• Автотести правил/порогів пройшли.
• Щоквартальний аудит рішень (семплювання).
• Drift-моніторинг в нормі; пороги переглянуті.

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

«Один поріг для всіх» без урахування гео і якості даних.
Відсутність журналювання версії списків і підстав рішення.
Постійні permanent whitelist без закінчення терміну і причини.
Дві версії правди: Excel-рішення і окремі логи в проді.
Необґрунтовані затримки виплат без ETA і комунікацій.
Вимкнений рескринінг при оновленнях списків.

15) 30/60/90 - план

• Затвердити політику SANC-PEP, пороги matching, ролі і SLA.
• Підключити провайдерів списків; логування'list _ version'.
• Включити три базових контролю: `SIGNUP`, `PRE_PAYOUT`, `RESCREEN`.
• Розгорнути кейс-менеджмент, дашборди та evidence-сховище.

• Додати RCA/адверс-медіа, сегменти high-risk і VIP.
• Оптимізувати fuzzy (транслітерації/аліаси), знизити FPR ≥ 20%.
• Автоматизувати рескринінг за подіями та оновленнями списків.
• Включити семплювання якості і квартальні аудити.

• Досягти цільових KPI Precision/Recall і Time-to-Triage.
• Інтегрувати з AML (EDD/SoF) і payout-гейтами (source-to-source).
• Включити KPI в OKR команд, провести зовнішній/внутрішній аудит.

16) FAQ

Q: Як відрізнити однофамільця від справжнього збігу?
A: Використовуйте підтверджуючі поля (ДР/документ/громадянство), контекст по гео і аліаси; для прикордонних - ручний тріаж з порогом впевненості.

Q: Чи потрібно скринити афіліатів і їх UBO?
A: Так. KYB обов'язковий: UBO/директора + санкції/РЕР + негативні медіа; при зміні UBO - ре-вера і рескринінг.

Q: Що робити при підтвердженій санкції?
A: Негайний блок, freeze виплат, повідомлення регуляторам/банкам за вимогами юрисдикції, збереження повного пакету evidence.

Q: Навіщо adverse media, якщо є санкції?
A: Часто це ранній сигнал ризику (до санкцій). Використовуйте для EDD/моніторингу та превентивних обмежень.