A Loan Denial Cannot Just Say the AI Scored You Low

Consider one line in a lender’s proposed adverse-action notice: “Your application was denied because your AI risk score was below our approval threshold.” The sentence identifies the mechanism and outcome. It does not say which facts about this applicant drove the score down.

That distinction matters because a model can produce a number without producing a legally adequate reason. In covered credit decisions, the Equal Credit Opportunity Act and Regulation B already impose notice requirements; the Consumer Financial Protection Bureau has said creditors cannot avoid them because a model is complex or opaque. This is an existing compliance constraint, not a proposed right to generic “AI transparency.”

The same words carry different consequences in housing, insurance, and employment, where the Fair Credit Reporting Act, sector-specific statutes, state rules, or local AI requirements may apply. There is no single US adverse-action rule for every automated decision. This explainer uses the lender’s notice as its anchor and is not legal advice.

The rule asks for the reasons for this action

Regulation B generally requires a creditor taking adverse action to give an applicant either the reasons or notice of the right to obtain them under specified conditions. Its operative language calls for a:

“statement of specific reasons for the action taken.”

The regulation also permits a disclosure explaining that the applicant may request those reasons within 60 days, after which the creditor must provide them within 30 days. Timing, coverage, and notice format depend on the transaction, so a team should map the precise requirement with qualified counsel rather than copy a consumer-loan template into every workflow.

The engineering point is narrower. “The AI scored you low” resembles “you failed our internal standard”: it reports that a decision rule fired but withholds the principal factors that caused it to fire for this application. CFPB circulars issued in 2022 and 2023 state that creditors using complex algorithms still must give specific, accurate reasons, and that sample reasons in Regulation B forms are not a checklist that can replace the factors actually considered.

Suppose the lender’s model transformed the applicant’s revolving-account balances, recent payment history, and length of credit history into features, then returned a score below the approval threshold. The notice should not substitute whichever reasons are easiest to display. Its reasons need to correspond to the principal factors behind that applicant’s adverse result, expressed accurately enough to be understood.

The original line therefore fails a basic traceability test: a reviewer cannot move from the notice back to the inputs that affected the decision.

Global importance does not explain one denial

A common model report ranks features by global importance, meaning their influence across a population of applications. It may show, for example, that payment history has a large effect on predictions overall. That finding can help validate the system or monitor whether its behavior has shifted. It does not establish that payment history drove this applicant’s result.

A case-specific explanation asks a different question: which inputs moved this particular output, under the model and data used at decision time? Some scorecards generate reason codes directly from their structure. More complex models often rely on a local explanation method, which estimates how each feature contributed to one prediction relative to a baseline.

Those estimates have limits. SHAP, a widely used family of feature-attribution methods, can distribute credit among correlated variables in ways that depend on its assumptions and reference data. An attribution describes model behavior, not a causal finding about the person. A later explanation can also differ if the team reruns it with another background dataset, changed preprocessing, or a newer model.

That makes a polished explanation chart insufficient on its own. A global feature ranking is too broad, while an unreproducible local explanation is too fragile. The lender needs the output presented to the applicant, but it also needs a receipt showing how that output was produced.

Build the receipt at decision time

Return to the proposed notice. Before replacing its low-score language with reason codes, the lender should reconstruct the path that produced them.

The application first enters an eligibility layer, which may reject incomplete submissions or products unavailable in the applicant’s location. Data then passes through preprocessing that converts raw fields into model features. The model returns a score, a policy layer compares it with a threshold, and a human or automated rule may override the result. Each stage can supply the real reason for the adverse action.

If an eligibility rule caused the denial, explaining the model’s strongest negative feature would describe a calculation that never controlled the outcome.

A usable decision record should preserve the application snapshot and relevant external data as they appeared at the time, along with the transformations applied to them. It should identify the model and policy versions, retain the score and threshold, record any override, and connect the final reason text to the factor or rule that controlled the action. Access logs and correction history matter because a later reviewer needs to know whether the record changed.

