Adverse Action Notices: Getting Decline Reasons Right

Adverse action notices are treated in most lending operations as a downstream formality — a template fired off after the real work of deciding is done. They are, in practice, the most examinable artifact your underwriting produces, because they're written, they're sent to consumers, and they can be compared directly against what your model actually did. A generic reason attached to a specific decline is not a technicality; it's the compliance failure that is easiest to find and hardest to explain. This guide covers what triggers a notice, how specific reasons have to be, how to generate them from complex models, and what to retain.

Why the notice exists

The requirement serves three purposes, and understanding them explains why regulators treat vagueness as a substantive failure rather than a formatting one.

• It gives the applicant actionable information. Someone told their utilization is too high can address it. Someone told they "did not meet our criteria" has learned nothing and cannot improve their position — which defeats the point.
• It enables error detection. A reason citing a delinquency the applicant doesn't have prompts them to check their credit report and dispute it, per our error correction guide. Without the reason, the error persists silently.
• It creates accountability. A lender required to state why is a lender required to know why, which is a discipline on the decision process itself.

That third function is the one that matters most for institutional design: the notice requirement is what forces explainability to be a property of the system rather than an aspiration. A lender that cannot articulate per-applicant reasons has not built an explainable process, whatever its documentation claims — and the notice is where that becomes visible.

What triggers a notice

Broader than most lenders assume, and the account management cases are the ones most often missed.

Action	Notice generally required
Denial of an application	Yes — the clear case
Counteroffer not accepted	Generally yes, where the applicant doesn't take the alternative offered
Credit line reduction	Generally yes, as an unfavorable change in terms
Account termination	Generally yes, subject to defined exceptions
Unfavorable term change	Generally yes
Incomplete application	Different treatment — notice of incompleteness may apply instead
Withdrawn by applicant	Generally no
Consumer report used in a non-credit decision	Separate notice obligation under credit reporting law — employment, insurance, tenant screening

Two points worth flagging. Account management actions carry the same obligations as origination, which is the gap our portfolio management guide identifies — line reductions and closures based on creditworthiness require the same specificity and documentation as declines, and they're frequently handled by teams that don't think of themselves as making credit decisions. And business credit has its own requirements, which differ from consumer credit in content and timing depending on the applicant's size, and are frequently overlooked entirely by small business lenders.

The specificity standard

The requirement is that the notice state the principal reasons for the decision — the factors that actually drove the outcome for that applicant. Regulators have been explicit that generic language does not satisfy it.

Failing reasons look like:

• "Did not meet our credit criteria"
• "Insufficient credit score" without identifying what in the file produced it
• "Based on information in your credit report" without saying what
• "Model output below threshold"
• Reasons that are technically true but not the drivers — listing a minor contributing factor while omitting the dominant one

Working reasons identify the factor and are specific enough to act on: proportion of balances to credit limits too high, length of credit history too short, delinquency on prior accounts, income insufficient for the amount requested, insufficient cash flow relative to existing obligations, and so on.

Two frequent errors deserve naming. Listing reasons that didn't drive the decision — padding the notice with plausible-sounding factors — is inaccuracy, and it's detectable by comparing notices against model attribution. And using the same reasons for everyone, which is the tell that reasons are being generated from a policy description rather than from what happened to that applicant.

The counterfactual test

The practical standard regulators describe is counterfactual, and it's the most useful internal check available: if the factor cited had been different, would the outcome plausibly have been different for this applicant?

Applied honestly, this test disqualifies most weak reason practices:

• A reason citing utilization on an applicant whose utilization was fine fails immediately.
• A reason citing a factor that contributed marginally while a dominant factor goes unmentioned fails, because changing the cited factor wouldn't have changed the outcome.
• A generic reason fails because it isn't a factor at all.

Building the test into the process is straightforward and worth doing: for each decline, the system should be able to state which factors, if changed, would have produced approval. That's both the compliance requirement and — usefully — the same computation that supports a genuinely helpful decline explanation, so the compliance work and the customer experience work are the same work.

Generating reasons from models

This is where lenders using modern underwriting most often have a gap, and the regulatory position is unambiguous: model complexity is not a defense. The obligation applies regardless of the technology used, which means a lender using a model it cannot explain has a compliance problem, not a technical limitation.

What works:

