Разработка системы sanctions screening для крипто-бизнеса

Разработка sanctions screening: где ломается проверка

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

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

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

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

Что даёт собственный screening-контур

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

На практике 85-95% проверок закрывается автоматически, и это не настройка раз и навсегда: пороги чувствительности меняются вместе с профилем риска площадки. Скоринг риска отсекает ложные совпадения — если имя совпало, а страна, дата рождения и документ расходятся, срабатывание снимается без инженера. Человеку остаются случаи с реальной неопределённостью.

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

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

Способы подключения перечней и правила сопоставления

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

Форматы выгрузок различаются (XML, CSV с собственной схемой), поэтому слой загрузки держим отдельно от слоя сопоставления: смена схемы не должна ломать правила поиска. Обновления забираем дельта-файлами по расписанию, при смене структуры — полная перезагрузка снапшота с версионированием, чтобы в журнале осталось, на какой версии перечня принято решение по клиенту.

Режимы сопоставления и порог

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

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

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

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

1. Аудит процессов комплаенса. Разбираем текущие проверки: источники данных, ручные шаги, сроки разбора срабатываний, историю отказов и инцидентов. Фиксируем, какие операции сегодня проходят без проверки вообще.
2. Схема проверок. Определяем точки встраивания — регистрация клиента, входящая и исходящая транзакция, вывод средств. Согласуем форматы событий, роли и права, поведение системы при недоступности внешнего списка.
3. Настройка правил и порогов. Подбираем логику сравнения имён: транслитерация, перестановка частей, нечёткое сопоставление, вес совпадения. Настраиваем уровни риска и очереди ручного разбора, чтобы аналитик видел только значимые срабатывания.
4. Тестовый прогон на истории. Прогоняем накопленный массив операций, сверяем результат с решениями комплаенс-офицеров, считаем долю ложных срабатываний и пропусков. По этой сверке калибруем пороги, а не «на глаз».
5. Регламент проверки. Описываем порядок разбора: сроки реакции, критерии эскалации, основания для блокировки, обязательная фиксация решения. Регламент согласуется с действующей политикой и ложится в основу обучения команды.
6. Передача в эксплуатацию. Отдаём конфигурации, схему интеграции, инструкции для аналитиков и дашборд с метриками. Первые недели сопровождаем, пока команда не выйдет на самостоятельный режим.

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

Комплект схем, регламентов и доступов на выходе

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

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

Артефакты проверяем на учениях: поднимаем стенд, прогоняем сценарии с недоступным источником и потоком ложных совпадений. Если по инструкции решение принимается в отведённое время — комплект считаем принятым.

Кейс: как сократили ложные срабатывания вдвое

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

Мы перестроили маршрут проверки в три шага: сверка по санкционным спискам (OFAC SDN, EU, OFSI, UN), обогащение адресов данными Chainalysis и расчёт оценки риска по настраиваемым весам. Пороги и правила разбора вынесены в конфигурацию, поэтому чувствительность меняется без выпуска новой версии.

Показатели до и после

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

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

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

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

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

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

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

Технические сомнения: совпадения, нагрузка, доработки

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

Коротко закрываем четыре пункта ниже; остальное разберём вместе с нашим инженером на созвоне по вашей схеме процессов.

Выдержит ли система пиковую нагрузку?

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

Как дорабатывать правила после запуска?

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

Как проходит интеграция с учётной системой?

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

Обсудим задачу и вернёмся с оценкой и планом

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

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

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