The adverse action notice requirement under 12 CFR 1002.9 — Regulation B's notification provision — is one of the more deceptively simple obligations in consumer lending compliance. You must give applicants specific reasons for credit denial. Those reasons must be specific enough to be actionable. The CFPB and OCC have both said as much. And yet, as scoring models have grown more complex, the gap between what a model actually does and what an adverse action notice actually says has quietly widened to the point where many mid-market lenders are carrying real examination exposure without knowing it.
This is the ECOA explainability gap: technically compliant reason codes that don't accurately represent the decision logic behind a denial.
What Reg B Actually Requires — and What "Compliant" Hides
12 CFR 1002.9(b) requires that a statement of reasons for adverse action be specific. The official commentary clarifies that vague or overly broad reasons don't satisfy the requirement. "Credit score" alone is not an adequate reason. The Regulation B sample form (Form C-1 through C-5) provides a checklist of reasons that many lenders use directly, which creates a false sense of safety: if you're sending a notice with four codes from the approved list, you assume you're covered.
You may be covered technically. You may not be covered substantively.
CFPB Circular 2022-03, which addressed the use of complex algorithms in credit decisions, made explicit what had been implicit for years: when a creditor uses a model — particularly a model whose outputs aren't directly traceable to human-readable factors — the "principal reason" provided on the adverse action notice must reflect the actual factors driving the decision, not a post-hoc rationalization generated by a lookup table keyed to score range.
FCRA Section 615 adds an additional dimension. When a consumer report is a factor in an adverse credit decision, the lender must provide the credit score that was used, the key factors associated with that score, and the name of the consumer reporting agency. This is not a separate obligation from Reg B — it runs in parallel. A lender running a gradient-boosted ensemble on top of a bureau pull is subject to both. The principal factors disclosed under FCRA 615 should be consistent with the principal reasons on the Reg B notice.
They often aren't.
The Reason Code Generation Problem
Traditional scorecards — logistic regression, WOE-binned variable scorecards — have a natural reason code infrastructure. The model's coefficients tell you which variables contributed most to a given score, and that contribution ranking maps directly to the "top 4 reasons" required by most adverse action notice procedures. This is what FICO's standard reason code framework was built for: each score comes with up to four ranked factors, drawn from a defined list, each traceable to a specific input variable.
Modern ML models don't work that way. A gradient-boosted model has feature importances at the population level, but for any given application, the marginal contribution of each feature to that specific decision can vary dramatically. A SHAP value or LIME approximation can produce a plausible explanation after the fact, but those are approximations — and approximations of nonlinear, interaction-heavy models are not the same as the decision logic itself.
We are not saying that gradient-boosted models or neural networks can't be used in credit decisions. We are saying that using a model's global feature importance rankings as a substitute for application-level reason codes is a compliance architecture problem, not a model-performance problem. The distinction matters enormously when an examiner pulls your adverse action notice file and asks you to show that the reasons on the notice actually reflect why that specific applicant was declined.
OCC Bulletin 2011-12, which remains the principal guidance on model risk management for OCC-supervised institutions, describes the expectation that model outputs be explainable and that limitations of a model be understood and documented. A model that generates adverse action reasons through a post-hoc lookup table keyed to score tier — rather than through principled analysis of the actual decision factors for each application — has a documented limitation that most MRM frameworks don't capture cleanly.
What an Examiner Actually Looks For
Consider a hypothetical: a federal credit union with $2.4B AUM and 280,000 members running a consumer personal loan portfolio. The credit union upgraded from a traditional scorecard to a challenger gradient-boosted model in late 2023. The adverse action notice workflow was not updated — it still keys off a reason code lookup table tied to the score tier that the new model produces. The notice says "length of credit history" and "number of recent inquiries" because those are the top factors associated with that score range in aggregate. But the actual model, for that specific applicant, assigned the highest negative SHAP contribution to "utilization of revolving credit" and "number of accounts past due."
The notice is technically four-reason compliant. It's also wrong. It doesn't tell the applicant what they could actually change to get a different outcome. That's the counterfactual reasoning gap — and CFPB exam teams have cited this pattern explicitly in examination findings published in 2022 and 2023.
CFPB examination findings have documented instances where creditors using complex scoring models issued adverse action notices that listed reasons inconsistent with the model's actual outputs for those specific applications. The guidance did not ban those models. It put the burden back on the creditor to close the gap between model output and notice content.
Principal Reason Analysis: The Missing Step
The mechanics of closing this gap require what's sometimes called principal reason analysis — a per-application review of which factors, in what ranking order, contributed to the model's output for that specific decision. For a traditional scorecard, this is trivial: scorecard reason codes are embedded in the model output by design. For an ML model, it requires an explicit explainability layer that runs at inference time, not as a post-hoc reporting exercise.
The difference between inference-time explanation and reporting-time explanation matters legally and practically. Inference-time means the reason code generation is part of the decision pipeline. Every decision produces a ranked set of applicant-level factors that reflects what the model actually evaluated. Reporting-time means you're running a separate explanation job against a stored score, often with approximations, often keyed to population-level patterns rather than application-level ones.
For lenders using standard bureau-delivered FICO scores — FICO 8, FICO 9, or FICO 10T — the reason code infrastructure is delivered by FICO as part of the score product. You get the four principal reason codes from the scoring algorithm directly. The gap problem is most acute when lenders augment that score with internal models, add additional ML-derived attributes, or use any proprietary model output as a tiebreaker or override that doesn't carry its own reason code structure.
The Layered Decision Problem
Mid-market lenders running layered decision architectures — FICO score as primary, internal behavior score as secondary, hard knock-out rules as tertiary — face a compound reason code challenge. When a decline is driven primarily by the knock-out rule (say, a bankruptcy discharge fewer than 24 months ago), the reason code is clean and traceable. When the decline is driven by the interaction of a marginal FICO score and an internal behavior score that together fall below a combined threshold, the "principal reason" question becomes genuinely ambiguous. Which model's factors govern the notice?
The defensible answer is whichever factor, in whichever model layer, had the greatest marginal effect on the outcome. That requires a decision engine that can attribute the final outcome to its contributing inputs across layers — not one that treats each layer as a black box and generates the reason code from the bottom-layer output only.
This is where the compliance liability concentrates. It's not that lenders are acting in bad faith. It's that the adverse action notice generation was designed for single-model, scorecard-based architectures, and the decision logic has grown in complexity faster than the notice-generation workflow evolved to match it.
What a Defensible Adverse Action Architecture Looks Like
A defensible notice architecture has three properties. First, reason codes are generated at decision time, not as a post-processing batch job. The explanation is part of the pipeline. Second, the reason code vocabulary maps to the actual decision factors — bureau tradeline attributes, income-to-payment ratios, derogatory mark recency — not to generic labels that could apply to many different applicants in a score tier. Third, when multiple model layers contribute to a decision, the attribution logic is documented and consistently applied, and the resulting reason code reflects the dominant contribution.
None of this requires abandoning ML models or reverting to logistic regression scorecards. It requires that the decision orchestration layer — the layer between bureau pull and adverse action output — be built with reason-code attribution as a first-class output, not an afterthought appended to a score.
The lenders who will face examination findings in the next round are those running ML-augmented decisioning where the explanation layer hasn't kept pace with the model's complexity. The lenders who won't are those who've built the attribution directly into the decision pipeline, so the notice is a direct read of the model's actual output for that application.
That's the standard Reg B has always meant. The tooling is finally catching up to what the regulation requires.