AI in lending: credit decisioning that regulators accept
Alternative data, explainability and adverse action notices — building credit models that hold up to scrutiny as well as backtests.
Credit is one of the most heavily governed uses of modelling there is. The constraint is not whether a model can predict default — it is whether you can explain, defend and evidence every decision it contributed to.
Explainability is a hard requirement
In most jurisdictions a declined applicant is entitled to know why. That obligation shapes model choice before accuracy does — a slightly weaker model you can explain per-decision beats a stronger one you cannot.
Alternative data widens access and widens risk
Cash-flow data, rental history and utility payments genuinely extend credit to people thin files exclude. They also correlate with protected characteristics in ways that are not obvious. Test for proxy discrimination explicitly and document that you did.
Where LLMs belong in a lending stack
Good fit
- Extracting income from irregular payslips and statements
- Summarising an applicant file for a human reviewer
- Detecting inconsistencies between submitted documents
- Drafting the decision rationale for a human to approve
Poor fit
- Producing the credit score itself
- Making the accept/decline call
- Anything whose reasoning can't be reproduced deterministically
- Any step you couldn't explain to a declined applicant
Where LLMs fit, and where they do not
Language models should not be scoring credit. They are excellent at the document work surrounding it — reading bank statements, extracting income from irregular payslips, summarising an applicant's file for a human reviewer.
- Good fit: document extraction, file summarisation, drafting decision rationale
- Good fit: detecting inconsistencies between submitted documents
- Poor fit: producing the score or the accept/decline itself
- Poor fit: anything where the reasoning cannot be reproduced deterministically
Fairness is a running requirement
Ongoing
- Fairness metrics on the same dashboard as performance
- Proxy testing after removing protected fields
- A named owner reviewing on a set cadence
- Adverse action reasons generated per decision
Not sufficient
- A fairness audit at launch only
- Removing protected characteristics and stopping there
- Explainability that works in aggregate but not per case
- Documentation nobody has read since go-live
Monitor for disparate impact continuously
A model fair at launch can drift into unfairness as populations shift. Fairness metrics belong on the same dashboard as performance metrics, reviewed on the same cadence, with a named owner.