Привет, Хабр! На связи — Ольга Кравченко, техдиректор по разработке моделей Газпромбанк.Тех. Сегодня я поделюсь кейсом, как наша команда создала инструмент, позволяющий нам продвигаться от просроченной задолженности к прибыли через персонализацию коммуникаций. Эта статья основана на моём выступлении на HighLoad++.
В нашем коллективе 11 человек: дата-сайентисты, дата-инженеры и специалисты автоматизации. Мы отвечаем за работу блока взыскания. Всё, что связано с просрочками, должниками, колл-центром, возвратом невозвратного — это наша вотчина для оптимизации и моделирования.
Зачем банку взыскание
Для стабильной работы и развития банка недостаточно выдачи новых кредитов или привлечения новых клиентов. Важно не только правильно выдавать кредиты, но и в дальнейшем сопровождать их жизненный цикл, особенно когда они достигают стадии задолженности.
Какое это имеет значение в моменте:
Снижение резервов — нет необходимости замораживать дополнительные средства на возможные потери.
Экономия ресурсов — можно избежать затрат на суды, сократить расходы на коллекторов, минимизировать потери времени колл-центра.
Возврат средств — банк получит хотя бы часть задолженности сразу или постепенно через программы реструктуризацию.
Улучшение показателей — качество кредитного портфеля и финансовые показатели банка повышаются, а нагрузка на капитал снижается.
Как это работает в долгосрочной перспективе:
Сохранение репутации банка в глазах клиентов, партнёров, конкурентов.
Поддержание лояльности клиентов — корректное и персонализированное взыскание помогает клиентам оставаться, возвращаться и идти на контакт.
Развитие инструментов помощи клиентам (рефинансирование, реструктуризация).
Основа для будущих прибыльных операций — там, где нравится одному, может понравиться многим.
Всё это звучит хорошо, но есть проблема: сложно организовать процессы так, чтобы было одновременно дёшево, быстро и качественно.
В любой задаче глобальной оптимизации пересекаются подобные круги, только их значительно больше. Так выглядит наше «колесо фортуны»:
В центре находится плюс-минус идеальный процесс возврата средств. Есть семь условий, с помощью которых этого удаётся достичь:
Доля урегулирования — это про деньги. Здесь важно начинать коммуникацию как можно быстрее, потому что время — деньги, как для банка, так и для клиента.
Объём урегулирования — это про клиентов, которые, как говорят в банке, «выздоровеют» и выйдут из стадии просроченной задолженности.
Лояльность клиентов — это главная опора банка, поэтому коммуникации должны быть персонализированными.
Нагрузка на колл-центр. Работники колл-центров — святые люди, но их мало, а работы у них много.
Затраты на коммуникации. Чем меньше денег мы тратим на СМС и звонки, тем лучше.
Стоимость решения. Часто, когда начинаются большие проекты, вносится дополнительное ПО и железо, но хорошо, если можно обойтись собственной инфраструктурой.
Дополнительные человеческие ресурсы. Здесь нам ничего не надо, у нас всё хорошо 🙂
Мы стали искать решение, которое бы соблюдало все эти условия.
В первую очередь разделили все хотелки на две части:
Оказалось, что сделать быстро, с минимальной стоимостью и своими ресурсами — это про архитектуру, а сделать эффективно, оптимально и без потери лояльности — про моделирование.
Мы приступили к реализации.
Про архитектуру
Начали с архитектуры. Чтобы понимать, как в банке хранятся и обрабатываются данные, лучше обратиться к платформе данных — комплексу автоматизированных систем хранения и обработки информации. Вот как она выглядит:
Разберём эту сложную систему по частям. Прежде всего, данные нужно откуда-то брать.
Банк использует множество источников данных, которые, если обобщать, можно разделить на два типа: внешние и внутренние. Загрузка производится пакетами или потоково. Любая автоматизированная система может поставлять данные на платформу данных и являться для неё источником.
В области хранения сырых данных у нас лежит автоматизированная система операционного хранилища данных.
Туда помещаются реплики систем источников для того, чтобы они хранились в исходном формате с учётом изменения. Операционное хранилище необходимо для унификации доступа к данным из различных систем-источников и для того, чтобы проводить оперативную аналитику данных.
В область детального слоя данные попадают уже в детальном, нормализованном, консолидированном и очищенном виде. Здесь у нас находится корпоративное хранилище данных (КХД) — предметно-ориентированная база, построенная по принципу DWH (data warehouse) для управления большими объёмами структурированных данных. Она имеет двухслойную архитектуру:
Область Stage хранит детальные данные в разрезе системы источников и является технической.
Область Core — детальные консолидированные данные, т. е. данные в одном экземпляре с исключением дублей по клиентам, счетам и договорам.
В области хранения — витрины пользовательских данных. В этом блоке хранятся данные, полученные путём преобразований над ядром.
Здесь в КХД находится пользовательская область с данными, view и процедурами, и различные витрины данных, где происходит расчёт показателей, агрегация и обогащение необходимых данных для потребителей. Отдельным блоком лежат OLTP-витрины (online transaction processing), чтобы убрать OLTP-нагрузку с основного хранилища.
В правой части схемы — область применения. Здесь находятся потребители данных: функциональные подсистемы, автоматизированные системы и в целом любые сотрудники банка.
Текущие и архивные записи операционного хранилища, областей Core и Stage КХД реплицируются в фабрику данных — корпоративную информационную платформу (здесь происходит сбор, хранение, обработка, аналитика супербольших объёмов данных, в том числе и неструктурированных). Здесь же лежат витрины Hadoop, на которых обучаются модели — о них расскажу подробнее ниже.
Для моделей, которые являются онлайн-сервисами, данные обрабатываются потоково и выгружаются в витрины операционного слоя.
Отдельным стеком располагаются платформы гео-, текстовой и графовой аналитики со своими визуальными интерфейсами.
Чтобы ничего не потерять, а если потеряли — иметь возможность восстановить, основной кластер Hadoop реплицируется в лабораторию данных. Здесь же располагается большая песочница с пользовательскими областями.
После того как данные будут очищены и преобразованы, на них выстраиваются онлайн- и офлайн-ML-пайплайны. Для онлайн-варианта применение происходит по единичным запросам или в потоке, для офлайн — механизмами пакетного регламентного расчёта.
Для применения моделей поднимаются контейнеры с необходимыми наборами библиотек и компонент. Для регистрации этапов жизненного цикла моделей, их мониторинга и корректировок используется система управления моделями (СУМО).
Теперь детально рассмотрим витрины Hadoop.
Здесь у нас единая витрина данных. Это огромная совокупность знаний обо всех физических и юридических клиентах и их продуктах. Глобально она состоит из двух областей:
Область детальных данных для анализа данных в разрезе ключа сущности из источника.
Область унифицированных данных для анализа поведения глобального клиента и истории жизни договора.
На основе единой витрины данных и Stage КХД формируются витрины для моделей машинного обучения: после проведения проверок готовности источников, загрузки точек, просрочек и айдишников, происходит предагрегация, например на клиента и на просрочку, и рассчитываются переменные для моделей на так называемый закрытый операционный день. Это день, когда все филиалы нашей банковской распределённой сети закрывают учёт и отправляют нам данные. Расчёт происходит параллельно в определённое время с помощью сателлитов — больших блоков SQL-кода. Когда сателлиты готовы, формируется итоговая витрина для моделирования.
Очевидно, все эти процессы занимают много времени.
Следуя регламенту загрузки Stage, репликации, а затем расчёта единой витрины данных (что занимает до семи часов), мы имеем значительный лаг между источниками и скорингом модельных данных. Всё это время бизнес простаивает.
Лаг по самой важной для нас информации, а именно о возникновении просрочки, достигает трёх дней, то есть сегодня клиент должен был заплатить, не заплатил, а что-то с этим сделать мы сможем только послезавтра. И это проблема.
Чтобы её решить, мы погрузились в источники бизнеса — в автоматизированную бизнес-систему Collection (АБС Collection).
В общем виде АБС Collection представляет собой совокупность бизнес-модулей, каждый из которых содержит сложные ветвящиеся схемы различных процессов. На этих схемах есть квадратики — это так называемые работы (плюс-минус крупная единица), чуть более мелкие элементы — задачи, которые спускаются непосредственно на сотрудников колл-центра, и условные переходы между ними. Бизнес-процессы могут запускаться по различным объектам (физлицу, юрлицу, судебному делу и так далее).
В простейшем варианте бизнес-процесс выглядит так:
Но, конечно, в жизни всё сложнее.
И при этом мы предложили сделать ещё один страшный бизнес-процесс, который помог бы нам оптимизировать работу с данными. Естественно, нам отказали, потому что Collection является нагруженной системой, и если мы инициируем ещё один процесс, то вылетим из требования по нагрузке.
Найти решение помогли коллеги из бизнеса. Они объяснили, что работы бывают двух видов: ручные и автоматические. Автоматические работы выполняются непрерывно. Их не надо инициировать много раз на дню. Одной из таких работ является информирование как раз на этапе возникновения просроченной задолженности — то, что нам нужно. Мы решили, что нам необходимо подключиться к моменту запуска этого процесса, не создавая новый. Для этого использовали подсистему репликации данных из бизнеса в наш Hadoop — ETL Framework.
Система устроена несложно. Там есть база PostgreSQL, которая хранит настроечные таблицы, и исполняемое Java-приложение, отвечающее за весь функционал. Используя лазейку в виде автоматического процесса и инструмент, умеющий выгружать данные из источника, мы навесили тег на нужную нам информацию.
Так мы проложили мост от сырых данных из источника без какой-либо нагрузки на бизнес-систему и получили возможность доставать данные напрямую из бизнеса, чтобы их скорить. Благодаря этому о просрочке становилось известно сразу после её возникновения.
Про моделирование
Как бизнес-процессы плодятся, цепляются друг за друга в крупных компаниях, так и моделирование представляет собой водопад, где модельки работают на выходах друг друга. Встроить в эту систему что-то новое довольно сложно.
У нас есть четыре типа модели:
Модели, которые предсказывают вероятности, например выхода в заданную просроченную задолженность.
Модели, которые помогают нам принимать решения, например какой дисконт мы можем предоставить по амнистии.
Модели определения событий, например станете ли вы банкротом.
Модели помощи заёмщикам, рефинансирования и реструктуризации.
Применяем мы их так: систематизируем все договоры в цветной светофорной матрице, которая называется Balance at Risk (BaR). Клиенты в ней в зависимости от суммы долга, находящегося под риском, распределены на сегменты Low, Medium и High.
Чем выше у клиента вероятность задолженности и чем выше баланс, тем большая коммуникация на него будет направлена. Происходит это последовательно: отправка пуша, СМС, звонок робота и так далее.
Мы решили отказаться от сегментации в пользу прямой рекомендации канала коммуникации. Для первых просрочек используем подход First Best Action, то есть выбираем для первого взаимодействия наилучший инструмент коммуникации. Затем следующий по оптимальности и так до самого дефолта. Дефолт — это выход в 90 дней.
После того как мы попытались создать огромные бизнес-процессы, коллеги нам опять напомнили, что персонализированные коммуникации — это не всё. Нужно оглядываться на нагрузку на колл-центр и на бюджет, на СМС и звонки.
М-м-маркетинг!
В результате ресёрча мы решили попробовать то, что никогда во взыскании не применялось, — маркетинговые инструменты.
С точки зрения реакции на взаимодействие клиенты делятся на четыре типа:
Клиенты «Не беспокоить». Такие граждане при попытке коммуницировать с ними сигнализируют о том, что им это не нравится.
Лояльные клиенты. Независимо от характера и активности коммуникации, лояльный клиент выполняет целевое действие. В случае маркетинга, например, нажмёт кнопку, перейдёт по ссылке, в нашем случае — заплатит по кредиту.
Потерянные клиенты. В противоположность лояльным, они не совершат целевого действия, несмотря ни на что.
Убеждаемые клиенты. Самый интересный и нужный тип клиента, который реагирует положительно только при коммуникации с ним.
С точки зрения моделирования есть три крупных подхода:
Look-alike-модель — поиск клиентов, похожих на тех, которые уже совершали целевое действие.
Response-модель, когда мы коммуницируем со всеми и смотрим на эффект.
Uplift-модель (то, на чём мы остановились) — поиск чистого эффекта от коммуникации, то есть тех самых убеждаемых клиентов.
После выбора подхода и сферы нам предстояло расписать этапы реализации.
Этапы реализации
Первый этап — архитектура пилотирования, чтобы мы уверенно могли сказать бизнесу, что всё победили. Затем нужно выбрать метрики, чтобы понимать, что вообще такое победа, и выбрать алгоритм среди множества Uplift-подходов. А чтобы это всё не было исключительно в теории, нужно поставить задачу в промышленную эксплуатацию.
Начали с архитектуры пилота. Там, где был один тег, мы сделали два. 30% всего потока пошло на пилотирование, а остатки разделились пополам на скоринг по старому процессу с раскрашенной матрицей и на наши новые модельки. Накопление данных происходило на разных этапах просроченной задолженности, как на таймлайне. Здесь были случайно разбитые равные группы в зависимости от того, какие коммуникации доступны.
Например, на схеме выше на розовом поле расписан этап First Best Action. Здесь нам доступны SMS, пуши, e-mail, звонки оператора и звонки робота. Потом полученные данные выгружались во View, и мы забирали ETL-фреймворком данные в Data Factory на скоринг.
Что такое победа? Разберём по критериям, которые мы учитываем.
Доля урегулирования — любимая метрика финтех-бизнеса Gini, чтобы оценивать, как модели сегментируют и перформят.
Объём урегулирований — через нашу раскрашенную матрицу Balance at Risk смотрим, как мы разносим наших клиентов по модельному риску относительно балансов.
Затраты на коммуникации — нагрузка на колл-центр хорошо оценивается Uplift-метриками, например Uplift на топ-30% выборки наиболее убеждаемых клиентов.
Лояльность — здесь мы выбрали метрику Qini. Она бывает положительная и отрицательная и позволяет оценить попадание в тех клиентов, которые, если им звонить, будут реагировать негативно.
Стоимость решения — используем Time To Market, чтобы отследить, какая разница во времени внедрения получится относительно наших классических моделей и уложимся ли мы в типовой жизненный цикл.
Любимый дополнительный человеческий ресурс. Здесь главная метрика — это улыбка заказчика 🙂
После того, как определились с метриками, мы пошли искать модельные подходы. Их можно разделить на три категории:
Одна модель (Solo) с признаком коммуникации, с пересечением признаков или с трансформацией классов.
Две модели, зависимые или независимые, зависимые перекрестно или по данным.
Одна модель с множественным классом или множественным тритментом.
Самый простой подход — это обучаться одновременно на двух группах:
Тестовой, она же тритмент, — то есть обучаться там, где мы производим воздействие.
Контрольной — там, где мы воздействие не производим.
В случае solo-модели с признаком коммуникации флаг коммуникации выступает как дополнительный признак. Здесь искомый Uplift — это просто разница предиктов.
Её «дочка» — соло-модель с пересечением признаков:
Здесь всё то же самое, только размерность расширяется вдвое за счёт того, что мы множим признаки на флаг взаимодействия.
Чуть более интересный и математически обоснованный подход — соло-модель с трансформацией классов.
Это интересный математически обоснованный подход, где делается предсказание изменённого таргета. Исходит из парадигмы, что новый класс равен 1, если мы знаем, что для конкретного наблюдения при использовании инструмента коммуникации результат был бы не хуже, чем без него.
Две независимые модели — самый популярный подход, которым пользуются все:
В этом случае обучаемся отдельно на целевой и контрольной группах. Uplift, опять же, — разница предиктов двух моделей.
Чуть более интересный вариант — две зависимые модели.
Здесь классификатор обучается на контрольной группе, затем его предсказания подаются как признак классификатору на тестовой группе. Uplift — разница предиктов того классификатора, который использовал чужой признак, и того, который не использовал.
Ещё чуть интереснее — это две перекрёстно зависимые модели:
В этом случае сначала обучаются две независимые модели, затем делаются предсказания наперекрёст: модель, обученная на контроле, делает предикт на тесте, а обученная на тесте — на контроле. Далее таргеты в группах преобразуются с учётом этих перекрёстных предсказаний, и на изменённых таргетах обучаются две новые модели. Взвешенная сумма предсказаний с некоторым коэффициентом, который зависит от размера групп, и будет нашим Uplift.
Последний вариант — это модель с множественным классом или тритментом:
Мы снова возвращаемся к клиентам, которые либо любят нас, либо кричат. Только из них уже переходим к четырём классам в зависимости от действия в результате воздействия: CR, CN, TR, TN. Где C — Control; T — Treatment; R/N — Responder/Non-responder (отвечает ли клиент на воздействие).
Получили четыре класса, обучили многоклассовый классификатор. Вероятности, которые содержат нужных нам убеждаемых клиентов, — складываем, а негативно реагирующих — вычитаем.
Для множественного тритмента, когда в тестировании происходит одновременно множество разных воздействий, используются методы, основанные на деревьях. Например, мы можем делать сплит на уменьшение расстояния между распределением таргета контрольной и целевой групп.
Что выбрать?
На разных глубинах просроченной задолженности модели перформят совершенно по-разному. Сели всей командой думать, что же нам выбрать, и решили, что вообще не будем ничего выбирать, а просто напишем оптимизатор.
Оптимизатор получает на вход накопленные данные на определённом этапе просроченной задолженности, обучает все модели, тюнит их и взвешивает на все метрики, о которых я рассказала, с учётом любимой метрики Gini, BaR, и ограничения на колл-центр и на бюджет коммуникаций.
В результате мы получаем на каждом этапе просроченной задолженности топ наиболее хорошо перформящих моделей, согласовываем. Например, для этапа FBA работает две Uplift-модели (оператор и робот), которые напрямую рекомендуют канал коммуникаций. Для того, чтобы смотреть на перформанс Uplift-моделей под капотом, у нас есть ещё три модели контроля качества на всей выборке и по одной модели для каждой группы.
Дальше — CTRL-C/CTRL-V: берём оптимизатор и на каждом этапе просроченной задолженности получаем наиболее хорошо перформящие модели. Так и сделали, осталось только наблюдать.
Получилось три группы:
Модель текущей стратегии с бизнес-рулами и сегментами.
Uplift-модели, которые мы так старательно делали.
Случайное взаимодействие, чтобы оценить, насколько полученный эффект статистически значим.
Round One, Fight!
Накопление данных мы начали в конце 2024 года. Сейчас уже готовы показать первые результаты. Вот что из этого вышло:
Time to market. Четыре месяца мы копили данные, ещё два потребовалось на разработку и внедрение — ни днём больше, чем наш стандартный жизненный цикл.
Доля урегулирования. Самый классный показатель здесь — мы стали урегулировать просроченную задолженность на 25% лучше относительно текущей стратегии, что составляет от 15 до 32% профита по каналам коммуникации.
Gini — она тоже выросла. И всё это произошло при тотальном снижении нагрузки на колл-центр.
Нагрузка на колл-центр. Операторы колл-центра стали совершать на 73% меньше звонков за счёт того, что мы просто стали им говорить, кому нужно звонить.
Затраты на коммуникацию снизились на 10% на одного клиента.
Лояльность клиентов приросла. Лично я ненавижу, когда мне звонят из банков. Но здесь люди стали отвечать лучше на 5% при звонке оператором и на 11% — при звонке роботом.
Основная банковская метрика — это, конечно, финансовый эффект.
Мы получили более 3 млрд сохранённых балансов на каждые 20 тысяч договоров, и это только за один месяц и только по First Best Action. Общая оценка компании от бизнеса, как у сеньора на перформанс-ревью, — выше всяких ожиданий 🙂
Но наша главная оценка — это любовь заказчика или, как у джуна на перформанс-ревью, — всё хорошо, ты молодец! 🙂
С докладом на эту тему я выступала на конференции HighLoad++ 2025. Следующее крупное событие для разработчиков высоконагруженных систем — конференция Saint HighLoad++ 2026, она пройдёт в Санкт-Петербурге в июне. Участников ждут не просто доклады — «Онтико» в этом году переворачивает рынок IT-мероприятий! Подробнее — на сайте. Вас ждёт много интересного и необычного :) Присоединяйтесь!