Интеграция AML-скрининга (Chainalysis, Elliptic, Crystal) под ключ

AML-скрининг криптовалют: где ломается комплаенс

Пока объём операций небольшой, проверку транзакций ведут руками: аналитик открывает адрес в обозревателе блоков, сверяет с санкционными списками, пишет комментарий в таблицу. Пока в сутки проходит десяток выплат, задержка вывода средств незаметна — на сотнях операций очередь растёт быстрее, чем её разбирают, и срок ответа клиенту уезжает с часов на сутки.

Вторая точка отказа — ложные срабатывания. Автоматические правила помечают подозрительными переводы, косвенно связанные с миксером или биржевым кошельком, и до 80% таких меток закрываются как безосновательные. Аналитик тратит день на разбор шума, а действительно рисковая транзакция проходит мимо: внимание уже исчерпано.

Дальше подключается внешний контур. Партнёр по ликвидности или банк-корреспондент видит непрозрачную историю операций и блокирует счёт до выяснения — выплаты встают целиком, а не по одному клиенту. На аудите криптоопераций выясняется, что решения по прошлым меткам нигде не зафиксированы: непонятно, кто и на каком основании пропустил транзакцию.

Именно здесь теряются риски комплаенса — не в отсутствии скрининга, а в его ручном режиме. Разбираем, как это закрывается: Chainalysis и аналогичные сервисы дают оценку адреса, но эффект появляется только тогда, когда оценка встроена в сам процесс выплат и оставляет след для проверяющего.

Что даёт автоматический скрининг: эффект в измеримых величинах

Скрининг встраивается в момент зачисления или вывода, поэтому каждая операция получает оценку риска до движения средств, а не задним числом. Скорость обработки операций задаёт пропускная способность сервиса, а не число аналитиков в смене: поток адресов проверяется автоматически, и ручная работа остаётся только на срабатываниях.

Доля ложных срабатываний — управляемая величина. Оценка строится на данных провайдеров аналитики блокчейна, например Chainalysis, а пороги риска настраиваются под профиль ваших клиентов, географию платежей и типовые суммы. После настройки сигналы поднимают действительно нестандартные маршруты, а не каждый новый контрагент — это разгружает разбор и снижает число случаев, где приходится запрашивать документы у клиента.

Время разбора случая сокращается за счёт готовой карточки: адрес отправителя, контрагент, маршрут средств, привязка к известным сервисам и история прошлых проверок. Аналитик подтверждает решение вместо сбора данных вручную — рутинный кейс закрывается за минуты вместо часа с лишним.

Главный эффект — устранённый класс отказов. Операции, которые банк-партнёр или биржа отклоняли из-за непрозрачного источника средств, проходят с подтверждённым риском и обоснованием. Стоимость простоя сокращается вместе с этим: замороженный депозит или вывод — это часы и дни без операций, и такой простой закрывается до того, как начался.

Способы интеграции проверки: сравнение режимов работы

Режим проверки определяется тем, где в потоке операций стоит вызов аналитического сервиса и что происходит с операцией до получения вердикта. Проверка на входе оценивает адрес отправителя до зачисления средств, проверка на выходе — перед формированием выплаты, чтобы транзакция не ушла на санкционный или высокорисковый адрес.

Гибридная схема совмещает оба контура и добавляет периодический пересмотр истории: адрес, чистый на момент входа, переоценивается по мере обновления данных поставщика. Режимы различаются ценой задержки и покрытием риска.

Чтобы режимы не расползались по коду, подключение аналитических сервисов — Chainalysis, Elliptic, Crystal — делают через единый адаптер: нормализованный вердикт, кэш оценки по адресу, повтор запроса при недоступности. Тогда смена поставщика или добавление второго — правка конфигурации, а не переписывание логики проверок.

Этапы внедрения: от аудита операций до передачи в работу

Внедрение скрининга — это не установка готового модуля, а настройка процесса под то, как реально движутся средства в вашем продукте. Ниже — этапы, которые мы проходим вместе с командой заказчика: от аудита операций до передачи контура в эксплуатацию.

