Credit Risk and Underwriting Models
Scoring models built to be defended rather than merely to perform: documented at every step, tested for disparate impact, producing reason codes, and delivered with the evidence pack your validators and regulator will ask for.
In credit, the model that performs best is frequently not the model you can deploy. Explainability, documentation, fairness and stability requirements constrain the choice, and a team that optimises for discrimination power alone usually ends up rebuilding after validation.
Credit risk and underwriting modelling is the development of models that estimate the probability of default or of another credit outcome, built to the documentation, explainability, fairness and monitoring standards required by internal model risk management and by the regulator in your jurisdiction.
Constraints first, performance second
We establish the boundaries before choosing a method, because they eliminate options rather than merely influencing them:
- Explainability. Whether every declined applicant must receive specific reasons, which in several jurisdictions is a legal requirement rather than a preference.
- Permitted variables. What may lawfully be used, what is prohibited, and which apparently neutral fields act as proxies for protected characteristics.
- Validation standard. What your independent validation function requires in the development documentation, and what evidence it needs to reproduce your work.
- Stability requirements. How much the score distribution may move before recalibration is required, and who monitors that.
- Override policy. Where human underwriters may depart from the score, on what grounds, and how those overrides are recorded and reviewed.
Only once these are written down do we choose a method. In practice they frequently favour interpretable models, and a well-built scorecard remains competitive far more often than the industry's enthusiasm for complexity suggests.
How we develop the model
Reject inference, honestly
You only observe performance for applicants you accepted, which biases the training data in a way that is easy to ignore and expensive to get wrong. We apply reject inference where the data supports it, state the assumptions plainly, and quantify how sensitive the result is to them rather than presenting a single number.
Out-of-time validation, not just out-of-sample
Credit performance shifts with the economic cycle, so a model validated on a random split of the same period will overstate its stability. We validate on later periods and, where history permits, on a period of genuine stress, because that is when the model's behaviour matters most.
Fairness testing as a development step
Disparate impact measured across protected groups where the data lawfully allows, proxy analysis for apparently neutral variables, and the trade-off between performance and fairness quantified rather than asserted. This is done during development, not as a compliance check afterwards when changing anything is expensive.
Reason codes that are actually reasons
Each decline maps to specific, accurate and comprehensible factors. Not a feature name, and not a generic phrase covering every case. This is a hard requirement in several jurisdictions and it constrains the model choice more than most teams anticipate.
Calibration, not just ranking
Underwriting needs probabilities that mean what they say, because pricing and provisioning depend on them. A model that ranks well but is poorly calibrated will misprice systematically, so calibration is measured and maintained separately from discrimination.
Champion and challenger from the start
The incumbent model or policy keeps running alongside, with performance compared continuously on the same population. This is how you know when to switch, and it is also the evidence your validators will want when you propose to.
The documentation is a deliverable, not paperwork
Model risk management expects a development document that lets an independent reviewer reproduce your decisions: data lineage, exclusions and why, variable selection, alternatives considered and rejected, assumptions, limitations and monitoring plan. We write it as the work proceeds, because reconstructing it afterwards is both slower and less credible.
Where these models are used
| Decision | Model | Particular constraint |
|---|---|---|
| Accept or decline | Application scorecard | Reason codes and fairness testing |
| Limit and pricing | Probability of default plus loss given default | Calibration accuracy drives pricing |
| Affordability | Income and expenditure assessment | Regulatory rules on responsible lending |
| Collections prioritisation | Probability of cure or of roll-forward | Treatment fairness and vulnerability handling |
| Provisioning | Expected credit loss inputs | Accounting standards and audit scrutiny |
| Portfolio monitoring | Early warning indicators | Stability and drift measurement |
How the engagement runs
Constraints and documentation run alongside development, not after it.
Constraints and data
Explainability, permitted variables, validation standard and override policy documented; data lineage and performance definitions established.
Development data
Sampling, exclusions, reject inference approach and out-of-time split design, all documented as decisions with reasoning.
Model development
Variable selection, candidate models within the explainability constraint, calibration and out-of-time validation.
Fairness and reason codes
Disparate impact and proxy analysis, reason code mapping tested for accuracy and comprehensibility.
Implementation and monitoring
Deployment with champion and challenger running in parallel, monitoring thresholds set, and the model risk pack completed.
What you receive
A model your validation function can approve and your regulator can inspect.
Model development document
Data lineage, exclusions, variable selection, alternatives rejected, assumptions and limitations.
Validated model
Deployed scoring with out-of-time and, where possible, out-of-cycle validation results.
Fairness assessment
Disparate impact and proxy analysis with the performance trade-off quantified.
Reason code framework
Decline reasons per case, tested for accuracy and comprehensibility.
Calibration report
Predicted against realised rates by score band, with the recalibration trigger.
Monitoring and challenger
Stability, drift and performance monitoring with the incumbent running in parallel.
Is this the right engagement?
Worth being direct. Credit Risk and Underwriting Models is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- You underwrite credit and the current model or policy is ageing.
- Application and performance data exists with a clear outcome definition.
- Risk and compliance can engage from week one on constraints.
- Declined applicants must receive specific reasons.
- An independent validation function will review the work.
Choose something else if
- Performance history is too short to observe outcomes.
- Explainability requirements have not been established and nobody will decide them.
- The intention is to use variables that are prohibited or act as proxies.
- There is no plan to monitor the model after deployment.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Can machine learning be used for credit underwriting?
Yes, within the explainability and fairness constraints of your jurisdiction and your model risk framework. Those constraints often favour interpretable methods, and a well-built scorecard remains competitive more often than expected. We establish the constraints before choosing a method rather than after.
What is reject inference and why does it matter?
You only observe repayment behaviour for applicants you accepted, so the training data systematically excludes the people your current policy declined. Reject inference estimates how those applicants would have performed. It rests on assumptions, so we state them and quantify how sensitive the result is rather than presenting one number.
How do you test a credit model for fairness?
By measuring outcome differences across protected groups where the data lawfully allows, analysing apparently neutral variables that may act as proxies, and quantifying the trade-off between performance and fairness. This happens during development, because discovering it at validation means rebuilding.
What documentation will our validators need?
Enough to reproduce your decisions independently: data lineage, exclusions and why, variable selection, alternatives considered and rejected, assumptions, limitations, validation results and the monitoring plan. We write it as the work proceeds, since reconstructed documentation is both slower to produce and less credible.
How often should a credit model be rebuilt?
Monitored continuously, recalibrated when the score distribution or the predicted-to-realised relationship drifts past your threshold, and redeveloped when performance degrades or the population changes materially. The champion and challenger arrangement is what tells you which of those is needed.
Often paired with this
Most clients combine two or three engagements from the Machine Learning & Predictive Analytics pillar. These are the ones that most often run immediately before or after.
Fraud and Anomaly Detection
Detection tuned to what your review team can actually work, with explanations analysts can act on.
Read more →Custom ML Model Development
A bespoke model for a problem no off-the-shelf product fits, benchmarked against a simple baseline and deployed properly.
Read more →Predictive Analytics
Predictions embedded in the decisions they are meant to improve, measured on the business outcome rather than on AUC.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.