Настройка compliance AML/KYC для криптопроекта

Почему AML/KYC настройка ломается на первом же потоке клиентов

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

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

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

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

Что даёт выстроенная AML/KYC настройка: правила, роли, отчётность

Уровни идентификации: сколько проверок реально нужно

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

Правила мониторинга транзакций

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

Роли и отчётность

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

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

Этапы внедрения compliance-контура: от аудита до передачи

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

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

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

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

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

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

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

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

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

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

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

Что изменили

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

Метрики до и после

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

Что дало устойчивость

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

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

Опишите ваш поток регистраций и текущую нагрузку на проверки — вернёмся с оценкой и планом настройки под ваш профиль риска.

Сомнения перед внедрением: совместимость, миграция, откат, доступы

Ключевое опасение при AML/KYC настройке — что проверки придётся встраивать в уже работающий продукт и это заденет живые сценарии: регистрацию, вывод средств, лимиты. На практике модуль подключается на уровне сервисного слоя: правила проверки выносятся в отдельный компонент, а бизнес-логика обращается к нему как к внешней зависимости. Текущая инфраструктура остаётся на месте — меняется только точка, где принимается решение о допуске операции.

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

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

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

На руки вы получаете:

• конфигурации правил проверки и порогов срабатывания;
• схемы потоков данных между продуктом и модулем проверок;
• политики AML/KYC в виде, пригодном для внутреннего регламента;
• описание ролей и матрицу разграничения доступов;
• инструкцию по плановому откату и переключению контуров;
• документацию по журналированию и выгрузке отчётов для проверяющих.

Опишите вашу задачу и текущую инфраструктуру — вернёмся с оценкой и планом внедрения.