How to Document AI-Assisted Decisions for Examiner Review

The Documentation Goal

A documented AI-assisted decision should let any qualified reader answer five questions without follow-up:

1. What information was considered?
2. What did the AI analysis find?
3. What did the reviewer do with that analysis?
4. What was the decision and on what authority?
5. How can the decision be reconstructed against the configuration that was actually in effect?

‍

If any answer requires follow-up, the documentation is incomplete. These are also the questions embedded in supervisory guidance: SR 11-7 made documentation and reproducibility central to model risk management, and the agencies issued revised, principles-based interagency model risk management guidance in April 2026, SR 26-2, that carries the same documentation expectations forward to AI-era tools.

Step 1. Capture the Inputs

The inputs to the decision include the application or case file, the supporting documentation submitted by the customer, external data the workflow consumed, and the customer's prior history with the institution if relevant. The audit trail captures each input with timestamp and source.

Step 2. Capture the AI Analysis

The AI analysis section includes the agent personas that ran, the version of each, the configuration applied, the analyses performed, the outputs produced, and the citations to specific evidence.

The output is itself the artifact. The configuration version lets any subsequent reviewer reconstruct exactly how the analysis was performed. Without it, the answer to "how did the system reach this conclusion" is a guess, and examiners working through BSA/AML case files under the FFIEC BSA/AML Examination Manual do not accept guesses.

Step 3. Capture the Reviewer Actions

The reviewer actions include the reviewer identification, the exception clearances with documented reasoning, the threshold disposition with documented reasoning, any additional documentation requested, and the escalation actions taken. Each action is preserved with timestamp.

Step 4. Capture the Decision

The decision itself includes the decision (approve, decline, escalate, request additional documentation), the conditions imposed, the risk classification assigned, the reviewer's rationale tied to the evidence, and the signature or equivalent authentication.

Step 5. Capture the Downstream Actions

Where applicable, downstream actions include the customer communication, the monitoring posture established, the next-review cadence, and the escalation to other functions. For CDD decisions, the monitoring posture connects the decision record to the ongoing obligations of the FinCEN CDD Final Rule.

The Structure of the Case File

A well-structured case file is a single artifact organized:

1. Summary section. The decision, the rationale, the reviewer, the date.
2. Inputs section. The documents considered, with hyperlinks to each.
3. Analysis section. The structured AI outputs with citations.
4. Reviewer section. The exception clearances, threshold dispositions, and reasoning.
5. Decision section. The formal decision, conditions, and authorization.
6. Audit trail section. The configuration version, the timestamps, the system identifiers.

‍

A reader who opens the file should be able to navigate to any of these sections in seconds. This is the file an examiner will ask to walk through.

Documenting Adverse Decisions

For adverse decisions (declines, account closures, denied applications), the documentation discipline is heightened. CFPB Circular 2023-03 makes clear that AI complexity is not a defense for vague adverse-action reasons; the CFPB made the same point about complex algorithms in Circular 2022-03. The decision documentation should support specific, accurate principal reasons that meet the requirements of Regulation B (12 CFR Part 1002).

The reviewer should be able to articulate the specific factors that drove the decision, the supporting evidence for each, and the policy provisions invoked. The AI analysis supports this by producing evidence-grounded, citation-backed findings the reviewer can translate into specific adverse-action reasons.

Common Pitfalls

• Boilerplate rationale. Generic rationale tied to no specific evidence.
• Reviewer rationale buried in free text. Structured fields are reviewable; long narratives are not.
• Missing configuration version. Decisions cannot be reconstructed against the configuration in effect.
• No clear decision authority. The signature or equivalent must be present.
• Disconnected artifacts. Multiple systems hold pieces of the case. The case file should consolidate.

‍

How StandardC AI Approaches This

StandardC AI produces structured case-level documentation as the standard output of every analysis. StandardC AI Report assembles the inputs, the analyses, the citations, the reviewer actions, and the decision into a single artifact. Configurations are version controlled. The audit trail is preserved automatically. The documentation supports the specific, evidence-grounded rationale required for adverse decisions under Regulation B and Circular 2023-03.

Frequently Asked Questions

Where should the case file be stored?

In the institution's system of record (LOS, core, case management) with the structured StandardC AI Report attached or referenced.

How long is the documentation retained?

Aligned to the institution's retention policy, typically five years for most compliance records.

Can the case file be reproduced if a vendor model is updated?

Yes. Configurations are version controlled.

Authoritative Sources

• CFPB Circular 2023-03, Adverse Action Notification Requirements
• CFPB Circular 2022-03, Adverse Action Notices and Complex Algorithms
• Regulation B (12 CFR Part 1002, Equal Credit Opportunity Act)
• SR 11-7, Supervisory Guidance on Model Risk Management
• SR 26-2, Revised Interagency Guidance on Model Risk Management
• FFIEC BSA/AML Examination Manual
• FinCEN CDD Final Rule

‍