AML для крипто: ланцюжки та мітки

1) Навіщо iGaming потрібен ончейн-AML

• фільтрацію адрес і ланцюжків походження коштів (source of funds on-chain),
• ранній стоп високоризикових перекладів,
• доказову базу для регуляторів/банків/провайдерів.

2) Словник: мітки, кластери, ланцюжки

Мітка (label/tag) - атрибут адреси/кластера: біржа, сервіс, «дарк-ринок», «мультипідписний гаманець», «міст», «міксер», «фішинг-гаманець», «санкційний суб'єкт» тощо.
Кластеризація - об'єднання адрес, що належать одному суб'єкту (евристики co-spend/change/temporal).
Ланцюжок (path/trace) - набір hops від джерела до вашої адреси/гаманця із зазначенням сум/часток «брудних» коштів.
KYT (Know Your Transaction) - скоринг конкретної транзакції/адреси/ланцюжка по наборах міток і поведінкових ознак.

3) Карта ризиків за мітками (приблизна шкала)

4) Типові ризикові патерни в ланцюжках

Peeling chain: довгі лінійні висновки маленькими частинами від великого «брудного» пулу.
Layering через мости і L2: швидкий мультичейн-маршрут зі спробою розірвати трасування.
Rapid in–out: депозит → майже миттєвий вивід на нову high-risk адресу.
Cluster-hopping: перехід через безліч однотипних гаманців без економічного сенсу.
Mixer sandwich: вхід/вихід з «бутербродом» міксерів.
Sanctions proximity: зв'язок ≤ N-хопів з санкційними кластерами з істотною часткою успадкованих коштів.

5) KYT-скоринг і ознаки (feature set)

Label risk score: вага за типом мітки (санкції> міксер> high-risk P2P>...).
Proximity: відстань (хопи) і частка забруднення (taint%) у вашій транзакції.
Behavioral: час життя адреси, fan-in/fan-out, транзакційна періодичність, round-amounts, типові суми.
Counterparty quality: KYC-VASР/регульовані біржі vs неідентифіковані.
Geo & time: регіони ризику, «тимчасові вікна» після інциденту (злому/санкції).
Entity graph: зв'язку клієнта з раніше флагнутими контрагентами у вашій системі.

Вихід: агрегований risk score 0-100 для транзакції/адреси/ланцюжка.

6) Матриця рішень (RBA) для вхідних/вихідних

7) Travel Rule + KYT: Як поєднати

Робіть pre-KYT до відправки Travel Rule, щоб не обмінюватися даними по очевидно забороненим маршрутам.
При VASP↔VASP зберігайте IVMS101-повідомлення разом з KYT-звітом і hash-посиланням на транзакцію.
Unhosted адреси: підтвердження володіння (підпис/мікропереклад), KYT до зарахування, ліміти та періодична реверифікація whitelist.

8) Процеси: від алерта до закриття кейса

1. Алерт KYT → авто-кейс в системі.
2. Тriage (L1): швидкий перегляд міток/проксиміті, зіставлення з профілем клієнта.
3. Investigations (L2): детальне трасування, перевірка SoF/SoW, Travel Rule-відповіді, оцінка «частки забруднення».
4. Рішення: allow/partial release/hold/reject/escalate.
5. Документація: журнал даних, скріншоти, звіти провайдерів (ID, timestamp, версії міток).
6. SAR/STR (якщо потрібно законом).
7. Пост-аналіз: навчання правил/моделей, оновлення порогів.

SLA орієнтири: авто-тріаж ≤ 5-15 c p95; L2-review ≤ 2-4 год для High; звичайні кейси ≤ 24 год.

9) Як знижувати false positive і не душити конверсію

Контекстна нормалізація: мітки «гемблінг-сервіс» не дорівнюють ризику за замовчуванням - враховуйте ліцензію/гео/Travel Rule-відповідь.
Time-decay: знижуйте вагу старих подій в ланцюжку (якщо немає свіжих інцидентів).
Whitelist адрес/бірж з періодичною реверифікацією і KYT-порогами.
Сегменти клієнтів: хороший історичний профіль → нижче пороги hold; нові/High-risk → вище.
Feedback loop: розмічайте результати (TP/FP/FN), калібруйте скоринг (Brier/PR-криві).
Чітка комунікація: зрозумілі причини hold і чек-лист документів → менше тікетів і суперечок.

10) Дані, приватність і зберігання

Мінімізація PII: зберігайте тільки необхідне для AML/звітності; мітки/звіти KYT - в ізольованому сховищі (PII Vault).
Шифрування в спокої/транзиті, розділення доступів (RBAC, need-to-know).
Версіонування міток: позначайте джерело і версію бази/моделі на момент рішення.
Retention: відповідно до закону (часто 5 + років); авто-експірація та аудит видалень.
DSR: процеси доступу/виправлення/видалення (де застосовується).

11) Метрики та OKR

Дотримання/ризик

KYT hit% (за типами міток), Reject/Hold rate, SAR-conversion.
Sanctions proximity incidents і час реакції.

Якість/точність

False Positive%, Precision/Recall для High-risk кейсів, Time-to-Decision p95.

Бізнес/UX

Approval Rate після AML-фільтрів, Impact на Time-to-Finality, частка partial release.
Частка звернень в саппорт з AML-причин і середній час роз'яснення.

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

Покладатися тільки на «чорні списки» без аналізу ланцюжка і taint%.
Ігнорувати мости/L2 як шар «маскування».
Авто-відмови по будь-якій мітці «міксер» без урахування контексту/частки/часу.
Відсутність журналювання версій міток і джерел → не можна захистити рішення.
Жорсткі правила без RBA/порогів → знесення конверсії і VIP-досвіду.
Відсутність ідемпотентності та anti-duplicate в KYT-вебхуках → розбіжності та подвійні блокування.

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

• Провайдер (и) KYT: покриття мереж, точність міток, SLA, версії/джерела.
• Матриця ризиків/порогів (T1/T2/T3), політика proximity/taint% і time-decay.
• Інтеграція Travel Rule (IVMS101) і політика unhosted (підтвердження адреси).
• RBA-рушій: allow/limits/hold/reject/escalate + partial release.
• Case-management: ролі L1/L2/L3, шаблони SAR/STR, звіти для банків/регуляторів.
• Whitelist/denylist з TTL, адресна книга клієнтів, підтвердження володіння.
• Логи/версіонування: джерело міток, версія моделі, timestamp рішення.
• Метрики: FP%, Time-to-Decision, SAR-conversion, Approval Rate post-AML.
• Навчання команд (Risk/Compliance/Support), плейбуки комунікацій.
• Регулярні рев'ю порогів і ретроспективи програних/спірних кейсів.

14) Резюме

Ефективний AML для крипто в iGaming - це не «магічний список адрес», а система: мітки і кластери + трасування ланцюжків + KYT-скоринг + RBA-рішення, інтегровані з Travel Rule і процесами SoF/EDD. При правильному калібруванні ви знижуєте регуляторні і санкційні ризики, утримуючи конверсію і швидкість виплат на рівні, прийнятному для бізнесу і партнерів.