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

    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 и поменять правила игры. Но для того, чтобы выдавать кредиты, надо играть по уже существующим правилам, а следовательно становится Банком со всеми вытекающими последствиями. Круг замкнулся.

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

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 6 247 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 0

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

    Самое читаемое