Какие AML-проверки нужны до завершения онбординга
AML-проверка при онбординге решает конкретную задачу: до момента установления деловых отношений определить, допустимо ли обслуживание клиента с точки зрения законодательства о противодействии отмыванию доходов и финансированию терроризма (ПОД/ФТ). Рекомендации FATF и 115-ФЗ выстраивают эту проверку по принципу риск-ориентированного подхода: объем и глубина процедур зависят от уровня риска, а не от единого шаблона.
На этапе онбординга обязательны три блока: идентификация клиента и связанных с ним лиц, скрининг по санкционным и иным ограничительным спискам, первичная оценка уровня риска. Эти блоки завершаются до того, как клиент получит доступ к услугам. Транзакционный мониторинг, периодическое обновление данных, углубленный анализ поведения — все это относится к ongoing monitoring и выполняется уже в процессе обслуживания.
Избыточный объем синхронных проверок увеличивает время прохождения онбординга и снижает конверсию. Недостаточный — создает регуляторные риски и делает систему уязвимой для мошенничества. Баланс определяется четкой архитектурой: какие проверки блокируют выдачу доступа, а какие работают асинхронно.
Кого проверять помимо клиента
Проверка только заявителя — распространенная ошибка, которая приводит к пропуску рисков на уровне структуры владения и контроля. 115-ФЗ (в редакции с учетом Приказа Росфинмониторинга № 74, вступившего в силу 1 июля 2025 года) прямо обязывает идентифицировать не только самого клиента, но и его представителей, выгодоприобретателей и бенефициарных владельцев (UBO). Аналогичные требования содержат рекомендации FATF и европейские директивы по AML.
Бенефициарный владелец — физическое лицо, которое прямо или через цепочку юридических лиц владеет более чем 25 % капитала клиента либо контролирует его действия. Для юридических лиц установление UBO — обязательный шаг до начала обслуживания. Если цепочка владения непрозрачна или клиент не раскрывает конечного бенефициара, это само по себе является сигналом повышенного риска и основанием для усиленной проверки (EDD).
Представители клиента — лица, действующие от его имени на основании доверенности, учредительных документов или иных полномочий, — также подлежат идентификации и скринингу. В частности, единоличный исполнительный орган юридического лица проверяется как представитель. Выгодоприобретатель — лицо, в интересах которого совершается операция, — проверяется, когда клиент действует не в собственных интересах.
На практике AML-скрининг при онбординге охватывает минимум четыре категории лиц: самого клиента, его представителя, бенефициарного владельца и выгодоприобретателя. Для каждого из них выполняется проверка по санкционным спискам, перечням террористов и экстремистов, а также PEP-скрининг. Автоматизация через единый API-вызов, объединяющий данные из KYC-пайплайна, позволяет проверить всех связанных лиц за одну сессию без повторного ввода данных и без заметного увеличения времени для пользователя.
Проверка четырех категорий — самого клиента, представителя, бенефициарного владельца и выгодоприобретателя — требует доступа к актуальным санкционным базам и единой точки интеграции. AML-модуль NeuroVision принимает нормализованные данные из KYC-контура и выполняет скрининг всех категорий лиц за одно обращение к API, обращаясь к более чем 1700 источникам — от перечней ООН и OFAC до национальных списков, PEP-баз и массива adverse media. Обновление источников происходит ежедневно, что исключает проверку по устаревшим данным.
Мы подключим санкционный скрининг к вашему KYC-пайплайну так, чтобы данные всех связанных лиц передавались автоматически, без повторного ввода. Среднее время ответа — менее одной секунды, а интеграция AML-контура занимает 1–2 дня в зависимости от инфраструктуры и требований информационной безопасности. Вы получите процесс, который закрывает обязательные категории проверяемых лиц по 115-ФЗ и не создает задержки на стороне пользователя.
Какие списки и сигналы риска проверять в реальном времени
Синхронная проверка до завершения онбординга включает скрининг по трем категориям источников: санкционные списки, перечни PEP и списки террористов/экстремистов.
Санкционные списки покрывают ограничения, наложенные международными и национальными регуляторами. Минимальный набор: сводный перечень Совета Безопасности ООН, списки OFAC (SDN и производные — SSI, FSE, NS-CMIC), консолидированные списки ЕС, санкционные перечни HMT/OFSI Великобритании, а также национальные списки юрисдикций, в которых работает компания. Для организаций с международной деятельностью рекомендуется учитывать перечни дебармента международных организаций. Списки должны обновляться ежедневно: санкционные режимы меняются часто, и скрининг по устаревшей базе создает ложное чувство защищенности.
PEP-скрининг выявляет публичных должностных лиц и связанных с ними персон. Статус PEP не означает автоматического отказа в обслуживании, но требует усиленной проверки (EDD) и одобрения со стороны руководства. Практическая сложность — объем ложных совпадений: алгоритмы нечеткого сопоставления генерируют множество кандидатов, часть которых не имеет отношения к проверяемому лицу. Качественные системы скрининга применяют оценку значимости совпадений (relevance scoring), чтобы снизить долю ложноположительных результатов до ручного разбора.
Проверка по перечням террористов и экстремистов в РФ регулируется ст. 7.4 115-ФЗ и включает сверку с перечнем Росфинмониторинга. Совпадение по этим спискам — блокирующий сигнал: операция не может быть завершена до снятия подозрений.
При первичном скрининге также целесообразно учитывать дополнительные сигналы риска: географию клиента (связь с юрисдикциями повышенного риска по классификации FATF), тип деятельности, сложность структуры владения. Эти сигналы не обязательно приводят к отказу, но влияют на присвоение уровня риска и определяют необходимость углубленной проверки на следующем этапе.
Все перечисленные проверки технически выполнимы в реальном времени, если скрининг-движок интегрирован в KYC-пайплайн и получает данные клиента автоматически. Среднее время ответа качественного AML-модуля, работающего по API, — менее одной секунды. Это сопоставимо со временем биометрической проверки и не создает заметной задержки для пользователя.
Состав списков для проверки в реальном времени зависит от географии бизнеса: одним организациям достаточно перечней ООН и OFAC, другим необходимы региональные санкционные базы, списки дебармента и локальные реестры. AML-модуль NeuroVision покрывает свыше 1700 источников — санкции, PEP, перечни террористов и экстремистов, adverse media и репутационные риски — и обновляет их ежедневно, что исключает ложное чувство защищенности из-за неактуальных данных.
Мы проанализируем ваш набор юрисдикций, согласуем перечень обязательных и рекомендуемых источников и настроим пороги чувствительности с учетом профиля клиентского потока. Оценка значимости совпадений встроена в модуль и снижает долю ложных срабатываний еще до этапа ручного разбора. SLA доступности сервиса — 99,99 %, среднее время ответа по API — менее секунды.
Что переносить в ongoing monitoring
Не все AML-проверки имеют смысл на этапе онбординга. Часть из них требует данных, которые появляются только после начала обслуживания, и попытка выполнить их синхронно не повышает безопасность, но тормозит процесс.
Транзакционный мониторинг — основной кандидат на вынос из онбординга. До первой операции анализировать нечего: поведенческий профиль клиента не сформирован, исторических данных нет. Мониторинг транзакций запускается после активации учетной записи и работает непрерывно, выявляя отклонения от ожидаемого профиля: дробление сумм, нетипичных контрагентов, резкие изменения оборотов. Этот слой относится к KYT (Know Your Transaction) и требует потоковой обработки данных, а не одноразовой проверки.
Проверка adverse media (негативных упоминаний в СМИ и открытых источниках) допускает асинхронное выполнение. Ее результат обычно не блокирует онбординг. Запуск параллельно с завершением регистрации позволяет получить данные в течение нескольких минут после выдачи доступа и при необходимости инициировать ручной разбор.
Периодическое обновление данных и повторная оценка уровня риска — задача ongoing monitoring по определению. Согласно актуальным требованиям, данные о клиентах высокого риска обновляются не реже одного раза в год, о клиентах низкого риска — раз в три года. Пересмотр риск-профиля инициируется также событийно: при изменении санкционных списков, появлении клиента или связанных лиц в новых перечнях, при выявлении подозрительных операций.
Архитектура AML-проверок распределяется на два контура. Первый — синхронный, блокирующий: санкционный скрининг, PEP, списки террористов, идентификация UBO и первичная оценка риска. Второй — асинхронный и непрерывный: транзакционный мониторинг, adverse media, периодическое обновление данных, уведомления при изменении статусов. Такое разделение позволяет выполнить регуляторные требования в полном объеме, не перегружая точку входа и сохраняя скорость онбординга на уровне, приемлемом для цифровых сервисов.
Как встроить AML и санкционный скрининг в KYC-онбординг
Санкционный скрининг и KYC-верификация решают разные задачи, но работают с одними и теми же входными данными. Если эти процессы реализованы как изолированные системы, клиент вынужден дважды вводить одну и ту же информацию, а бизнес тратит ресурсы на повторные запросы и согласование результатов. Задача архитектора онбординга — связать оба контура в единый пайплайн, где данные передаются между модулями автоматически, а итоговое решение складывается из результатов всех проверок без дополнительных задержек.
Рекомендации FATF и требования 115-ФЗ предполагают, что идентификация клиента и оценка рисков ПОД/ФТ выполняются как части единого процесса надлежащей проверки (CDD). Разрыв между ними создает не только техническую, но и регуляторную уязвимость: если между завершением KYC и запуском AML-проверки проходит значительное время, организация фактически допускает клиента к сервису без полной оценки рисков.
Какие данные передавать из KYC без повторного ввода
На этапе KYC система уже собирает и верифицирует набор данных, достаточный для запуска санкционного скрининга. Повторно запрашивать их у клиента нет необходимости — достаточно передать из KYC-модуля в AML-контур нормализованные поля.
Минимальный набор для скрининга по большинству санкционных баз и спискам PEP: полное имя (включая латинскую транслитерацию, если документ содержит MRZ), дата рождения, гражданство, страна выдачи документа, номер документа. Эти поля извлекаются при распознавании документа через AI-OCR и уже прошли валидацию — повторный ручной ввод только увеличит вероятность ошибок и расхождений.
Для расширенного скрининга и оценки контекста полезно передавать дополнительные атрибуты: страну резидентства (если она отличается от гражданства), адрес регистрации, ИНН или аналогичный идентификатор, а также метаданные устройства и геолокации, полученные при прохождении KYC-сессии. Эти сигналы позволяют AML-системе точнее определять юрисдикционные риски и снижать число ложных совпадений — например, когда распространенное имя совпадает с записью в санкционном списке, но страна и дата рождения не подтверждают связь.
Принципиальное условие — нормализация данных до передачи. Имена приводятся к единому формату (без сокращений, с учетом порядка «фамилия — имя — отчество» и альтернативных написаний), даты — к ISO 8601, страны — к кодам ISO 3166. Без этого шага алгоритм нечеткого сопоставления на стороне AML-модуля будет генерировать избыточное число алертов или, наоборот, пропускать реальные совпадения из-за расхождений в форматах.
Точность сопоставления в AML-контуре напрямую зависит от качества входных данных: расхождения в форматах имен, дат и кодов стран приводят либо к лавине ложных алертов, либо к пропуску реальных совпадений. В платформе NeuroVision нормализация встроена в архитектуру — AI-OCR извлекает поля документа, включая машиночитаемую зону, приводит имена и даты к единому стандарту и автоматически передает результат в AML-модуль вместе с данными биометрической верификации и liveness-проверки.
Мы спроектируем связку KYC и AML так, чтобы клиент проходил один сценарий без повторного ввода, а оркестратор агрегировал результаты обоих контуров в единое решение. Платформа поддерживает более 10 000 типов документов из 200+ стран на 90+ языках — данные нормализуются на этапе распознавания, а не вручную перед скринингом. Развертывание возможно в облаке, в вашем защищенном контуре или в гибридном формате, интеграция выполняется через REST API.
В какой точке запускать скрининг
Оптимальный момент — сразу после того, как KYC-модуль подтвердил подлинность документа и извлек данные, но до вынесения финального решения об успешности онбординга. На практике: документ распознан, поля извлечены и провалидированы, биометрическое сравнение (селфи с фото документа) и liveness-проверка пройдены — и в этот момент нормализованные данные передаются в AML-контур.
Такое расположение в пайплайне дает два преимущества. Во-первых, скрининг работает с уже проверенными данными, а не с «сырым» пользовательским вводом, что повышает точность сопоставления. Во-вторых, к моменту запуска AML-проверки система уже отсеяла явный фрод (поддельные документы, дипфейки, повторные попытки), и AML-модуль обрабатывает только клиентов, прошедших базовый порог доверия.
Выбор между синхронным и асинхронным выполнением зависит от допустимого времени отклика и риск-профиля потока. При синхронной схеме AML-скрининг выполняется в рамках основной сессии онбординга: клиент ждет результата, но получает итоговое решение за один проход. Если провайдер обеспечивает время ответа менее одной секунды, пользовательский опыт практически не страдает. При асинхронной схеме клиенту выдается предварительный статус («документы приняты, проверка завершается»), а скрининг выполняется фоном — это уместно для низкорисковых сегментов, где регулятор допускает начало ограниченного обслуживания до завершения полной проверки.
Риск-ориентированный подход FATF допускает дифференциацию: для клиентов из юрисдикций с повышенным риском, PEP-кандидатов и операций выше пороговых значений 115-ФЗ скрининг целесообразно выполнять синхронно и до предоставления любого доступа. Для стандартного потока из низкорисковых юрисдикций допустима асинхронная модель с жестким SLA на завершение проверки — например, не более 30 минут.
Как объединять результаты AML с решением по KYC
KYC-модуль и AML-контур возвращают результаты в разных форматах: первый — статус верификации и скоринг доверия (документ подлинный, лицо совпало, liveness пройден), второй — список совпадений с рисковыми базами и их релевантность. Чтобы превратить два набора данных в одно решение, нужен оркестрационный слой с прозрачной логикой маршрутизации.
Базовая модель принятия решений строится как матрица. Если KYC пройден и AML-скрининг не выявил совпадений — клиент одобряется автоматически. Если KYC пройден, но зафиксировано совпадение — кейс направляется на ручную проверку комплаенс-офицеру, а клиенту выставляется статус ожидания. Если KYC не пройден (поддельный документ, несовпадение биометрии) — процесс прекращается вне зависимости от результатов AML, поскольку без подтвержденной личности дальнейшие проверки теряют смысл.
На практике эффективнее работать не с бинарными статусами, а с числовыми скорингами. Каждый модуль присваивает сессии балл: KYC-скоринг учитывает качество документа, уверенность биометрического сопоставления и результат антифрод-проверок; AML-скоринг отражает степень релевантности совпадений, количество затронутых списков и уровень риска юрисдикции. Оркестратор агрегирует оба скоринга и применяет правила, настроенные под политику конкретной организации: пороги для автоматического одобрения, автоматического отказа и зоны ручного разбора.
Регулятор и внутренний аудит должны видеть, почему конкретный клиент был одобрен, отклонен или отправлен на ручную проверку. Оркестрационный слой обязан логировать не только финальный статус, но и входные данные, промежуточные результаты каждого модуля, примененные правила и временные метки. Такой аудит-трейл — требование 115-ФЗ и рекомендаций FATF в части документирования процедур CDD, а не опциональное удобство.
Техническая реализация связки чаще всего строится через REST API: KYC-модуль по завершении проверки отправляет результаты в оркестратор, тот передает данные в AML-контур, получает ответ и формирует агрегированное решение. Каждый модуль при таком подходе остается заменяемым, а логика принятия решений — настраиваемой без изменения кода. Для организаций, которым важна скорость, весь цикл — от передачи данных до агрегированного статуса — должен укладываться в допустимый SLA онбординга.
Как разбирать совпадения без потери скорости
Санкционный скрининг при онбординге неизбежно генерирует совпадения — алерты, указывающие на возможное присутствие клиента в санкционных списках, реестрах PEP или базах adverse media. Проблема не в самих алертах, а в их объеме и качестве. По данным PwC, от 90 до 95 % всех срабатываний в AML-скрининге оказываются ложными — клиент не связан с подсанкционным лицом, а совпадение вызвано сходством имени, транслитерацией или неполнотой идентифицирующих данных в списке. Каждый такой алерт требует проверки, и если процесс разбора не выстроен, очередь на ручной анализ парализует онбординг.
Задача — не убрать совпадения полностью (это повысит риск пропуска реальных угроз), а минимизировать долю ложных срабатываний до ручной проверки, четко маршрутизировать оставшиеся кейсы и задать прозрачные сроки их закрытия.
Как снижать ложные совпадения до ручной проверки
Основной источник ложных срабатываний — примитивное нечеткое сравнение, при котором система оценивает только степень символьного сходства имени клиента с записями в санкционных списках. Имя «Мохамед Али» может дать десятки совпадений с разными подсанкционными лицами, ни одно из которых к реальному клиенту не относится.
Снижение ложных совпадений происходит в несколько слоев, до того как алерт попадет к аналитику.
| Категория | Описание |
|---|---|
| Первый слой — нормализация и токенизация данных | Перед сравнением система очищает входные данные: убирает стоп-слова (Ltd, ООО, Inc, Bank), разбивает полное имя на компоненты, приводит транслитерацию к единому стандарту. Без этого шага слово «Bank» в названии клиента будет давать совпадение с каждой второй записью в списке OFAC. |
| Второй слой — использование вторичных идентификаторов | Чем больше дополнительных параметров участвует в сравнении, тем точнее фильтрация. Дата рождения, страна гражданства, место регистрации, ИНН или номер документа — каждый из этих атрибутов позволяет отсечь совпадения, основанные только на сходстве имени. Если KYC-процесс уже собрал эти данные, они должны автоматически передаваться в AML-модуль. |
| Третий слой — адаптивные пороги и риск-профилирование | Единый порог чувствительности для всех клиентов — типичная причина перегрузки. Для клиентов из низкорисковых сегментов допустим более строгий порог срабатывания (выше процент совпадения, необходимый для генерации алерта), а для высокорисковых — более чувствительный. Калибровка порогов должна опираться на статистику прошлых алертов: если правило генерирует 98 % ложных совпадений, это сигнал к пересмотру параметров, а не повод нанимать дополнительных аналитиков. |
| Четвертый слой — автоматическое разрешение очевидных несовпадений | Часть алертов система способна закрыть без участия человека: когда дата рождения клиента расходится с записью в списке на десятки лет, когда страна регистрации не совпадает, когда пол клиента отличается от пола подсанкционного лица. Такие правила авторазрешения документируются и периодически пересматриваются — регулятор оценивает не отсутствие алертов, а обоснованность методологии их обработки. |
В совокупности четыре слоя позволяют сократить поток алертов, поступающих на ручную проверку, в разы. Автоматизация первичной фильтрации может снизить долю ручного разбора до 10–20 % от общего числа срабатываний при условии качественных входных данных и регулярной калибровки правил.
Когда поток ложных совпадений перегружает аналитиков, страдает и скорость онбординга, и качество разбора реальных кейсов. AML-модуль NeuroVision использует оценку значимости совпадений, сопоставляя не только имя, но и вторичные идентификаторы — дату рождения, гражданство, номер документа, — которые автоматически поступают из KYC-контура. До 90 % проверок закрываются без участия оператора, а встроенный кейс-менеджмент с аудит-логом и хронологией действий фиксирует каждое решение для регулятора и внутреннего аудита.
Мы настроим пороги срабатывания и правила авторазрешения под ваш риск-профиль и статистику прошлых алертов, подключим непрерывный мониторинг с уведомлениями при изменении статусов клиентов. Источники обновляются ежедневно, а среднее время автоматического ответа не превышает одной секунды — в ручную очередь попадают только те кейсы, которые действительно требуют решения аналитика.
Когда переводить совпадение в case management
Не каждый алерт заслуживает полноценного расследования. Перевод совпадения в кейс — момент, когда система фиксирует: автоматические проверки не дали однозначного ответа и требуется решение аналитика с документированием обоснования.
Критерии эскалации зависят от политики организации, но обычно включают три условия. Первое: совпадение по имени подтверждено хотя бы одним вторичным идентификатором (совпадает страна или возрастной диапазон). Второе: клиент попадает в высокорисковую категорию по типу деятельности, географии или структуре владения. Третье: источник совпадения относится к категории повышенного регуляторного внимания — санкционные списки OFAC, ООН, ЕС или национальные перечни террористов.
Кейс в системе кейс-менеджмента — структурированный объект с обязательными атрибутами: идентификатор клиента, источник совпадения, результаты автоматической проверки, уровень риска, назначенный аналитик, хронология действий и итоговое решение. Каждое действие фиксируется в аудит-логе — это прямое требование регуляторных рамок, будь то 115-ФЗ, 6AMLD или рекомендации FATF.
Здесь принципиально разделить два сценария. Если совпадение выявлено на этапе онбординга, кейс создается параллельно с регистрацией, и пока он не закрыт, онбординг приостанавливается или завершается с ограниченным доступом к услугам. Если совпадение обнаружено в ходе ongoing monitoring для уже действующего клиента, кейс не блокирует текущие операции автоматически, но может инициировать усиленную проверку (EDD) и временные ограничения.
Организации, которые не формализуют критерии перевода алерта в кейс, сталкиваются с двумя крайностями: либо аналитики перегружены кейсами, большая часть которых закрывается за минуты, либо реальные совпадения теряются в потоке неразобранных алертов. Оба варианта создают регуляторные риски.
Как задать SLA для спорных кейсов
SLA в контексте AML-кейсов — внутренний норматив, определяющий максимально допустимое время на каждый этап разбора: от создания кейса до финального решения. Без SLA кейсы накапливаются, сроки расследований растягиваются, а регулятор при проверке видит бэклог, свидетельствующий о незрелости комплаенс-программы.
Структура SLA привязана к уровню риска кейса. Для высокорисковых совпадений (прямые санкции, совпадение по нескольким идентификаторам) — первичная оценка в течение нескольких часов, финальное решение в пределах одного-двух рабочих дней. Для среднего риска (PEP, adverse media с неоднозначными сигналами) — до трех-пяти рабочих дней на полный цикл расследования. Для низкорисковых кейсов, попавших на ручную проверку из-за пограничного скоринга, — не более пяти-семи рабочих дней.
Отдельно фиксируется SLA на первичную реакцию — время от создания кейса до момента, когда аналитик принимает его в работу. Если этот интервал превышает несколько часов для высокорисковых кейсов, процесс нуждается в доработке: не хватает аналитиков или система приоритизации работает некорректно.
При определении SLA следует учитывать регуляторные сроки. Если расследование подтверждает подозрительную активность, организация обязана подать отчет (SAR/STR в зависимости от юрисдикции, сообщение в Росфинмониторинг в РФ) в установленные законом сроки — как правило, не более 30 календарных дней с момента выявления. Внутренний SLA на разбор кейса должен оставлять достаточный запас для подготовки и подачи отчета.
Три практических принципа при внедрении SLA. Автоматическая эскалация: если кейс не закрыт в рамках SLA, он автоматически передается руководителю комплаенс-подразделения или MLRO. Визуальный мониторинг: дашборд с текущим статусом кейсов, распределением по срокам и долей просроченных позволяет выявлять узкие места до того, как они станут системной проблемой. Регулярный пересмотр: раз в квартал анализируется фактическое время закрытия, доля просрочек и причины задержек, нормативы и ресурсы корректируются.
Фиксированные SLA превращают разбор совпадений в измеримый и управляемый процесс. Для клиента это означает предсказуемые сроки онбординга даже при наличии совпадений. Для регулятора — доказательство того, что организация контролирует свои комплаенс-процессы и реагирует на риски своевременно.
Как измерять влияние AML на скорость онбординга
AML-проверки защищают бизнес от регуляторных санкций и финансовых потерь, но одновременно создают дополнительный шаг в клиентском пути. Если не отслеживать, как скрининг влияет на время и конверсию, легко попасть в одну из двух ловушек: ослабить контроль ради скорости или потерять клиентов ради формального соответствия. Выход — зафиксировать набор метрик, которые покажут реальное состояние процесса и укажут на точки, требующие корректировки.
Каждая метрика привязана к конкретному этапу воронки — от первого запроса до выдачи финального решения. Измерять нужно не «работу AML-модуля изолированно», а его вклад в общий цикл онбординга.
Время первого ответа и время финального решения
Для оценки скорости AML-скрининга полезно разделить два показателя: время до первого ответа системы (FRT, first response time) и время до финального решения (TTD, time to decision).
FRT фиксирует, за сколько секунд AML-система возвращает результат автоматической проверки — совпадения по спискам, PEP-статус, adverse media. В решениях с API-интеграцией ориентир — менее одной секунды. Отдельные платформы обрабатывают запросы за 60–250 миллисекунд при высокой нагрузке. Если FRT превышает 2–3 секунды, это уже ощутимо для пользователя и может спровоцировать отказ от регистрации, особенно в мобильных сценариях.
TTD учитывает полный цикл: автоматическую проверку, разбор совпадений (если они есть), ручную верификацию и вынесение итогового решения. Для клиентов без совпадений TTD практически совпадает с FRT — решение выносится мгновенно. Для кейсов с совпадениями TTD зависит от SLA на ручную проверку и сложности кейса. Разрыв между FRT и TTD — главный индикатор узких мест: если автоматический ответ приходит за полсекунды, а финальное решение занимает часы или дни, проблема не в скрининге, а в операционном процессе разбора.
На дашборде стоит отслеживать медиану и 95-й перцентиль FRT, медиану и 95-й перцентиль TTD, а также разбивку TTD по типам результатов: «чисто» (без совпадений), «автоматически разрешено» (совпадение отклонено алгоритмом) и «ручная проверка». Перцентили информативнее средних значений, поскольку показывают, с какой задержкой сталкиваются клиенты в «хвосте» распределения.
Доля ручной проверки и доля ложных совпадений
Два связанных показателя определяют операционную нагрузку на комплаенс-команду: manual review rate (доля кейсов, уходящих на ручную проверку) и false positive rate (доля совпадений, которые оказались ложными).
Доля ручной проверки показывает, какой процент проверок не может быть закрыт автоматически. Чем выше показатель, тем сильнее AML влияет на общее время онбординга: каждый ручной кейс — это очередь, время ожидания и риск потери клиента. В зрелых системах ориентир — автоматическое закрытие до 90 % проверок без участия оператора. Если доля ручного разбора превышает 20–25 %, стоит пересмотреть настройки скрининга: пороги нечеткого совпадения, использование вторичных идентификаторов (дата рождения, страна, ИНН), стоп-слова и токенизацию.
Доля ложных совпадений — индикатор точности настройки системы. Ложное совпадение возникает, когда алгоритм сигнализирует о совпадении с санкционным списком или PEP-базой, но при разборе выясняется, что речь идет о другом человеке или организации. По данным PwC и ряда отраслевых исследований, доля ложных срабатываний в AML-скрининге достигает 90–95 %, а их ручной разбор съедает значительную часть операционных расходов на комплаенс. Снижение false positive rate хотя бы на 30–40 % за счет тонкой настройки алгоритмов сопоставления, нормализации данных и контекстных фильтров может кратно сократить время обработки очереди.
Эти метрики работают в паре: если false positive rate снижается, сокращается и manual review rate, а вместе с ними — TTD. Регулярный аудит ложных совпадений (какие имена, какие списки, какие алгоритмы вызывают наибольший шум) позволяет непрерывно улучшать качество скрининга без ослабления контроля.
Конверсия после AML-проверки
Финальная и наиболее показательная метрика — конверсия: какой процент клиентов, прошедших этап AML-скрининга, доходит до завершения онбординга. Этот показатель связывает комплаенс с бизнес-результатом и позволяет оценить реальную «стоимость» AML-проверки в терминах привлечения клиентов.
Конверсию после AML-шага следует считать отдельно от общей конверсии онбординга. Общая воронка включает множество этапов (загрузка документов, биометрия, liveness, заполнение анкет), и падение на любом из них маскирует влияние конкретного шага. Изолированная метрика «прошел AML — завершил регистрацию» показывает, сколько клиентов теряются именно на стадии комплаенс-проверки.
Причины потерь делятся на две категории. Первая — задержки: клиент уходит, не дождавшись результата ручной проверки. По данным отраслевых исследований, если процесс открытия счета занимает более 3–5 минут, уровень отказов может превышать 50 %. Вторая — отклонения: клиент получает отказ по результатам скрининга. Рычаги влияния у них разные: задержки решаются ускорением процесса, отклонения — корректностью данных и адекватностью порогов.
Для полноты картины полезно сравнивать конверсию в трех сегментах: клиенты, прошедшие скрининг автоматически (полностью автоматический путь); клиенты, попавшие на ручную проверку и дождавшиеся решения; клиенты, попавшие на ручную проверку и ушедшие до получения результата. Разрыв между первым и третьим сегментами — прямая оценка потерь, вызванных недостаточной автоматизацией.
Разрыв конверсии между полностью автоматическим путем и сегментом ручного разбора — прямой индикатор потерь, вызванных задержками в AML-скрининге. Если часть клиентов уходит, не дождавшись решения, проблема чаще всего не в самом скрининге, а в доле кейсов, попадающих к аналитику. Платформа NeuroVision обрабатывает запрос менее чем за секунду, а автоматизация скрининга и кейс-менеджмента позволяет закрывать до 90 % проверок без участия оператора — это сокращает ручную нагрузку на комплаенс-команду до 80 %.
Мы разберем ваш текущий процесс — от момента передачи данных в скрининг до финального решения — и предложим конфигурацию, которая сократит время полного цикла для стандартного потока. Интеграция AML-модуля через REST API занимает 1–2 дня, развертывание возможно в облаке или в вашем контуре. Вы получите измеримые ориентиры по FRT, доле автоматического одобрения и конверсии после каждого этапа воронки.
Все перечисленные метрики — FRT, TTD, manual review rate, false positive rate и конверсия после AML — отслеживаются регулярно и в динамике. Разовый замер полезен для диагностики, но реальную ценность дает мониторинг трендов: как изменения в настройках скрининга, обновления списков или рост объемов заявок влияют на каждый показатель. Такой подход позволяет находить баланс между скоростью онбординга и надежностью комплаенса не интуитивно, а на основе данных.
Скорость и комплаенс перестают конфликтовать, когда санкционный скрининг спроектирован как часть KYC-пайплайна, а не как отдельный шлагбаум после него. Разделение проверок на синхронный блокирующий контур и асинхронный мониторинг, автоматическая передача нормализованных данных из KYC в AML-модуль, многослойная фильтрация ложных совпадений и четкие SLA на разбор кейсов — эти архитектурные решения позволяют выполнить требования 115-ФЗ и рекомендации FATF, удерживая время автоматического ответа в пределах секунды и сохраняя конверсию на каждом этапе воронки.
Устойчивость модели определяется не однократной настройкой, а регулярным измерением: FRT, TTD, доля ручной проверки, false positive rate и конверсия после AML-шага показывают, где процесс работает штатно, а где накапливается операционное давление. Компании, которые отслеживают эти метрики в динамике и калибруют пороги скрининга на основе реальной статистики, получают управляемый комплаенс-процесс — предсказуемый для клиента, прозрачный для регулятора и масштабируемый вместе с ростом пользовательской базы.
