Financial services
Credit scoring for thin-file applicants
Default-risk models built from relational behavioural data, with the reason codes a regulated lender has to produce.
This page describes a problem class and the architecture we deploy for it, written against a named public benchmark — the open dataset or competition where the world's data scientists have tested approaches to this exact problem against a hard metric. It is not a client engagement, and the benchmark's results, prizes and rankings belong to its host and participants, not to us. Client work is confidential and is only ever published with written permission.
The problem
What it costs when this goes unsolved.
The applicants a growing lender most wants to serve are the ones the bureau file says least about. Declining them all forfeits the market; approving on intuition books unpriced risk. The model that solves this has to do two things at once: extract signal from behavioural data the bureau does not see, and explain every adverse decision in language a regulator accepts.
Real lending data is relational — applications, prior loans, repayment histories, card balances — spread across tables at different grains. The signal lives in behavioural aggregates (how repayment behaviour trends, not just its level), and the risk lives in leakage: a feature computed with information from after the decision point produces a model that aces validation and fails in production.
How we build it
The architecture, stage by stage.
01
Relational feature engineering
Hundreds of behavioural ratios and trend aggregates built across the application's full relational history, each timestamped to the decision point so nothing leaks from the future.
02
Gradient boosting as the workhorse
LightGBM and XGBoost ensembles — still the strongest published approach on tabular credit data — with calibration so scores read as probabilities, not ranks.
03
Explainability as a feature, not an afterthought
Per-decision reason codes derived from the model's own attributions, mapped to adverse-action language your compliance team signs off.
04
Stability engineering
Drift monitoring and stability-adjusted validation, because the real cost centre in model risk is not accuracy at launch but decay in month nine.
Model families on this problem class: LightGBM / XGBoost · Relational feature stores · SHAP reason codes · Stability-adjusted validation.
What you get
What an engagement hands over.
Everything below goes in the scope document before you sign it, with a fixed price or a rate with a ceiling — the same terms as every other engagement in the catalogue.
- An application scorecard with calibrated probabilities and reason codes
- A feature store over your relational lending data, timestamped and leak-free
- Validation documentation written for model risk review, not just for us
- Drift monitoring with a retraining policy and its triggers agreed in writing
Provenance
The benchmark behind this page.
Home Credit Default Risk, run by Home Credit Group, is the public proving ground for this problem class. The figures below are the host's, cited as context for how seriously this problem is tested in the open — they are not our results and we do not claim them.
How to buy this
The services this build draws on.
More proof
Next step
Thirty minutes on whether this fits your problem.
Bring the constraint — the regulator, the data boundary, the latency budget. If your data cannot support this build yet, the call will conclude with what to fix first, not with a proposal.