KYC/AML-інтеграція з провайдерами перевірки

1) Навіщо це потрібно і які KPI важливі

Цілі: відповідність вимогам регуляторів, запобігання шахрайству/відмиванню, зниження чарджбеків і ризиків партнерів/платіжок при мінімумі тертя.

Ключові метрики:

Approval rate (за сегментами ринку/платіжками/VIP), FPR/FNR, час онбордингу (p95), вартість перевірки на гравця.
Hit-rate за санкціями/PEP/Adverse Media, частка ручних кейсів, відсоток незавершених перевірок.
SLA провайдера (аптайм, latency, p95 відповіді), ретраї/помилки інтеграції.

2) Базова архітектура інтеграції

Шари:

1. Orchestrator (ваш сервіс risk-onboarding): роутит запити між провайдерами за правилами/країнами/типами перевірки.

2. Providers SDK/API: KYC (ID + Liveness), AML (санкции/PEP/Adverse Media), Address, Age, Device.

3. Feature Store / Risk Engine: зберігає результати, прапори, фічі для скорингу та антифроду.

4. Case-менеджмент: ручні перевірки, апеляції, second-line review.

5. Audit & Compliance: незмінювані логи рішень, версіонування правил/моделей, звіти регулятору.

Потоки подій:

Registration → Age/ID (мінімальний KYC по юрисдикції).
First Deposit/Withdrawal → Enhanced Due Diligence (EDD за сумами/ризиками).
Recurring AML Screening: перезапит санкцій/РЕР за розкладом (щодня/щотижня).
Trigger-based: зміна реквізитів/пристрою/гео → re-screen.

3) Типи перевірок і що саме вони роблять

Document Verification: паспорт/ID/вод. посвідчення/посвідка на проживання; OCR + MRZ/Barcode, чек автентичності.

Liveness & Biometrics: активний/пасивний liveness, face-match (selfie↔document).

Address Verification: proof of address (utility bill/банківська виписка), іноді - реєстри адрес.

Sanctions/PEP/Watchlists: OFAC/UN/EU/UK HMT + локальні; політично значущі особи; списки небажаних ЗМІ/судові хроніки (Adverse Media).

Age Verification: дата народження vs локальні пороги.

Device/Email/Phone: ризик-сигнали (одноразові домени, віртуальні номери, проксі/хостинг).

KYB (для партнерів/мерчантів): статутні документи, бенефіціари (UBO), реєстраційні реєстри, негативні новини.

4) Оркестрація і ризик-базований підхід

Правила маршрутизації: країна документа → провайдер A, якщо немає покриття → провайдер B; VIP/висока сума → EDD-пакет.

Step-up логіка: soft-чек (джерела даних) → при ризику запитуємо селфі/документи.

Композиція: комбінація AML screening + IDV + Address залежить від юрисдикції (MGA/UKGC/Curacao та ін.) і стадії життєвого циклу (onboarding vs payout).

Re-screening: періодичний (наприклад, щодня за санкціями) і подієвий (зміна країни/документа).

5) Дизайн API та інтеграційні патерни

Идempotency & retries: всі виклики - з ключем ідемпотентності; експоненціальні ретраї, таймаути, circuit-breaker.

Вебхуки: асинхронні статуси (processing → completed → reviewed).

Валідація введення: контроль формату (MRZ, ISO country, документ-тайпи).

Зберігання артефактів: шифрування, TTL/retention по юрисдикціях, доступ за принципом «мінімально необхідного».

Приклад запиту (псевдо):

http
POST /kyc/start
{
"user_id": "u_123",  "flows": ["IDV","AML"],  "country_hint": "DE",  "document_types": ["PASSPORT","NATIONAL_ID"],  "webhook_url": "https://risk. example. com/webhooks/kyc"
}

Відповідь провайдера:

json
{
"session_id": "sess_abc",  "status": "pending",  "redirect_url": "https://provider/flow/sess_abc"
}

Вебхук-підсумок:

json
{
"session_id": "sess_abc",  "status": "approved",  "checks": {
"idv": {"liveness": "pass", "face_match": 0. 92, "doc_authenticity": "pass"},   "aml": {"sanctions": "clear", "pep": "clear", "adverse_media": "none"}
},  "risk_score": 18
}

6) Якість даних: типові проблеми та рішення

Транслітерація/варіативність імен: використовуйте фонотичні алгоритми, нормалізацію, alias-таблиці.

Не-латинські скрипти: порівняння імен в кирилиці/арабській в'язі/ханзі → локальні модулі порівняння.

Дата народження/адреса: форматування, крос-перевірка з документом і платіжною адресою (BIN/AVS).

Помилкові збіги в санкціях/РЕР: налаштування fuzzy-score і правил ескалації (молоді тезки, часті прізвища).

Якість фото: підказки UX (світло, рамка, відблиски), автоматичний контроль різкості/кута.

7) SLA, спостережуваність і алерти

Latency цілі: інтерактивний онбординг ≤ 60-120 мс на запит до каталогу/скринінгу + асинхронні кроки ≤ 2-3 хв (документи).

Аптайм: ≥ 99. 9% на критичні ендпоінти; подвійний провайдер (active-active/active-standby).

