Regulation B, implementing the Equal Credit Opportunity Act at 12 CFR 1002.9, requires creditors to notify applicants of adverse action within 30 days and to state the specific reasons for it — and the CFPB's Circular 2022-03 answered the machine-learning era's favorite excuse directly: the reasons must be specific and accurate even when a complex algorithm produced the decision, and "the model did it" is not a reason. A creditor using AI in credit decisions owes the same notice quality as one using a scorecard from 1975, which converts the adverse-action reason pipeline from a reporting function into a model-governance deliverable.
3G Times publishes information, not legal advice. Adverse-action compliance is creditor-specific and exam-exposed; programs should be built with fair-lending counsel.
What does Regulation B's notice require?
Form and content: the notice must arrive within 30 days of a completed application, state the action taken, and — the load-bearing element — give the principal reasons for denial or for less-favorable terms, in specific language the applicant can act on. "Insufficient credit history" is a reason; "did not meet our requirements" is not, and the regulation's commentary has long graded the difference. Where a scoring system drove the decision, the creditor states the reasons for the score's result — the practice matured with reason codes attached to bureau scores. The notice is not ceremony: it is the applicant's map to what went wrong, and the supervisory read of a notice program is whether the map matches the decision.
What did Circular 2022-03 add?
Three sentences of consequence. Creditors must give specific and accurate reasons regardless of the decision system's complexity; vague or contrived reasons that do not actually reflect the model's basis violate the rule; and using complex models is no defense for a notice program that cannot explain them. The circular's context was AI underwriting: as lenders adopted machine-learning scorecards, the industry's inherited practice — mapping model outputs to a fixed library of generic reason codes chosen for readability — drifted from accuracy, because the code selected was not always the factor that moved the score. The circular closed the drift: the reason must be true of this decision, not merely plausible and well-worded. Composed alongside the circular's sibling guidance on adverse-action notices with algorithmic scores, the Bureau's position is a decade old in spirit and fully current in exams.
| Notice element | Reg B expectation | AI-era failure pattern |
|---|---|---|
| Timing | 30 days from completed application | Automated decisions, manual notice queues |
| Specificity | Principal reasons, actionable language | Generic code libraries |
| Accuracy | Reasons reflect the actual basis | Readable codes mismapping the model |
| Completeness | All required statements present | Template drift across products |
How do you build accurate reasons from a complex model?
As an engineering problem with governance, not a translation problem. The reason pipeline needs attribution methods that are validated — whatever technique extracts the principal factors from the model's output for this applicant, the technique itself is model infrastructure, subject to the same validation discipline the credit model is: tested on real portfolios, monitored for drift, documented in the model file. It needs vocabulary honesty: the consumer-facing reason library must be mapped so that each code genuinely corresponds to the factor it names — where the model's influential feature has no plain-language equivalent, the honest move is new language reviewed by counsel, not the nearest comfortable old code. And it needs monitoring tied to outcomes: reason distributions by segment over time, flagging when a retrained model silently changes which reasons surface — the drift that turns an accurate program inaccurate without anyone deciding anything.
How do exams read the program?
Through the consistency triangle: the model file describes what drives decisions, the reason pipeline extracts what drove this decision, and the notices state what the pipeline found. Examiners sample the triangle's agreement — denials pulled, reasons extracted, notices compared — and probe the mismatches first. The fair-lending overlay reads the same artifacts across protected classes: if reason codes distribute differently by protected status in ways the model's inputs don't explain, the notice program has surfaced a model issue, which is the program quietly doing its second job. Institutions that treat the reason pipeline as part of model governance — inventoried, validated, monitored — pass both readings with the same file; institutions that treat it as a letter-generator discover that the letter is an exhibit.
What does this mean in practice?
- Inventory the reason pipeline as a model. Attribution methods belong in the model inventory with validation dates and owners — SR 11-7's logic applied to the explanation layer.
- Audit the vocabulary mapping. Every consumer-facing code must correspond to the factor it names; the mismatches found in audit are the exam's findings found early.
- Monitor reason drift with model drift. A retrained scorecard changes which reasons surface — the notification program should know the same week the monitoring does.
- Test the 30-day clock against automation. Instant decisions with batched notice generation accumulate latency the regulation never excused.
Circular 2022-03's enduring effect was definitional: explanation is a compliance deliverable, not a product feature. The creditors who built reason pipelines with model-governance discipline answer the machine-learning era with the same notice quality Regulation B always demanded — and the ones who kept the comfortable old codes keep explaining, to examiners, why their letters told applicants stories the models never wrote.
The supervisory read deserves repetition in one sentence: examiners sample the triangle — model file, reason pipeline, notices — and the first mismatch narrates the finding. Institutions that survived that sampling with AI models in production are the ones whose reason libraries were audited against the models' actual features, a task measured in days per model and priced far below the alternative.
A last word on the notice's audience: the specific-reasons requirement exists for the applicant, and the AI era has not changed what a confused denied applicant does — reads the letter, tries to fix the named problem, applies again. Notices with accurate machine-extracted reasons close that loop honestly; notices with comfortable codes send applicants repairing the wrong thing, which is the consumer-harm story the rule was written to prevent.
How does pricing-based adverse action differ operationally?
In notification mechanics more than analysis: risk-based pricing triggers the Reg B-lineage notice path with its own timing and content rules, and the AI-era obligation — accurate reasons for the terms offered — runs through the same validated attribution pipeline the denial notices use. One pipeline, two notice templates, a single governance file.
Frequently asked questions
Do the rules differ for AI models and scorecards?
No — the notice duties are identical. The circular's point is that complexity changes the difficulty of compliance, never its content: specific, accurate, timely reasons whatever the decision system's architecture.
Can reason codes be purchased with the model?
Vendor-supplied reason outputs are inputs, not answers — the creditor owes the notice's accuracy, so vendor mappings get the same validation review as internal ones. The obligation travels with the charter, not the software license.
What about less-favorable terms, not just denials?
Adverse action under the ECOA frame reaches pricing and term decisions, not only outright denial — notices with specific reasons are owed in those settings too, and automated pricing models create the same reason-extraction duty the underwriting ones do.
For more context, read How SR 11-7 Applies to AI Credit Models: Building a Compliant Model Risk Management Program.
For more context, read regulation e error resolution.
For more context, read e-sign act consumer consent.