Реализация AI-скоринга заёмщика в мобильном FinTech-приложении

Реализация AI-скоринга заёмщика в мобильном FinTech-приложении

Традиционный кредитный скоринг по НБКИ/ОКБ работает с историей: нет кредитной истории — нет оценки. 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)  # Объяснимость
    }

Объяснимость скоринга (XAI)

ЦБ РФ и общий тренд регулирования требуют объяснимости кредитных решений. 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). Транзакционные данные для скоринга — не передаются третьим лицам без отдельного согласия.

Процесс работы

Аудит доступных данных и получение правового заключения → проектирование признакового пространства → разработка ETL-пайплайна → обучение baseline-модели (логистическая регрессия как benchmark) → gradient boosting с тюнингом → SHAP-объяснения → A/B тест против baseline → мониторинг в продакшене.

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

MVP на логистической регрессии с базовыми транзакционными признаками — 3–4 недели. Продакшен-система с LightGBM, SHAP, мониторингом и compliance-аудитом — 2–3 месяца. При отсутствии готового дата-пайплайна — добавьте 2–4 недели на разработку сбора и хранения событий.