Writing an Adverse Action Notice When a Model Declines Someone

The core technical problem is that a credit scorecard with a handful of weighted variables has an obvious path from input to decision, while a gradient boosting or neural model produces output from nonlinear interactions across many features with no inherent human-readable path Trussed on ECOA notices.

Legacy explanation methods do not survive that. "Drop one" and impute-median techniques only handle single-direction, single-variable relationships, where an increase in one variable always moves the score the same way; a model with hundreds of interacting credit variables breaks that assumption, which is why Shapley-value attribution from cooperative game theory became the standard approach Zest AI on model explainability.

A decision rule that holds up in practice:

• If you rely on an industry scorecard, you may rely on the reason codes the consumer reporting agency supplies; you have effectively outsourced the underwriting Zest AI.
• If you build your own custom model, you must produce your own explanations, and for machine learning that means per-applicant attribution math, not aggregate importance Zest AI.
• If a vendor supplies the model, you still own the obligation. Lenders retain full compliance responsibility even when the reasons come from a third-party model, so confirm the vendor can produce feature-level explanations adequate for a notice before you go live Trussed on specific reasons.

A minimal attribution pass at decision time looks like this: compute the top contributing features for the declined applicant, rank by absolute contribution in the direction of the decline, and keep the raw attribution values with the decision record.

# Pseudocode: one declined applicant, one model version
attributions = explain(model_version, applicant_features)
negative = sorted(
    [a for a in attributions if a.shap_value < 0],  # pushed toward decline
    key=lambda a: abs(a.shap_value),
    reverse=True,
)
top_features = negative[:4]  # candidate principal reasons

Four is a common working number, not a legal one: Regulation B does not set a fixed count of reason codes per notice, only that the listed reasons reflect the factors that actually affected the applicant Trussed on specific reasons.

The insight most teams miss: attributions are model-level evidence, not applicant-facing text. They need a governed mapping layer that translates feature-level output into standardized reason code categories, and that mapping needs validation against Regulation B commentary so the reasons are principal causes rather than plausible-sounding ones Trussed on ECOA notices.

Build one governed table that joins three things: the model feature name, an internal reason code, and the customer-facing sentence. Version it alongside the model. When the model changes, the mapping is re-validated, because reasons must remain accurate and stable as the model or its inputs change Trussed on specific reasons.

The last row matters. "You failed to achieve a qualifying score" is explicitly insufficient under Regulation B, and a reason code that restates the threshold teaches the applicant nothing CrossCheck on adverse action denial reasons. Keep infrastructure and threshold metadata out of the disclosure and in the audit file.

Two quality gates on this table:

1. Specificity. Does the sentence name a factor the model actually used for this applicant? A loosely matched code is not a compliance strategy if it is not the real reason CrossCheck.
2. Actionability. Can a reasonable applicant change the outcome next time, or request a correction? If not, the sentence is decoration.

Plain language here is a narrow craft, not general readability. Three rules do most of the work.

Name the factor, not the score. "Insufficient income" on its own is weak; "we could not verify enough of the income you listed" tells the applicant what to fix. Regulation B requires the specific principal reasons, and generic statements about internal standards or policy are not substitutes CrossCheck.

Do not try to teach the model. The Official Interpretation allows you to disclose a factor even when its relationship to creditworthiness is not intuitive to the applicant, so you are not obliged to explain the mechanics of a cash-flow volatility feature CFPB innovation blog. This is the single biggest time saver in drafting.

Keep the FCRA layer separate. When the action is based in whole or in part on a credit score from a consumer reporting agency, the notice must also disclose the key factors that adversely affected the score, the agency's name and contact information, and additional content CFPB innovation blog. Build the notice as two blocks: FCRA disclosures, then your own model reasons. Do not blend them, and do not let a templating engine drop one block.