1. Аудит операций. Разбираем входящие и исходящие потоки: пополнения, выводы, переводы между счетами, обмен. Фиксируем, где нужна полная проверка адреса, а где достаточно сверки с санкционными списками.

2. Профиль риска. Определяем критерии подозрительной операции: юрисдикция, источник средств, возраст адреса, доля поступлений с миксеров и площадок без проверки клиента.

3. Проектирование схемы. Подбираем провайдера под ваши сети и активы — Chainalysis, Elliptic или Crystal, — и описываем действия при срабатывании: блокировка, ручная проверка, запрос документов.

4. Подключение и пороги срабатывания. Проверка встраивается в момент создания транзакции и в фоне, чтобы не задерживать платежи. Пороги задаём не по умолчанию, а от вашего профиля риска и допустимой доли ложных срабатываний.

5. Проверка на исторических данных. Прогоняем накопленные транзакции через готовые правила и смотрим, сколько срабатываний приходится на реальные риски, а сколько — на шум. Только так пороги калибруются до запуска.

6. Регламент и передача. Описываем действия аналитика по каждому классу риска и хранение доказательств для отчётности, передаём конфигурацию и инструкции — и остаёмся на поддержке при подключении новых сетей.

Что остаётся у вас на руках: конфигурация и регламенты

После сдачи проекта у вашей команды остаются не только работающий сервис, но и полный набор артефактов, по которым его можно эксплуатировать, развивать и передавать новым инженерам. Конфигурация лежит в вашем репозитории с историей изменений, решения задокументированы — интеграция не держится на подрядчике.

• Схема интеграции — путь от адреса или транзакции до вердикта скрининга: где вызывается проверка, как обрабатывается таймаут провайдера и что уходит в резервный канал.
• Конфигурации — пороги риска, списки доверенных адресов, маршрутизация по провайдерам для разных сетей и активов, отдельные наборы для тестового и рабочего окружений.
• Регламент разбора срабатываний — уровни риска, сроки реакции, кому эскалируется находка и как фиксируется принятое по ней решение.
• Политики доступа — роли, разделение прав на изменение порогов и на просмотр данных проверок, журналирование действий операторов.
• Инструкции для поддержки — что делать при недоступности провайдера, как проверить статус конкретной проверки, разбор типовых обращений клиентов.
• Отчётность по операциям — выгрузки по проверкам, отказам и эскалациям за период в формате, который принимает комплаенс.
• План развития — как подключаются новые сети и провайдеры, как меняются правила без остановки сервиса.

Каждый пункт передаём с разбором на созвоне и в записи — чтобы дежурный инженер мог действовать по документу, а не по памяти.

Кейс: как сократили ручные разборы на потоке операций

Клиент — платёжный сервис с потоком входящих и исходящих переводов в нескольких блокчейнах и обязательством проверять источник средств по каждому адресу. Скрининг был подключён, но работал как «чёрный ящик»: правила срабатывали на весь трафик подряд, а решения принимали люди.

Что было до

Алерты падали в одну общую очередь без приоритета, и аналитики разбирали их подряд. До 71% срабатываний оказывались ложными: депозитные адреса крупных площадок, кошельки самих клиентов, легальный оборот через сервисы обмена. Очередь росла быстрее, чем её чистили, а выплата клиенту ждала вердикта до 26 часов — при пиковой нагрузке дольше.

Что изменили

Развели поток по уровням риска и добавили дедупликацию: адрес из одного кластера больше не поднимал новый алерт каждый раз. Доверенные адреса и известные сервисные кошельки ушли в автоматическое закрытие, а на разбор попали только операции с непокрытой историей. Порог срабатывания настроили по методике оценки кластеров — она открыто описана в материалах Chainalysis, а не выставлен «на глаз».

Ручные разборы упали почти в шесть раз, срок вывода сократился больше чем на порядок. Ключевое следствие — на проверку стали попадать операции, которые действительно этого требуют, а каждое решение осталось в журнале с обоснованием: при запросе от банка или регулятора выгрузка собирается за минуты, а не за недели переписки.

