Когда ручная проверка перестаёт работать
Ручная проверка даёт сбой по трём причинам, которые возникают одновременно. Объём растёт, и копирование адресов вручную уже не поспевает за потоком. Очередь рассмотрения увеличивается, вывод средств замедляется, пользователи ждут. А после завершения проверки за адресом никто не наблюдает, поэтому изменение риска через три недели остаётся незамеченным. Автоматизация решает все три проблемы сразу.
Первое ограничение — количество. Пополнения и заявки на вывод поступают пакетами, а сотрудник, обрабатывающий их по одному, становится самым медленным звеном. Второе — сама очередь. Каждая минута ожидания проверки адреса — минута ожидания денег для пользователя, и комплаенс начинает восприниматься как помеха продукту. Третье — время. Ручная проверка заканчивается в момент завершения; после неё ничего не продолжает работать.
Группа разработки финансовых мер борьбы с отмыванием денег (FATF) ожидает непрерывного мониторинга в рамках риск-ориентированного подхода, а не только проверки на входе. Санкционные списки обновляются по собственному графику, что наглядно видно на странице новых действий OFAC: адрес может попасть в список в любое утро независимо от того, следит ли за ним кто-нибудь. Эти два обстоятельства — основной аргумент в пользу интеграции проверок в системы, а не сохранения их в отдельной вкладке браузера.
Автоматизация меняет место проверки в процессе. Встроенная проверка выполняется независимо от того, вспомнил ли о ней сотрудник, применяет одинаковый стандарт к первому и десятитысячному адресу и сама записывает результат. Именно запись превращает аудит из отдельного проекта в запрос к данным.
| Аспект | Ручная проверка | Автоматизированный процесс |
|---|---|---|
| Где выполняется проверка | Во вкладке браузера, которую сотрудник должен не забыть открыть | В процессе пополнения и вывода |
| Последовательность при больших объёмах | Зависит от сотрудника и времени | Одинаковый стандарт для каждого адреса |
| Наблюдение после одобрения | Заканчивается вместе с проверкой | Вебхуки передают изменения уровня риска |
| Записи | Восстанавливаются по запросу аудита | Создаются автоматически по мере выполнения |
Признаки необходимости перехода просты: ежедневные проверки нельзя пропустить ни на день, аудит требует записей по каждому решению, а обязанность мониторинга выполняется командой лишь формально.
Пакетная проверка через API
API превращает разовые проверки в этап обработки. Запросы отправляются на базовый адрес https://api.blocksec.com с префиксом пути /phalcon/compliance/v2/ и аутентифицируются ключом API, созданным в System → API → Generate Key. Лимит проверок — 50 запросов в минуту на ключ, остальных вызовов — 10 в секунду; успешный результат обозначается code=0.
Основную нагрузку несут четыре конечные точки: /address/screen для одного адреса, /addresses/screen для пакета, /transaction/screen для одной транзакции и /transactions/screen для пакета транзакций. Одиночные и пакетные формы позволяют использовать один инструмент и для разового ручного случая, и для ночной обработки десяти тысяч элементов.
При работе с конечными точками соблюдайте обычные правила надёжной обработки. Учитывайте ограничения частоты при проектировании: ставьте пакеты в очередь, увеличивайте задержку при достижении лимита и предусматривайте повтор неудачных вызовов. Проверяйте в момент решения о пополнении или выводе и сохраняйте результат вместе с соответствующей транзакцией, чтобы их связь не терялась.
Ключи управляются отдельно для каждого проекта. Полные сведения о запросах и ответах, поле за полем, приведены в официальной документации API; эта страница описывает рабочий процесс и не дублирует справочник.
Важный для сроков факт: API доступен на тарифах Scale и Enterprise, а не на всех тарифах. Если запуск предполагает API, сначала подтвердите тариф. Это реальное условие доступа, а не формальность; лучше выяснить его на первой неделе, чем на шестой.
Наблюдение за изменениями через вебхуки
Вебхуки обеспечивают наблюдение. Вы регистрируете конечную точку, и сервис направляет ей два вида сообщений: уведомления notification типа 1 с предупреждениями движка рисков и сообщения monitorEvent типа 2 с событиями Monitor. Последние сообщают об изменениях в кошельке, который вы уже одобрили.
Для комплаенса наиболее важны события изменения уровня риска: Risk Level Increased и Risk Level Decreased. Каждое содержит prevLevel и newLevel, позволяющие увидеть переход, а также Risk Timeline адреса. Если кошелёк прошёл проверку при подключении, а затем соприкоснулся с санкционными средствами, возникает именно такое событие. Это машинный ответ на частый вопрос: может ли чистый кошелёк стать рискованным? Да, и так это выглядит в системе.
Одно имя поля требует внимания: targetIdentifiter похоже на опечатку, но именно так записано в официальных данных. Копируйте его точно из документации, включая необычную букву; иначе поиск причины сбоя интеграции может занять полдня.
Доставка не ограничивается вашим сервером. Те же уведомления распространяются по 7 каналам, включая Telegram, электронную почту и Lark. Сотрудник, который должен действовать, получит их там, где уже работает, а не на панели, за которой никто не следит в 2 часа ночи.
Назначайте ответственных одновременно с выбором каналов. Уведомление, адресованное всем, часто не принадлежит никому. За каждым каналом должен стоять сотрудник или график дежурств; письменно определите срок реакции на изменение риска и первое действие.
Что даёт автоматизация
Когда проверка встроена в процесс обработки, появляются три устойчивых результата. Каждое пополнение проверяется до принятия, поэтому решения опираются на свидетельства. За каждым одобренным кошельком продолжается наблюдение, поэтому изменения риска выявляются автоматически. Каждая проверка оставляет запись, поэтому аудит становится поиском сведений, а не восстановлением событий.
Производительность рассчитана на такой режим: ответ на проверку менее чем за 100 миллисекунд, оценка на основе более 200 сигналов риска (по данным BlockSec). Цены начинаются с бесплатного уровня; затем можно покупать пакеты кредитов по мере необходимости или перейти на ежемесячную подписку при росте объёмов.
Ограничение нужно понимать честно: автоматизация расширяет охват и ускоряет проверки, но не устраняет риск. Ошибочная политика остаётся ошибочной, даже если применяется быстро и с подробными записями. Практические границы — описанные выше лимиты запросов и условия тарифа. Работайте в их пределах, масштабируйтесь при достижении границ и пересматривайте саму политику регулярно, а не только после сбоя.
О базовых понятиях — метках, сигналах и формировании оценки — читайте в статье «Что такое проверка адресов в криптокомплаенсе?». Карта всей темы, от первой проверки до мониторинга и записей, находится в разделе проверки кошельков.