Как автоматизировать AML-проверку адресов в криптосервисе

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

Материал подготовлен командой Nomium. В ее проектах создание криптообменника с самого начала включает AML-контур, а не добавляет его после запуска. В основе статьи — рекомендации FATF и OFAC, а также требования площадок, с которыми работает криптобизнес.

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

Почему ручная проверка перестает работать

Во многих обменниках и OTC-сервисах проверка выглядит так: оператор вставляет адрес клиента в AML-сервис, смотрит на оценку и решает, что делать. Пока заявок мало, этого достаточно.

С ростом потока у ручной проверки проявляются три слабых места:

• Нет единых правил. Два оператора могут по-разному оценить один и тот же отчет со средним риском.
• Нет следа для аудита. Через полгода трудно доказать, что именно проверяли и почему операцию одобрили.
• Нет повторной проверки. Адрес, который был чистым в момент операции, позже может получить опасную метку, и этого никто не заметит.

При этом цена ошибки растет. Tether, эмитент USDT, оставляет за собой право замораживать токены и блокировать адреса, на которых они хранятся. А мониторинг обменников BestChange требует, чтобы выплаты клиентам соответствовали требованиям FATF и OFAC: если отправленная клиенту транзакция получит AML-метку, обменник обязан компенсировать клиенту потери.

Четыре точки AML-проверки в продукте

Проверка полезна, только если может что-то остановить. Поэтому ее ставят там, где дальше идет необратимое действие: зачисление средств на баланс клиента или отправка на внешний адрес.

1. Входящий перевод — до зачисления

Когда перевод приходит на кошелек сервиса, его проверяют вместе с адресом отправителя — до зачисления на баланс или обмена. Пока идет проверка, заявка ждет.

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

2. Адрес получателя — до выплаты

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

По рекомендациям OFAC для криптоиндустрии, риск несут и адреса, которых нет в санкционных списках, но которые ранее взаимодействовали с адресами из них. Сверка со списком такие связи не найдет, а блокчейн-аналитика — найдет.

3. Кошельки самого сервиса

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

Поэтому средства из спорных источников не смешивают с общим пулом, пока по ним нет решения, а выплаты клиентам идут с адресов с низким риском. Например, правила BestChange требуют, чтобы выплаты шли с одноразовых адресов или с адресов, которые AML-аналитика не относит к высокорисковым.

4. Повторная проверка истории

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

Поэтому адреса клиентов стоит регулярно перепроверять. FATF рекомендует сверять адреса клиентов и контрагентов со списками нежелательных адресов в рамках постоянного мониторинга, а не только при первой операции.

Проверять адрес или транзакцию?

Это разные вопросы. Проверка адреса показывает, откуда в целом приходили средства на кошелек. Проверка транзакции — откуда пришел конкретный перевод.

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

Несколько технических нюансов, в которых часто ошибаются:

• В одной транзакции бывает несколько платежей. В биткоине одна транзакция часто отправляет средства нескольким получателям. Для AML это отдельные переводы, поэтому в запросе нужно указывать конкретный адрес.
• Один токен — разные сети. USDT выпущен в Tron (TRC-20), Ethereum (ERC-20), BNB Smart Chain (BEP-20) и других сетях, и в каждой у адреса своя история. Проверять нужно в той сети, где прошел перевод.
• Одинаковый формат адреса не означает одну сеть. Адреса Ethereum и BNB Smart Chain начинаются с 0x и выглядят одинаково. Если продукт хранит адрес без сети, рано или поздно он проверит не ту историю.

Как превратить оценку риска в решение

AML-сервисы обычно возвращают общую оценку риска и разбивку по источникам средств. Например, в GetBlock шкала такая: 0–30 — низкий риск, 31–69 — средний, 70–100 — высокий. Источники делятся на доверенные (лицензированные биржи, платежные сервисы, майнеры), подозрительные (криптоматы, биржи без лицензии) и опасные (санкции, даркнет-рынки, миксеры, краденые средства, мошенничество).

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

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

Как превратить оценку риска в решение

AML-сервисы обычно возвращают общую оценку риска и разбивку по источникам средств. Например, в GetBlock шкала такая: 0–30 — низкий риск, 31–69 — средний, 70–100 — высокий. Источники делятся на доверенные (лицензированные биржи, платежные сервисы, майнеры), подозрительные (криптоматы, биржи без лицензии) и опасные (санкции, даркнет-рынки, миксеры, краденые средства, мошенничество).

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

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

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

Что построить вокруг AML API

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

Статусы заявок

У заявки есть статусы: «ожидает проверки», «проверка пройдена», «на ручной проверке», «отклонена». Зачисление или выплата возможны только после статуса «проверка пройдена». Это правило лучше заложить на уровне бэкенда, а не интерфейса: тогда его нельзя обойти кнопкой в админке.

