"The Model Said No" Is Not a Reason. What Regulation B Asks of an AI Credit Decision.

The new credit model is better. It approves more good applicants and fewer bad ones, and the risk team signed it off. Then compliance asks for the decline letters.

The letters say what they always said: the application did not meet the lender’s criteria. The engineers say the model weighs hundreds of inputs and there is no single reason. Someone suggests asking a language model to write a reason from the model’s output.

Compliance asks a simpler question. Are those the reasons the applicant was actually declined for?

The paradox: The better the model is at deciding, the harder it can become to say, truthfully, why it decided.

What We Found

Before we recommend anything to a lender about an AI credit decision, we read the rule that governs the notice the applicant receives. For this article we read Regulation B (12 CFR Part 1002), which implements the US Equal Credit Opportunity Act, and its official staff interpretations in Supplement I, as published on eCFR.

Four findings stand out.

The reasons must be specific, and a failed score is not a reason. Section 1002.9(b)(2) says: “The statement of reasons for adverse action required by paragraph (a)(2)(i) of this section must be specific and indicate the principal reason(s) for the adverse action. Statements that the adverse action was based on the creditor’s internal standards or policies or that the applicant, joint applicant, or similar party failed to achieve a qualifying score on the creditor’s credit scoring system are insufficient.”

The reasons must be the real ones. The official commentary says the specific reasons disclosed “must relate to and accurately describe the factors actually considered or scored by a creditor”. For a credit scoring system, “the reasons disclosed must relate only to those factors actually scored in the system. Moreover, no factor that was a principal reason for adverse action may be excluded from disclosure.” The creditor “must disclose the actual reasons for denial … even if the relationship of that factor to predicting creditworthiness may not be clear to the applicant.”

The method of choosing reasons is flexible. “The regulation does not require that any one method be used for selecting reasons for a credit denial or other adverse action that is based on a credit scoring system. Various methods will meet the requirements of the regulation.” The commentary describes two methods based on how far the applicant’s score on each factor fell below an average, and accepts “any other method that produces results substantially similar”.

In a system with several parts, the reasons follow the part that said no. Where a system combines credit scoring with a judgmental assessment, “the reasons for the denial must come from the component of the system that the applicant failed”. Where a feature calls for automatic denial because of a negative factor, “the creditor must disclose that specific factor.”

What our review does not show: We read the regulation and its official commentary, not the statute, case law or supervisors’ examination practice, and nothing here is legal advice. Neither the regulation nor the commentary mentions artificial intelligence; they describe credit scoring systems, judgmental systems and systems that combine them. How a particular AI model maps onto those terms is a question for each lender’s compliance team and counsel. Other notice rules, such as those under the Fair Credit Reporting Act, sit beside this one and are not covered here.

Why an AI Decision Makes This Harder, and When It Does Not

Our reading is that the rule does not change because a model is more advanced. What changes is how hard it is to meet.

A scoring system built on a set of factors can produce its reasons as a by-product: the factors where the applicant fell furthest short are recorded at the moment of the decision. A rule that denies automatically for a stated factor names that factor. A person making a judgmental decision can say which parts of the record they reviewed.

The difficulty starts when the decision comes from something that cannot say which factors it actually used, and the reasons are written afterwards. A language model asked to “explain” a decision will produce fluent reasons. Whether they “relate to and accurately describe the factors actually considered or scored” is a separate question, and the notice has to answer it.

The gap we see: many lenders are improving the decision and leaving the notice to catch up. Lenders that design the decision so its reasons are recorded when it is made, from the factors it actually scored, can adopt better models without weakening the one document every declined applicant receives.

This is our reading of the regulation. It is not legal advice and not a measured market figure.

Four Ways to Produce the Reasons, Weighed

Option	When it fits	What it risks
A complex model decides; an explanation tool estimates reasons afterwards	The lender’s compliance team and counsel are satisfied the estimates reflect the factors actually scored	Reasons that are estimates of the decision rather than records of it
A model decides; a language model writes the notice	Wording only, from reasons already selected by an approved method	If the language model chooses the reasons, they may drift from the factors actually used
A scoring system with a documented method for selecting reasons, rules for automatic denials, people for judgmental review	Most consumer credit decisions	Needs the reason-selection method designed, tested and documented
AI reads documents and extracts data; the decision runs in a scored system or fixed rules; the notice comes from approved templates	The lender wants AI in the process without AI choosing the reasons	Requires separating reading from deciding in the workflow

Our recommendation: keep the choice of reasons inside the decision itself. Record, at the moment of each decision, the factors that drove it, using a selection method your compliance team has approved; let AI read applications and help word notices, but not decide which reasons are true. Take the mapping of any AI model onto the regulation’s terms to compliance and counsel before it goes live.

Where You Are Now, and Where You Should Be

Measure	Typical starting point	Where it should be	How it is checked
Where reasons come from	Generic wording, or written after the decision	Recorded at the decision, from the factors actually considered or scored	A trace from each notice to its decision record
The method for selecting reasons	Undocumented	Written, approved by compliance, and tested	Method documentation and test results
Systems with several parts	Reasons from whichever part is easiest	Reasons from the component the applicant failed	Decision logs by component
Automatic denials	Folded into a general reason	The specific factor disclosed	Notice review
Notice wording	Free text, sometimes generated	Approved templates; AI words only what the decision recorded	Template library and sample review

The starting points above are what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a client.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the credit workflow, how notices are produced and what compliance has asked. You leave with a short written note of what we found.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We diagnose: the Workflow Diagnostic. It sorts each step of the workflow into compile, keep on an AI model, or don’t automate, and includes a 100-rerun consistency test of your current pilot, a policy-to-rules map, the evidence gaps, the cost per case today against projected, and a change plan. It may recommend another firm or tool, or not automating at all. We take no referral fees on model or platform recommendations.
4. If you approve, we prove it: a Proof Sprint. One workflow, on your own cases, measured for consistency and for accuracy against your own experts. You keep the code.
5. We review against the benchmark. Before work starts we set the benchmark. At each stage we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The Diagnostic fee is credited against a Proof Sprint within 90 days.

What changes for the business:

Role	What they gain
CRO or Head of Compliance	Every decline notice traces to the factors the decision actually used, recorded when it was made.
CFO	A better credit model adopted without the cost of reworking notices, or of explaining them under examination.
CTO or CIO	A design rule the team can build to: the decision records its own reasons, and AI only words them.
Head of AI or Data	Room to use stronger models, because the reasons question is answered by design, not after the fact.
CEO	Growth from better credit decisions, without weakening the letter every declined applicant reads.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation as a case. It quotes a regulation and its official commentary.	The Workflow Diagnostic maps each step of the credit workflow, including where reasons are produced, and sets out the evidence gaps for the lender’s compliance team.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Where a question is for counsel, we say so.

Book a free Reliability Review →

Get a fixed quote →

See the Workflow Diagnostic →