For two years banks have been putting AI agents into customer service, fraud operations, credit work and software delivery faster than supervisors could describe what "good control" looks like. On 4 November 2026 the US Office of the Comptroller of the Currency (OCC) published the first serious answer. OCC Bulletin 2026-54 introduces a supervisory framework that tells its examiners how to evaluate banks' use of generative and agentic AI, which the agency, following Executive Order 14434 of 2 October 2026, now calls "super intelligence" (SI). The framework is formally modest: it sets no new expectations for banks and creates no enforceable standards. In practice, as law firms advising banks quickly pointed out, it is the clearest statement yet of what examiners will ask for when they review an AI agent. For technology leaders anywhere, not only at US national banks, it is also one of the most practical AI governance checklists a regulator has published.
What the OCC AI supervisory framework actually is
The package has three parts: News Release 2026-97, Bulletin 2026-54 and a twenty-page examiner document, the OCC Supervisory Framework for Bank Use of Super Intelligence. The OCC uses "super intelligence" to mean the technologies previously covered by the statutory definition of artificial intelligence (15 USC 9401(3)), "as well as the promise, potential, and rapidly advancing capabilities of those technologies". In other words, this is about the AI banks already run, not about a hypothetical future system.
Four statements define the framework's status and scope:
- It is an examiner resource. The OCC says it does not establish supervisory expectations, enforceable standards or prescriptive requirements, and that banks are not expected to use it to assess their own AI risk management. Examiners are told to tailor their work to the materiality of each use case and to the bank's size, complexity and risk profile, including at community banks.
- AI is not a separate risk category. Examiners should not treat SI as distinct, and banks are not required to define a separate SI risk appetite. AI is seen as something that introduces, amplifies or modifies existing operational, compliance and credit risks.
- It is aimed at generative and agentic systems. A footnote explains that the revised model risk management guidance (OCC Bulletin 2026-13) applies to non-generative and non-agentic models, so this framework is "more applicable to generative and agentic SI".
- It is a living document. The OCC intends to update it regularly as technology, use cases and supervisory understanding change, and in response to stakeholder feedback.
The context matters. On 17 April 2026 the OCC, the Federal Reserve and the FDIC replaced the 2011 model risk management guidance (SR 11-7 / OCC 2011-12) with a shorter, risk-based version. That guidance narrowed the definition of a model, said it is most relevant to banks with more than $30 billion in assets, and explicitly placed generative and agentic AI out of scope as "novel and rapidly evolving". The agencies also promised a request for information on model risk management and AI. Bulletin 2026-54 fills the gap that the April guidance left open.
The core idea: consequence and autonomy, not model sophistication
The framework's overarching principle is one sentence that every AI programme should pin to the wall: a bank's control intensity could increase with the potential consequences of an AI agent's failure or misuse. Risk classification may be based on potential consequences, the transfer of agency and the degree of human oversight, "rather than the technical sophistication" of the system.
The OCC gives a simple example: a rules-based agent authorised to initiate transactions could present greater risk than a sophisticated model limited to internal drafting. That inverts the way many organisations still triage AI, where the biggest model gets the longest review and a "simple" automation with payment permissions slips through as an IT change.
Six pillars and sixteen components
The sixteen components are grouped into six pillars, each answering one supervisory question:
- Purpose — what is the system or agent permitted to do? (Defined purpose and permitted use)
- Risk — what happens if its output or action is not fit for purpose? (Risk classification and criticality assessment)
- Control — what prevents unauthorised, inappropriate or unsafe actions? (Human-in-the-loop and human-on-the-loop controls, model risk management extensions, data governance, privacy, compliance, cybersecurity)
- Oversight — who monitors it and who is accountable? (Governance and accountability, human oversight, performance monitoring, reporting and transparency)
- Resilience — can the bank detect, contain, recover from and remediate failures while critical processes continue? (Operational resilience, cybersecurity)
- Assurance — is there evidence that controls keep working? (Testing, documentation and auditability, third-party and vendor risk, internal audit and independent challenge)
The four-tier AI risk tiering
Section 3 of the framework offers an illustrative way to score every AI model and agentic use case against the same factors regardless of business line: decision consequence (inform, decide or act), reversibility, customer and financial impact, autonomy level, data sensitivity, explainability and provenance (built in-house, fine-tuned from a third-party base model, or consumed as an external service). The factors combine into a composite tier:
| Tier | Illustrative profile | Illustrative use cases |
|---|---|---|
| Tier 1: Critical | Direct action, low or no reversibility, high financial or customer impact, autonomous or partially autonomous | Autonomous payment agent; real-time credit decisioning; fraud-hold release; market access |
| Tier 2: High | Direct action or high-weight decision support, human-on-the-loop, moderate-to-high impact | AI-assisted underwriting; agent-initiated customer communications; AML alert disposition; code assistance for internal code or data access changes |
| Tier 3: Moderate | Decision support with mandatory human-in-the-loop, limited data sensitivity, reversible | Internal document summarisation for credit memos; agent-assisted research |
| Tier 4: Low | No customer or financial data exposure, no direct action, fully human-controlled | Internal productivity tools; code assistance; general employee Q&A |
The most quotable line sits under the table: a fully autonomous, customer-facing payment agent sits at Tier 1 "regardless of how well it performs in testing". Good test results do not buy a lower tier; only less consequence, more reversibility or more oversight do.
Agentic AI governance for banks: five details that will change how AI agents are built
Beyond the headline structure, several specific points are worth reading closely, because they turn general principles into things an examiner can check.
Scope drift is a control failure. The bank should document, before deployment and after material change, what a system is designed to do and not do, who may invoke it, which data and systems it may reach, the actions it may take and when it must be reviewed or suspended. Activity outside the approved purpose "may be treated as a control failure even when the resulting output or action appears reasonable". A tool approved for internal research may need fresh review before it becomes customer-facing.
A human in the loop has to be real. The framework distinguishes human-in-the-loop (approval before an output is used or an action executes) from human-on-the-loop (active monitoring with authority and practical ability to intervene). The reviewer needs the expertise, information and authority to reject, modify, pause or halt the system. Approval should be "more than a nominal click", and high volumes or bulk approval can reduce review quality and cause alert fatigue. Banks are asked how many agents, accounts or alerts one person can credibly monitor.
An AI system can be up and still be failing. Operational resilience covers "both loss of service and incorrect operation": an agent can remain available while taking harmful actions. The suggested brakes are familiar to anyone who has run payment systems: monitoring and observability, control agents, deterministic rules, circuit breakers, rate limits, least-privilege permissions and kill switches, plus tested fallback to trained staff or a narrower agent, and a separate customer-remediation workstream when a misfire affects customers. External agents that the bank does not control, from customers, fintechs or agentic-commerce platforms, are treated as channel risk.
Agents are privileged users. In the cybersecurity component, prompt injection, data and model poisoning, model extraction and "excessive agency" are named explicitly. The breadth of agent permissions and tool access may be treated as part of the attack surface, and agent identities, credentials and logs may be governed in a manner comparable to privileged users.
One good test run proves little. For non-deterministic systems, repeated testing, defined samples, distributional measures and consistency thresholds give more useful evidence than a single successful run. The framework discusses adversarial testing, red teaming, expert review calibrated to the failure rate a bank is trying to detect, hallucination measurement, and LLM-as-a-judge with attention to the judge model's own validation, bias and correlated failures. Documentation should allow someone other than the developers to reconstruct a material decision from inputs, outputs, retrieved sources, tool calls, approvals and overrides.
Vendor contracts get their own attention. Banks may define what a provider's agents may do inside bank systems, agree a specific AI incident vocabulary (hallucination, misfire, drift, manipulation) with notification timelines, clarify liability for model-related errors and customer harm, and require notice when an existing vendor adds AI features or changes models in products already in use. Accountability, the framework says, generally remains with the bank even when development or hosting is distributed across vendors.
How to read "not a requirement"
It is tempting to file a document that says "banks are not expected to use this" under optional reading. I would not. King & Spalding's analysis puts it plainly: the framework is the clearest available statement of what OCC examination teams will look for, and institutions should expect it to shape examiner requests, scoping and conversations with management. Jones Day similarly notes that it may be referenced by examiners during upcoming examinations and previews how examiners will evaluate AI use under existing standards.
There is also a small tension worth resolving deliberately. Banks do not need a separate AI risk appetite, yet the governance component says the board and senior management "may establish an SI risk appetite" covering autonomy, permitted actions, customer impact and concentration. My reading is the practical one: put AI inside the existing enterprise risk appetite, but make autonomy and permitted actions explicit dimensions of it, so that a board can see how much agency it has delegated to software.
Finally, the framework does not stand alone. Law-firm commentary links it to Treasury's AI Lexicon and Financial Services AI Risk Management Framework released in February 2026, to proposed revisions of interagency third-party risk guidance, and to state guidance such as the Connecticut Department of Banking's in September 2026. A bank operating in several jurisdictions should map its controls once and reuse the evidence, rather than building one programme per regulator.
An AI governance playbook for bank technology leaders
The framework is written for examiners, but read from the other side it is a design specification. This is how I would turn it into work for the next two quarters.
Build an AI inventory that includes agents and embedded vendor features. For every use case, record owner, provider, model and version, permissions, data reached, deployment status, monitoring and fail-over. Many organisations can list their models; far fewer can list every SaaS product that has quietly added an AI assistant, which is exactly the vendor-change risk the framework describes.
Tier by consequence and transfer of agency. Score each use case on action versus advice, reversibility, impact, autonomy, data sensitivity, explainability and provenance. Expect surprises: a modest rules-based agent with payment or data-access permissions may land higher than your flagship chatbot.
Write purpose statements that can be tested. "Assists customer service" is not testable. "May read card transaction history for the authenticated customer, may draft but not send messages, may not change limits, escalates disputes above a set amount" is. Then monitor for drift against it.
Enforce permissions outside the model. Least-privilege credentials, separate agent identities, rate and value limits, circuit breakers and a kill switch that someone has actually tested. This is the same principle I argued for in agentic payments: controls that do not depend on the agent behaving well.
Design human oversight with capacity in mind. Define who reviews what, with which evidence and how much time. Measure override and approval rates; a reviewer approving hundreds of agent actions per hour is a rubber stamp, not a control.
Make evaluation statistical and continuous. Repeated sampling, adversarial and red-team testing, hallucination rates on representative prompts, and re-validation triggers when prompts, models, tools or permissions change. In AI agent benchmarks in 2026 I explained why a leaderboard score is only a hypothesis until it is confirmed on your own tasks; this framework makes the same point in supervisory language.
Log enough to reconstruct a decision. Inputs, retrieved sources, tool calls, approvals, overrides and resulting actions, with version and permission changes linked to test evidence. If an agent touches a legacy core, this belongs in the integration layer; I discussed that architecture in Core banking modernization in 2026.
Rehearse misfires, not just outages. Run exercises in which an agent stays online while doing the wrong thing: how quickly is it detected, contained and rolled back, who identifies affected customers, and how does the business process continue without it?
Renegotiate AI terms with vendors. Change notice for new AI features and model swaps, limits on use of bank data to train models for other customers, AI incident definitions and timelines, audit access and liability for customer harm.
Give the board a view of delegated agency. Report material use cases by tier, changes in permissions, incidents, customer remediation and assurance results, reconciled to the inventory. Boards approve risk appetite; they should also see how much autonomy the bank has handed to machines.
Closing thought
The most important idea in Bulletin 2026-54 is not the new vocabulary but the shift of attention from what an AI model is to what it is allowed to do. That is good engineering as much as good supervision. Banks that design agents around explicit purpose, consequence-based tiers, real human oversight and tested brakes will find examinations easier, but more importantly they will be able to give agents more responsibility safely, and sooner, than those still debating which model is most impressive.
References
- OCC Issues Supervisory Framework on Bank Use of Super Intelligence, Office of the Comptroller of the Currency, News Release 2026-97, 4 November 2026
- Super Intelligence: Supervisory Framework, Office of the Comptroller of the Currency, OCC Bulletin 2026-54, 4 November 2026
- OCC Supervisory Framework for Bank Use of Super Intelligence (PDF), Office of the Comptroller of the Currency, November 2026
- Model Risk Management: Revised Guidance, Office of the Comptroller of the Currency, OCC Bulletin 2026-13, 17 April 2026
- The OCC Issues Examiner Framework for Bank Use of AI: What OCC Bulletin 2026-54 Means, Matthew L. Biben, Kimberly A. Prior, Michael Regan, Russell David Sacks and Kent Jordan, King & Spalding, 9 November 2026
- OCC Issues Super Intelligence Supervisory Framework, Keegan King, Jones Day, November 2026
- OCC releases framework for supervising artificial intelligence, ABA Banking Journal, 4 November 2026