Adverse Action Notices When an AI Model Denies Credit

The notice reads: “Your application was declined based on the results of our automated underwriting system.” Or it lists “Other”, or “value of collateral” on an unsecured product, or four reasons the model did not actually use. Each of those is the same failure and it is a statutory one, not a style problem.

The notice that fails

The typical way this surfaces is one of three. An examination requests a sample of adverse action notices and traces the stated reasons back to the decision record, and they do not match. A complaint asserts that the reasons given were not the reasons for the decision. Or an internal review discovers that the notice generator maps model scores onto a fixed list of reason codes written for a scorecard the institution retired two model generations ago.

The last of those is the most common and the least visible, because nothing is broken: notices go out, they are well-formatted, they cite plausible reasons, and they are wrong.

Where the duty comes from

Two statutes overlap and it is worth keeping them apart, because they impose different things.

The Equal Credit Opportunity Act, at 15 U.S.C. 1691(d), requires a creditor taking adverse action to provide a statement of reasons, and requires that statement to be specific and to state the principal reasons for the adverse action. The United States Code publishes section 1691. It is implemented by Regulation B at 12 CFR 1002.9, which sets the timing — generally 30 days after receiving a completed application — and the content. The Electronic Code of Federal Regulations publishes section 1002.9. The regulation states in terms that a statement that the adverse action was based on the creditor’s internal standards or policies, or that the applicant failed to achieve a qualifying score on a credit scoring system, is insufficient.

The Fair Credit Reporting Act, at 15 U.S.C. 1681m, requires a separate disclosure when the adverse action was based in whole or in part on information in a consumer report, including the identity of the consumer reporting agency and notice of the right to a free copy and to dispute. A credit-score disclosure obligation attaches where a score was used.

The critical point for anyone reasoning about AI: neither statute mentions models, algorithms or automation, and neither contains an exception for a decision a creditor cannot explain. The duty is stated in terms of the applicant’s entitlement to know the principal reasons. It does not soften because of how the decision was reached.

Why the model makes it harder

A traditional scorecard makes the notice easy: the score is a weighted sum, the largest negative contributions are readable directly, and the reason codes fall out of the arithmetic. Three things about modern models break that.

• Non-additivity. In a gradient-boosted or neural model, a variable’s contribution depends on the values of other variables. There is no fixed per-variable weight to read off, so reasons have to be computed per applicant.
• Feature counts. A model with a thousand engineered features may produce a top contributor that is a transformation — a ratio of a ratio, a rolling aggregate — with no natural-language description. “Insufficient value of feature_882” is a reason in a technical sense and not in the statutory one.
• The fixed-list habit. Regulation B provides sample forms with a checklist of common reasons. Those are samples. Using them as an exhaustive vocabulary means the notice reports the closest available reason rather than the actual one, and that is precisely the substitution the specificity requirement forbids.

The rejoinder sometimes offered — that the model is a black box and therefore the reasons cannot be given — is not a defence, because the obligation runs to the creditor and not to the model. A creditor that cannot state the principal reasons for its own decision has not found a gap in the statute; it has built a decision process it is not permitted to use for this purpose.

Fixing the notice

1. Establish ground truth. For a sample of recent denials, pull the decision record and identify what the model actually weighed most heavily for that applicant. If your inference pipeline does not retain per-decision attributions, that is the first defect to fix — everything else depends on it.
2. Compute per-applicant reasons, not per-model ones.The standard approach is a local attribution method that ranks each feature’s contribution for the individual decision. Whether a given method is acceptable has not been litigated; what is clearly unacceptable is a global ranking applied identically to every applicant.
3. Map features to language a consumer can act on. Each model feature needs a plain-language reason that is accurate about what the feature measures. Where a feature is a composite, the mapped reason must describe the underlying behaviour, not the composite. Build this mapping with the modelling team and review it with counsel, once per model version.
4. Do not cap the vocabulary at the sample form. If the actual principal reason is not in the Regulation B sample list, write it. The samples do not limit what may be disclosed.
5. Wire it to the notice generator and remove the fallback.A default reason code used when attribution fails is a silent compliance failure. Fail the notice loudly instead and handle it.
6. Regenerate the mapping on every model change. Tie it to the model version in your inventory so a retrain cannot ship without it. See model risk validation.
7. Test it. Sample notices, hand them to someone who did not build the system with the corresponding decision record, and ask whether the stated reasons are the reasons. Retain that testing; it is the evidence.

A worked shape of what a per-decision record needs to carry, so the notice can be regenerated and defended later:

decision_record = {
  "application_id": "A-2026-0041983",
  "decision": "denied",
  "model_id": "credit-risk",
  "model_version": "2026.05.2",          # exact, never a moving alias
  "score": 0.2814,
  "threshold": 0.4000,
  "reason_features": [                    # local attributions, ranked
    {"feature": "revolving_utilisation_12m", "contribution": -0.118},
    {"feature": "months_since_delinquency",  "contribution": -0.071},
    {"feature": "inquiries_6m",              "contribution": -0.044}
  ],
  "reason_text_map_version": "rb-map-14", # reviewed with counsel
  "consumer_report_used": true,           # drives the FCRA disclosure
  "decided_at": "2026-05-14T09:12:44Z"
}

The two fields that make this defensible years later are model_version and reason_text_map_version. Without them you can reproduce neither the decision nor the wording you sent.

The status of the CFPB’s guidance

The Consumer Financial Protection Bureau addressed this directly in two circulars. Circular 2022-03, published on 26 May 2022, stated that creditors using complex algorithms must still provide accurate and specific reasons and cannot rely on the technology’s complexity as an excuse. The CFPB publishes Circular 2022-03. Circular 2023-03, published on 19 September 2023, addressed the sample forms specifically, stating that the checklist of sample reasons is not a safe harbour where the actual reason is not among them. The CFPB publishes Circular 2023-03.

Two adjacent obligations are worth checking at the same time, because the same decision record supports all three: state automated-decision rules that may add a notice or opt-out right (see US automated decision laws), and the parallel duties where the model is scoring people for employment rather than credit (see AI and hiring law).