In our practice, traditional credit scoring based on credit bureau data works only with history: no credit history — no score. AI scoring adds alternative signals: in-app behavior, transactional patterns, indirect socio-economic indicators. Our AI credit scoring method is specifically designed for mobile credit scoring in fintech apps. As a team with 5 years of experience in fintech, we ensure that the developed model meets regulatory requirements.
This article explains how to build an ML pipeline for scoring, which data to use, and how to ensure decision explainability. According to Accenture, a properly built AI scoring system can reduce delinquency rates by 15–20% and increase approval rates by 40% for customers without a credit history. Our experience shows that implementation pays off in 3–6 months by reducing risks and expanding the customer base. We use proven methods and stacks: LightGBM, SHAP, Swift/Kotlin for mobile integration. All solutions comply with regulatory requirements. The pilot project costs $5,000 and takes 3 weeks. AI scoring is 30–50% more accurate than traditional scoring for thin-file borrowers.
What data sources does AI scoring use?
Only data that the user explicitly authorizes (consent is mandatory, per data protection law):
Transactional patterns. Regularity of income (salary vs erratic), income-to-expense ratio, end-of-month balance, use of credit vs debit instruments. This is the most reliable source — data from your own app, difficult to manipulate.
Behavioral signals. Frequency of app usage, percentage of completed sessions (user opened app and performed at least one action vs just opened it), use of long-term planning features. These correlate with financial discipline but are weaker than transactional data.
Socio-demographic indicators. Region, device type (indirect income proxy), app usage tenure. Extreme caution is needed: the model must not discriminate on legally prohibited attributes.
ML Pipeline Architecture
The scoring model lives on the server — no on-device models for this task. The mobile app collects and sends events; the server calculates the score on request.
# Feature engineering pipeline — server
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 stability
"income_regularity": df[df.amount > 0].amount.std() / df[df.amount > 0].amount.mean(),
# Expense to income ratio
"expense_to_income_ratio": abs(df[df.amount < 0].amount.sum()) / df[df.amount > 0].amount.sum(),
# Days with negative balance
"negative_balance_days": calculate_negative_balance_days(df),
# Month-end balance stability
"month_end_balance_stability": calculate_eom_balance_stability(df),
# Number of unique income sources
"income_source_diversity": df[df.amount > 0].merchant.nunique(),
# Average days between transactions
"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 or CatBoost
probability = model.predict_proba(feature_vector)[0][1]
return {
"score": int(score * 1000), # 300–850, FICO-like
"probability_of_default": float(probability),
"confidence": calculate_confidence(features),
"feature_contributions": get_shap_values(feature_vector) # Explainability
}
Why SHAP is necessary for scoring explainability?
Regulatory bodies and the general trend require explainability of credit decisions. SHAP (SHapley Additive exPlanations) is the standard for explaining tree-based model decisions. SHAP result: "Score affected by: income stability (+120 points), high entertainment spending (−45 points), short user tenure (−30 points)."
This must be shown to the user in the mobile app upon credit denial — not technically, but translated into plain language:
// iOS — translating SHAP values to user-friendly text
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 "High spending relative to income"
case "income_regularity" where contribution.value > 0:
return "Stable regular income"
case "negative_balance_days" where contribution.value < 0:
return "Periods with insufficient balance"
default:
return contribution.defaultDescription
}
}
}
How to monitor model quality after launch?
Models degrade over time — economic conditions change, user patterns shift. Required:
- Population Stability Index (PSI) — monitoring drift of input features. PSI > 0.25 signals need for retraining.
- Gini coefficient on fresh data — monthly check of model discriminative power.
- Retrospective analysis of predictions after 90 days (default confirmation period).
Compliance and Limitations
The scoring model must not include protected attributes — gender, nationality, religion, place of birth. Before production, audit for disparate impact: check if the model indirectly discriminates certain demographic groups (via proxy features). Fairness testing using fairlearn or aequitas.
Data storage: personal data must reside on servers within the country (data localization law). Transactional data for scoring must not be shared with third parties without separate consent.
Comparison of Traditional vs AI Scoring
| Criteria | Traditional Scoring | AI Scoring with Alternative Data |
|---|---|---|
| Data sources | Only credit bureau history | Transactions, behavior, device data |
| Audience coverage | Only borrowers with credit history | Thin-file and new-to-credit customers |
| Update frequency | Monthly | Real-time |
| Accuracy for thin-file | Low | High (30-50% higher) |
| Explainability | Simple (from bureau) | Requires XAI (SHAP) |
Process of Work
- Audit available data and obtain legal opinion
- Design feature space
- Develop ETL pipeline
- Train baseline model (logistic regression as benchmark)
- Gradient boosting with tuning
- SHAP explanations
- A/B test vs baseline
- Production monitoring
What you will get as a result
- Working ML pipeline on server with LightGBM/CatBoost
- SHAP explanations for each decision, integrated into mobile app
- PSI and Gini monitoring with alerts
- Compliance audit and fairness report
- Integration with App Store/Google Play and analytics systems
Timeline Estimates
MVP on logistic regression with basic transactional features — 3–4 weeks. Production system with LightGBM, SHAP, monitoring, and compliance audit — 2–3 months. Without an existing data pipeline, add 2–4 weeks for event collection and storage development.
We have 20+ successful projects in fintech and more than 5 years on the market. Our engineers are certified in secure mobile app development. We offer a turnkey solution with a pilot project that can be completed in 3 weeks. Contact us for a free consultation and project evaluation. What's included: Documentation (system architecture, API specs, model cards), Access to model monitoring dashboard, Training for your team (2 sessions), 3 months of post-launch support.