This is also where customer-service quality becomes a compliance asset. In Deloitte's survey of US banking customers and executives, 71 percent ranked ease of resolving issues as their top support factor, 28 percent said repeated negative contact-center experiences made them reduce spending with the bank, and 31 percent stopped doing business with the institution altogether Deloitte Insights. A decline notice is the first contact-center interaction after a rejection. If the reasons are vague, the call becomes a dead end, and the customer's next action is often to leave.

If your team is drafting and testing this language at volume, a Quanta Expert can take the reason-code library and your tone guide and return finished sentence sets for review: https://quantaintelligence.ai/agents

The notice should not leave the building until a person has confirmed two things: that the decline decision is correct, and that the listed reasons match what the model did for that applicant.

Build the review as a queue, not a courtesy. Each item carries the application file, the model score band, the top attributions, the proposed reason codes and the drafted sentences. The reviewer's job is to check fit, not to re-underwrite from scratch, so the queue needs a time standard that matches the decision timeline your jurisdiction imposes.

Two things justify the human step beyond good service. First, overrides and manual review are their own stage in the credit funnel, and disparities can originate there rather than in the model, which means a reviewer who rubber-stamps notices removes your ability to detect that CrossCheck's funnel analysis. Second, supervisory thinking has moved decisively toward keeping a human in control of critical automated decisions while requiring auditable governance even where the underlying model is not fully transparent Moody's on AI model risk standards.

Set a decision rule for disagreements. If the reviewer's file review contradicts the model, the decline goes back to underwriting with a written note, and no notice is sent. If the reviewer agrees with the decline but not the reasons, the mapping is corrected and the notice regenerated from the corrected library, with both versions retained. Never edit reasons by hand in the notice itself.

The notice is evidence. A regulator or auditor reconstructing a decline needs to see the model version, the inputs, the attributions, the reason mapping in force that day, the reviewer identity, and the exact text sent. If any link is missing, you cannot demonstrate that the disclosed reasons were accurate, and accounting firms describe exactly this documentation burden for AI and third-party models, including the expectation that a knowledgeable third party could recreate the model's behavior from the record Kaufman Rossin.

A workable record schema:

• decision_id, application_id, timestamp of model score
• model_id and version hash
• input vector snapshot (or a hash plus a retrievable store)
• raw attribution values for the top contributing features
• reason code library version and mapped codes
• drafted notice text hash, reviewer ID, review timestamp and outcome
• send timestamp and channel

Run a monthly reconciliation: sample notices, replay them against the stored inputs and the stored library version, and confirm the notice text reproduces. Drift shows up here first. Supervisory frameworks increasingly expect model risk management to catch performance degradation and unreliable behavior over time, and reason codes that stop matching the model are a leading symptom Moody's. Note also that the OCC's updated model risk management guidance is risk-based and tailored to institution size and model use, and that generative and agentic AI models sit outside its scope, which means your own documentation discipline, not a checklist, is what carries the file OCC News Release 2026-29.

If translation to plain language is generated by a model in your pipeline, route it through a single API so the prompt, model version and output are all captured in one place: https://quantaintelligence.ai/inference

An applicant is declined by a gradient-boosted model. Raw attributions show four features pushing toward decline: recent delinquency count, revolving utilization, months since last new trade, and a cash-flow volatility index. Two more features pushed slightly toward approval but were outweighed.

Wrong notice: "Your application did not meet our credit criteria. You failed to achieve a qualifying score." This is insufficient, because it restates the creditor's internal standard rather than the specific reasons CrossCheck.

Also wrong: "Our AI model found your application too risky." Model complexity is not a defense, and "the AI decided" is not a reason Consumer Finance Monitor on the CFPB circular.

Right notice, four reasons, each tied to a factor the model actually used: too many recent late or missed payments; high revolving balances relative to limits; a credit history shorter than required; large recent swings in deposits. Plus the FCRA block, because a credit score was part of the file CFPB innovation blog.

Then the reviewer confirms the file, the codes match the attributions, the sentences pass the language check, and the notice is released with a record of all four steps. The applicant calls, hears the same four reasons, and knows which two are fixable within a quarter.