Inside the OCC's "Super Intelligence" Examiner Framework: What Banks and Their Fintech Vendors Should Expect

On Nov. 4, 2026, the OCC issued Bulletin 2026-54 and, with it, a 22-page “Super Intelligence Supervisory Framework.” The framework is addressed to the OCC’s examination workforce rather than to banks. It exists so examiners can evaluate banks’ use of what the OCC calls super intelligence (SI) “in normal-course business activities,” from credit decisioning and payments to fraud detection and customer service. Reuters’ headline called it the regulator’s first-ever AI guidance for examiners (Nov. 4, 2026), and nothing in the document argues.

The revealing part is what the bulletin says the framework does not do. It “does not establish supervisory expectations for banks.” Banks are not expected to use the document to assess their own SI risk management, and nothing in it “is intended to establish new regulatory expectations or set forth enforceable standards or prescriptive requirements.” An examiner playbook, deliberately not a rulebook.

Why examiners got a playbook instead of banks getting rules

The OCC’s summary positions the framework as a resource: examiners may use it to identify SI-specific considerations that supplement existing model risk management, governance, technology, compliance and operational-risk practices, and to tailor supervisory work accordingly. One instruction preempts an overreaction: “Examiners should not treat SI as a separate and distinct risk category, and banks are not required to define a separate SI risk appetite.” (p. 1)

In the OCC’s telling, SI use can “introduce, amplify or modify risk in existing risk categories, such as operational, compliance and credit,” and those risks are handled under the risk management framework the bank already operates. A bank about to stand up a parallel AI risk silo beside its existing taxonomy can stand that plan down.

The framework is also openly provisional, “treated as a living document which is expected to change as technology, use cases, and supervisory understanding change and mature,” and the OCC’s news release commits to regular updates informed by stakeholder feedback, alongside its “technology-neutral approach” reminder. Community banks get an explicit proportionality note: examinations should be tailored to the bank’s size, complexity and risk profile. That is scaling, not exemption.

The gap this framework fills

The timing is not accidental. In April, the OCC, Federal Reserve Board and FDIC revised their interagency model risk management guidance with a conspicuous carve-out: “Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance.” The framework’s first footnote closes the examiner side of that April carve-out in model-risk guidance, holding that Bulletin 2026-13’s principles apply to “non-generative and non-agentic SI models” while this document is “more applicable to generative and agentic SI.”

About the name

“Super Intelligence” comes from Executive Order 14434, published Oct. 2, 2026 (91 Fed. Reg. 63129), which substituted the term for “artificial intelligence” in federal usage. The OCC’s footnote says the term covers the technologies previously defined as artificial intelligence under 15 USC 9401(3), “as well as the promise, potential, and rapidly advancing capabilities of those technologies.” The label changed and the substance did not, so the rest of this piece says AI. One aside amuses anyone who has run an AI program: the framework itself was “prepared with the assistance of SI,” with content “reviewed, edited, and approved by a human.”

Six pillars, sixteen components

Sixteen components sit under six pillars (p. 2):

• Purpose: what actions the system or agent is permitted to execute (defined purpose and permitted use).
• Risk: what happens if the output or action is not fit for purpose (risk classification and criticality assessment).
• Control: what stops unauthorized, inappropriate or unsafe actions, through human-in-the-loop and human-on-the-loop controls, model risk management extensions, data governance, privacy, compliance and cybersecurity.
• Oversight: who monitors the system and who answers for it (governance and accountability, performance monitoring, reporting and transparency).
• Resilience: how the bank detects, contains, recovers from and remediates failures while critical processes continue.
• Assurance: evidence that controls keep operating, through testing, documentation and auditability, third-party and vendor risk, and internal audit.

A summary table pairs every component with an illustrative SI-specific risk; the third-party row reads like a vendor manager’s worry list: “Opaque provider chains, weak contractual rights, switching constraints, or concentration in common models and infrastructure” (p. 13).

Risk classification follows consequences, not cleverness

The framework’s signature line sits on page 2: “Risk classification may be based on potential consequences, transfer of agency, and the degree of human oversight, rather than the technical sophistication of the SI used. For example, a simple rules-based agent authorized to initiate transactions could present greater risk than a sophisticated model limited to internal drafting assistance.”

That logic animates an illustrative four-tier composite scale (pp. 14-15), built on deliberately non-technical scoring factors: decision consequence, reversibility, customer and financial impact, autonomy level, data sensitivity, explainability and provenance. Tier 1 (Critical) covers direct action with low reversibility and high financial or customer impact: an autonomous payment agent, real-time credit decisioning, fraud-hold release. Tier 2 (High) includes SI-assisted underwriting and agent-initiated customer communications. Tier 3 (Moderate) covers reversible decision support with mandatory human review. Tier 4 (Low) covers internal productivity tools with no customer or financial data exposure. The framework’s own illustration: a simple internal productivity tool sits at Tier 4, whereas “a fully autonomous, customer-facing payment agent sits at Tier 1, regardless of how well it performs in testing.”

