Суть кейса

У банка была понятная задача:
нужно быстрее и точнее принимать решения по кредитным заявкам.

Но на практике это означало конфликт сразу между несколькими целями:

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

Старая скоринговая схема работала, но начинала проигрывать рынку:

слишком много ручных проверок;
часть хороших клиентов отклонялась;
часть плохих проходила;
правила накапливались слоями и становились трудноуправляемыми;
время решения по заявке было нестабильным.

Банк решил внедрить более современный AI-based credit scoring, но не как «чёрный ящик», а как систему поддержки кредитного решения.

Что было до проекта

Обычно решение складывалось из смеси:

анкеты клиента;
бюро кредитных историй;
набора жёстких правил;
простого скорингового балла;
ручной проверки пограничных кейсов.

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

1. Правила разрастались

Каждое исключение добавляло новый if-else.
Через время система становилась тяжёлой и плохо объяснимой даже для самой команды.

2. Потери на хороших клиентах

Консервативные пороги снижали риск, но одновременно резали одобрение там, где клиент на самом деле был качественным.

3. Недостаточно тонкая оценка риска

Два клиента могли попадать в одну группу по формальным признакам,
хотя их реальный риск отличался заметно.

4. Долгий путь заявки

Чем больше ручных этапов, тем выше:

стоимость процесса;
отток клиентов;
нагрузка на андеррайтеров.

Главный вопрос проекта

Не просто:

«Вернёт клиент кредит или нет?»

А скорее:

«Какое решение по этой заявке оптимально с точки зрения риска, доходности и политики банка?»

Потому что решения могли быть разными:

одобрить;
одобрить на меньшую сумму;
одобрить на другой срок;
запросить дополнительные документы;
отправить на ручную проверку;
отклонить.

То есть скоринг был не только про PD, но и про маршрутизацию заявки.

Какие данные использовали

Чем лучше был цифровой след, тем сильнее работал проект.

Основные источники

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

Что оказалось особенно полезным

Не только абсолютные значения, но и комбинации:

стабильность доходных поступлений;
изменение финансового поведения за последние месяцы;
аномальная активность перед заявкой;
число недавних запросов в БКИ;
несоответствие анкеты и цифрового следа;
паттерны использования продуктов банка.

Что строили на самом деле

Проект редко ограничивается одной моделью.

Слой 1. Policy rules

Жёсткие правила всё равно остаются:

возрастные ограничения;
обязательные регуляторные проверки;
стоп-факторы;
KYC/AML;
базовые ограничения по продукту.

Слой 2. Risk model

ML-модель оценивала вероятность дефолта или серьёзной просрочки на выбранном горизонте.

Слой 3. Fraud / suspicious patterns

Отдельно ловили:

поддельные заявки;
синтетические личности;
аномальные устройства;
подозрительные повторные обращения.

Слой 4. Decision engine

Он уже переводил score в действие:

auto-approve;
approve with modified terms;
manual review;
decline.

Что быстро стало ясно

Банк сначала думал, что главное — построить самую точную модель.

Но этого оказалось мало.

Почему

Если модель не встроена в процесс, то она не даёт полной ценности:

андеррайтеры ей не доверяют;
комплаенс блокирует rollout;
бизнес не понимает, как менять пороги;
операционка не успевает обрабатывать новые потоки;
customer experience не улучшается.

Поэтому проект пришлось делать одновременно в трёх измерениях:

риск
операции
объяснимость

Как выглядел результат для заявки

Система не просто возвращала число.
Она выдавала понятную кредитную логику.

Пример

Клиент: новый
Продукт: потребительский кредит
Оценка риска: низко-средняя
Ключевые факторы: стабильный доход, хорошая история, умеренная долговая нагрузка
Решение: одобрить
Корректировка: сумма ниже запрошенной на 15%
Причина корректировки: политика банка по сегменту и текущему уровню нагрузки

Другой пример

Клиент: новый
Оценка риска: пограничная
Дополнительные сигналы: множественные недавние заявки, нестабильность заявленных доходов, аномалия по устройству
Решение: ручная проверка
Причина: сочетание кредитного и fraud-риска

Что показал пилот за 3 месяца

Бизнес-метрики

Метрика	До	После
Approval rate по целевому сегменту	100% базовый уровень	112%
Среднее время решения по auto-flow	100%	54%
Доля ручных проверок	100%	63%

Риск-метрики

Метрика	До	После
Доля плохих выдач в пилоте	100%	86%
Gini / rank-order quality	100%	118%
Точность разделения good/bad клиентов	100%	115%

Операционные метрики

Метрика	До	После
Нагрузка на андеррайтеров	100%	69%
Стоимость обработки заявки	100%	74%
Доля заявок с мгновенным решением	100%	141%

Где был главный эффект

Не только в том, что модель стала точнее.

1. Быстрее проходили хорошие клиенты

Это дало рост конверсии и улучшение клиентского опыта.

2. Пограничные кейсы стали разбираться аккуратнее

Их не просто массово отклоняли, а лучше маршрутизировали.

3. Ручной ресурс ушёл на действительно сложные заявки

Андеррайтеры перестали тратить время на очевидные случаи.

4. Банк стал лучше различать кредитный риск и fraud-риск

Раньше это часто смешивалось.

Где проект чуть не сломался

1. Смещение обучающей выборки

Исторические данные отражали старую кредитную политику,
а не весь реальный рынок заявок.

2. Проблема reject inference

По отклонённым заявкам банк не знает, как они вели бы себя после выдачи.
Это делает обучение модели неполным.

3. Data leakage

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

4. Смена рынка

При изменении экономики поведение клиентов может резко меняться,
и модель начинает стареть быстрее, чем ожидалось.

5. Чрезмерная сложность

Слишком сложная модель могла дать прирост в качестве, но потерять объяснимость и доверие.

Что пришлось держать под контролем

Fairness и bias

Нужно было следить, чтобы модель не давала нежелательных перекосов по чувствительным сегментам.

Regulatory compliance

Решение должно быть воспроизводимым, объяснимым и пригодным для аудита.

Monitoring

После запуска банк отслеживал:

drift по данным;
drift по качеству;
изменение профиля входящего потока;
стабильность cut-off;
винтажи и дефолтные кривые.

Champion-challenger setup

Оставляли текущую модель как baseline и сравнивали с новыми версиями.

Что не стали отдавать в полный автомат

Банк не разрешил модели без человека:

принимать решения по крупным суммам;
одобрять нестандартные кейсы;
менять кредитную политику;
обходить обязательные регуляторные правила;
финально решать сложные fraud-подозрения без дополнительной проверки.

AI стал ядром скоринга, но не единственным источником решения.

Что добавили следующим этапом

После пилота банк обычно расширяет систему:

pricing based on risk;
limit assignment;
collection prioritization;
early warning для уже выданных клиентов;
pre-approval кампании;
next best product;
отдельные модели для self-employed и thin-file клиентов.

Почему этот кейс важен

Он хорошо показывает, что AI в кредитовании — это не просто «модель вместо таблицы».

Настоящая ценность появляется, когда банк умеет:

точнее оценивать риск;
быстрее принимать решения;
снижать ручную нагрузку;
объяснять результат;
соблюдать политику и регулирование;
превращать score в бизнес-действие.

Итог: выше качество портфеля, быстрее обработка заявок, лучше конверсия хороших клиентов и меньше лишней ручной работы.

Скоринг заявок в банке

Похожие статьи

Поделиться в соц. сетях

Комментарии