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: перезапрос санкций/PEP по расписанию (ежедневно/еженедельно).
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).

Ложные совпадения в санкциях/PEP: настройка 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, частота обновления санкций/PEP, latency, вебхуки, SDK, отчёты, DPIA/сертификации, on-prem варианты, судебная/регуляторная практика, референсы из iGaming.

11) KYB: когда вы работаете с B2B/партнёрами

Регистры: Companies House, местные торговые реестры, UBO-цепочки.

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

Скрининг: санкции/PEP для 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 (санкции/PEP) и event-based триггеры.
Мониторинг качества (hit-rate, FPR/FNR, время прохождения).
Политика retention/удаления и доступов (RBAC).
План DR и учения по деградации.

Резюме

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