Control intensity follows the tier. Higher-consequence use cases may warrant greater restrictions on autonomy, stronger controls, more direct human oversight, more independent validation and more robust resilience measures (p. 2). A model that performs beautifully in testing buys nothing.

What it means for the vendors selling AI into banks

Fintech and SaaS executives serving OCC-supervised banks should read this part closely. Banks usually buy these capabilities rather than build them, and the framework says the quiet part: reliance on third parties “has the potential to introduce model, operational, data, legal, concentration, and resilience risks that are not fully addressed by conventional service-level and information-security reviews” (p. 7).

Component 2.9 reads like a list of the questions coming toward every AI vendor serving banks. Provider agent visibility: banks may define “the scope of authority, identity, permitted tool use, data use and escalation limits for provider agents that interact with bank systems and data,” and may “monitor and potentially limit what provider agents do without impacting the relationship with the provider” (pp. 7-8). Expect procurement and vendor-risk teams to ask what your agents may do inside their environment, under what identity, with which tools, and when a human gets involved.

Contracts get specific attention. On liability, the bank should consider “how contracts assign responsibility for model related errors or losses including customer harm,” with clarity sought through “indemnification, caps or loss responsibility” (p. 8). On change and exit, vendors “may add SI features, functionality or change models connected to products already in use by the bank,” and the bank may require “notice and transparency of new SI functionality” before or when changes land, or retest the model. Vendors who ship an AI feature inside a routine product update should expect a different conversation than they are used to.

Component 2.10 widens the lens past your own customer list: “Customer, counterparty, fintech, or agentic-commerce systems that the bank does not control could present channel risk” (p. 8), with identity, provenance, delegation, velocity limits and revocation calibrated to the action requested. If your platform’s agents transact with a bank’s customers, the bank is planning for the day those agents misbehave, whether or not you have signed a contract with it.

Accountability has an equally clear answer. “Although development or hosting could be distributed across vendors, accountability for managing the bank’s risk generally remains with the bank” (p. 5). Component 2.8 adds the corollary that AI “does not change the bank’s underlying legal obligations” (p. 7). Buying from you does not transfer the bank’s regulatory duties to you, and, in fairness, it does not transfer yours to the bank either. (The accountability gap around agentic AI we flagged earlier this fall gets a one-line answer: it stays with the bank.)

The bank side is already tightening in parallel. Examiners’ third-party expectations were overhauled earlier this year in the interagency TPRM guidance rebuild, and component 2.11’s instruction that agent identities, credentials and data use be “governed in a manner comparable to privileged users” (p. 9) is the same design conversation MCP security design considerations covers from the agent-protocol side.

Using the framework without overbuilding

For bank program owners, the components translate into work that should have been underway anyway:

• Purpose boundaries. Document what each use case may do, what it may not, who may invoke it and which data and systems it may touch. The framework treats activity outside the approved purpose as a control failure “even when the resulting output or action appears reasonable” (p. 3).
• Human oversight that survives scrutiny. Human-in-the-loop means review and approval before an output is used; human-on-the-loop means active monitoring with practical ability to intervene (p. 4). Procedures should make approval “more than a nominal click,” and the framework warns that “High volumes or bulk approval could reduce review quality and contribute to alert fatigue.”
• Monitoring that catches drift. Model updates, prompt changes and vendor version changes can alter behavior without anything resembling a traditional release, which is why component 2.12 puts upstream changes on the monitoring list.
• Documentation that reconstructs. Records should “support reconstruction of material outputs or actions even when the model cannot produce a rule-based rationale” (p. 11).
• Reporting tied to consequences. Incidents, customer harm, concentrations and remediation belong in front of the board in a form that supports timely challenge, not buried in a model inventory appendix.

For vendors, assume the questions arrive through procurement and vendor-risk channels, not from an examiner directly. A bank that has read this document will ask for agent purpose statements, permission scopes, escalation and kill-switch arrangements, testing beyond a happy path, and incident notification terms. It will also want clarity on data use: component 2.7 flags “whether bank data can be used to train or improve models made available to other customers” (p. 6) as a contract and configuration question. Negotiating a shared vocabulary for AI incidents that captures “hallucination, misfire, drift or manipulation” (p. 8) sounds trivial until a dispute starts and neither side can define what was reported. None of this is required of banks yet, which is what makes it a preview rather than a checklist.

Where this leaves banks and vendors

The OCC intends to update this framework regularly in response to stakeholder feedback, so treat the current text as version one. For bank executives and boards, nothing here changes a single requirement today, and the OCC is pointed about that. What the document provides is the clearest public statement yet of how examiners will think about AI risk: through consequences, agency and oversight, folded into existing risk categories rather than a new silo. For the vendors serving those banks, it functions as a specific preview of what procurement, vendor-risk and examination teams will ask next. The organizations that can already answer the provider-agent, liability and change-notification questions will make their bank clients’ next examination easier. The ones that cannot will hear about it earlier than they would like.