This is where many explanation projects become records projects. If a system stores only the final score, a team may be unable to reproduce which input values entered the model after a consumer disputes a report. If it stores only displayed reason codes, it cannot prove that those codes matched the principal factors. Retaining every intermediate value indefinitely creates its own security, privacy, and storage costs, so retention should follow applicable obligations and a defined review window rather than an instinct to log everything.

Local explanations also cost compute. A lender can calculate them after scoring so they do not delay the initial model call, but the adverse-action workflow must wait for a stable result before issuing the notice. Native reason codes are cheaper and easier to reproduce; post hoc methods can support models that lack them, at the price of more validation and a risk that the explanation layer drifts away from the production model.

The fallback is operational, not rhetorical. If the system cannot generate reasons that map reliably to the recorded decision, route the case to a trained reviewer or use a model whose outputs can be supported. A disclaimer about AI complexity does not repair a missing reason trail.

The sector determines which notice is due

Credit has the clearest federal requirement for specific reasons under Regulation B. The FCRA can add another notice when a creditor takes adverse action based wholly or partly on information in a consumer report. That notice identifies the consumer reporting agency, explains that the agency did not make the decision, and describes rights to obtain and dispute the report. Those disclosures do not replace Regulation B’s reasons when both laws apply.

A landlord that rejects an applicant because of a tenant-screening report may also owe an FCRA adverse-action notice. An insurer’s obligations can depend on its use of consumer reports and applicable state insurance law. Calling the scoring software “AI” neither creates one uniform explanation duty nor removes existing duties attached to the data and decision.

Employment has another boundary. When an employer uses a third-party background report covered by the FCRA, the law generally requires a pre-adverse-action step that gives the person a copy of the report and a summary of rights before the final decision, followed by an adverse-action notice if the employer proceeds. An internally built résumé-ranking model is not automatically a consumer report, although employment discrimination laws and some state or local automated-decision rules may still govern it.

Teams should therefore avoid one universal AI-denial template. The product interface can share components, but the compliance logic needs to identify the decision type, jurisdiction, data source, and controlling actor before selecting the notice.

Test the notice against the stored record

The final quality check starts with the exact sentence sent to the applicant. A reviewer should be able to trace each stated reason to the production record, confirm that it concerned the individual rather than the average applicant, and verify that no later model version or refreshed dataset supplied the explanation.

Then reverse the test. Starting with the controlling rule and strongest adverse model factors, check whether the notice omitted a principal reason or replaced it with a friendlier but inaccurate label. Monitor the mapping whenever features, thresholds, preprocessing, or notice language change. A reason-code dictionary that passed review last year can become wrong while the surrounding interface looks unchanged.

For the lender’s original line, the repair is not to add a paragraph describing machine learning. It is to preserve the decision-time evidence and state the specific reasons the creditor can support from that evidence.

Questions people ask

Is a credit score itself a sufficient reason for denial?

A score reports a result, not necessarily the principal factors behind it. CFPB guidance says creditors must provide specific and accurate reasons for covered adverse actions, even when a complex algorithm produced the score; separate credit-score and consumer-report disclosures may also apply.

Can a company use SHAP values as adverse-action reasons?

SHAP values may help identify case-specific feature contributions, but they are not automatically compliant reason codes. The company must validate that the method uses the production inputs, remains stable enough for review, maps accurately into understandable language, and reflects the factor that controlled the outcome rather than a later reconstruction.

Does every employer have to explain an AI rejection?

No single federal rule requires the same explanation for every AI-assisted employment decision. FCRA procedures can apply when an employer relies on a covered third-party consumer report, while discrimination law and state or local automated-employment rules create different duties. Coverage depends on the tool, data source, location, and action.

What should an applicant keep after receiving a notice?

Keep the notice, application materials, relevant correspondence, and any consumer report obtained through the rights described in the notice. Compare the stated reasons with the underlying report and dispute inaccurate information through the listed channels; deadlines and remedies vary, so seek qualified help for advice about a specific case.