When a creditor denies an application, ECOA, implemented through Regulation B at 12 CFR 1002.9, requires an adverse action notice within 30 days. The notice has to state the specific principal reasons that drove the decision, up to four of them. Not a category. Not “did not meet our criteria.” The actual factors that moved the outcome for this applicant.
Most teams treat that as a compliance task that happens after the model. It is not. It is a constraint on what the model is allowed to be. The CFPB has said a creditor cannot excuse non-compliance by claiming its technology is too complex or too opaque to identify specific reasons. Read that plainly: a model too opaque to explain a denial cannot be used for that denial. The explanation requirement is not downstream of the modeling decision, it sits inside it.
Reason codes tied to the model, not invented after it
The failure mode we see is a model trained for accuracy with no thought to explanation, then a second system bolted on to produce reasons for the notice. That second system tells a story about why the applicant was denied. The story sounds plausible. The problem is that nothing guarantees it matches what the model actually scored.
Reason codes have to reflect the factors the model genuinely weighted for that applicant. If the model leaned on a particular signal and the notice cites a different one, the reason code is wrong even when it reads well. That gap is hard to catch by eye precisely because the post-hoc explanation is built to be readable. So the work is:
- Generate reason codes from the model that made the decision, using attribution the model can support, not a separate narrative layer guessing at its behavior
- Cover alternative-data factors, because Regulation B reaches whatever the model actually scored; cash-flow signals, telco or utility records, and the like all need to surface as reasons when they drove the outcome
- Test that the codes are accurate, on held-out cases where you know which factors moved the score, the same way you would build an eval set for any other claim the system makes
- Keep the audit trail, so for any denial you can reconstruct the inputs, the score, and the four reasons that were sent
That third point is the one teams skip. A reason-code generator is a model output like any other, and an untested model output is a guess. You need cases where you can check the cited reasons against the factors that actually changed the decision, and a number that tells you how often they agree.
Design for explainability before you pick the model
The cheapest time to satisfy this is at model selection. A model whose denials you can attribute to specific scored factors is a model you can use in lending. One you cannot attribute is one you will be unwinding later, after it has already sent notices you cannot defend. That ordering matters because the alternative is discovering, in production, that your most accurate model is one you are not permitted to deploy for the decision it was built to make.
Explainability here has to be sufficient under both ECOA and FCRA. FCRA carries its own disclosure duties when a credit decision rests on a consumer report, and a reason-code scheme that satisfies one statute does not automatically satisfy the other. We treat both as design inputs at the start rather than constraints discovered at review.
In engineering terms, none of this is exotic. It is the same discipline as point-in-time correctness or data lineage: decide up front what the system has to be able to prove, and build so it can. For a credit model, “prove” means: for any denial, here are the specific factors that drove it, here is the evidence they are the real factors and not a plausible substitute, and here is the trail from input to notice.
That standard rules some models out. A model you cannot interrogate at the level of an individual denial is a model that cannot meet the adverse action notice requirement, and so it cannot make that denial. Better to learn that during selection than after the notices have gone out.
This is general industry analysis, not legal advice. The specific obligations for any lending program should be confirmed with qualified counsel.