Как повысить качество AML-контроля без бесконечного роста правил

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

Обычно проблема возникает сразу в трех местах. Данные о клиенте распределены между системами и плохо связаны. Сигнал сообщает о сработавшем условии, но не объясняет общую картину риска. Расследование остается ручным и требует переключения между источниками. Поэтому качество AML-контроля определяется не количеством отдельных технологий, а тем, насколько данные, аналитика и процесс принятия решения работают вместе.

Масштаб задачи в Центральной Азии показывает Basel AML Index 2025. Чем выше балл по шкале от 0 до 10, тем выше уязвимость страны. Простое среднее по пяти странам региона составляет 5,92 против 5,28 в среднем по миру. Туркменистан набрал 6,73, Таджикистан 6,44, Кыргызстан 5,96, Узбекистан 5,27, Казахстан 5,18. Индекс оценивает не объем отмывания денег, а уязвимость страны и способность ее системы противодействовать финансовым преступлениям, и качество контроля в отдельном банке он не измеряет. Но он задает фон: от банков региона, как правило, ждут подтверждаемого качества контроля, а разброс оценок между соседними странами означает, что банковская группа не может применять один и тот же подход ко всем юрисдикциям.

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

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

Здесь появляется организационный вопрос, который часто недооценивают. Служба финансового мониторинга видит последствия плохих данных, но не всегда управляет системами, в которых они возникают. Поэтому для критичных атрибутов нужны владельцы на стороне бизнеса и ИТ, правила исправления и срок реакции на дефект. Без такой ответственности команда AML будет компенсировать проблемы ручной работой, а качество профиля станет зависеть от опыта конкретного аналитика.

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

Поэтому начинать стоит не с новых правил, а с ревизии действующих. Для каждого сценария полезно посчитать, сколько алертов он создает, какая их доля закрывается без вывода, сколько срабатываний дублирует другие правила и сколько значимых кейсов он выявил за период. Сценарии, которые не дают значимых кейсов или полностью перекрываются другими, можно объединить или отключить по согласованной процедуре, проверив на исторических данных, что покрытие не снижается. Пороги уместно задавать по сегментам клиентов, а не единым значением для всех, а несколько срабатываний на одно событие стоит группировать в один кейс. Так очередь сокращается без потери покрытия, а новые правила добавляются только там, где пробел подтвержден данными.

Одновременно финансовые схемы становятся многоканальными. В сентябре 2026 года FATF сообщила, что профессиональные сети отмывания используют банковские счета, финтех-платформы, платежных провайдеров, виртуальные IBAN, предоплаченные карты и виртуальные активы как точки входа и выхода. В таких случаях анализ одной транзакции нужно дополнять историей поведения и движением средств между участниками.
Машинное обучение — один из методов ИИ, который можно использовать в AML для анализа поведения, поиска аномалий и ранжирования сигналов. ML-модель имеет смысл применять, когда у банка есть достаточная история проверенных кейсов и понятный критерий качества. Если лишние алерты возникают из-за дублей данных, устаревшего порога или ошибки интеграции, сначала нужно устранить исходный дефект.

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

Помимо ML-моделей, в AML применяют ИИ-ассистентов и ИИ-агентов. Ассистент помогает аналитику по запросу: объясняет причины срабатывания, обобщает предоставленные материалы или готовит черновик заключения. Агент получает задачу и в пределах заданных полномочий сам определяет последовательность действий: выбирает разрешенные источники, запрашивает недостающие сведения, проверяет результат и передает материалы аналитику. Его самостоятельность касается выполнения задачи, а не окончательного решения по AML-кейсу.

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

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

Окончательное решение по AML-кейсу принимает уполномоченный сотрудник банка. Банк ограничивает доступ и действия ИИ, журналирует операции и хранит версии моделей и промптов, чтобы любой вывод можно было воспроизвести при проверке. Эффект оценивают по качеству сигналов, состоянию очереди и нагрузке на аналитиков.

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

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

В каждой стране Центральной Азии действуют собственные требования ПОД/ФТ, включая правила расследования, документирования, сроки и форму сообщений в уполномоченный орган. Поэтому ускорение расследования не должно снижать полноту фиксации. Управлять процессом помогают медианное время обработки кейса, доля возвратов на доработку, нагрузка по ролям, соблюдение внутренних сроков и полнота обязательных полей.

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

