AI-Скоринг заємщика для FinTech мобільного додатку
Традиційний кредитний скоринг через НБКИ/ОКБ працює з історією: немає кредитної історії—немає оцінки. AI-скоринг додає альтернативні сигнали: поведінка в додатку, трансакційні паттерни, непрямі соціоекономічні маркери. Для FinTech-додатків з власним гаманцем або кредитним продуктом це дозволяє працювати з аудиторією, яку традиційні банки не розглядають.
Джерела даних для альтернативного скорингу
Тільки ті дані, які користувач явно дозволив передавати (згода обов'язкова, закон про захист даних):
Трансакційні паттерни. Регулярність надходжень (зарплатні vs хаотичні), співвідношення доходів та витрат, баланс в кінці місяця, використання кредитних vs дебетових інструментів. Найнадійніше джерело—дані з власного додатку, маніпуляція утруднена.
Поведінкові сигнали. Частота використання додатку, відсоток завершених сесій (користувач відкрив додаток і зробив дію vs просто відкрив), використання функцій довгострокового планування. Ці маркери корелюють з фінансовою дисципліною, але слабше трансакційних.
Соціодемографічні маркери. Регіон, тип пристрою (непрямий сигнал доходу), стаж використання додатку. Екстремальна обережність потрібна: модель не повинна дискримінувати за законодавчо захищеними ознаками.
Архітектура ML-конвеєра
Модель скорингу живе на сервері—без on-device моделей для цієї задачі. Мобільний додаток збирає та відправляє eventos, сервер обчислює скоринг на запит.
# Pipeline feature engineering — сервер
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 днів (період підтвердження дефолту)
Відповідність і обмеження
Модель скорингу не повинна містити захищені ознаки—стать, національність, релігію, місце народження. Pre-production аудит на disparate impact: перевіряємо, чи модель не дискримінує певні демографічні групи непрямо через proxy-ознаки. Fairness-тестування: fairlearn або aequitas.
Зберігання даних: персональні дані росіян—тільки на серверах в РФ (закон про захист даних). Трансакційні дані для скорингу—не передаються третім особам без окремої згоди.
Процес розробки
Аудит доступних даних та отримання правового заключення → проектування ознакового простору → розробка ETL-конвеєра → обучение baseline-моделі (логістична регресія як benchmark) → gradient boosting з тюнінгом → SHAP-пояснення → A/B тест проти baseline → моніторинг у production.
Орієнтири за часом
MVP на логістичній регресії з базовими трансакційними ознаками—3–4 тижні. Production-система з LightGBM, SHAP, моніторингом та compliance-аудитом—2–3 місяці. При відсутності готового data-конвеєра—додайте 2–4 тижні на розробку збору та зберігання подій.