AML-система для банка: 7 ключевых задач и инструменты для их решения

Финансовые регуляторы ужесточают требования, объемы транзакций растут, а схемы отмывания денег усложняются. Поэтому выбор AML‑системы становится стратегической задачей для банков, представителей финтеха и других регулируемых организаций.

Ключ к выбору — понимание, какие задачи должна закрывать система и какими модулями это обеспечивается. В этом материале директор продукта TALYS.AML в компании Data Sapience Елена Куприянова поможет разобраться в вопросе и решить, какой инструмент нужен конкретно вашей организации.

• Мониторинг деятельности клиента

Основная задача AML‑системы — выявление подозрительного поведения в рамках № 115-ФЗ. Если раньше анализировали в основном транзакции, то сейчас мониторинг включает и нефинансовую активность: входы в личный кабинет с фиксацией IP‑адресов, запросы баланса в банкоматах и другие события, которые могут дополнять картину риска.

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

• Оценка комплаенс‑риска клиента (риск‑ориентированный подход)

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

Для AML‑решения принципиально наличие инструментов, которые позволяют: 

• загружать и поддерживать риск‑факторы; 
• рассчитывать риск‑уровень клиента; 
• использовать риск‑оценку при расследовании и принятии решений по инцидентам.

Риск должен обновляться регулярно и опираться на сочетание динамических критериев (операции/активность клиента) и статических критериев (профиль и характеристики). Чем больше релевантных классификаторов и источников учтено, тем точнее риск‑профиль.

• Расследования и кейс‑менеджмент (документооборот)

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

• Скрининг по спискам особого контроля («санкции») и снижение ложных срабатываний

Оценка риска и мониторинг контрагентов практически всегда включают фильтрацию по спискам особого контроля. Из‑за роста числа списков важна не только загрузка/обновление, но и качество сопоставления.

AML‑система должна уметь:

• загружать и поддерживать множество списков и справочников;
• сравнивать данные клиентов и контрагентов со списками;
• извлекать данные из текстовых полей и сопоставлять их, в том числе с применением нечеткой логики (для вариативности написания ФИО/наименований).

Чтобы не «утонуть» в алертах, необходимо их оптимизировать с помощью белых списков и подавления повторных инцидентов: если паттерн уже проверен и признан нормальным для конкретного клиента, система не должна постоянно генерировать одинаковые уведомления.

• Регуляторная отчетность

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

• Выявление финансирования терроризма

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

• Интеграции, качество данных и способ их представления в системе

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

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

• Движок онлайн‑контроля (real‑time) с возможностью приостановки операций

Чтобы выполнять качественный мониторинг до проведения платежа, нужен движок, который обрабатывает поток событий в режиме реального времени, умеет приостанавливать/блокировать операции по правилам, интегрируется с ДБО и процессингом, позволяет разрабатывать и тестировать правила в удобной среде (в том числе в графическом интерфейсе) прямо на потоке. Все описанные функции доступны в системе TALYS.AML. Важный момент: онлайн‑контроль должен анализировать не только отдельную операцию, но и историю и последовательность событий в режиме реального времени, иначе часть схем будет проходить незамеченной.

• Графические интерфейсы расследования и документальной фиксации

Расследования часто остаются преимущественно ручными, и основная потеря времени — в сборе контекста и оформлении решения. Поэтому нужен «единый экран», где комплаенс‑офицер может видеть данные о клиенте, счетах и транзакциях, понимать причины автоматического выявления, запрашивать документы у клиента, видеть историю по клиенту и принятые ранее решения, в результате применять меры (ограничения, изменения уровня риска, добавление в списки) и автоматически формировать мотивированное обоснование. Также важна возможность подключать внешние источники (например, СПАРК, Контур.Фокус и аналогичные сервисы) вместе с внутренними системами банка. Решение TALYS.AML предоставляет данные возможности.

• Инструменты машинного обучения и углубленной аналитики + поддержка ModelOps

По мере усложнения схем одной только онлайн‑проверки и сценариев недостаточно, требуется углубленная аналитика. При этом ML в ПОД/ФТ — это непрерывный цикл разработки, тестирования, ввода в эксплуатацию и сопровождения (ModelOps). Практически важны инструменты, которые упрощают настройку и публикацию моделей, контроль качества и обновление моделей, прозрачность результатов для комплаенса. Увидеть реальные результаты от внедрения платформы аналитики данных, машинного обучения и LLM/MLOps на примере Kolmogorov AI можно в совместном кейсе от Data Sapience и GlowByte.

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

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