Чем отличается встроенная проверка от ручного разбора?

Проверка в потоке — синхронный запрос оценки риска в момент операции: адрес проверяется до подтверждения вывода или зачисления, при превышении порога операция уходит в удержание, и только тогда к ней подключается аналитик. Чтобы уложиться в окно обработки, оценки кэшируются, а сверка идёт по уже размеченной базе атрибуции, без пересчёта кластеров на каждый запрос.

Отложенная проверка собирает операции в пакет и разбирает их по расписанию или по запросу — с полным кластерным анализом на несколько переходов и разбором истории. Точность выше, но результат приходит с задержкой, а каждая находка ложится в очередь ручного разбора.

Выбор определяет точка контроля, а не удобство. В потоке проверяют то, что нельзя отменить: зачисления, выводы, добавление адреса в белый список. Отложенно — периодическую перепроверку клиентской базы, разбор истории и выборки для отчётности, где важнее полнота, чем скорость.

Нагрузка на аналитика отличается на порядок. В потоке очередь формируют только срабатывания выше порога, типовые случаи закрываются правилами автоматически — при настроенных порогах до восьми из десяти срабатываний не требуют человека. Отложенный разбор даёт поток ручной работы, пропорциональный числу операций: каждую находку разбирает человек.

На практике AML-скрининг криптовалют не сводится к выбору одного режима: поток закрывает операции на входе и выходе, отложенный разбор — глубину и периодичность. Риск ловится в момент операции, а время команды уходит на неочевидные случаи, а не на механическую сверку.

Частые технические вопросы по внедрению проверки

Перед стартом интеграции заказчики задают одни и те же вопросы: они касаются не выбора сервиса, а стыковки с работающей инфраструктурой. Ниже — пять сомнений, которые чаще всего тормозят решение.

Можно ли заменить аналитический сервис без потери истории?

Смена поставщика — это перенос вердиктов, а не чистая установка. Сверяем шкалы риска двух систем, спорные адреса перепроверяем вручную, чтобы после миграции статус клиентов не «поехал».

Как отсекать ложные срабатывания?

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

Что запрашивают банки и контрагенты?

Подтверждение происхождения средств. Отчёт формируется в формате, который принимает комплаенс-служба контрагента, вместе с журналом проверок и историей вердиктов по адресу.

Куда уходят данные клиентов?

Наружу передаётся только адрес или хеш операции, а не персональные данные. Вердикты, история и журнал доступа остаются в вашем контуре: ролевая модель, срок хранения и выгрузка по политике.

Обсудим задачу: какие данные нужны для оценки и плана

Чем точнее исходные данные на старте, тем меньше допущений в оценке. Ниже — минимальный набор, после которого мы возвращаемся с планом внедрения по этапам и сроками работ, а не с «уточним по ходу».

• Перечень сетей и активов: какие блокчейны в работе, включая L2 и сайдчейны, какие токены и стандарты — от этого зависит покрытие риск-оценки адресов.
• Типы операций под проверку: входящие депозиты, выводы, внутренние переводы между клиентами, P2P и обменные сценарии.
• Текущая инфраструктура: где хранится история транзакций и адресов клиентов, есть ли свои узлы или сервис индексации, в каком виде ведётся учёт.
• Политика риска и пороги: с какого уровня риска операция уходит на ручную проверку, кто принимает решение и как фиксируется обоснование.
• Требования аудита и регулятора: состав отчётности, сроки хранения данных, нужны ли выгрузки в согласованном формате.
• Точки интеграции и доступы: тестовые ключи сервиса аналитики (например, Chainalysis), доступ к тестовому контуру, роли для наших инженеров.
• Ограничения: санкционные списки, география клиентов, правила обработки персональных данных.

По этим пунктам мы оцениваем объём, собираем план внедрения и называем сроки работ. Опишите задачу — вернёмся с оценкой и планом.