Интеграция Elliptic: где ломается ручной AML-скрининг
Ручная проверка вывода средств держится на операторе: он открывает адрес получателя в веб-интерфейсе, сверяет его с санкционными списками и ставит отметку в таблице. Пока заявок десятки в сутки, этого хватает. Когда поток вырастает в разы, очередь на вывод становится узким местом, и время до подтверждения транзакции начинает измеряться часами.
Вторая проблема — решения не воспроизводимы. Риск-балл адреса один оператор трактует как повод для ручного разбора, другой пропускает платёж, потому что порог «серой зоны» каждый держит в голове. Один и тот же кошелёк проходит на утренней смене и застревает на ночной — не из-за уровня риска, а из-за того, кто сидел на проверке.
Третья — история проверок расползается по таблицам, логам и переписке. Проверка адресов кошельков не привязана к конкретной заявке, а снимок экрана из интерфейса не заменяет запись о том, когда, по какому списку и с каким результатом адрес проверяли.
В сумме это три класса издержек: простой в очереди вывода, размытые критерии и доказуемость, которую трудно предъявить банку-партнёру. Интеграция Elliptic закрывает их не лозунгом «ускорим операторов», а переводом AML-скрининга транзакций в автоматический контур с фиксируемым результатом. Разбираем, как это устроено и где осознанно остаётся ручное решение.
Что меняется после внедрения: скорость, риск, отчётность
Доля ручных проверок падает до целевого порога
Правила скоринга настраиваются под риск-профиль продукта: объём операции, возраст и активность кошелька контрагента, происхождение средств, близость к санкционным адресам. Транзакции с однозначным вердиктом закрываются автоматически, на ручной разбор уходит только серая зона — единицы процентов потока вместо прежних десятков. Порог меняется без правок кода: риск-аналитик правит правило, сервис Elliptic применяет его к следующей проверке.
Время обработки вывода сокращается до одного цикла
Вердикт по кошельку запрашивается до постановки вывода в очередь на подпись — без него транзакция не подписывается. Это не задержка, а условие прохождения контроля, поэтому время обработки вывода определяется циклом обработки, а не расписанием ручного разбора. Клиент видит финальный статус сразу, а не на следующее утро.
Журнал решений закрывает вопросы аудита
Каждая проверка оставляет неизменяемую запись: вердикт, риск-оценка, сработавшие правила, время, инициатор и подтверждение исключения. Банк-партнёр получает выгрузку, из которой видно, почему конкретная транзакция прошла, а доля спорных решений падает — вопрос решается фактом, а не перепиской.
История проверок транзакций хранится на любую глубину
История проверок транзакций привязана к адресу и внутреннему идентификатору клиента, поэтому цепочку по кошельку можно поднять за любой период. Это закрывает запросы комплаенса при разборе инцидента или повторной оценке контрагента и даёт готовую основу для отчётности.
Сравнение подходов: ручной контроль, свой реестр, готовый сервис
Режим скрининга выбирают не по размеру компании, а по потоку операций и требованиям партнёров и банков-корреспондентов. Ручной контроль держит небольшие объёмы, но при сотнях адресов в сутки проверка упирается в людей: решения расходятся, история разборов не сохраняется, а на повторную сделку никто не отвечает.
Развилка одна — откуда берётся признак риска: из собственного реестра рисков или из внешней аналитики адресов. Второй вопрос — кто применяет автоматические правила проверки: человек по чек-листу или движок, который считает оценку сам и отдаёт пограничные случаи на разбор.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Ручной контроль | Единичные проверки, поток в несколько операций в день | Не масштабируется, зависит от смены, нет журнала решений |
| Собственный реестр рисков | Закрытый контур, свои адреса и известные инциденты | Пополнять вручную, чужие адреса не оценены, растёт доля ложных срабатываний |
| Внешняя аналитика адресов (Elliptic) | Нужна оценка адреса, которого нет в своих данных | Зависимость от поставщика, пороги настраиваются под его модель риска |
| Гибридная схема скрининга | Свой реестр плюс внешняя аналитика на смешанном потоке | Нужен приоритет источников и регламент при расхождении оценок |
Выбранный режим фиксируют в правилах: порог риска, действие при срабатывании — блокировка, ручной разбор или запрос документов, — и кто эти разборы закрывает. После этого схему меняют точечно: отдельные направления переводят на автоматические правила проверки, не перестраивая весь процесс.
Как проходит интеграция Elliptic: этапы работ
Скрининг не подключается одной кнопкой: сначала нужно понять, где в вашей инфраструктуре средства входят и выходят, иначе проверка либо тормозит легитимных клиентов, либо оставляет дыру на промежуточных переводах. Ниже — последовательность, по которой мы ведём внедрение Elliptic: от инвентаризации потоков до передачи системы в эксплуатацию.
Этапы внедрения скрининга
- Аудит потоков и инвентаризация адресов. Собираем карту клиентских, кастодиальных и горячих кошельков, отмечаем потоки через промежуточные адреса и контракты.
- Проектирование точек проверки транзакций. Фиксируем, что проверяется на входе, на выводе и в фоне: входящий депозит, исходящий перевод, смена адреса в личном кабинете.
- Настройка порогов риск-балла. Низкий балл проходит автоматически, средний уходит на ручной разбор, высокий блокирует операцию до решения ответственного за комплаенс.
- Автоматические действия по адресу. Прописываем политики: пометка в базе, ограничение вывода, блокировка, повторный скрининг по расписанию.
- Инженерная обвязка. Асинхронная очередь запросов, повторные попытки при недоступности сервиса, хранилище уже проверенных адресов, журнал всех решений для аудита.
- Испытания на реальных данных. Прогоняем исторические транзакции, измеряем долю ложных срабатываний и калибруем пороги под ваш профиль клиентов.
- Передача в эксплуатацию. Регламенты ручного разбора, панель мониторинга, инструкции для поддержки, порядок обновления правил.
После запуска пороги не остаются застывшими: раз в квартал мы сверяем долю ручных разборов и ложных блокировок и пересматриваем политики, чтобы скрининг не превращался в тормоз для нормальных операций.
Что остаётся у команды заказчика после запуска
После запуска интеграции со Elliptic проверки продолжают работать без нашего участия — мы передаём не только настроенный сервис, но и правила, по которым он принимает решения. Разбор инцидента, смена порогов или подключение нового направления делаются силами вашей команды.
- Регламент ложных срабатываний: какие метки считаются пограничными, при каком уровне риска транзакция уходит на ручной разбор, кто и в какой срок снимает метку, что фиксируется в журнале.
- Схема обмена данными: какие атрибуты адреса и транзакции уходят на проверку, что приходит в ответе, как сопоставляются идентификаторы и где хранится история проверок.
- Политика доступа к данным скрининга: роли, кому видны результаты, кто вправе менять пороги, как ведутся журналы обращений к сервису.
- Документация скрининга: описание правил, текущие значения порогов, история изменений настроек, разбор типовых случаев и порядок добавления новых сценариев.
- Комплект конфигураций и ключей доступа в вашем контуре с порядком ротации и восстановления.
- Регламент действий при подтверждённом риске: блокировка, уведомление, отчётность, сроки реакции по каждому уровню.
- Чек-лист приёма-передачи ответственному: что проверить, где смотреть журналы, к кому идти при сбое проверок.
В передачу входит и порядок проверки новых правил на исторических данных — сравнение результатов до и после правки, чтобы настройка не ломала уже разобранные случаи. Скрининг вы ведёте сами; подключаемся, когда меняется схема данных или нужна новая логика оценки.
Кейс: снижение доли ручных проверок и времени ответа
Клиент — платёжный сервис, который выводит средства пользователей в сеть. До скрининга каждый вывод уходил в ручной разбор: аналитик сверял адрес получателя по спискам и открытым источникам, а решение принимал уже после того, как клиент начал писать в поддержку.
Что было до внедрения
В смену приходило 400–600 запросов на проверку, и они копились: один и тот же адрес перепроверялся повторно, если встречался в другом платеже. Автоматика закрывала около 38% случаев, остальное висело в очереди — среднее время ответа клиенту составляло 6–8 часов, в пиковые дни доходило до суток. Основной класс отказов был не про запрет, а про молчание: пользователь видел «вывод в обработке» и не понимал, чего ждать.
Что изменили и что это дало
Подключили Elliptic как источник оценки риска: адрес получателя проверяется до постановки платежа в очередь, результат пишется в карточку операции вместе с историей. Дальше — правила, согласованные с комплаенсом: высокий риск блокирует вывод автоматически с понятной формулировкой для клиента, средний уходит в приоритетную очередь аналитика, низкий пропускается без участия человека. Повторные проверки одного адреса кэшируются, поэтому нагрузка на разбор не растёт вместе с оборотом.
Доля автоматических решений выросла с 38% до 91%, среднее время ответа по спорным операциям сократилось с 6–8 часов до 12–20 минут. Ручных проверок стало вчетверо меньше, а обращения в поддержку по теме «где мой вывод» — втрое. Отдельный эффект — ушёл класс отказов-сюрпризов: клиент получает причину и ссылку на решение, а не тихую задержку.
Чем отличается блокировка адреса от понижения риск-балла
Блокировка адреса — это жёсткий запрет: адрес попадает в чёрный список, и операция по нему не проходит ни при каком раскладе. Понижение риск-балла — мера другого класса: оценка адреса сдвигается в сторону риска, но финальное решение по операции остаётся за вашей политикой, а не за внешним источником.
В Elliptic и подобных источниках скоринга адрес получает числовую оценку по совокупности признаков: близость к миксерам, связь с санкционными перечнями, число «рук» от источника средств. Уровни риска транзакции считаются по всей цепочке, а не по одному узлу, — два адреса с одинаковым баллом дают разный итог, если пути к ним различаются.
Различие прямо влияет на решения по выводу средств. Блокировка бинарна и легко автоматизируется, но ошибочное попадание в список обрывает легитимные выплаты без варианта частичной меры. Понижение балла даёт градацию: приостановить операцию до подтверждения источника средств, урезать лимиты на вывод или отправить на ручную проверку вместо отказа.
Для разбора обращений клиентов это тоже разные сценарии. При блокировке вы показываете основание запрета и не можете предложить обход; при снижении балла — называете сработавшие признаки и перечень документов, которые вернут адресу нормальную оценку. Оба решения фиксируются в журнале: видно, кто, когда и на каком основании закрыл операцию.
Технические сомнения перед подключением скрининга
Когда поток транзакций уже развёрнут, вопросы к интеграции Elliptic обычно не про «нужен ли скрининг», а про стыки: как встроиться, не переписывая логику, что делать с частичным риском адреса, какие данные клиентов уходят наружу и кому отвечать за ложные срабатывания. Ниже — то, что чаще всего уточняют технические команды до старта.
Можно ли встроить проверку в уже работающий поток?
Да, переписывать логику не нужно. Проверка ставится в точки, где адрес уже известен: при формировании операции, при зачислении, при выводе. Добавляется вызов и обработка ответа — остальная цепочка остаётся как была.
Что считается частичным риском адреса?
Ответ приходит не «чисто или грязно», а с долей риска и признаками, из которых она собрана: связь с миксером, попадание в санкционный перечень, контрагент без процедур проверки. Дальше работает порог: ниже — пропускаем, выше — на ручной разбор, у верхней границы — блокируем. Порог задаётся политикой и меняется без релиза.
Какие данные клиентов уходят наружу?
Наружу уходит только то, что нужно для сопоставления с базой рисков: публичный адрес или его хеш. Персональные данные остаются в вашем контуре, а набор передаваемых полей настраивается — от одного адреса до идентификатора операции, без имени и документов клиента.
Кто отвечает за ложные срабатывания?
Ложное срабатывание — не сбой, а рабочий случай: в ответе есть признак, по которому оно возникло, и правило, позволяющее переопределить решение с записью в журнал. Первый месяц разбираем очередь вместе — так пороги совпадают с вашим реальным профилем операций.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы вернуться со схемой потоков транзакций, планом работ и оценкой внедрения, нам нужен минимум вводных: какие сети и активы обслуживаются, в какой точке вашего контура появляется адрес или хэш транзакции, кто принимает решение по алерту. Этого достаточно, чтобы разложить интеграцию на этапы и назвать сроки — без долгих вводных встреч и переписки на неделю.
- Перечень сетей и типов активов: нативные монеты, токены, внутренние переводы между своими кошельками — от этого зависит глубина разбора и набор правил.
- Точки интеграции: депозит, вывод, исходящий платёж, разовый запрос по адресу — и где в этих сценариях нужно блокирующее, а где отложенное решение.
- Политика риска: пороги по уровню риска контрагента, что считается стоп-фактором, кто и в какие сроки разбирает спорный случай.
- Роли и доступы: кто видит алерт, кто может снять блокировку, как фиксируется обоснование — это ложится в журнал для регулятора.
- Требования к отчётности: выгрузки, сроки хранения истории проверок, формат ответа на запросы службы контроля.
- Порядок нагрузки: пиковая частота проверок и допустимая задержка на подтверждение операции — отсюда схема очередей и кеширования.
Из этого мы собираем схему потоков, описание этапов и критерии приёмки — документ, по которому можно принимать решение. Опишите задачу скрининга в двух-трёх абзацах, и мы вернёмся с планом и оценкой.
