Data Science на страже закона: как мы автоматизировали финансовый мониторинг в ПУМБ

Всем привет! Меня зовут Автандил, я Data Scientist в банке ПУМБ.

Первый украинский международный банк (ПУМБ) на рынке с 1991 года, является универсальным банком и входит в топ-5 крупнейших банков Украины по версии «50 ведущих банков Украины». Обслуживает 1,6 миллиона клиентов, операционная прибыль в 2020 году составила 2,6 млрд грн.

Пару слов о себе и команде Data Science. К ПУМБ я присоединился в 2018 году, заняв позицию ad-hoc аналитика управления Business Intelligence (BI). В 2020 году было принято решение о создании Data Science подразделения. Основанием для этого стал целый пул задач от бизнеса, которые требовали применения отличных от BI подходов и инструментов. Наша команда занимается разработкой моделей для привлечения клиентов, рекомендации новых продуктов, распознавания документов, предотвращения мошенничества и так далее.

Я возглавляю направление, в котором отвечаю за антифрод и финансовый мониторинг. Сегодня расскажу о том, как мы упростили процесс выявления потенциальных НВР-клиентов (НВР — неприемлемо высокий риск) для финансового мониторинга (далее ФМ) с помощью Data Science. Поехали!

Бизнес-ситуация и проблема

Мы хотели не просто «выкатить» в production еще одну модель, а сделать действительно удобный продукт для бизнеса. Поэтому перед стартом разработки исследовали то, как сейчас выглядит процесс выявления НВР-клиентов.

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

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

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

При этом проблема для ФМ — недостаточное количество своевременно обработанных потенциальных НВР-клиентов, поскольку:

• проводится ручной мониторинг и анализ отчетов/выборок/сценариев;
• у сотрудников ФМ нет физической возможности обработать большое (~1,6 млн) количество клиентов и их транзакций;
• отсутствует модель (нестандартная, многофакторная), которая может прослеживать тенденцию «усложнения» рисковых клиентов.

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

Таким образом, автоматизация процесса выявления потенциальных НВР-клиентов — это необходимость для современной службы финансового мониторинга.

Решение

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

В упрощенном виде процесс построения модели машинного обучения выглядит так:

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

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

Подготовка набора данных

Для построения модели машинного обучения (ML) были использованы наши внутренние данные:

• таблица с перечнем клиентов банка;
• таблица с демографическими данными по клиентам (возраст, пол, образование, место работы и так далее);
• таблица о транзакционной активности клиента за два года (снятие денежных средств в банкоматах, переводы с карты на карту (P2P), переводы от юридических лиц);
• таблица разметки НВР/неНВР от ФМ.

На ежедневной основе данные из production-систем загружаются в хранилище данных (DWH).

При подготовке набора данных мы столкнулись с проблемой объема, так как после обогащения таблицы клиентов данными по транзакциям получался огромный датасет (1,6 млн клиентов * 720 дней = 1 152 млн записей). Текущая архитектура не позволяла нам обработать такой массив данных. Решением проблемы стал отбор части клиентов для будущей модели. Мы сформировали список из всех НВР-клиентов, дополненный «хорошими» клиентами в соотношении 1:10. В результате полученный набор данных содержал ~6 млн записей.

Первая итерация: Baseline model

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

В качестве базы мы использовали математический baseline — прогнозируем всех клиентов наиболее рисковым классом (НВР).

Для оценки работы модели нужны две метрики:

• ML-метрика — для валидации и тюнинга гиперпараметров модели.
• Бизнес-метрика — для оценки влияние модели на бизнес-показатели.

Решающим фактором при выборе метрик стал дисбаланс классов — НВР-клиенты составляют менее 1% от общего количества записей в наборе данных.

Как ML-метрику взяли логистическую функцию потерь (log loss).

Как бизнес-метрику взяли сбалансированную точность (balanced accuracy). Для простоты понимания — это средний процент верно предсказанных клиентов по «хорошим» (не НВР) и «плохим» (НВР) клиентам.

