Executive Summary: CSBS AI Supervisory Framework
- Revised April 2026 interagency model risk management guidance excluded generative and agentic AI from its scope, deferring governance to individual banks.
- On September 16, 2026, the Conference of State Bank Supervisors (CSBS) issued a discretionary AI Supervisory Framework to give state examiners a structured approach to assess AI risks.
- Its optional Risk Tiering Worksheet uses four dimensions to classify AI use cases into Low, Moderate, and High Risk tiers: consumer impact, human oversight, harm potential, and data sensitivity.
- The framework can take supervisory attention beyond AI inventory and policies to how higher-risk AI use cases are governed and controlled, including the actions an AI system acting with limited human direction is permitted to take.
- For contact center AI agents, that means being able to show what each agent can execute and which controls apply before it does.
What State-Chartered Banks Should Expect When Examiners Ask What Their AI Agents Can Actually Do
Think of a state-chartered bank that has done the governance work. Its AI inventory is current. Its acceptable-use policy is approved. Its vendor file holds the contracts and documentation for the AI agent now handling calls in the contact center.
Then the examiner asks a different question: what can that agent actually do to a customer’s account, and what prevents it from doing the wrong thing?
That question now has a structure. On September 16, 2026, the Conference of State Bank Supervisors (CSBS) released an Artificial Intelligence Supervisory Framework, a discretionary tool for state examiners to identify AI use at financial institutions and assess the associated risks. It is not a new source of substantive legal requirements. Because CSBS released it publicly, institutions can see the general approach, the types of questions, and the information an examiner may request. That visibility is the reason to prepare now.
The April Guidance Excluded Agentic AI Without Exempting It
On April 17, 2026, the OCC, the Federal Reserve, and the FDIC issued revised interagency model risk management guidance as OCC Bulletin 2026-13, SR 26-2, and FDIC FIL-15-2026. The agencies rescinded the earlier model risk management guidance (FIL-22-2017 and FIL-27-2021).
A single footnote set the boundary for AI. Generative and agentic AI models are “novel and rapidly evolving,” and therefore outside the guidance’s scope.
The same footnote directs banks to let their broader risk management and governance practices determine the governance and controls for any tools, processes, or systems the guidance does not cover. The federal position on agentic AI is not silence. It is a pointer back to the bank’s own governance practices.
The agencies also said they plan to issue a request for information (RFI) on model risk management that considers banks’ use of AI, including generative and agentic AI. As of early October 2026, no such RFI appears in official agency materials.
CSBS Gave State Examiners a Structured Way to Ask
The CSBS framework turns that broad governance question into a structured examination approach.
Its Core Examiner Guide gives examiners initial scoping questions, a document request list, and procedures for governance and oversight, AI inventory and use cases, and generative AI and emerging use.
Unlike the April guidance, it directly addresses generative and agentic AI, and it draws on the NIST AI Risk Management Framework.
The reach is broad. In CSBS’s words, “State regulators supervise 79% of all U.S. banks”. That figure counts banks by number, not by share of assets.
But adoption is decided state by state: each state agency determines the extent to which it incorporates the framework into its supervisory program. No comment period or compliance deadline came with the release, so the depth of AI review can differ from one state to the next.
Risk Tiering Moves the Exam From Inventory to Execution
Source: Conference of State Bank Supervisors
The optional Worksheet sorts AI use cases into Low, Moderate, and High Risk tiers using four risk factor assessments: consumer impact, human oversight, harm potential from errors or outages, and data sensitivity.
The Worksheet also suggests controls that scale by tier. Baseline suggested controls for every tier include a documented inventory entry with a business owner and purpose, a written acceptable-use policy, trained users, periodic management reporting, and, where a third party is involved, vendor contracts that address AI risk.
Higher tiers add more stringent controls, and the controls are cumulative: a High Risk use case is expected to have the Low and Moderate Risk controls in place as well.
Consider two AI uses in the same contact center. The first summarizes calls for human agents. A person reads the summary, and the output does not touch an account. The second is an AI agent that can initiate account changes during the call. Its actions can directly affect a consumer outcome, and a human may review them only by exception or not at all.
Run both through the four dimensions, and they score differently on nearly every one.
The summary tool might sit toward the low end. The agent that changes accounts carries the direct consumer outcomes and limited human review that the Worksheet associates with High Risk.
The bank can use the Worksheet’s factors to assess its own use cases, and examiners can use the same factors to identify where additional review may be appropriate.
Once an AI system stops assisting employees and starts taking actions that affect consumers, the question is no longer what the AI is. It is what it is allowed to execute.
Five Execution Questions Documentation Alone May Not Answer
Return to the bank from the opening. Its documentation describes the agent well. The five questions below are NovelVox’s practical synthesis of the execution-related issues reflected in the CSBS framework.
CSBS does not present them as a checklist. Several of them track one Core Examiner Guide procedure closely. Where AI systems can take actions with limited human direction, procedure GE-8 directs examiners to “review how the institution defines the actions the system is permitted to take, human checkpoints, logging, reversibility, and the ability to restrict or halt the system.”
What actions can the agent invoke?
The inventory may say “customer-facing contact center AI agent.” It rarely lists the callable actions: balance inquiry, address change, card block, funds transfer. Assessing consumer impact requires knowing what actions the agent can actually invoke, not just how the product is described.
Which actions require approval?
A policy can state that higher-risk actions need human review. The test is whether the system enforces that review before execution or relies on the agent to ask for it.
What sequence must occur before execution?
Identity verification should precede an address change. If the required order exists only in a prompt, it is an instruction to the model, not an enforcement control. Model behavior can vary, so a sequence that lives in a prompt can be skipped.
What systems of record can the action affect?
Harm potential and data sensitivity depend on where the action lands. It comes down to what the action changes, what data it uses, who it affects, and what happens if it fails. An account-changing action in a core platform such as Jack Henry, Fiserv, or FIS can therefore carry very different risk from a read-only knowledge-base query.
What was actually executed?
Transcripts show what was said. Model logs show what the agent decided. Neither alone shows which call reached the core, under what approval, and with what result. These gaps match the patterns in 4 Signals Your Bank’s AI Agents Are Operating Ungoverned.
An Execution Layer Makes the Answers Demonstrable
The point isn’t that an examiner expects a particular technology. It is that the bank should be able to demonstrate the control. CSBS does not prescribe any architecture. One way to make those controls enforceable and their results traceable is through an execution layer.
CCIP addresses that execution gap: governing which AI-initiated actions can execute, enforcing required steps and approvals before higher-risk actions, and maintaining an execution record built to the bank’s requirements.
CCIP sits between the AI the bank brings, its CCaaS platform, and its systems of record. It complements each one. The bank keeps its AI, its CCaaS platform, and its core. CCIP’s prebuilt execution patterns are proven across 1.2B+ governed enterprise executions annually.
CCIP is one product that supports two protocols, MCP for AI-native orchestration and REST for direct system calls, with both executing under the same governed layer.
Each of the five questions maps to a control the bank can show an examiner.
What Actions Can the Agent Invoke?
In CCIP, every tool an agent can call is tagged Low, Medium, or High risk, with behavior hints such as “Needs human approval.”
Which Actions Require Approval?
CCIP enforces approval: it can mandate sign-off before actions like account closure and execute only after approval.
What Sequence Must Occur Before Execution?
CCIP can require “Verify OTP” to run before “Send Text Message” and reject the call if Verify OTP was not invoked within 60 seconds. The order lives in the execution layer, not in the prompt.
What Systems of Record Can the Action Affect?
The bank enables only the actions it needs, such as debit card locks, loan payments, or profile updates, inside core banking systems like Jack Henry, Fiserv, and FIS. CCIP applies policies, approvals, and sequencing before any action reaches a system of record.
What Was Actually Executed?
CCIP keeps an execution record: every tool call is logged with a timestamp, actor, status, and response time, filterable by session or correlation ID. That is the record that transcripts and model logs cannot provide on their own.
For multi-agent environments, see Multi-Agent Banking Won’t Survive 2026 Without an Execution Layer.
Preparation Starts With What Each Agent Can Execute
- Map AI use cases against the four dimensions. Score each use case the way an examiner would, starting with the agents that can change an account.
- Document what each agent can execute. List callable actions by agent, not just the agent itself.
- Confirm approval and sequencing controls. Verify that required approvals and step order are enforced at execution.
- Be ready to show execution records. Produce, by session, what executed, under whose approval, and with what result.
- Track state adoption and the federal RFI. State AI rules are moving on other fronts too, as Colorado ADMTA Closes the AI Compliance Loophole Banks Used to Rely On shows.
The Examiner’s Question Has an Answer
The examiner in the opening asked what the agent can do to a customer’s account and what prevents it from doing the wrong thing.
Policies, inventories, and vendor files explain intent. They do not, by themselves, show the boundary of execution.
CSBS did not require a new answer. It made the question easier to ask. Banks that can show what each agent is allowed to execute, which controls apply, and what it actually executes will be better prepared for that conversation.
