Regulation B Adverse Action Notice for AI Systems
Shipping an AI decision system in a lending product is a compliance problem before it is a modeling problem.
Blake Aber · Predicate Ventures · 2026
The rule that constrains your model
Regulation B governs how creditors communicate decisions. When you deny credit, the rule requires a statement of reasons that is specific and that indicates the principal reason or reasons for the adverse action (12 CFR 1002.9).
This is a design constraint, not a disclosure afterthought. If your model cannot produce specific principal reasons for each denial, the model is not shippable in a regulated product.
The CFPB removed any ambiguity about scope. Adverse action requirements apply equally to all credit decisions, regardless of whether the technology uses complex or 'black-box' algorithmic models (Circular 2023-03). A model you cannot explain is a model you cannot deploy.
The timing and content obligations
Two mechanics shape the system you build.
First, timing. A creditor must notify an applicant of action taken within 30 days after receiving a completed application, covering approval, counteroffer, or adverse action (12 CFR § 1002.9). Your pipeline needs to resolve a decision and generate a notice inside that window.
There is a variant. Instead of stating reasons up front, a creditor may disclose the applicant's right to a statement of specific reasons within 30 days, provided the applicant requests it within 60 days of the notification (CFPB § 1002.9). If you take that path, your system must still produce the reasons on demand, so the explainability requirement does not go away.
Second, content. The reasons must be specific. The official interpretations do not mandate a fixed number of reasons, but note that disclosing more than four is not likely to be helpful to the applicant (CFPB § 1002.9). That gives you a practical target: surface the top reasons, ranked, not an exhaustive feature dump.
Why the checklist shortcut fails
The sample forms in Regulation B include a checklist of reasons. Teams reach for it because it looks like a safe default. It is not.
The CFPB stated that creditors may not rely on the checklist if those reasons do not specifically and accurately indicate the principal reasons for the adverse action, and may not rely on overly broad or vague reasons (Circular 2023-03).
So the reason you send must map to what your model actually did. If the model denied an applicant because of a feature not represented on the standard checklist, picking the nearest checkbox is a violation. The reason has to be accurate to the decision, which means your explanation layer has to read the real drivers, not a canned list.
Designing the explanation layer
The engineering question becomes concrete: for any denied applicant, what were the principal reasons, in rank order, in language a consumer can act on?
For linear and additive models, this is tractable. You can attribute the decision to the features that moved the score across the threshold and translate those into plain reasons.
For gradient-boosted trees and neural models, you need a reason-generation method that produces stable, faithful attributions. The method must be deterministic enough that the same application yields the same reasons, and faithful enough that the reasons reflect the actual decision drivers rather than a post-hoc rationalization.
Build the reason codes as a product surface, not a report. Each reason should tie to a model feature, a human-readable template, and a record of which model version produced it. When a regulator or an applicant asks why, you want a direct line from the notice back to the computation.
The audit trail
Regulation B imposes retention obligations that your logging has to satisfy.
Creditors must retain consumer credit application records, including the notification of action taken and the statement of specific reasons for adverse action, for 25 months after notifying the applicant, or 12 months for business credit (12 CFR § 1002.12).
That retention window sets a floor for your data architecture. For every decision you need to store the input application, the model version, the score, the reasons generated, and the notice sent, and keep them retrievable for the full period.
Tie every stored reason to the model artifact that produced it. Models get retrained. A notice generated in March under one model version, questioned eighteen months later, has to be reconstructable against the model that was live in March. Without version-pinned logs, you cannot answer that question, and the retention requirement becomes a liability instead of a defense.
Scale changes the obligation
The rule scales with volume. A creditor that did not receive more than 150 applications during the preceding calendar year can satisfy the notification requirements, including statements of specific reasons, through oral notifications (12 CFR 1002.9).
Few AI-driven lending products sit under 150 applications a year. The oral-notification carve-out is a small-lender provision, not an architecture you can design around. Assume written, specific, version-traceable notices as the baseline.
A build sequence that avoids compliance debt
Compliance debt accrues when you train a model first and ask how to explain it later. Reverse the order.
Start with the reason taxonomy. Decide the set of specific, accurate reasons your product can defend, then constrain feature engineering so every decision maps to that taxonomy.
Make explainability a training-time requirement. Evaluate reason faithfulness and stability alongside accuracy, and reject models that score well but produce reasons you cannot defend.
Wire the audit trail before launch. Store inputs, model version, score, reasons, and notice together, with retention set to the 25-month floor.
Test the 30-day path end to end, including the request-driven variant where an applicant asks for reasons after a short notice.
The result is a system where the regulatory obligation and the model are the same object. The model that scores an applicant is the model that explains the denial, retained with the notice, traceable to the version that made the call. That is what regulator-ready design means in a lending product: the explanation is not bolted on, it is what the system computes.