Adverse Action Credit: Shipping AI Without Debt
An AI credit model that cannot explain a denial is a liability waiting for a written request.
Blake Aber · Predicate Ventures · 2026
The gap between a prediction and a reason
A credit model outputs a score. A regulator asks for a reason. These are not the same thing, and the distance between them is where compliance debt accumulates.
Most teams build the model first and treat the explanation as a reporting feature bolted on later. That order is backwards. The reason you give an applicant is a legal artifact, and it has to be correct on the first day the system makes a live decision.
Under Regulation B, when an applicant makes a written request for the reasons behind an adverse action, the creditor must provide a written statement of specific reasons if the request arrives within 60 days of notification (§ 1002.9, Consumer Financial Protection Bureau). The clock starts when you tell someone no. The system that said no has to already know why.
What "specific reasons" actually demands
The common shortcut is to surface the top factors that moved a credit score and call it done. That does not meet the standard.
Regulation B's commentary is explicit: disclosing the key factors that adversely affected a consumer's credit score does not satisfy the ECOA requirement to disclose specific reasons for the adverse action (12 CFR Part 1002, eCFR). The score factors are about the score. The adverse action reasons are about your decision.
There is a second rule that constrains the engineering directly. No factor that was a principal reason for the adverse action may be excluded from disclosure (12 CFR Part 1002, eCFR).
Read that as a system requirement. If a feature drove the denial, you have to be able to name it. A model that ranks reasons but cannot guarantee it captured the principal ones has a defect, not a limitation.
Why post-hoc explainability is a trap
Many AI systems reach for explanation methods applied after the fact: feature attribution computed on a model that was trained with no explanation constraint. These methods approximate. They produce plausible rankings, not guaranteed ones.
An approximation is fine for a dashboard. It is not fine when the output is a legal statement that must not omit a principal reason.
The design response is to make the reasoning path a first-class output of the decision, not a reconstruction of it. The system should record, at decision time, the factors that determined the outcome, in a form you can defend. If your model architecture makes that hard, that is information about the architecture.
This shapes model selection. A simpler model whose contributions are exact may carry less regulatory risk than a complex one whose explanations are estimated. The accuracy gain has to be weighed against the obligation to produce specific reasons you can stand behind.
Build the audit trail before you need it
Adverse action is not a one-time notice. It is a record-keeping obligation that outlives the decision.
Under Regulation B § 1002.12, creditors must retain records tied to consumer credit applications and adverse action for 25 months from the date the applicant is notified, and 12 months for business credit (V-7 ECOA, FDIC). The retention window is long enough that your model will likely have been retrained or replaced before it closes.
That has a direct consequence. You cannot re-derive the reason for an old decision from your current model, because the current model is not the one that made the decision. The reasoning has to be captured and stored with the decision, versioned to the model that produced it.
What the record needs to hold
A defensible audit trail for an AI credit decision includes, at minimum:
- The input data as it existed at decision time.
- The model version and configuration that ran.
- The output and the specific reasons derived from it.
- The notice sent to the applicant and its date.
Store these together, immutably, keyed to the decision. When an examiner or an applicant asks, you reconstruct the moment, not an approximation of it.
Treat regulator-readiness as an interface
The teams that struggle treat compliance as a review gate at the end. The teams that ship cleanly treat it as an interface the system exposes from the start.
The interface has a few obligations. It produces specific reasons on request within the 60-day window. It never omits a principal reason. It retains records for the full statutory period. And it can replay any past decision with the exact inputs and model version that produced it.
Write those as acceptance tests. A denial decision that cannot produce a complete, specific reason set should fail your test suite the same way a crash does. This moves the compliance question out of a document and into the build.
The order of operations that avoids the debt
Shipping an AI decision system in a regulated product without the compliance debt comes down to sequence.
Decide what reasons you must produce before you choose the model. Let the reason requirement constrain the architecture, not the other way around. Capture reasoning at decision time rather than reconstructing it. Version every decision to its model. Retain the full record for the statutory window.
None of this slows the model down. It changes what the model is accountable for. A system designed this way answers the written request, survives the examination, and does not force a rebuild the first time a regulator looks closely.
The cost of skipping these steps is not a fine in the abstract. It is the moment an applicant exercises a right that has been on the books for decades, and the system that made the decision has no honest answer. Build so that it always does.