Поведение при сбоях

Внешний сервис может не ответить или ответить с задержкой. Для платежей безопаснее всего правило «нет проверки — нет выплаты». Запрос встает в очередь и повторяется, а заявка остается в статусе «ожидает проверки».

Повторные запросы не должны создавать дубли и лишние платные проверки. Некоторые сервисы, например GetBlock, позволяют бесплатно получить повторно отчет по уже проверенному адресу или транзакции.

Журнал решений

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

Срок хранения зависит от юрисдикции и требований партнеров. Например, OFAC с марта 2025 года требует хранить записи об операциях 10 лет (раньше — 5 лет), а правила BestChange — не менее 5 лет по каждой обменной операции.

Кэш и свежесть данных

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

Очередь ручной проверки

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

Защита доступа

API-ключ хранится в хранилище секретов, а не в коде. Если сервис поддерживает белый список IP-адресов, стоит разрешить запросы только с серверов продукта.

Требования, актуальные для любой страны

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

Базовый уровень по стандартам FATF

Стандарты FATF лежат в основе национальных AML-правил в большинстве стран. Для криптосервиса из них следует несколько практических требований:

• оценивать риск клиента и в зависимости от него менять глубину проверки;
• сверять адреса клиентов и контрагентов со списками нежелательных адресов в рамках постоянного мониторинга;
• отслеживать признаки риска не только в адресах, но и в поведении клиента.

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

Данные для Travel Rule

Рекомендация 16 FATF, или Travel Rule, требует передавать вместе с переводом данные об отправителе и получателе: их имена, адреса кошельков и идентифицирующие данные отправителя. Их передают до перевода или одновременно с ним. FATF допускает порог в 1000 долларов или евро, ниже которого требования мягче, но многие страны его не применяют.

Даже если в стране работы сервиса это требование еще не действует, поля для этих данных стоит сразу предусмотреть в модели данных. Добавить их в работающий сервис сложнее, чем заложить при разработке.

Как выглядят требования там, где они уже действуют

Регламент ЕС 2023/1113 о переводах средств обязывает криптопровайдера при переводе свыше 1000 евро на некастодиальный (self-hosted) адрес убедиться, что адрес принадлежит клиенту или находится под его контролем. В США OFAC с 2018 года вносит адреса криптокошельков в список SDN и рекомендует проверять не только адреса кошельков, но и IP-адреса пользователей, чтобы не допускать доступ из санкционных юрисдикций.

Эти примеры показывают, куда движется регулирование, но обязательны только в своих юрисдикциях.

Требования контрагентов

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

Настройки вместо кода

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

Ограничения автоматических проверок

У блокчейн-аналитики есть пределы точности, и их нужно учитывать при проектировании:

• Неполные данные. FATF прямо называет ограничения аналитики: охват, своевременность, точность и надежность данных.
• Разные оценки у разных провайдеров. У каждого свои базы и правила, поэтому один и тот же адрес может получить разную оценку. При смене провайдера пороги придется пересмотреть.
• Владельца кошелька нельзя определить точно. FATF в своем руководстве пишет, что не знает технически доказанного способа полно и точно определить провайдера, который управляет кошельком получателя.
• Ложные срабатывания. Клиент с хорошей историей может получить средний риск из-за старых транзакций. На этот случай нужна процедура: запрос пояснений, повторная проверка, решение аналитика.
• Проверка адреса не заменяет проверку клиента. Она отвечает на вопрос о происхождении средств, но не о личности клиента. Полноценный AML-контур объединяет проверку транзакций, KYC и мониторинг поведения.

Чек-лист перед запуском

1. Входящие переводы проверяются до зачисления, после нужного числа подтверждений.
2. Адрес получателя проверяется при вводе и повторно перед выплатой.
3. Спорные поступления не смешиваются с кошельком для выплат.
4. Адреса хранятся вместе с сетью, проверка идет в сети перевода.
5. Решения принимаются по оценке и категориям источников, правила зафиксированы заранее.
6. Зачисление и выплата невозможны без статуса «проверка пройдена», и это контролирует бэкенд.
7. При недоступности сервиса проверки выплаты останавливаются, а запросы повторяются без дублей.
8. Каждое решение сохраняется вместе с отчетом и версией правил.
9. Для спорных случаев есть очередь ручной проверки.
10. Адреса постоянных клиентов регулярно перепроверяются.
11. В модели данных есть поля для Travel Rule.
12. Пороги и правила для каждой страны меняются в настройках, а не в коде.

Такой AML-контур не делает сервис неуязвимым, но меняет главное: решения по рискованным средствам принимаются по одним и тем же правилам, вовремя и с понятным следом. Для криптобизнеса это меньше замороженных средств, меньше споров с партнерами и меньше зависимости от внимательности конкретного оператора.