• Per-applicant attribution rather than global feature importance. What mattered for this applicant is the question; what the model weights on average is not.
• Attribution methods that produce individual explanations, mapped to human-readable reason language.
• A mapping layer translating technical features into reasons an applicant can act on — "cash flow variability" rather than a variable name.
• Validation that the mapping is honest, by sampling decisions and confirming the stated reasons correspond to what actually drove them.

What doesn't work: reason codes assigned by a lookup table keyed to score bands, reasons derived from the model's general characteristics rather than the individual decision, and — the most common — a vendor score with no usable attribution behind it.

On that last point: a vendor arrangement does not transfer the obligation. The lender making the decision owes the notice and must provide reasons it can defend, which means reason-code access and documentation belong in the contract, per the vendor oversight requirements in our monitoring guide. "The vendor's model declined you" is not a principal reason.

The same discipline extends to alternative data. Where cash flow information drives a decline — the signals in our cash flow guide — the reason must reflect that specifically, and "insufficient credit history" is inaccurate if the actual driver was the applicant's monthly low balance. This matters particularly for the thin-file population in our thin-file guide, where the temptation to default to a credit-history reason is strongest and frequently wrong.

Existing accounts

Account management is where notice obligations are most often missed, because the decisions feel operational rather than credit-related.

The recurring failures:

• Line reductions issued without notice, or with a notice citing no specific reason.
• Batch actions across a portfolio with a single generic reason applied to everyone, which fails specificity by construction.
• Closures treated as operational housekeeping when they were creditworthiness-based.
• Term changes where the notice describes the change without stating why.

The remedy is process placement: the adverse action step belongs inside the account management workflow, triggered by the action rather than remembered afterward — and the reason must be derived from that account's specific circumstances, which means batch actions need per-account attribution or they shouldn't be batch actions.

Content and timing

Notices carry specific content requirements and deadlines, which differ between consumer and business credit and between the credit and credit-reporting obligations. The components generally required:

• Statement of the action taken.
• The principal reasons, or a statement of the right to request them where that alternative applies.
• The equal credit opportunity notice and the identity of the federal agency administering compliance.
• Credit reporting agency identification where a consumer report was used, with the statement that the agency did not make the decision and cannot explain it.
• The right to a free report from that agency within the applicable window, and the right to dispute.
• Score disclosure where a credit score was used, including the score, range, key factors, and date.

Timing requirements are defined and unforgiving, and they differ for consumer versus business applicants and by application size. Two practical notes: delivery method and proof matter, since an obligation met without evidence is difficult to demonstrate later; and the notice should be readable, because a technically compliant notice written in a way the applicant cannot understand fails the purpose even where it satisfies the form.

What to retain

The retention question is not "did we send a notice" but "can we reconstruct why this applicant received these reasons" — potentially years later, in an examination, on a specific file.

• The notice sent, with date and delivery method.
• The decision record — inputs, model version, score, and outcome.
• The reason attribution that produced the stated reasons for that applicant.
• The model version and its reason-mapping configuration as of the decision date, which is the item most often unavailable because configurations change without versioning.
• Any override and its documented basis, since an overridden decision needs reasons reflecting the actual basis rather than the model's.
• Policy documentation in effect at the time.

The standard that applies here is the one this desk keeps returning to across regulated activities: an undocumented control and an absent one are treated identically. A correct reason you cannot reconstruct is, for examination purposes, indistinguishable from a wrong one.

Auditing your own notices

This is inexpensive and finds problems reliably, which is a rare combination.

1. Sample recent notices across products, channels, and decision types including account management actions.
2. Apply the counterfactual test to each stated reason against that applicant's actual file.
3. Check reason distribution. If one reason appears on the overwhelming majority of notices, it's likely a default rather than an attribution — the single fastest diagnostic available.
4. Compare against model attribution to confirm stated reasons match actual drivers.
5. Test readability by having someone outside the credit function read a notice and say what they'd need to fix.
6. Verify timing against the applicable deadlines, by decision type.
7. Check coverage — that every action requiring a notice generated one, which frequently surfaces missed account management cases.
8. Review reason distribution across demographic outcomes, since a reason appearing disproportionately for one group is a fair lending signal worth investigating, per our governance report.

Frequently asked questions

---

This guide is educational and does not constitute legal or compliance advice. Adverse action content, timing, and coverage requirements derive from federal regulation and differ between consumer and business credit and across use cases; consult qualified counsel regarding your notices.