Machine Learning for Lenders and Credit Decisions

The lenders who get the most from it

A specialist lender writing 400 small business loans a month usually has an underwriting team that is good, overworked and inconsistent in ways nobody has measured. Two underwriters looking at the same application reach different answers more often than anyone would like to admit, and the file notes rarely say why.

That is where machine learning for credit decisions earns its place. It does not replace the underwriter. It gives every application the same starting view, flags the ones that deserve a closer look, and lets the experienced people spend their time on the marginal cases rather than the obvious approvals and declines.

The lenders who get little from it are the ones hoping a model will let them lend into a segment they do not understand. A model trained on your past book knows your past book. It knows nothing about the customers you turned away.

Where machine learning improves credit decisions

• Application scoring. Gradient boosted models on bureau data, application fields and, increasingly, open banking transaction data. The gain over a traditional scorecard is largest on thin-file applicants, where cash flow tells you more than credit history.
• Early warning on the existing book. Spotting borrowers whose transaction patterns are drifting towards arrears two or three months before a missed payment, while there is still something useful to do about it.
• Collections prioritisation. Ranking arrears cases by likelihood of cure, so the team calls the people a conversation will actually help first.
• Affordability checks. Categorising open banking transactions into income and committed spend, which is tedious for a human and well suited to a classifier.
• Fraud and application manipulation. Detecting edited bank statements, inconsistent employer details and velocity patterns across applications.

Explainability is a legal requirement, not a nice extra

When you decline someone, you need to be able to say why in terms they can understand. In the UK the FCA's Consumer Duty expects firms to show they deliver good outcomes and treat customers fairly; in the US, adverse action notices must give specific reasons. A model that produces a number with no reasons is not usable for consumer lending.

In practice we build credit models with monotonic constraints (more missed payments can never make a score better), a limited and reviewable feature set, and per-decision reason codes generated from the model's own attributions. The EU AI Act also treats creditworthiness assessment of individuals as a high-risk use, with documentation, human oversight and logging obligations phasing in. If you lend to EU consumers, check the current timetable with your compliance adviser and build the logging in from day one rather than retrofitting it.

If the underwriter cannot explain the model's decision to the applicant, the model is not finished.

The data problem nobody mentions: reject inference

Your historical data only contains outcomes for loans you approved. The people you declined never got the chance to repay or default, so the model learns from a filtered population. Train naively and it will look excellent in testing and misbehave on exactly the applicants you most want it to judge well.

There are standard approaches: bureau performance data on declined applicants where it is available, a small controlled test lending band, and statistical reject inference. None is perfect. All are better than pretending the problem does not exist, which is what most first attempts do.

Fairness testing before anything goes live

Removing protected characteristics from the inputs does not make a model fair. Postcode, employer and spending categories can act as proxies, and a model will happily find them. Fairness has to be measured on outcomes.

1. Compare approval rates and error rates across groups where you lawfully hold or can estimate the data
2. Check whether any single feature is doing a suspicious amount of work
3. Review a sample of declines by hand with an underwriter who did not build the model
4. Document what you found and what you changed, because a regulator will ask
5. Repeat quarterly, since the applicant mix shifts over time

When a scorecard is the better choice

Machine learning is the wrong choice for a lender with fewer than a few hundred defaults in its history. There is simply not enough signal, and a complex model will memorise noise. A logistic regression scorecard built with a credit risk specialist is transparent, easy to defend and often within a whisker of the more complex model's performance anyway.

How long it takes and what it costs

A first credit model for a small lender is rarely a quick project, and anyone quoting four weeks has not looked at your data. The modelling itself is a minority of the effort. Most of the time goes on assembling clean outcome history, agreeing definitions (is a default 90 days past due, or a write-off, or a restructure?) and building the decision logging a regulator will expect to see.

• Data assembly and default definitions: four to eight weeks, longer if loan records sit in several systems
• Model build, validation and fairness review: six to ten weeks
• Shadow running against live decisions: two to four months, which is calendar time rather than build effort
• Ongoing monitoring and periodic retraining: a small, permanent cost that should be in the budget from the start

The cost of getting it wrong is larger than the cost of building it slowly. A model that quietly approves a worse mix of borrowers takes a year to show up in arrears, by which point the loans are on the book.

How we would approach a lending model

At SpiderHunts we start by reproducing your current decisions: can a simple model predict what your underwriters already do, and where do they disagree with the eventual outcome? That comparison alone usually surfaces policy questions worth more than the model. Then we build the challenger, run it silently alongside live decisions for a few months, and only let it influence approvals once the shadow results hold up.

The engineering that surrounds the model matters as much as the model: versioned features, decision logs that store the inputs and reasons, drift monitoring and a clear route for an underwriter to override. Our machine learning service covers that full lifecycle, and our guide to deploying machine learning models explains why the unglamorous parts decide whether a model survives its first audit.

Frequently asked questions