Как я создал ML-пайплайн для поиска подозрительных транзакций

Подробности изложены в материале первоисточника. С ростом объемов банковских транзакций ручной разбор сигналов систем финмониторинга становится непосильной задачей для сотрудников, особенно учитывая, что подавляющее большинство срабатываний оказывается ложным. Меня зовут Максим Коцюба, и я разработал сквозной ML/MLOps-контур для риск-ориентированного ранжирования операций, решив отойти от простой бинарной классификации.

За годы развития банковского сектора объем платежей по картам многократно увеличился, в то время как количество кредитных организаций заметно сократилось, что привело к колоссальному росту нагрузки на каждый финансовый институт. Применяемые повсеместно традиционные механизмы на основе фиксированных правил генерируют огромный поток ложных тревог, отнимая большую часть рабочего времени комплаенс-отделов. При разработке проекта мы с научным руководителем, доцентом ФКН НИУ ВШЭ Салехом Хади Мухаммедом, тщательно взвешивали альтернативные подходы, включая готовые коммерческие решения вроде SAS AML и NICE Actimize, но каждое из них имело свои критические ограничения по гибкости, прозрачности или автономности.

Почему нужен именно сквозной пайплайн, а не просто модель

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

Почему ранжирование, а не бинарная классификация

На этапе проектирования системы я рассматривал классический подход с бинарным ответом и риск-ориентированное ранжирование. Из-за сильнейшего дисбаланса классов, когда доля реальных нарушений в датасете составляет доли процента, фиксированный порог отсечения 0,5 становится бесполезным для реальной эксплуатации. Гораздо эффективнее использовать модель для вычисления риск-скора и построения приоритизированной очереди, где самые опасные транзакции выводятся наверх. Эксперименты на специализированных наборах данных подтвердили, что метрики вроде Precision@k и Lift@k позволяют максимально точно оценивать качество работы алгоритмов.

Как контур вписывается в процесс финансового мониторинга

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

Что внутри

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

Верхний интерфейсный слой реализован на Streamlit для удобного просмотра результатов анализа. За оркестрацию вычислительных задач отвечает Apache Airflow, управляющий отдельными пайплайнами (DAG), в то время как MLflow фиксирует параметры, артефакты и метрики всех проведенных экспериментов. Для выдачи предсказаний в реальном времени или пакетном режиме задействован REST API на FastAPI, а за хранение метаданных и тяжелых файлов отвечают PostgreSQL и MinIO.

Как происходила реализация

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

Что происходит внутри обучающего DAG

Процесс обучения запускается оркестратором, фиксирующим начальный статус выполнения, после чего обучающий пайплайн выполняет расчеты, а MLflow параллельно логирует все гиперпараметры. По завершении работы алгоритмов система сохраняет спецификацию признаков и сводку обучения, отбирая лучшую модель по метрике valid PR-AUC для упаковки в production-файл. На завершающем этапе срабатывает защитный механизм: система пытается зарегистрировать новую версию в MLflow Registry, и даже при возникновении сбоя на этом шаге общий пайплайн не падает, сохраняя остальные артефакты.

Как устроены сами эксперименты

Блок бенчмарков управляется отдельным сценарием aml_benchmark_dag, где проверяются различные конфигурации данных и алгоритмов градиентного бустинга — LightGBM и XGBoost.

В ходе тестирования исследовались базовый набор признаков (raw) и расширенный набор после процедур feature engineering (engineered), а также внешние датасеты и специализированный набор SAML-D. Все метрики и обученные конфигурации автоматически фиксировались для последующего анализа эффективности.

Как считали

Эффективность каждого сценария оценивалась комплексно: с помощью стандартных метрик классификации и ранжирования ROC-AUC, PR-AUC, Precision, Recall, а также специализированных top-k показателей для верхней части риск-очереди. Дополнительно измерялось время, затрачиваемое на обучение моделей и выполнение инференса.

Усложнение признаков себя не оправдало

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

Дрейф данных — не абстрактная угроза, а то, что реально ловится

Для контроля актуальности моделей в контур был встроен ежедневный мониторинг статистического сдвига распределений (data drift). Анализ шестидесяти четырех признаков позволил обнаружить заметные изменения лишь в двух параметрах — возрасте клиента и производном признаке, связанном с датой рождения и активностью. Появление подобных сигналов служит для команды четким индикатором того, что модель пора отправить на переобучение.

Модель концентрирует подозрительные операции в верхней части очереди

Оценка качества ранжирования показала впечатляющие результаты: в топ-100 операций риск-очереди доля реальных нарушений достигала 70–77% в стандартных сценариях и абсолютных значений на специализированных датасетах. Использование метрики Lift продемонстрировало, что алгоритмы поднимают потенциально опасные транзакции наверх в десятки раз эффективнее случайного отбора.

Модель объясняет себя, а не просто выдаёт цифру

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

Главное — не модель, а контур вокруг неё

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