Consumer finance · Adverse action

Adverse action documentation when the decision came from a model

Regulation B requires specific principal reasons for a denial. When the denial came from a model, the notice makes a factual claim about that model's behaviour at a moment in time, and that claim may be tested later.

The Equal Credit Opportunity Act and Regulation B require a creditor to give applicants the specific principal reasons for an adverse action. Supervisory commentary in recent years has been direct about the implication for complex models: the obligation does not relax because the decision logic is difficult to summarise.

That creates a documentation problem that is easy to miss. The notice is a factual claim about what a particular model, in a particular configuration, did with a particular application. If the claim is challenged a year later, the institution has to be able to substantiate it.

What substantiation requires

  • The model version and configuration in force when the application was scored.
  • The inputs relied on, or a commitment to them that can be checked without disclosing them broadly.
  • The output, the reason codes derived from it, and how that derivation was performed.
  • Whether a human reviewed, overrode, or was absent from the decision.
  • A record of all of the above whose timestamp is credible to someone outside the institution.

The reconstruction trap

Models are retrained. Feature pipelines change. Reason-code mappings get updated. A year after the fact, rerunning today's system against last year's application does not reproduce last year's decision, and an institution that relies on reconstruction is producing an estimate, not a record.

The fix is contemporaneous: capture the decision record when the decision happens, and make it independently checkable afterwards, so the reason codes on the notice are backed by something that existed at the time.

Check it yourself

Every Rubric attestation resolves publicly, with no account and no API key, and every anchor resolves to a public ledger message you can read without our cooperation.

HCS topic 0.0.10416909 · ML-DSA-65 signatures

Verify an attestation · Read the ledger ↗

Privacy is not an obstacle

Attesting an adverse action does not require publishing the applicant's data. A hash commitment to the input lets the institution demonstrate later that a specific application produced a specific outcome, disclosing the underlying data only to those entitled to see it.

Where this sits in a programme

Adverse actions are usually the first attestation scope institutions pick, for a straightforward reason: they are the decisions most likely to be disputed by the person affected, examined by a supervisor, and litigated afterwards. Evidence quality matters most exactly where challenge is most likely.

Related: AI audit trail requirements in banking · How to prove an AI decision happened · Financial services