Как стать автором
Обновить

Специфические задачи Data Science в Банке

Время на прочтение7 мин
Количество просмотров5.9K
image

В течение последних пяти лет я проработал в Управлении Валидации моделей машинного обучения (machine learning, ML) в крупном банке и видел много «узких мест», которые возникают при разработке и валидации моделей.

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

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

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

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

Устоявшаяся банковская практика


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

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

Если клиенту присвоен статус дефолта, обычно говорят, что «клиент вышел в дефолт». С точки зрения процессов Банка это означает, что будут запущены определенные процедуры взаимодействия с клиентом. Возможно будет решаться вопрос о банкротстве заемщика, Банк попытается реализовать заложенное имущество, взыскать денежные средства с поручителей или продать долг должника коллекторам и т.д.

Так уж исторически сложилось, что ожидаемые потери от невозврата кредитов принято раскладывать на три компоненты:

EL = PD*EAD*LGD

где EL — expected loss, ожидаемые потери;
PD — probability at default, вероятность того, что заемщику будет присвоен статус дефолта в течение следующего года, начиная с даты оценки;
EAD — exposure at default, все те денежные средства, которые клиент на дату «выхода в дефолт» должен вернуть Банку, включая как выданную денежную сумму, так и проценты, штрафы и комиссии;
LGD — loss given default, доля от общей задолженности заемщика перед банком, которую Банк себе уже не вернет. То есть это чистая потеря для Банка;

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

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

Нет никакой истинной метки класса


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

Мы плохо знаем своего клиента


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

Наличие большого числа клиентов вызывает соблазн разбить их не сегменты, в рамках которых построить более «узкие» и в тоже время более точные модели. Но ведь разбиение на сегменты выполняется тоже по какому-то правилу, а это правило строится на все тех же данных о клиентах. И что мы имеем? А мы имеем пропуски в данных, а соотвенно не всегда можем даже понять к какому именно сегменту отнести того или иного клиента.

Регулятор требует делать модели интерпретируемыми


Говоря «регулятор», я имею в виду Центробанк, который требует делать модели понятными. Должен быть понятен не только сам прогноз, но и правила, по которым этот прогноз был сделан. Справедливости ради, скажу, что в большей мере такое правило касается только так называемых «регуляторных» моделей. Регулятор в целях обеспечения устойчивости банковской системы в целом постоянно мониторит деятельность банков по ряду ключевых показателей, среди которых, например, находится расчет достаточности капитала на покрытие непредвиденных потерь во время возможных экономических и финансовых кризисов.
Что означает требование к интерпретируемости? А означает оно, что в большинстве случаев придется довольствоваться моделями в виде логистической регрессии или дерева решений. Про нейронные сети, ансамбли, стекинги и прочие «современные» архитекторы придется забыть.

Прокрустово ложе устоявшейся банковской практики


Отраслевой стандарт де-факто требует оценивать ожидаемые потери как произведение трех величин: PD, EAD и LGD. Это справедливо только в том случае, когда события развиваются по одному и тому же сценарию. Клиент либо возвращает кредит, либо нет. В первом случае, считается что никаких потерь нет. Во втором же случае, предполагается наличие некоторой суммы под риском (EAD).

На практике, платежное поведение клиентов не сводится к двум простым вариантам, а граница между этими вариантами весьма условна. Заемщик может выйти в дефолт и через месяц, и через год, и через два, а затем после того, как ему присвоят статус «дефолт», вдруг вернуться к платежам и выплатить весь кредит. Более того, отклонения от графика платежей могут быть и по суммам и по срокам, с опережением или наоборот отставанием от графика. Финансовый результат для Банка во всех случаях будет разный.

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

На чем спотыкаются продвинутые data-driven альтернативы


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

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

В конечном итоге все движется к идее, когда для каждого пришедшего клиента будет почти мгновенно обнаруживаться наилучшее предложение (оптимальный банковский продукт), которое бы максимизировало CLTV (customer lifetime value) на заданном временном горизонте, либо иную метрику в зависимости от текущего состояния Банка и целей его стейкхолдеров.

Почему бы для решения вышеописанной задачи не применить мощную нейросеть (то есть пресловутый «искусственный интеллект»)? Перечислю несколько мешающих этому обстоятельств:

  • Центробанк требует, чтобы модели участвующие в расчете достаточности капитала применялись в «живом» кредитном процессе. То есть именно эти модели должны применяться в принятии решений о выдаче кредитов, быть интерпретируемыми и проходить ряд обязательных валидационных тестов;
  • базы клиентских данных постоянно расширяются и дополняются. Например, относительно новыми видами данных является биометрия, веб-аналитика, аналитика мобильных приложений, скоринг социальных сетей. Добавление новых атрибутов происходит в динамике, а соответственно исторических данных по ним у нас практически нет;
  • продукты и процессы Банка постоянно видоизменяются и требуется перерасчет CLTV по клиентам и расчет NPV (net present value) по новым продуктам. А для того, чтобы построить модель приемлемого качества надо подождать несколько лет, накопить исторические данные и вычислить фактические значения CLTV или NPV на выборке из реальных заемщиков

Итог


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

Порой кажется, что в банковскую область могут проникнуть компании извне с сильным data science и поменять правила игры. Но для того, чтобы выдавать кредиты, надо играть по уже существующим правилам, а следовательно становится Банком со всеми вытекающими последствиями. Круг замкнулся.

Появление нового крутого финтех-стартапа в кредитовании, по-видимому, в большей степени завязано на поиск лазеек в правовом поле, чем на внедрение инноваций в машинном обучении.
Теги:
Хабы:
-2
Комментарии0

Публикации

Истории

Работа

Data Scientist
63 вакансии

Ближайшие события