В статье мы будем рассматривать только результаты по бизнес-метрике.

Прежде чем вычислять базовый уровень, нужно разбить данные на обучающий и тестовый наборы:

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

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

Для обучения используем 80 % данных, а для тестирования — 20 %. Разделение делали по отсортированным по дате календаря записям, так как есть временная зависимость.

Сбалансированная точность на тестовом наборе ПО baseline-модели составила 50%. Как считали?

(Точность по «хорошим» клиентам — 0% + точность по «плохим» клиентам — 100%)/2 = 50%. Baseline решает проблему штрафов, поскольку мы предскажем всех НВР-клиентов, но невозможен для реализации с точки зрения обработки такого количества ФМ и жалоб от «хороших» клиентов.

Вторая итерация: ML-модель, работа с качеством данных

На данной итерации мы реализовали ML-модель.

Ключевой задачей стала работа с качеством данных. В процессе анализа набора нашли массу ошибок (некорректный возраст, неправильно собранные данные по транзакционной активности и так далее).

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

Для решения задачи использовали алгоритм машинного обучения «Случайный лес» (Random Forest). RF (Random Forest) — это множество решающих деревьев. В задаче регрессии их ответы усредняются, в задаче классификации принимается решение голосованием по большинству. Все деревья строятся независимо.

Мотивацией для использования этого алгоритма было то, что Random Forest:

• способен выявлять нелинейные связи в данных;
• устойчив к выбросам в данных и дисбалансу классов;
• позволяет получить неплохой ML-baseline без/с минимальным тюнингом гиперпараметров модели.

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

Результат по бизнес-метрике 66,50%. +16,5% в сравнении с baseline! Неплохой старт.

Для коллег из ФМ разработали отчет на Power BI. Процесс выявления НВР-клиентов по результатам итерации.

Третья итерация: разработка новых признаков на основании анализа прогнозов и ошибок модели

Ключевым тут стал анализ прогнозов и ошибок модели.

Работу мы вели в трех направлениях:

• анализ лучших кейсов по предсказанию — дал понимание, как модель принимает решение;
• анализ худших кейсов (целевая переменная = «НВР», предсказание = «неНВР») — дал понимание, где модель ошибается. Совместно с доменными экспертами ФМ мы разобрали кейсы и добавили в набор данных необходимые признаки для корректного предсказания;
• анализ худших кейсов (целевая переменная = «неНВР», предсказание = «НВР») стал базой для 4-й итерации. Мы сформировали список клиентов, так называемой серой зоны (клиенты НВР, не размеченные как НВР) и отправили для проработки ФМ.

Результат по бизнес-метрике 88,50%. Можно еще круче?

Четвертая итерация: переразметка целевой переменной

Целью этой итерации была максимальная минимизация серой зоны. По результату консультаций с доменными экспертами ФМ мы применили ряд правил для автоматической очистки и переразметки датасета.

Результат по бизнес-метрике 99,34%. Вау!

Что получил бизнес по результатам 4-х итераций:

• увеличили количество проанализированных клиентов без увеличения штата сотрудников подразделения;
• ускорили время выявления клиентов с признаками НВР;
• получили возможность ранжировать и фокусировать внимание сотрудников на клиентах с наибольшим количеством признаков рисковой деятельности;
• уменьшили количество анализируемых существующих отчетов + минимизировали заказ новых;
• модель помогает прослеживать тенденцию «усложнения» рисковых клиентов, которых по отчетам/выборкам/сценариям сложнее выявить вручную.

Планы: что еще будем улучшать

На текущий момент модель работает в так называемом human supervision режиме, то есть под контролем сотрудников ФМ и без автоматической блокировки клиентов с высокой вероятностью НВР. В случае успешной работы модели в таком режиме в течение полугода хотим разработать сервис и внедрить наше ML-решение в процессы банка.

В планах также попробовать:

• применить нейронные сети для нашей задачи, что позволит предсказывать НВР-клиентов еще точнее;
• обучить автоэнкодер, что позволит минимизировать серую зону.

На сегодня всё, спасибо за внимание!