Top.Mail.Ru
Колонки

Анализ больших данных помогает нам выявлять «сомнительных» клиентов. И вот как

Колонки
Андрей Созыкин
Андрей Созыкин

Разработчик в банке «Точка»

Полина Константинова

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

Анализ больших данных помогает нам выявлять «сомнительных» клиентов. И вот как

Зачем это нужно?

Банки, которые обслуживают юридические лица и индивидуальных предпринимателей, должны выполнять требования регулирования. Одно из важных требований содержится в законе 115-ФЗ «О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма». Банк должен проверять платежи всех клиентов на соответствие этому закону. Если он делает это плохо, то у него могут отозвать лицензию. Таким образом очень важно выявлять клиентов, которые выполняют сомнительные платежи, и применять к ним меры противодействия легализации доходов, вплоть до закрытия счета.

Как по операциям определить, что клиент «сомнительный»? Центральный Банк выпускает методические рекомендации. Их достаточно много, среди наиболее важных признаков сомнительных клиентов можно указать:

  • налоговая нагрузка меньше 0,9% к дебетовому обороту (сумма исходящих платежей);
  • не платится зарплата, аренда и другие типичные платежи;
  • остатки денег на счете малы по сравнению с оборотом;
  • назначения поступлений на счет не совпадают с назначениями затрат;
  • деньги приходят с НДС, а уходят без.

От онлайн-проверки операций до анализа больших данных

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

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

Другой недостаток онлайн-проверки заключается в том, что она выполняется по набору правил для выявления типичных «схем».

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

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

Как мы анализируем платежи с помощью больших данных

Для реализации предлагаемого решения использовался кластер Hadoop из пяти узлов. Исходные данные представляют собой таблицы в Hive/SparkSQL. Программы расчета показателей реализованы на Python и выполняются в кластере с помощью PySpark.

Всего мы рассчитываем более 140 различных показателей. Среди них есть как показатели, рекомендуемые ЦБ, так и подобранные нами самостоятельно. Мы построили графы платежей сомнительных клиентов и нашли некоторые закономерности. Например, деньги перечисляются юридическому лицу (ООО), которое затем отправляет их большому количеству ИП. В отличие от юридических лиц, ИП имеют полное право снимать наличные со своего счета. В случае недобросовестных компаний, ИП снимают наличные и передают их обратно отправителю платежа.

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

Сложность, с которой мы столкнулись при разработке программ, связана с несогласованностью API Spark SQL и Spark Data Frame.

Например, в Spark Data Frame API нет функции для расчета медианы, а медиана остатка на счету лучше позволяет выявить клиентов, занимающихся «транзитом», чем среднее значение остатка. Функция расчета медианы есть в Spark SQL, поэтому наш код содержит смесь SQL-запросов и вызовов Spark Data Frame API. Поддерживать и отлаживать такой код не очень удобно.

Рассчитанные с помощью программы на PySpark показатели передаются в модель машинного обучения. Мы использовали обучение с учителем, задача классификации, два класса: «плохие» — компании, которым закрыли счета за нарушение 115-ФЗ, «хорошие» — все остальные. Обучение выполнялось на данных за второй квартал 2018, тестирование на июле 2018.

Мы пробовали несколько моделей: логистическая регрессия, решающее дерево, нейронная сеть и XGBoost. Лучше всего заработали логистическая регрессия и XGBoost. Качество XGBoost выше, но логистическая регрессия интерпретируема.

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


Сомнительные компании найдены, что дальше?

Если модель машинного обучения показывает, что компания «подозрительная», что дальше с ней делать? Модель находит компании, отличающиеся от законопослушных, но не обязательно, что они нарушают закон! Возможно, у компании есть счет в другом банке, налоги и зарплата платятся там. Или платежи обусловлены характером бизнеса.

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

Итоги

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

В предложенном решении используются совместно большие данные (расчет 140 показателей платежей всех клиентов банка за 3 месяца) и машинное обучение (анализ предварительно рассчитанных показателей и определение сомнительных клиентов). Используемая ранее онлайн-проверка работает параллельно.

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


Кейс был представлен на Big Data Conference. Ответы автора колонки на вопросы аудитории, которые были заданы в ходе его выступления на конференции, опубликованы ниже.

1. Как боролись с несбалансированностью датасетов?

Датасеты подготовлены таким образом, чтобы в них было примерно 10% «сомнительных» клиентов. Этого оказалось достаточно, дополнительные меры по борьбе с дисбалансом классов не понадобились.

 

2. Много aml-щиков отмывают через новые компании/однодневки: что делать если юрлицо вчера зарегистрировано, и нет истории платежей/налоговой нагрузки?

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

 

3. Почему данные брали в csv, а не обращались за ними напрямую в базу данных?

Это первый этап реализации, в дальнейшем данные будут браться напрямую из кластера Hadoop.

 

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

Комплаенс и антифрод – это разные задачи. Для комплаенс сомнительным является клиент полностью, а не отдельные его операции. Поэтому если есть подозрение, что клиент сомнительный, то комплаенс-менеджер анализирует все операции клиента в совокупности, и при необходимости принимает меры по противодействию отмыванию доходов и финансированию терроризма (ПОД/ФТ), описанные в № 115-ФЗ.

 

5. Планируете ли переходить в онлайн-скоринг, и если да, то что для этого вам сейчас не хватает?

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

 

6. Почему не учитывали сезонность и почему не стекали алгоритмы?

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

Алгоритмы не стекировали, потому что XGBoost показал достаточную точность.

 

7. В какой программе строилась графовая аналитика по данной задаче? Какой процент «хороших» пользователей банка использовались в обучающей выборке?

Для графовой аналитики использовались пакет на Python NetworkX и программа визуализации графов Gephi.

В обучающей выборке было примерно 20% «хороших» компаний банка.

 

8. Почему использовали Спарк, а не все строили в Питоне?

Потому что расчет показателей выполняется долго, и эффективнее делать это в кластере, где расчет выполняется параллельно на нескольких серверах. Программы для Spark мы писали на Python, так что можно сказать, что все построено на Python :)

 

9. А какими инструментами пользуется сам Центробанк для определения сомнительных операций?

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

 

10. Есть требования к интерпретируемости происходящего?

Клиенты, которые выполняют «сомнительные» операции, делятся на две группы:

  • злонамеренные клиенты, сознательно выполняющие операции по отмыванию денег. Для таких клиентов не имеет значения, каким способом их выявили, поэтому интерпретация не нужна;
  • «хорошие» клиенты, которые сделали одну или несколько «сомнительных» операций. Как правило, такие операции выполняются из-за недостатков знаний законодательства и других областей. Таким клиентам нужно объяснить, что именно они сделали не так, и как они могут улучшить свое поведение. В этом случае нам важно уметь интерпретировать результаты работы модели, чтобы иметь возможность дать клиентам персонифицированные рекомендации.

Материал обновлен 25.09.2018 (добавлены ответы на вопросы аудитории конференции).


Материалы по теме:

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Эволюция ML-сервисов в микрофинансовых организациях и советы по внедрению
  2. 2 Цифровые двойники: как работают, зачем нужны и как смоделировать своего
  3. 3 С какими сложностями может столкнуться компания при внесении данных в IT-системы и как упростить этот процесс
  4. 4 Помощь агробизнесу. Как Big data улучшает работу сельхозпредприятий
  5. 5 Как использовать Big Data & AI для увеличения потока клиентов: кейс с крупным банком
DION
Что ждет рынок корпоративных коммуникаций в 2024 году?
Подробнее