The AI-in-Finance Governance Checklist Examiners and Auditors Will Use in 2026

A bank examiner sits across from your model risk lead and asks a single question: “Show me how this AI arrived at the figure you put in the credit memo.” If the honest answer is “the model wrote it,” you have a problem that no amount of policy documentation will paper over. That moment, repeated in audit rooms and supervisory exams through 2026, is what this checklist is built to survive.

Model-risk supervision was built for a different kind of model. SR 11-7, the Federal Reserve’s 2011 model risk guidance, has defined the discipline for more than a decade: governance, independent validation, and controls across the whole model lifecycle. It assumes a model whose logic you can inspect and whose outputs you can reproduce. Generative and agentic AI fit that frame badly, and no tailored successor rulebook has replaced it. That is not a reprieve. Supervisors and internal audit are already applying model-risk expectations to LLM-based tools by analogy, which means you carry the obligations without the comfort of guidance written for the technology you’re actually deploying.

So this is the awkward middle. The old standard is gone, the new one explicitly declines to cover the thing you actually deployed, and your auditor still expects you to answer for it. A checklist is how you close that gap before someone else opens it for you.

Why a checklist beats a policy

Policies describe intentions. Checklists force decisions. The difference matters because most AI-in-finance failures are not failures of intent; they are gaps nobody was assigned to close. A governance committee that signs a two-page AI policy feels protected. A governance committee that has to answer thirty concrete questions, in writing, before deployment finds the holes while they are still cheap to fix.

The questions below borrow structure from ISO/IEC 42001, the AI management system standard that has become the de facto reference for AI governance in regulated industries. It is voluntary and certifiable rather than mandated, but its spine, AI risk assessment, system impact analysis, lifecycle management, and third-party oversight, maps cleanly onto what examiners now probe. Use it as scaffolding, not scripture.

The pre-deployment questions your committee must answer

Inventory and ownership

Start with the boring part, because the boring part is where exams begin. Can you produce a complete inventory of every AI system that touches financial data, including the shadow tools a controller pasted quarterly figures into last month? Who is the named accountable owner for each one, a person, not a department? What decision does each system inform, and what is the worst plausible outcome if its output is wrong? If you cannot name the owner, you do not have governance; you have a vendor relationship.

Data lineage and the reconciliation question

Here is the question that separates real readiness from theater: can every figure the AI produces be traced back to a reconciled source that ties out to the ledger? Not “does the model cite a document,” but “does the number reconcile to the books.” Most LLM finance tools retrieve text and let the model do arithmetic on it. That is exactly where the silent errors live, an inverted ratio, a quarterly figure read as annual, a sign flip on a cash outflow.

This is the architectural fork. If your AI computes figures itself, you are validating a probabilistic system that gives different answers to the same question. If your AI retrieves from one reconciled model and runs the math through a deterministic engine, you are validating a calculation, which is something a controller already knows how to sign off on. We argue this more fully in Single Source of Truth vs. Sufficient Versions of Truth, but for the checklist the test is blunt: pick any AI-produced number and ask the team to walk it back to source. If they cannot do it in front of you, an examiner will not be able to either.

Validation when you cannot see inside the model

SR 11-7 assumed you could inspect a model’s logic. With a vendor LLM you cannot; the weights are a black box and they change under you on the vendor’s schedule. The checklist question becomes: how do you validate a system you cannot open? The answer is output-based validation, testing the system against a known-correct set of finance answers and measuring field-level accuracy, consistency on repeated queries, and traceability of each result. We cover the mechanics in You Cannot Validate the Weights. Your committee should be able to state the accuracy threshold it requires, how often the system is re-tested for drift, and who reviews the results. “The vendor says it’s accurate” is not a validation finding.

LLM-specific risks the old framework never named

SR 11-7 was written for statistical models, so it is silent on the failure modes that actually bite LLMs. Prompt injection, where hostile text in a document steers the model’s behavior. Retrieval bias, where the system pulls the wrong supporting figures and reasons confidently from them. Non-determinism, where the same prompt yields a different number on Tuesday than it did on Monday. Your checklist needs an explicit line for each: what is the attack surface, what control mitigates it, and how would you detect it in production? Prompt Injection and Retrieval Bias breaks these down. If your governance pack does not mention them, it was written for a previous era.

Human oversight that is real, not nominal

Examiners have learned to spot oversight that exists only on paper, the “reviewed and approved” rubber stamp on output nobody could actually check. Effective oversight requires that a human can interpret the output, see where each figure came from, and override it. That is only possible when the numbers are traceable to source. A reviewer staring at a confident paragraph of AI-generated commentary with no link back to the ledger is not supervising anything; they are co-signing. Build the checklist so oversight is testable: can the reviewer click any figure and see its lineage?

Logging, retention, and the replay test

The final question is the one auditors ask last and care about most: if we come back in nine months, can you reconstruct what this system did and why? That means automatic logging of inputs, outputs, the figures retrieved, and the calculations run, retained long enough to cover your audit and supervisory cycle. The gold-standard version is replayability, feeding the same inputs back through the system and getting the identical figure with the identical traceable path. Deterministic systems pass this test. Pure LLM systems generally cannot, which is the quiet reason so many AI finance pilots never make it past the model risk committee.

The honest limits

A checklist does not make a system safe; it makes a system’s risks visible and assigned. It will not catch a novel attack nobody has thought of, and it cannot validate a model whose vendor refuses to support output testing. It also costs something real, every question you add is work someone has to do before launch rather than after an incident. That tradeoff is the point. The institutions that struggle in 2026 are not the ones with too many controls at the front of the lifecycle; they are the ones discovering, during an exam, that the controls were never there.

The thread running through every question above is the same: traceability to a reconciled source. Governance, validation, oversight, logging, all of it collapses if the underlying numbers cannot be tied back to the books. That is not a policy problem you can write your way out of. It is an architecture choice you make before the first model goes live.

If your AI cannot walk a figure back to a reconciled ledger today, the fastest way to see the difference is to watch one do it. Book a demo and bring the number you would least want an examiner to question.