Алерти: зростання'error _ rate', деградація'hit _ rate', стрибок'review _ rate', «тихі вікна» вебхуків, затримки OCR/Liveness.

Логи/трейсинг: correlation-ID від фронту до провайдера; masked payloads; зберігання рішення і причин.

8) Управління випадками (Case management)

Черга кейсів: пріоритет за сумою/ризиком/регіоном.

Плейбуки: що запитувати у клієнта (селфі повторно, інший документ, proof of address).

SLA по ручних кейсах: p95 ≤ 24 год; high-value ≤ 2 ч.

Апеляції: повторний матч + незалежний reviewer; документування причин відмови (adverse action notice).

9) Комплаєнс і приватність

GDPR/локальні аналоги: purpose limitation, data minimization, право на доступ/видалення (де застосовується).

PCI DSS: якщо зачіпаються платіжні дані.

PSD2/SCA: кореляція з сильною автентифікацією на платіжних кроках.

Retention: зберігати тільки необхідні артефакти і тільки стільки, скільки вимагає закон/регулятор.

Explainability: фіксуйте «decision rationale» - на що спиралася система (liveness fail, doc mismatch, PEP hit).

10) Вартість і модель закупівлі

Pricing: per-check, пакетні тарифи, регіональні коефіцієнти, доплати за EDD/Adverse Media.

Оптимізація: ризик-базована оркестрація (дешевий провайдер → дорогий при фолбеку), кешування результатів на TTL, re-screen по дельті.

RFP-чек-лист: покриття за документами/країнами, точність liveness/face-match, частота оновлення санкцій/РЕР, latency, вебхукі, SDK, звіти, DPIA/сертифікації, on-prem варіанти, судова/регуляторна практика, референси з iGaming.

11) KYB: коли ви працюєте з В2В/партнерами

Регістри: Companies House, місцеві торгові реєстри, UBO-ланцюжки.

Документи: інкорпорація, статут, банківські листи, директори/довіреності.

Скринінг: санкції/РЕР для UBO і директорів, Adverse Media по бренду/юридичній особі.

Тригери re-screen: зміна директора/адреси/бенефіціара, різке зростання оборотів.

12) UX і конверсія: як не «зламати» онбординг

Mobile-first: SDK з автопідказками (рамка, нахил, бліковий захист).

Гайд для користувача: що готувати заздалегідь (документ, освітлення), скільки часу займе процес.

Прогрес-бар і чіткі статуси.

Graceful fallback: якщо камера/датчики недоступні → альтернативний потік (manual upload + подальша верифікація).

13) Інциденти і фолбеки

Fail-safe режим: при падінні провайдера - перемикання на резерв + застосування мінімально достатніх правил.

Degradation policy: дозволяємо тільки депозити малого ліміту без виведення до завершення перевірки.

Відкладена верифікація: видача тимчасових лімітів з позначкою про необхідність доверифікації.

14) Тестування та сертифікація інтеграції

Пісочниці провайдерів: скрипти «щасливих «/« нещасливих »шляхів, edge-кейси (відблиски, обрізаний документ, близнюки).

Contract-тести: фіксація схеми відповіді, міграції версій API.

Навантажувальне: пік релізів/промо (x5-x10 трафік), довгі вебхуки, reorder подій.

DR-навчання: відключення одного провайдера, падіння вебхуків, rollback версії.

15) Типові правила прийняття рішень

Приклад decision-table (спрощено):

Умова	Дія	Коментар
Sanctions=hit (strong match)	DENY	Ескалація в комплаєнс, звіт
PEP=possible + Adverse=negative	REVIEW/EDD	Доп. джерела коштів
Liveness=fail или FaceMatch<0. 8	RETRY (1-2 рази) → REVIEW	UX-підказки
Address=fail + High-risk country	HOLD	Proof of address повторно
Clean KYC/AML + Low risk score	APPROVE	Ліміти з політики

16) Приклад повного кейса (скорочено)

Сценарій: новий гравець з Німеччини, депозит €300, запит на бонус.

1. Soft check (AML fast): clear.

2. IDV: паспорт + selfie, liveness = pass, face_match=0. 93, doc=authentic.

3. Address: utility bill пройдено.

4. Decision: APPROVE, ліміт виведення до €2 000, повторний AML-re-screen щодня.

5. Аудит: записані версії рушія, провайдера, правила, фічі і rationale.

17) Чек-лист впровадження

Оркестратор c failover і роутингом по юрисдикціях.
Договори/SLA/цінники, DPIA і юридичні узгодження.
Вебхукі, ідемпотентність, ретраї, трейсинг.
Case-менеджмент і плейбуки EDD.
Periodic re-screen (санкції/РЕР) і event-based тригери.
Моніторинг якості (hit-rate, FPR/FNR, час проходження).
Політика retention/видалення і доступів (RBAC).
План DR і навчання з деградації.

Резюме

Сильна KYC/AML-інтеграція - це не «підключити одного провайдера», а побудувати оркестрацію з декількох джерел, де рішення приймаються ризик-базовано, прозоро і швидко. Комбінуйте IDV, Liveness, санкції/РЕР і адресу, впроваджуйте case-менеджмент і жорсткий аудит, тримайте фолбек-провайдерів і не забувайте про UX - так ви виконайте вимоги регуляторів і збережіть високу конверсію онбордингу.