Замена оправданна, если правила трудно обновлять, интеграции нестабильны, алерты не связаны с кейсами, а история решений хранится разрозненно. Но даже при очевидных технических ограничениях нужно оценить стоимость миграции, перенос истории, непрерывность контроля и готовность команды изменить операционную модель.
Для банковской группы выбор дополняется региональным измерением. Общими могут быть модель данных и аналитическая архитектура, но списки, сценарии и отчетность должны учитывать каждую юрисдикцию. Отдельный вопрос — движение данных внутри группы. Банковская тайна, требования локализации и ограничения на трансграничную передачу персональных данных могут не позволить собрать профиль клиента в одном центре. Поэтому до проектирования единой модели нужно определить, какие атрибуты допустимо передавать между дочерними банками, а какие остаются в стране и обрабатываются локально, передавая в центр только агрегированные признаки или оценки риска. Архитектура должна позволять менять локальные процедуры без перестройки всей платформы.

В проектах Databorn мы используем последовательность из четырех этапов. Ее смысл в том, чтобы подтвердить проблему и измерить эффект до масштабного изменения архитектуры.

Этап 1: Диагностика
Сначала фиксируются источники, идентификаторы, действующие правила и путь сигнала до решения. Одновременно рассчитывается исходный уровень: объем и возраст очереди, доля релевантных (закончившихся значимым выводом, например эскалацией или сообщением в уполномоченный орган) и повторных сигналов, время обработки кейса и основные разрывы в данных. Без этой точки отсчета банк не сможет отделить реальное улучшение от изменения способа расчета.

Этап 2: Подготовка данных
Подключаются приоритетные источники, формируется общая модель, настраиваются проверки полноты и сопоставление сущностей. Переход к аналитическому пилоту оправдан, когда банк подтвердил качество ключевых атрибутов, приемлемый уровень дублей и стабильность поставки данных.

Этап 3: Пилот
Для пилота выбираются несколько сценариев, по которым есть исторические кейсы и понятный критерий результата. Новое правило, ML-модель или ИИ-компонент сравниваются с действующей очередью. Команда оценивает не только точность, но и объяснимость результата, влияние на нагрузку и способность аналитика воспроизвести основание риск-оценки.

Этап 4: Промышленное внедрение
Проверенные сценарии интегрируются с алертами, кейсами и отчетностью. Настраиваются роли, журналирование, контроль качества данных, моделей и ИИ-компонентов, а также порядок внесения изменений. После запуска результат продолжает оцениваться по итогам расследований, а не только по техническим характеристикам решения.

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

Подход Databorn объединяет данные, потоковую обработку, аналитические компоненты и процессы принятия решений в едином технологическом контуре. Конкретная архитектура зависит от того, сохраняет ли банк действующую AML-систему или создает новый целевой контур.

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

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

Где теряется контекст? В источниках, идентификаторах, интеграциях или уже внутри расследования.

Какие сигналы действительно полезны? Это покажут результаты завершенных проверок, доля дублей и состояние очереди.

Что замедляет решение? Недостаток данных, качество сценариев, ручной сбор материалов или лишние согласования.

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

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

Эффект автоматизации лучше оценивать на конкретном процессе, а не по общим обещаниям. Самая трудоемкая часть расследования обычно не оценка риска, а подготовка материалов: сбор данных из разных систем, сверка с внутренними правилами и нормативными требованиями, оформление заключения. Именно здесь ИИ-агенты и ассистенты дают наибольший выигрыш, если финальную проверку выполняет сотрудник. Базовые значения фиксируются на этапе диагностики: время подготовки материалов по кейсу, доля заключений, принятых аналитиком без доработки, число кейсов на аналитика. Целевые значения задаются на пилоте на данных конкретного банка и не переносятся из чужих примеров.

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

Задача Databorn — помочь банку выбрать архитектуру, связать платформу с источниками и процессами и проверить эффект на измеримых показателях. Именно целостность решения позволяет развивать автоматизацию за пределами отдельных ИИ-инструментов.