В нашей практике традиционный кредитный скоринг по НБКИ/ОКБ работает с историей: нет кредитной истории — нет оценки. AI-скоринг добавляет альтернативные сигналы: поведение в приложении, транзакционные паттерны, косвенные социоэкономические признаки. Для финтех-приложений с собственным кошельком или кредитным продуктом это позволяет работать с аудиторией, которую традиционные банки не рассматривают. Мы, как команда с 5-летним опытом в fintech, гарантируем, что разработанная модель соответствует требованиям ЦБ РФ и 152-ФЗ.
В этой статье разберём, как построить ML-пайплайн для скоринга, какие данные использовать и как обеспечить объяснимость решений. Согласно данным Accenture, правильно построенный AI-скоринг позволяет снизить уровень просрочки на 15–20% и увеличить одобрение заявок на 40% для клиентов без кредитной истории. Наш опыт показывает, что внедрение окупается за 3–6 месяцев благодаря сокращению рисков и расширению клиентской базы. Мы используем проверенные методы и стеки: LightGBM, SHAP, Swift/Kotlin для интеграции на мобильных платформах. Все решения соответствуют требованиям ЦБ РФ и 152-ФЗ, что подтверждено юридическим аудитом.
Какие источники данных использует AI-скоринг?
Только те данные, которые пользователь явно разрешил передавать (согласие обязательно, 152-ФЗ):
Транзакционные паттерны. Регулярность поступлений (зарплатные vs хаотичные), соотношение доходов и расходов, баланс в конце месяца, использование кредитных vs дебетовых инструментов. Это самый надёжный источник — данные из собственного приложения, манипуляция ими затруднена.
Поведенческие сигналы. Частота использования приложения, процент выполненных сессий (пользователь открыл приложение и сделал хотя бы одно действие vs просто открыл), использование функций долгосрочного планирования. Эти признаки коррелируют с финансовой дисциплиной, но слабее транзакционных.
Социально-демографические признаки. Регион, тип устройства (косвенный доходной сигнал), стаж использования приложения. Здесь нужна крайняя осторожность: модель не должна дискриминировать по признакам, запрещённым законодательством.
Архитектура ML-пайплайна
Скоринговая модель живёт на сервере — никаких моделей на устройстве для этой задачи. Мобильное приложение собирает и отправляет события, сервер считает скоринг по запросу.
# Feature engineering pipeline — сервер
import pandas as pd
from sklearn.preprocessing import StandardScaler
import lightgbm as lgb
def extract_features(user_id: str, window_days: int = 90) -> dict:
transactions = db.get_transactions(user_id, days=window_days)
df = pd.DataFrame(transactions)
return {
# Стабильность доходов
"income_regularity": df[df.amount > 0].amount.std() / df[df.amount > 0].amount.mean(),
# Отношение расходов к доходам
"expense_to_income_ratio": abs(df[df.amount < 0].amount.sum()) / df[df.amount > 0].amount.sum(),
# Дней с отрицательным балансом
"negative_balance_days": calculate_negative_balance_days(df),
# Стабильность баланса в конце месяца
"month_end_balance_stability": calculate_eom_balance_stability(df),
# Количество уникальных источников дохода
"income_source_diversity": df[df.amount > 0].merchant.nunique(),
# Среднее время между транзакциями
"avg_days_between_transactions": df.timestamp.diff().dt.days.mean(),
}
def predict_score(user_id: str) -> dict:
features = extract_features(user_id)
feature_vector = pd.DataFrame([features])
score = model.predict(feature_vector)[0] # LightGBM, xgboost или CatBoost
probability = model.predict_proba(feature_vector)[0][1]
return {
"score": int(score * 1000), # 300–850, аналог FICO
"probability_of_default": float(probability),
"confidence": calculate_confidence(features),
"feature_contributions": get_shap_values(feature_vector) # Объяснимость
}
Почему SHAP необходим для объяснимости скоринга?
ЦБ РФ и общий тренд регулирования требуют объяснимости кредитных решений. SHAP (SHapley Additive exPlanations) — стандарт для объяснения решений tree-based моделей. Результат SHAP: «На скоринг повлияло: стабильность дохода (+120 баллов), высокая доля расходов на развлечения (−45 баллов), молодой стаж пользования (-30 баллов)».
Это нужно показывать пользователю в мобильном приложении при отказе в кредите — не технически, а в переводе на человеческий язык:
// iOS — перевод SHAP-значений в пользовательский текст
func localizeScoreExplanation(_ contributions: [FeatureContribution]) -> [String] {
return contributions.sorted { abs($0.value) > abs($1.value) }
.prefix(3)
.map { contribution in
switch contribution.feature {
case "expense_to_income_ratio" where contribution.value < 0:
return "Высокая доля расходов относительно доходов"
case "income_regularity" where contribution.value > 0:
return "Стабильные регулярные поступления"
case "negative_balance_days" where contribution.value < 0:
return "Периоды с недостаточным балансом"
default:
return contribution.defaultDescription
}
}
}
Как мониторить качество модели после запуска?
Модель деградирует со временем — экономические условия меняются, паттерны пользователей сдвигаются. Необходимо:
- Population Stability Index (PSI) — мониторинг дрейфа входных признаков. PSI > 0.25 сигнализирует о необходимости переобучения.
- Gini coefficient на свежих данных — ежемесячная проверка разделяющей способности модели.
- Ретроспективный анализ предсказаний через 90 дней (срок подтверждения дефолта).
Compliance и ограничения
Скоринговая модель не должна содержать защищённые признаки — пол, национальность, религию, место рождения. Перед продакшеном — аудит на disparate impact: проверяем, не дискриминирует ли модель определённые демографические группы косвенно (через прокси-признаки). Fairness-тестирование с использованием fairlearn или aequitas.
Хранение данных: персональные данные россиян — только на серверах в РФ (242-ФЗ). Транзакционные данные для скоринга — не передаются третьим лицам без отдельного согласия.
Сравнение традиционного и AI-скоринга
| Критерий | Традиционный скоринг | AI-скоринг с альтернативными данными |
|---|---|---|
| Источники данных | Только кредитная история (НБКИ/ОКБ) | Транзакции, поведение, данные устройства |
| Охват аудитории | Только заёмщики с кредитной историей | Thin-file и new-to-credit клиенты |
| Скорость обновления | Раз в месяц | Реальное время |
| Точность для thin-file | Низкая | Высокая (на 30–50% выше) |
| Объяснимость | Простая (по бюро) | Требует XAI (SHAP) |
Процесс работы
Аудит доступных данных и получение правового заключения → проектирование признакового пространства → разработка ETL-пайплайна → обучение baseline-модели (логистическая регрессия как benchmark) → gradient boosting с тюнингом → SHAP-объяснения → A/B тест против baseline → мониторинг в продакшене.
Что вы получите в результате
- Рабочий ML-пайплайн на сервере с LightGBM/CatBoost
- SHAP-объяснения для каждого решения, интегрированные в мобильное приложение
- Мониторинг PSI и Gini с алертами
- Compliance-аудит и отчёт по fairness
- Интеграция с App Store/Google Play и системами аналитики
Ориентиры по срокам
MVP на логистической регрессии с базовыми транзакционными признаками — 3–4 недели. Продакшен-система с LightGBM, SHAP, мониторингом и compliance-аудитом — 2–3 месяца. При отсутствии готового дата-пайплайна — добавьте 2–4 недели на разработку сбора и хранения событий.
Мы имеем 20+ успешных проектов в fintech и более 5 лет на рынке. Наши инженеры сертифицированы в области безопасной разработки мобильных приложений. Чтобы внедрить AI-скоринг в ваше приложение, получите консультацию. Закажите пилотный проект на ваших данных — мы покажем прирост точности на 30–50% для thin-file клиентов.