The OCC super intelligence framework, issued on November 4, 2026 as OCC Bulletin 2026-54, gives national bank examiners a structured way to evaluate how banks use generative and agentic systems. “Super intelligence” is not a new technology category. It is the term the OCC now uses for what the industry has called artificial intelligence, following Executive Order 14434. The framework does not create new requirements for banks, but it shows exactly what examiners will look at, and that makes it the most practical reference a bank has for reviewing its AI governance program today.
This article explains what the bulletin is and is not, the principle that drives it, how it changes the way banks should tier AI use cases and agents, and the steps worth taking before the next examination cycle.
What the OCC Super Intelligence Framework Is, and What It Is Not
The bulletin is addressed to examiners. The OCC states that it does not establish supervisory expectations for banks, that banks are not expected to use it to assess their own SI risk management, and that nothing in it sets enforceable standards or prescriptive requirements. Examiners are told to tailor their work to the materiality of each use case, and for community banks, to the bank’s size, complexity, and risk profile. The OCC also calls the framework a living document that it intends to update as the technology and supervisory understanding mature.
That legal status matters, but it should not be read as “nothing applies.” A bank’s examination will be scoped using these concepts, so a program that cannot answer the framework’s questions will produce findings in existing risk areas such as operational, compliance, and third-party risk.
The Gap It Fills
The framework arrives seven months after the agencies replaced SR 11-7. OCC Bulletin 2026-13, the revised model risk management guidance issued in April 2026, excluded generative and agentic AI from its scope. The new framework says so directly: the model risk principles in Bulletin 2026-13 apply to non-generative and non-agentic models, and the supervisory framework is more applicable to generative and agentic systems. Elevate’s analysis of why SR 11-7 was rescinded and what the replacement leaves out covers that first change.
| OCC Bulletin 2026-13 | OCC Bulletin 2026-54 | |
|---|---|---|
| Issued | April 17, 2026 | November 4, 2026 |
| Audience | Banks and examiners | Examiners |
| Scope | Traditional and non-generative models | Generative and agentic systems, called super intelligence |
| Legal status | Guidance, not enforceable standards | Examiner resource, no new expectations for banks |
| Organizing idea | Risk-based model risk management tied to materiality | Control intensity tied to the consequences of failure or misuse |
Read together, the two bulletins cover the full range of models and AI systems a bank operates. A credit scoring model falls under the first. A customer service agent, a code assistant, or an agent that can initiate payments falls under the second.
The Core Idea: Consequence, Not Sophistication
The framework’s overarching principle is that control intensity could increase with the potential consequences of an agent’s failure or misuse. Higher-consequence use cases may warrant tighter limits on autonomy, stronger controls, more direct human oversight, more independent validation, and more robust resilience measures. Risk classification may rest on three things: potential consequences, transfer of agency, and the degree of human oversight. The technical sophistication of the system is not on that list.
The OCC’s own example makes the point. A simple rules-based agent authorized to initiate transactions could present more risk than a sophisticated model that only drafts internal documents. A program that reserves its heaviest review for the largest or most novel models has the order reversed. Under this framework, a basic agent with access to payment rails deserves more scrutiny than an advanced model that cannot act.
No Separate Risk Category
Examiners are told not to treat super intelligence as a separate and distinct risk category, and banks are not required to define a separate SI risk appetite. AI is treated as something that introduces, amplifies, or modifies risk in categories the bank already manages, such as operational, compliance, and credit risk. Those risks, including the AI contribution to them, should be handled inside the bank’s existing risk management framework.
This has a practical consequence. A standalone AI policy that sits beside the enterprise risk framework, with its own taxonomy and its own reporting line, is harder to defend under this approach than AI considerations built into the existing risk register, risk appetite statements, and committee reporting.
Six Pillars and Sixteen Components
The framework groups sixteen components into six pillars. Each pillar answers one supervisory question.
| Pillar | The question it answers | Main components |
|---|---|---|
| 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 unauthorized, inappropriate, or unsafe actions? | Human oversight, model risk, data governance, privacy, compliance, cybersecurity |
| Oversight | Who monitors it and who is accountable? | Governance, human oversight, performance monitoring, reporting |
| Resilience | Can the bank detect, contain, recover from, and remediate failures? | Operational resilience, cybersecurity |
| Assurance | Is there evidence the controls keep working? | Testing, documentation, third-party risk, internal audit |
The table shows where the framework’s weight falls. Purpose and Risk come first because every other control is calibrated against them: a bank that has not documented what an agent may do, and how bad a failure would be, has no basis for deciding how much oversight, testing, or audit coverage the agent needs.
What It Means for AI Agent Intake and Risk Tiering
For most banks, the framework’s most actionable content is its illustrative risk-tiering method. It is offered as an example for examiners, not a mandated model, but it shows which attributes an intake process should capture and how they combine into a tier.
Seven Factors Scored for Every Use Case
The framework scores every use case against a common set of factors, regardless of business line, so that comparable risk receives comparable control. Decision consequence asks whether the system informs a human decision, makes a decision, or takes an action directly. Reversibility asks whether an error can be caught and undone before harm occurs. Customer and financial impact measures the size of the potential harm. Autonomy level distinguishes human-in-the-loop, human-on-the-loop, and fully autonomous operation. Data sensitivity, explainability, and provenance (built in-house, fine-tuned, or consumed from a vendor) complete the set.
An intake form that captures model type, vendor, and business owner but not reversibility, permission scope, or the oversight model will not support this kind of tiering. Those three attributes are where the framework puts the most weight.
Four Illustrative Tiers
| Tier | Profile | Example use cases from the framework |
|---|---|---|
| Tier 1: Critical | Direct action, low or no reversibility, high customer or financial 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 |
| Tier 3: Moderate | Decision support with mandatory human-in-the-loop, limited data sensitivity, reversible | Internal summarization 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 questions |
The framework is explicit that a fully autonomous, customer-facing payment agent sits at Tier 1 regardless of how well it performs in testing. Strong test results lower the likelihood of failure. They do not lower the tier, because the tier reflects what happens when failure occurs.
Human Oversight Has to Be Demonstrable
The framework separates human-in-the-loop, where a person approves each output or action before it takes effect, from human-on-the-loop, where a person monitors and has the authority and practical ability to intervene. Naming a reviewer is not enough. The reviewer needs the expertise, information, and authority to reject, modify, pause, or halt the system, and approval has to be more than a nominal click.
Two details are worth preparing for. The first is span of control: how many agents, accounts, or alerts one person can credibly monitor, and how much time they have to intervene. High volumes and bulk approvals can turn oversight into a formality. The second is escalation after a failure: a misfire, hallucination, or control breach may justify temporarily increasing human involvement, which assumes the bank can change an agent’s oversight level quickly.
Purpose Statements and Scope Drift
The Purpose pillar asks banks to document, before deployment and after any material change, what a system is designed to do and not do, who may invoke it, which data and systems it can reach, which actions it can take, and when it must stop for review. The framework treats activity outside that approved purpose as a control failure even when the result looks reasonable. Its example is a use case approved for internal research that later becomes customer-facing or decision-relevant, which should trigger review before the change, not after it.
Elevate’s guide to agentic AI in banking covers how these agents are being deployed, and the AI Governance Banking Intake Questionnaire is a starting point for capturing these attributes at intake.
Where Examiners Will Look Beyond the Risk Tier
The tier sets how much control a use case needs. The other components describe which controls examiners will look for. Four of them are worth checking line by line against a bank’s current program.
Third-Party and Vendor Risk
Banks often get AI capabilities through vendors, and the framework treats that reliance as a source of model, data, legal, concentration, and resilience risk that conventional service-level and security reviews do not fully cover. It points to defining the authority, identity, tool use, and escalation limits of provider agents that touch bank systems, and to a specific incident vocabulary with notification timelines for events such as hallucination, misfire, drift, or manipulation. It also flags a quieter risk: existing vendors adding AI features or changing underlying models in products the bank already uses. Contract terms that require notice of those changes, and a retest before or when they happen, are the control the framework describes.
Operational Resilience
The framework makes a distinction that availability-focused continuity plans miss. An agentic system can stay available while taking inappropriate or harmful actions. Resilience therefore covers detecting and containing a system that is working incorrectly, not only one that is down. The framework lists monitoring, deterministic rules, circuit breakers, rate limits, least-privilege permissions, and kill switches as containment tools, and it calls for a separate customer remediation workstream when a misfire affects customers. It also covers external agents acting on behalf of customers or counterparties through bank channels, which the bank does not control.
Cybersecurity and Non-Human Identities
Prompts, training pipelines, connected tools, and agent identities are attack surfaces that perimeter controls were not designed for. The framework names prompt injection, data and model poisoning, model extraction, and excessive agency, where broad credentials allow a manipulated agent to cause fraud or data exposure at machine speed. Its recommendation is to govern agent identities, credentials, and logs in a manner comparable to privileged users.
Testing, Documentation, and Audit
Because generative systems are non-deterministic, a single successful test run proves little. The framework points to repeated testing with defined samples and consistency thresholds, adversarial testing, and red teaming, noting that independent or external expertise may be useful when internal capability is limited. When one model is used to judge another, the judge model needs its own validation. Documentation should allow a material decision to be reconstructed from its inputs, outputs, retrieved sources, tool calls, approvals, and overrides. Internal audit should be independent of both the team that owns the system and the team that validates it. Elevate’s articles on AI red teaming for AI agents and AI assurance for AI agents go deeper on both practices.
The Same Signal Outside Banking: Evidence Over Assertion
The Assurance pillar asks banks for evidence that agent controls continue to work. The same expectation is moving through Congress for the companies that build the models. The FRONTIER Act (H.R. 9925), introduced in the House in July 2026, would require the largest frontier AI developers to publish risk-management frameworks, undergo independent audits, and report critical safety incidents. The VET AI Act (S. 2615), reintroduced in the Senate in July 2025, would direct NIST to develop voluntary guidelines for developers and deployers on internal assurance and on working with third parties for external verification and red teaming. Neither bill is law.
The bills and the OCC framework address different parties, but they point in the same direction: claims that an AI system is safe and controlled are expected to be backed by evidence someone else can check. For a bank, that evidence starts with its own inventory, tiering, testing, and audit records, and it extends to what the bank can obtain from its AI vendors.
How to Review Your AI Governance Program Against the Framework
Because the framework tells examiners what to look at, it doubles as a review checklist. Six steps cover most of it, and the depth of each should follow the materiality of the bank’s use cases.
Step 1: Complete the Inventory, Including Vendor Features
The framework expects an inventory that records each use case, its owner, provider, permissions, deployment status, monitoring, and fail-over arrangements, updated when any of those change. An easy item to miss is AI that arrived inside software the bank already licenses. Include those features, because the framework treats them as the bank’s risk even when a vendor hosts the model.
Step 2: Add Consequence Attributes to Intake
Extend the intake form so every use case records decision consequence, reversibility, customer and financial impact, autonomy level, permission scope, data sensitivity, explainability, and provenance. These are the inputs to the tier. Without them, tiering falls back on model type or vendor reputation, which the framework expressly does not use.
Step 3: Re-Tier by Consequence
Apply the attributes and check where each use case lands. Any agent that can move funds, change customer records, release fraud holds, or communicate with customers without approval belongs in the upper tiers, whatever its technical simplicity. Low-risk internal tools can move to lighter controls, which frees review capacity for the uses that matter.
Step 4: Make Human Oversight Demonstrable
For each Tier 1 and Tier 2 use case, document whether oversight is in the loop or on the loop, who the reviewer is, what authority they hold, what triggers a review, how many items one person reviews, and how overrides are logged. Then confirm the bank can raise the oversight level of an agent quickly after an incident.
Step 5: Fold AI Risk Into the Existing Framework
Map each AI risk to the operational, compliance, credit, or third-party category it affects, and report it through the same committees. The framework does not require a separate AI risk appetite, and a parallel structure makes it harder to show how AI risk is identified, measured, monitored, and controlled.
Step 6: Close the Vendor, Resilience, and Assurance Gaps
Update contracts so vendors must give notice of new AI features and model changes, define an AI incident vocabulary with notification timelines, and confirm that kill switches and fallback processes for high-tier agents have been tested. Scale testing frequency, red teaming, and internal audit coverage to the tier.
Community banks can apply the same steps at a smaller scale. The OCC has told examiners to tailor their work to the bank’s size, complexity, and risk profile and to the nature, consequences, autonomy, and complexity of its use cases. A bank with a handful of Tier 4 productivity tools needs far less than one running autonomous payment agents.
Elevate supports financial institutions with this review through its CRI FS AI RMF readiness service for financial services. To discuss where your program stands against the framework, talk to an Elevate advisor.
Conclusion
OCC Bulletin 2026-54 does not tell banks what to do, but it tells them exactly how examiners will think. The framework ties control intensity to the consequences of failure, transfer of agency, and the degree of human oversight, not to how advanced a system is. It keeps AI inside the bank’s existing risk categories, and it expects evidence that oversight, testing, and resilience controls work in practice.
The practical response is a review, not a rebuild: complete the inventory, capture consequence attributes at intake, re-tier by consequence, make oversight demonstrable, fold AI risk into the existing framework, and close vendor and resilience gaps. Banks that run that review now will meet their next examination with answers instead of a remediation plan. To review your AI agent intake and risk tiering against the framework, book a call with an Elevate advisor.
Key Takeaways
The OCC super intelligence framework is an examiner resource that shows how banks’ use of generative and agentic AI will be assessed.
- It sets no new requirements for banks. The OCC states that it creates no supervisory expectations or enforceable standards, but examinations will be scoped with its concepts.
- Consequence drives the tier. Risk classification rests on potential consequences, transfer of agency, and human oversight, so a simple agent that moves money can outrank an advanced drafting model.
- AI is not a separate risk category. Banks are not required to set a separate AI risk appetite, and AI risk belongs in the operational, compliance, credit, and third-party categories they already manage.
- Oversight must be demonstrable. A named reviewer needs the expertise, authority, and capacity to act, and approval has to be more than a click.
- Resilience includes systems that work incorrectly. Containment, kill switches, and customer remediation matter for agents that stay online while acting wrongly.
- It fills the gap left by Bulletin 2026-13. The revised model risk guidance excluded generative and agentic AI; this framework is where those systems are addressed.
Frequently Asked Questions
What is the OCC super intelligence framework?
It is a supervisory framework the OCC issued on November 4, 2026 with Bulletin 2026-54 to help examiners evaluate banks’ use of super intelligence in normal business activities. It describes sixteen components grouped into six pillars: purpose, risk, control, oversight, resilience, and assurance. It also includes an illustrative risk-tiering method and a lexicon. The OCC calls it a living document that it plans to update as the technology and supervisory understanding mature.
Does the OCC framework create new requirements for banks?
No. The OCC states that the framework does not establish supervisory expectations for banks, that banks are not expected to use it to assess their own risk management, and that it sets no enforceable standards or prescriptive requirements. It is guidance for examiners. Because examinations will be tailored using its concepts, it is still a useful reference for reviewing a bank’s AI governance program.
What does “super intelligence” mean in OCC guidance?
In the OCC’s usage, super intelligence refers to the technologies and systems previously described as artificial intelligence under federal law, along with their rapidly advancing capabilities. The OCC adopted the term following Executive Order 14434. It is a change in terminology, not a new category of technology. Generative and agentic systems are the main focus of the framework.
How does the OCC framework tier AI agents?
The framework scores each use case on decision consequence, reversibility, customer and financial impact, autonomy level, data sensitivity, explainability, and provenance. Those factors combine into four illustrative tiers, from Tier 1 (critical) to Tier 4 (low). An autonomous, customer-facing payment agent sits at Tier 1 regardless of its test results, while an internal productivity tool with no data exposure sits at Tier 4. The method is an example for examiners, not a mandated model.
How does Bulletin 2026-54 relate to OCC Bulletin 2026-13?
OCC Bulletin 2026-13, issued in April 2026, is the revised model risk management guidance that replaced the guidance known as SR 11-7, and it excluded generative and agentic AI from its scope. Bulletin 2026-54 states that the model risk principles in 2026-13 apply to non-generative and non-agentic models, and that the new framework is more applicable to generative and agentic systems. Together, the two documents cover the full range of models and AI systems a bank operates.