Adverse Action Letter: Shipping AI Decisions
An adverse action letter is where your model's reasoning meets the law, and most AI systems aren't built to pass that test.
Blake Aber · Predicate Ventures · 2026
The letter is the product
When a lender declines an application, the law requires a specific explanation. That document is the adverse action notice, and it is the point where an AI decision system either holds up or fails.
Most teams treat the letter as a downstream formality. It is better understood as a design constraint that reaches back into the model, the feature pipeline, and the logging layer.
If your system cannot produce accurate reasons at the moment of decision, you are accruing compliance debt that compounds with every application you score.
Two laws, two obligations
Teams building credit decision systems often conflate the FCRA and ECOA requirements. They are distinct, and satisfying one does not satisfy the other.
Under the FCRA, when adverse action is based on a credit score, the notice must disclose the numerical score, the range of possible scores under the model, the key factors, the date the score was created, and the name of the entity that provided it. The notice must list up to four key factors that adversely affected the score, or up to five if the number of inquiries is a key factor. FCRA credit score disclosure
ECOA, implemented through Regulation B, is separate. The CFPB has stated plainly that disclosing the FCRA key factors does not by itself satisfy the ECOA requirement to disclose specific reasons for the adverse action. Consumer Financial Protection Circular 2022-03
A system that generates one set of disclosures and assumes the other is covered will produce defective notices at scale.
"Accurately describe" is the hard part
The ECOA standard is specific. The reasons in an adverse action notice must relate to and accurately describe the factors actually considered or scored by the creditor.
The CFPB has said a creditor may not simply check the closest identifiable factor on a sample form. Consumer Financial Protection Circular 2023-03
This is the line that complex models cross without noticing. A model that weighs hundreds of features in nonlinear combinations does not reduce cleanly to a short list of reasons. If the explanation layer approximates, rounds, or substitutes a convenient label, the notice no longer accurately describes what the model did.
The CFPB first addressed this for algorithm-based decisions in Circular 2022-03, issued in May 2022, and the 2023 circular builds on it. Circular 2022-03
The message across both: the complexity of the model is not a defense. If you cannot explain a decision accurately, you should not be making it.
Design the explanation before the model
The common failure is to build a high-performing model first and bolt on an explanation method afterward. That ordering guarantees friction, because post-hoc attribution methods do not always describe what the model actually scored.
The better sequence treats explainability as a requirement the model must meet, not a property you hope to recover later.
Constrain the feature space
Every feature that can influence a decision must map to a reason a consumer can understand and a regulator can verify. If a feature cannot be expressed as an accurate, specific reason, it carries explanation risk disproportionate to its predictive value.
Bind reasons to the scored decision
The reasons on the letter must come from the same computation that produced the decision, not a separate approximation. This means the reasoning path is captured at inference time, for the exact input that was scored.
Separate FCRA and ECOA logic explicitly
Build the key-factor disclosure and the specific-reasons disclosure as distinct outputs with distinct logic. Treating them as one path is how teams ship notices that satisfy neither requirement.
Audit trails are not optional storage
Regulation B requires creditors to retain written or recorded material related to a credit application, including the notification of action taken and the statement of specific reasons for adverse action, for 25 months. Supporting Statement for Regulation B
For an AI system, that retention obligation reaches further than the letter itself. To defend a decision months later, you need the input features, the model version, the score, the reasons generated, and the logic that connected them.
If your logging captures only the final decision, you cannot reconstruct why the system reached it. The audit trail has to record the reasoning, not just the result.
Treat the 25-month window as the minimum design horizon for every model version you put into production. A model you retired a year ago still needs to be explainable for decisions it made.
Regulator-ready design
A system built to pass examination shares a few properties.
Decisions are reproducible. Given a stored input and a model version, you can regenerate the exact score and the exact reasons.
Reasons are traceable to features, and features are documented against the disclosures they support.
Model versions are pinned to decisions, so a letter sent in March can be explained by the model that was live in March, not the one running today.
The disclosures are tested the way you test code. If the FCRA notice and the ECOA notice are generated by separate logic, both are validated against their respective standards on every release.
The debt compounds quietly
A decision system can run for a long time before its explanation gaps surface. The decisions go out, the letters are generated, and nothing breaks visibly.
The cost appears later, during an examination or a complaint, when a sample of letters is checked against what the model actually did. By then the defective notices number in the thousands, and the retention requirement means they are all still on record.
The cheaper path is to build the explanation layer, the audit trail, and the separation between FCRA and ECOA logic before the first decision ships. The letter is the test. Design for it from the start.