An AI-Written Denial Notice Still Needs the Real Reason

Consider an illustrative loan workflow. An underwriting system declines an application and returns a code such as `DTI_RATIO`, intended to mean that the applicant’s debt-to-income ratio exceeded the program limit. A language model receives the code, application data and an instruction to write a clear explanation.

The resulting sentence sounds reasonable: “Your application was declined because your monthly debt payments are high compared with your income.”

That sentence is compliant only if the underwriting system used that ratio, the factor was a principal reason for the decline, and the wording describes its direction correctly. If `DTI_RATIO` came from a downstream reporting rule, while the model’s decisive factors concerned credit history, the explanation is polished but false. The same problem appears when the language model adds an unsupported cause, such as unstable income, because it associates that concept with debt-to-income calculations.

This is the central engineering constraint. The notice generator cannot discover why the decision happened by reading a few codes and guessing what they probably mean. It must render a reason record produced by the decision system.

The requirement attaches to the decision

For credit decisions covered by the Equal Credit Opportunity Act and Regulation B, the controlling language is more exacting than a general call for transparency. Regulation B 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.” It adds that references to internal standards, policies or failure to reach a qualifying score are insufficient.

The regulation’s official interpretation narrows the task further: “The specific reasons disclosed under §§ 1002.9(a)(2) and (b)(2) must relate only to those factors actually scored in the system.” A creditor generally cannot replace that requirement with a fluent account of factors that might have mattered.

The Consumer Financial Protection Bureau has addressed algorithmic underwriting directly. Its 2022 and 2023 circulars state the bureau’s interpretation that creditors do not receive an exception because a model is complex or opaque, and that reasons selected from model forms must still accurately describe the factors considered or scored. Those circulars communicate the agency’s supervisory and enforcement position; they are not newly enacted statutes, and how the underlying requirements apply depends on the facts.

A lender therefore cannot treat the language model as a compliance oracle. Regulation B is the enforceable constraint. The model is a writing component inside the workflow.

The reason record comes before the prose

Return to `DTI_RATIO`. Before any prompt is sent, the underwriting service should produce a structured reason record, meaning machine-readable fields that identify what drove the result. An illustrative record might contain:

```text decision: decline principal_reason_id: DTI_RATIO factor_used: debt_to_income_ratio direction: above_program_limit rank: 1 source: underwriting_engine ```

These fields do different jobs. The stable identifier connects the decision system to an approved explanation. `factor_used` states the input or derived feature that the system evaluated. `direction` prevents the notice from reversing the meaning.

Rank records which reasons were principal when the system identified several. Source distinguishes an underwriting output from a code added later by a case-management or reporting tool.

A language model may turn that record into plainer prose, but it should not receive a broad application file and decide which facts look unfavorable. That setup quietly creates a second decision system, one that reconstructs causality after the original result and may select sensitive, correlated or merely salient details that did not determine the action.

The stronger design uses an approved mapping first. `DTI_RATIO` maps to a controlled statement such as “Your debt payments were high relative to your income under this loan program’s requirements.” The model may adjust syntax or reading level within narrow boundaries, while a validator checks that the output retains the approved factor and direction. If the record is missing, contradictory or unrecognized, the workflow stops and routes the case to review.

It does not ask the model to fill the gap.

That fallback matters more than the model choice. A newer model can reduce awkward wording, yet no general-purpose generator can repair decision provenance that the underwriting system never captured.

Free-form generation buys little here

For a lender with a limited, stable set of reason codes, a deterministic template is often the better component. Templates cost less to run, return immediately within the application workflow, produce predictable translations and make review manageable. They may sound repetitive. Repetition is preferable to variation that changes the asserted cause.

A language model becomes more useful when approved reasons contain conditional wording, when notices must be rendered at different reading levels, or when a jurisdiction requires additional language around the same verified reason. Even then, generation adds a model call, output validation and exception handling; human review adds queue time, while automated review can miss a paraphrase that is grammatical but materially broader than its source.

The model should see only the minimum fields needed to produce the notice. Sending a full credit file increases privacy exposure and gives the generator more unsupported material to mention. It also makes testing harder because the same reason code can yield different prose as unrelated application details change.

A useful invariant is blunt: if the structured reason record stays the same, changing irrelevant applicant data must not change the stated reason. Another is that replacing the language model must not alter which principal reasons appear. The generator may rewrite. It may not reprioritize.

The receipt must reach back to the model

An audit log can show what the notice generator received, which prompt or template it used, what it produced, whether validation passed and which text was sent. That is necessary evidence, but it cannot establish that `DTI_RATIO` really drove the decline.

For that, the receipt must connect the notice to the underwriting run: the decision identifier, model or ruleset identifier, recorded factor values, reason-ranking method, approved label revision and any human override. Logs need access controls and retention rules because they can contain financial or employment data. Storing every prompt indefinitely is not a neutral observability choice.

Teams should test the complete chain with historical or synthetic cases whose expected reasons are known. The test should catch omitted principal factors, invented contributing factors, reversed directions, ranking changes and wording that implies a different threshold. Reviewers also need cases where no valid reason record exists. The expected output there is no generated notice, followed by escalation or a controlled non-generative fallback.

One governance check is especially revealing: trace a sentence from the mailed notice back to the exact field and decision artifact that authorized it. If the answer ends at the prompt, the organization has a writing log, not a decision audit trail.

Credit rules do not transfer unchanged

“Adverse action” appears across lending, housing and employment, but the notice duties are not interchangeable. Mortgage credit generally falls within ECOA and Regulation B. A landlord using a consumer report for tenant screening may instead trigger Fair Credit Reporting Act duties, including identifying the consumer reporting agency, stating that the agency did not make the decision, and explaining rights to obtain and dispute the report. The FCRA does not impose the same universal principal-reason wording used by Regulation B for every housing decision.

Employment has another sequence. When an employer plans adverse action based on a consumer report, the FCRA generally requires a pre-adverse-action copy of the report and a summary of rights, followed by the applicable notice after the decision. State and local requirements, contractual duties or an employer’s own policy may add explanation obligations. A lending prompt should not be copied into hiring software and labeled compliant.

The shared technical problem remains useful: generated text must not claim that a factor drove a decision unless the controlling system recorded that relationship. The governing law determines what must be disclosed, when it must be delivered and which rights accompany it. This explainer describes the system design issue, not legal advice for a particular notice.

Questions people ask

Can a language model choose the reason from the application file?

It can produce a plausible reason, but that is the wrong assignment. The decision system should identify and rank the factors it used, after which the model may render those verified fields in readable language. Letting the model infer causality from the file creates an ungoverned second explanation process.

Is an approved reason-code list enough?

No. A code dictionary explains what a code is supposed to mean, but it does not prove that the factor drove this decision or was a principal reason. The notice needs a case-specific reason record tied to the underwriting run, plus a controlled mapping from that record to the final text.

Does a human reviewer make free-form generation safe?

Human review can catch obvious drift, but the reviewer still needs access to the decision record and authority to stop delivery. If the interface shows only the application and generated paragraph, the reviewer may approve a convincing explanation without evidence that the model used that factor.

What should happen when the decision system cannot provide a reason?

The generator should fail closed, meaning it withholds the notice rather than inventing missing content. The case can move to a designated review queue or use another approved workflow, while the missing reason record is treated as a defect in the decision system rather than a copywriting problem.