Банк — это по определению «кредитно-денежная организация», и от того, насколько успешно эта организация выдает и возвращает кредиты, зависит ее будущее. Чтобы успешно работать с кредитами, нужно понимать финансовое положение заемщиков, в чем помогают факторы кредитного риска (ФКР). Кредитные аналитики выявляют их в огромных массивах банковской информации, обрабатывают эти факторы и прогнозируют дальнейшие изменения. Обычно для этого используется описательная и диагностическая аналитика, но мы решили подключить к работе инструменты машинного обучения. О том, что получилось, читайте в посте.



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

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

Почему бы не попробовать для этих целей машинное обучение? Так вполне можно улучшить расчет значимости факторов кредитного риска, говоря техническим языком — повысить на несколько процентных пунктов показатель Джини (Gini), по которому мы оцениваем точность прогнозных моделей. Чем лучше расчет ФКР, точнее оценка финансового состояния клиентов — тем выше качество кредитного портфеля банка. И тем ниже доля ручного труда.

Ход проекта


Для хранения больших данных выбрали Cloudera Hadoop, для доступа к сырым данным развернули Apache Spark и Apache Hive SQL, для координации и запуска потоков загрузки и расчета данных — Apache Oozie. С помощью Apache Zeppelin и JupyterHub визуализировали и исследовали данные. Помимо этого, использовали ряд библиотек машинного обучения, поддерживающих параллельную обработку — Spark MLIB, PySpark и H20.



На все это выделили семь узлов:

  • 3 master-узла с 64 Гб vRAM и 2 Тб дискового пространства у каждого
  • 3 data-узла с 512 Гб vRAM и 8 Тб у каждого
  • 1 узел для приложений со 128 Гб vRAM, 2,5 Тб



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

На первой стадии мы развернули инфраструктуру и подключили первые источники данных:

  • Корпоративное информационное хранилище (КИХ) – основное хранилище в банке. Чтобы свободно оперировать с данными в пределах Data Lake и не создавать нагрузку на продакшн-системы, мы загрузили его фактически целиком.
  • Система расчета рейтингов (СРР) – одна из основных баз данных для оценки рисков, связанных с деятельностью корпоративных клиентов. Содержит информацию о рейтингах предприятий, показатели финансовой отчетности.
  • Данные из внешних источников, отражающие аффилированность и другие критерии.
  • Отдельные файлы, содержащие дополнительную информацию и данные для работы дата-сайентистов.

На второй стадии рассчитали первые ФКР, попробовали построить модели на основе этих показателей, установили BI-средство и обсудили как визуализировать динамику ФКР. В итоге решили сохранить привычную для пользователей структуру таблиц Excel в новом инструменте, оставив продвинутую визуализацию на будущее.

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

Результат


Кластер на Hadoop легко масштабируется и позволяет скармливать моделям больше данных, а они могут выполнять вычисления параллельно. Показатель Джини вырос — модели стали точнее предсказывать те или иные события, связанные с факторами кредитного риска.

Нашим аналитикам раньше приходилось обращаться в Департамент ИТ, чтобы мы написали SQL-запросы к корпоративному хранилищу, а потом обрабатывать модели на своих персональных компьютерах. А теперь пилотный кластер позволяет аналитикам писать запросы самостоятельно, то есть поднимать сырые данные и обрабатывать модели получается гораздо быстрее.

Планы


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

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

Комментарии (15)


  1. xmaster83
    23.07.2018 14:04

    Вы тут описали вначале что политика банка возвращать кредиты и спрогнозировать это, А как вы в нейронную модель загнали коллекторский отдел?


    1. tashanov
      23.07.2018 15:53

      На этом этапе мы пытаемся предугадать заранее – кому из клиентов можно давать кредиты, а кому – не стоит. Соответственно коллекторский отдел пока в планах.


    1. nikolayv81
      24.07.2018 10:59

      Это же про юридических лиц, с местом в data-lake под физиков не так всё хорошо (хотя и по «юрикам» — в КИХ может не хватать данных :)


  1. roryorangepants
    23.07.2018 14:27

    Спасибо за статью!
    Скажите, пожалуйста, правда ли, что в моделях кредитного скоринга не используются признаки, которые могут внести в модель дискриминирующий bias (например, пол и национальность)?


    1. tashanov
      23.07.2018 15:54
      +1

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


      1. roryorangepants
        23.07.2018 15:57

        Спасибо за ответ.

        но в целом для нас проблемы дискриминирующих признаков неактуальны.

        А по какой причине? Вы считаете, что использование подобных признаков корректно, или ни один подобный признак не сработал для вас как хороший предиктор, и поэтому вам просто неважна эта проблема?


        1. tashanov
          24.07.2018 11:10

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


          1. roryorangepants
            24.07.2018 11:21

            Я понимаю, но вы написали:

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

            И вторая часть воспринимается так, будто проблемы нет и для не корпоративных клиентов.
            Или я неправильно понял?


  1. nikolayv81
    24.07.2018 11:01

    Жаль для физиков нет, а то очень удивляют звонки от call-центра с заманчивыми предложениями, которые явно основаны «не на тех данных».


  1. WTYPMAH
    24.07.2018 11:29

    А детали самой модели покажите? Какие методы, как потимизировались, тестировались, отбирались переменные, какие результаты? Без этого не очень похоже на тему для хаба Машинное обучение…


    1. tashanov
      24.07.2018 12:54

      Модель базируется на ФКР (факторах кредитного риска), которые мы (как банк) раскрывать не можем. В посте же речь скорее об инфраструктуре для эффективного построения моделей data science аналитиками, которые работают в рисках.


      1. WTYPMAH
        24.07.2018 14:54

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


        1. tashanov
          24.07.2018 18:36

          В большинстве случаев ФКР разрабатываются на основе экспертных суждений, и впоследствии тестируются в рамках моделей прогнозирования дефолтов. Основной инструмент (алгоритм) для моделирования – обычная логрегресссия, что позволяет получить интерпретируемые результаты. Мы в рамках пилота пробовали различные алгоритмы (случайный лес, градиентный бустинг), которые позволяют улучшить качество моделей (+несколько пунктов Джини), но при этом модель теряет в интерпретируемости.


  1. vagon333
    24.07.2018 23:55

    Интересная статья. Вопрос насчет эффективности решения.
    Не нашел у решения анализ эффективности и коррекцию алгоритмов.
    В банковском кредитовании «action plan» (US market), т.е. работа над ошибками и коррекция процессов — обязательный этап. У вас этот этап не описан. Это для простоты описания или не внедрено?


    1. tashanov
      25.07.2018 12:42

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