Defensible Credit Decisioning
A glass-box decision layer sits over the core credit model and generates regulator-ready adverse-action reasons automatically, in place of analysts hand-writing them.
The challenge
The lender's core underwriting model — a gradient-boosted ensemble trained on 11 years of repayment history — scored well, but Regulation B requires a specific, accurate reason for every adverse action, and a boosted ensemble doesn't hand those out on its own. That left the compliance team to:
- Manually translate top model features into approved reason codes for every decline
- Spend roughly 45 minutes per file during high-volume weeks, creating a standing backlog
- Produce reason codes that varied between analysts for functionally similar declines
- Field examiner findings about inconsistency between the model's actual drivers and the stated reasons
- Re-justify the same decision logic from scratch at every periodic exam
Only 72% of declines carried reason codes the compliance team was confident would hold up under examiner questioning; the rest were reworked by hand.
How it works
An explainable layer between the model and the notice
Rather than replace the underwriting model, the team built a second model whose only job is to explain the first one defensibly:
- 01
An Explainable Boosting Machine trained to approximate the core model's decision surface with monotonic, auditable feature effects
- 02
SHAP values extracted from the core model for every decline to identify the true top drivers
- 03
A reason-code taxonomy mapped one-to-one against approved ECOA/Reg B language
- 04
Consistency checks confirming the glass-box explanation and the core model's actual decision agree above a set threshold
- 05
Fair-lending disparate-impact testing run against the explanation layer before go-live
- 06
Integration with the loan origination system so reason codes generate at the moment of decline
- 07
Every explanation logged with the model version and feature snapshot it was generated from, for exam retrieval
What we built
Key capabilities
Reasons generated at decision time
Adverse-action reason codes are produced the instant a loan is declined, not reconstructed afterward by an analyst.
Consistency-checked against the real model
Explanations are validated to agree with the core model's actual decision drivers above a set threshold before they ship.
Full audit trail
Every generated reason is logged with the model version and feature snapshot behind it, ready for exam retrieval.
Fair-lending tested
The explanation layer itself is tested for disparate impact before deployment, not assumed neutral because it's 'just explaining'.
Before vs after
What changed in the review cycle
- Reason-code turnaround
- 45 min → 90 sec
- Declines with defensible reasons
- 72% → 100%
- Examiner hours per cycle
- ~120 hrs → ~60 hrs
- Analyst rework on reason codes
- 28% of files → near zero
Business impact
What it changed
Examiner time cut roughly in half
Auto-generated, consistency-checked reason codes meant examiners spent the most recent cycle verifying the system rather than re-deriving reasons file by file — cutting review hours from about 120 to about 60.
100% defensible coverage
Every decline now carries a reason code checked against the model's actual drivers, up from the 72% the compliance team was previously confident in.
Backlog eliminated
Reason-code generation dropped from 45 minutes of analyst time to under two minutes, removing the backlog that used to build during high-volume weeks.
Technology stack
“Explainability that only lives in a slide deck doesn't survive an exam. This one lives in the decision path, generated the moment the decision is made.”
Keep reading