ML-система кредитного скоринга
Классический скоринг на логистической регрессии с 15–20 ручными фичами — это 2010-е годы. Современные ML-подходы работают с сотнями признаков, захватывают нелинейные зависимости и повышают Gini на 8–15 п.п. по сравнению с традиционными моделями. Разница в 8 п.п. Gini — это миллионы рублей в годовой прибыли для среднего банка.
Постановка задачи и данные
Целевая переменная: дефолт в течение 12 месяцев (бинарная классификация) или вероятность дефолта (регрессия вероятности для PD-оценки в рамках Basel III). Класс-имбаланс: типично 1:10–1:50 (дефолтные vs. нормальные), что требует особого внимания.
Источники признаков:
| Источник | Тип признаков | Значимость |
|---|---|---|
| Кредитная история (БКИ) | Просрочки, количество кредитов, запросы | Высокая |
| Транзакционные данные | Паттерны расходов, остатки, регулярность | Высокая |
| Демография | Возраст, регион, занятость | Средняя |
| Телеком-данные | Регулярность пополнения, роуминг | Средняя |
| Поведенческие | Время заполнения анкеты, устройство | Низкая-средняя |
Модели и стек
XGBoost / LightGBM — основная рабочая лошадь. Обрабатывает табличные данные, нечувствителен к выбросам, хорошо работает с пропусками, интерпретируем через SHAP. Для большинства задач скоринга — оптимальный выбор.
CatBoost — преимущество при большом числе категориальных признаков (регион, профессия) без ручного кодирования.
Нейросети (TabNet, AutoInt) — дают прирост на очень больших датасетах (>5M записей) с богатыми поведенческими данными. Сложнее в интерпретации и обслуживании.
Стекинг. В production часто используем ансамбль: LightGBM + logistic regression (для интерпретируемости regulatory reporting) с мета-леарнером.
Глубокий разбор: работа с имбалансом и calibration
Precision 0.71 при recall 0.89 на классе "default" из-за дисбаланса 1:25 — стандартная боль скоринговых моделей. Что действительно работает:
Focal Loss. Для нейросетевых моделей значительно лучше простого weighted cross-entropy. Параметр gamma=2 фокусирует обучение на сложных примерах.
SMOTE осторожно. Oversample + undersample работает, но SMOTE на финансовых данных может создавать нереалистичные синтетические примеры — обязательно валидировать бизнес-логикой.
Calibration критична. Модель выдаёт score, но нам нужна реальная вероятность дефолта для расчёта LGD и EAD. Isotonic regression или Platt scaling после обучения. Проверяем calibration curve — идеальная модель: предсказанная вероятность 0.3 = 30% фактических дефолтов.
from sklearn.calibration import CalibratedClassifierCV
from lightgbm import LGBMClassifier
base_model = LGBMClassifier(
n_estimators=500,
learning_rate=0.05,
scale_pos_weight=25, # соотношение классов
min_child_samples=50
)
calibrated_model = CalibratedClassifierCV(
base_model, method='isotonic', cv=5
)
calibrated_model.fit(X_train, y_train)
Мониторинг и data drift
Скоринговая модель деградирует со временем. Причины: изменение экономической ситуации, изменение кредитной политики банка, изменение поведения заёмщиков.
Обязательный мониторинг:
- PSI (Population Stability Index) по входным признакам: PSI > 0.25 — критическое изменение распределения, нужно переобучение
- Gini на hold-out выборке ежемесячно
- Score distribution shift: если средний score популяции сдвинулся на >15 пунктов — проверяем причины
- Outcome monitoring: через 6–12 месяцев сравниваем предсказанный vs. фактический дефолт rate
Практический кейс
МФО, исходная модель — логрег с 18 признаками из БКИ. Gini = 0.52 на тестовой выборке.
Что сделали:
- Добавили 140 транзакционных признаков (паттерны расходов, cash-in/out ratio, регулярность)
- LightGBM с hyperparameter tuning через Optuna (300 trials)
- Feature selection: оставили топ-80 признаков по SHAP importance
- Calibration: Platt scaling для получения реальных PD
- Gini на тестовой выборке: 0.71 (+19 п.п.)
- Approval rate при том же уровне дефолтности: +12% (одобряем больше хороших заёмщиков)
Регуляторные требования
В России кредитный скоринг регулируется ЦБ РФ. Ключевые требования: интерпретируемость решений по отказам (SHAP-объяснения), возможность оспорить решение, запрет на использование ряда признаков (дискриминационных). GDPR-аналог — ФЗ-152 — требует обоснования автоматических решений.
Сроки: 8–12 недель для базовой ML-модели, 4–6 месяцев для production-системы с мониторингом, интерпретируемостью и compliance.







