An AI Denial Letter Needs Reasons a Customer Can Challenge

Consider one concrete workflow: a lender’s underwriting system receives an application, retrieves credit and income data, transforms those inputs, produces a risk score, applies eligibility rules, and generates a denial letter. The letter says the applicant had “insufficient creditworthiness.”

That sentence sounds explanatory. It is not useful. The applicant cannot tell whether the system used an outdated debt balance, misunderstood variable income, applied the wrong loan threshold, or relied on a factor that should not have affected the decision. The lender may have a colorful feature-importance chart in its internal dashboard, but the customer still lacks a claim that can be checked.

The operational test is narrower than general transparency: can the organization reconstruct why this application was denied and state the principal reasons in language that lets the applicant dispute a fact or the application of a policy?

The rule attaches to the decision, not the model

For US credit decisions, Regulation B under the Equal Credit Opportunity Act supplies an unusually direct requirement. Its adverse-action provision 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.”

The same provision says that citing internal standards or saying an applicant failed to achieve a qualifying score is insufficient. Consumer Financial Protection Bureau guidance has also made clear that creditors do not get an exemption because they use complex algorithms and cannot rely on a model-form checklist when the real reason falls outside it.

That does not make one regulatory rule universal. Insurance, housing, and public-benefit decisions can sit under different federal, state, local, and program-specific requirements, while the Fair Credit Reporting Act imposes separate notice duties when a consumer report contributes to adverse action. Teams need counsel to identify the rules governing their workflow. This analysis is not legal or financial advice.

The engineering implication is still portable. A regulated organization cannot treat explainability as a generic property purchased with a software package. It must connect the final outcome to the actual inputs, transformations, model output, policy rules, and human interventions used for that case.

Return to the denial letter. If a hard eligibility rule rejected the application before the model score mattered, citing the model’s strongest features would misdescribe the decision. If the model score crossed a threshold but a human reviewer then denied the file for unverifiable income, the letter should not pretend the score was dispositive. Decision sequencing matters.

Feature importance answers the wrong question

Feature importance estimates how much input variables influenced a model’s prediction, either across many cases or for one case. A local explanation concerns one prediction; a global explanation summarizes broader model behavior. Both can help developers test a system, but neither automatically produces a valid adverse-action reason.

Suppose an internal explanation ranks revolving-credit utilization as the largest contributor to a score. That ranking may be relative to a statistical baseline rather than to the lender’s approval threshold. Correlated variables can divide or swap apparent importance, while small changes in the explanation method can reorder factors without changing the prediction. A transformed feature may also be unreadable outside the model, such as a normalized ratio assembled from several source fields.

The deeper problem is causality. Importance shows how a model associated an input with its output under a particular explanatory method. It does not establish that changing the input would have changed the final decision, especially when policy rules run before or after the model.

A feature-importance chart therefore belongs in model validation and investigation. It should not be copied into the letter without checking that each stated factor was present, materially affected this case, and survived the rest of the decision pipeline.

Reason codes need a traceable mapping

A reason code is a controlled label that maps a decision factor to customer-facing language. For the sample workflow, an internal code might connect a verified debt-to-income calculation to wording that identifies high monthly debt obligations relative to verified income. The exact wording and required specificity depend on the applicable rules and facts.

Good reason-code generation starts after the system has identified the components that truly determined the outcome. The decision service records which eligibility rules fired, whether the model score crossed a relevant threshold, and whether a reviewer added or replaced a reason. A mapping layer then converts those case-level causes into approved language.

This creates a fidelity problem. A short code library is easier to review, translate, and keep consistent, but broad codes can erase the distinction between low verified income and an unexpectedly high requested amount. A large library captures more detail, yet it costs more to govern and creates more opportunities for contradictory or poorly tested wording.

The answer is not to expose raw model fields. It is to make every customer-facing code traceable back to a defined condition and a value in the preserved case record. The lender should be able to show that the cited condition was true at decision time and that it was principal rather than incidental.

That trace also prevents a common failure: selecting the nearest available reason from a fixed menu even though it did not drive the denial. A polished sentence generated after the fact is still wrong if the underlying mapping is false.

Counterfactuals are useful, but easy to overstate

A counterfactual explanation describes a change that would have produced a different model result, such as a lower requested amount moving an application across the model threshold while other modeled inputs remain fixed. It can make a decision boundary easier to understand than a ranking of influential features.

Yet a model-level counterfactual is not necessarily an approval path. The revised application may fail a separate eligibility rule, trigger a different pricing policy, or require evidence the customer cannot supply. Some generated changes may also be impossible or inappropriate, particularly when they involve immutable characteristics, proxies, or variables outside the customer’s control.

Counterfactual generation adds computation and governance work because the system must search for plausible changes while respecting constraints on which fields can move together. More important, the letter must not present a hypothetical as a promise. “The model score would differ” and “the application would be approved” are distinct claims.

In the denial workflow, a counterfactual can supplement a specific reason code when the organization has validated it against the full decision pipeline. It cannot repair an inaccurate reason or replace the record showing what happened.

The case record is the receipt

Case-level documentation is the preserved evidence for one decision. At minimum, the lender needs the input values as used, their sources, the transformations applied, the model and policy versions, the relevant outputs, the rules that fired, and any human review or override. Retention and access controls must follow the laws and policies governing the data.

Capturing this record increases storage, integration, and review costs. It may also expose sensitive information if access is too broad. Those are real constraints, but reconstructing a decision later from current databases is unreliable because source data, code, thresholds, and third-party services change.

The record should also distinguish missing data from a value of zero, raw data from corrected data, and a model recommendation from the final action. Otherwise an investigator can see what the system stores today without learning what the decision service saw at the relevant moment.

When the applicant challenges the sample letter, the service team does not need to rerun a current model and hope for the same answer. It retrieves the decision snapshot, verifies the cited debt and income fields against their sources, checks the rule and model path, and corrects or escalates the case if the record does not support the notice.

A practical predeployment test follows from that workflow. Select denied cases, ask a reviewer who did not build the model to connect every sentence in each letter to the preserved evidence, then test whether correcting the cited fact changes the relevant calculation or sends the case through a defined reconsideration path. If the reviewer must infer what happened from a feature-importance chart, the system is not ready to issue the letter.

Questions people ask

Is feature importance enough for an AI denial letter?

Usually not. Feature importance can help explain model behavior, but it may not identify the rule, threshold, or human judgment that determined the final outcome. A customer-facing reason should match the principal cause in that case and connect to evidence the organization can retrieve.

Are counterfactual explanations better than reason codes?

They answer a different question. A reason code states why the recorded decision occurred, while a counterfactual identifies a change that might alter a model result. Use a counterfactual only after checking it against eligibility rules and other decision stages, and do not phrase it as a guarantee of approval.

What should an organization retain for each automated decision?

Retain the inputs as used, source references, transformations, model and policy versions, outputs, triggered rules, and human actions needed to reconstruct the decision. The precise record and retention period depend on the workflow’s legal, security, and privacy requirements.

Can a human reviewer fix a weak AI explanation?

A reviewer can correct a notice when the underlying case record is complete. Human review cannot reliably recover missing inputs, an overwritten model version, or an undocumented rule path. The fallback must be designed into the decision system before notices are issued, not improvised after a complaint.