Как работает автоматический кредитный скоринг
Продвинутое3 минРедакция Innovialabs
Коротко
Автоматический скоринг собирает данные бюро, анкеты и поведения, оценивает вероятность дефолта моделью (scorecard или ML), а затем decision rules превращают эту оценку в одобрение, отказ, лимит и ставку.
Коротко о том, как это устроено
Автоматический кредитный скоринг — это конвейер из четырёх частей:
- Сбор данных о заявителе из нескольких источников.
- Модель, которая выдаёт балл или вероятность дефолта (PD).
- Правила решения (decision rules): стоп-факторы, пороги, лимит, ставка.
- Мониторинг: качество модели, стабильность входных данных, объяснение отказов.
Модель отвечает на вопрос «насколько рискован клиент», а правила — «что мы с этим делаем».
Источники данных
| Источник | Что даёт | Особенности |
|---|---|---|
| Кредитное бюро | Кредитная история, просрочки, текущая долговая нагрузка, число запросов | Самый сильный сигнал; нужен договор и согласие клиента |
| Анкета | Доход, занятость, семейное положение, цель кредита | Данные могут быть неточными, нужна верификация |
| Внутренние данные | История клиента в вашей компании: платежи, обороты, прошлые займы | Работает только для существующих клиентов |
| Поведенческие данные | Как заполнялась заявка, устройство, время, транзакционное поведение | Используйте с учётом закона о персональных данных |
| Внешние сервисы | Проверка личности, реестры, верификация дохода | Каждая интеграция добавляет задержку и стоимость |
Правило: каждый источник подключается через согласие клиента и с понятной юридической базой. Недостаточно технически получить данные.
Scorecard или ML-модель
Скоркарта — классика: логистическая регрессия на сгруппированных признаках (WoE-биннинг), каждому диапазону значения присваиваются баллы, сумма баллов и есть скор.
ML-модели (градиентный бустинг и подобные) используют больше признаков и нелинейные связи.
| Критерий | Scorecard | ML-модель |
|---|---|---|
| Прозрачность | Каждый балл виден | Нужны SHAP и reason codes |
| Требования к данным | Работает на небольших выборках | Лучше раскрывается на больших |
| Нелинейные связи | Только через биннинг | Находит сама |
| Валидация регулятором | Привычна | Требует больше документации |
| Сопровождение | Простое | Нужен MLOps |
Частая компромиссная схема: ML-модель как challenger работает параллельно со скоркартой, и её переводят в боевой режим только после доказанного выигрыша на отложенной выборке.
Правила принятия решения
Даже лучшая модель не принимает решение сама. Поверх скора работают:
- Стоп-факторы (knock-out): возраст вне допустимого диапазона, текущая просрочка, совпадение с чёрными списками, мошенничество.
- Пороги скора: зоны «одобрить», «отказать» и серая зона для ручного андеррайтинга.
- Affordability: отношение платежа к доходу, чтобы не выдать кредит, который клиент не потянет.
- Risk-based pricing: лимит и ставка зависят от рискового сегмента.
- Стратегии: champion/challenger для правил — часть потока идёт по новой стратегии, чтобы сравнить результаты.
Храните правила в decision engine, а не в коде приложения: риск-менеджер должен менять пороги без релиза.
Мониторинг модели
Модель стареет: меняется экономика, продукт, маркетинговые каналы. Что отслеживать:
- PSI (population stability index) — изменилось ли распределение скоров и ключевых признаков.
- Gini / AUC на созревших кредитах. Учтите, что дефолт становится известен через месяцы, поэтому смотрите ранние индикаторы, например первые просрочки.
- Approval rate и доля серой зоны.
- Reject inference: модель обучена только на выданных кредитах; по отклонённым исходов нет, и это искажение нужно учитывать при переобучении.
Объяснимость и справедливость
Отказ должен быть объяснимым — и для клиента, и для регулятора, и для собственной команды.
- Сохраняйте для каждой заявки: входные данные, версию модели, скор, сработавшие правила.
- Формируйте reason codes — несколько главных причин отказа понятным языком.
- Проверяйте, не используются ли прямо или косвенно признаки, на основании которых дискриминация запрещена законом.
Типичные ошибки
- Обучать модель на признаках, которых не будет в момент подачи заявки.
- Жёстко зашивать пороги в код.
- Не логировать решения — потом невозможно разобрать спорный отказ.
- Запускать модель без отложенной выборки и проверки во времени (out-of-time).