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 → авто-кейc в системе.
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. При правильной калибровке вы снижаете регуляторные и санкционные риски, удерживая конверсию и скорость выплат на уровне, приемлемом для бизнеса и партнеров.