OCC Bulletin 2026-54 explained: the Super Intelligence (AI) supervisory framework for banks

What is OCC Bulletin 2026-54, the Super Intelligence supervisory framework?

On November 4, 2026 the Office of the Comptroller of the Currency published a document for its own examiners called Super Intelligence: Supervisory Framework, transmitted to banks as OCC Bulletin 2026-54 and announced in News Release 2026-97. It is the first OCC issuance devoted to how its examiners should look at a bank's use of generative and agentic AI, and the news release calls it “an important milestone for the financial industry as it continues to embrace innovation responsibly”. The OCC does not use the words “artificial intelligence”: following Executive Order 14434 it calls the technology “Super Intelligence” (SI), and defines the term in a footnote as “the technologies and systems previously encompassed by the term ‘Artificial Intelligence’ as defined in 15 USC 9401(3) as well as the promise, potential, and rapidly advancing capabilities of those technologies”. For a bank, SI means what AI meant on November 3.

The framework is twenty pages long. An executive summary states the overarching principle and groups the content into six pillars; a second part walks through sixteen “framework components”, each describing how SI could affect an established control area, the key concepts and illustrative considerations an examiner may weigh; a summary table pairs each component with its SI-specific risk; a third part sets out an illustrative risk-tiering methodology with four composite tiers; and Appendix A is a lexicon of some fifty terms, most borrowed from the AI Lexicon workstream of the Artificial Intelligence Executive Oversight Group (AIEOG) with “AI” changed to “SI”. The scope is banks' use of SI “in normal-course business activities, including, but not limited to, credit decisioning, payments, fraud detection, customer service, operations, risk management and market activities”.

Two framing statements run through the whole document. First, the framework is an examiner resource, not a rulebook: the bulletin says it “does not establish supervisory expectations for banks”, that banks “are not expected to use this document to assess their use of SI or their SI risk management”, and that nothing in it sets “enforceable standards or prescriptive requirements”. Second, SI is not a new risk: examiners “should not treat SI as a separate and distinct risk category”, banks “are not required to define a separate SI risk appetite”, and SI risk is to be identified, measured, monitored and controlled inside the bank's existing risk categories, such as operational, compliance and credit risk. The OCC also discloses, in a footnote, that the framework “was prepared with the assistance of SI” and that its content “has been reviewed, edited, and approved by a human”. The document's status, links and change log live on our OCC Bulletin 2026-54 document page; this guide explains what it says.

Who does the OCC AI framework apply to, and is Bulletin 2026-54 mandatory?

The bulletin is addressed, as every OCC bulletin is, to the chief executive officers of all national banks, federal savings associations and federal branches and agencies of foreign banking organizations, together with OCC department heads and “all examining personnel”. Those three charter types are what the document means by “banks”. State-chartered banks supervised by the Federal Reserve or the FDIC, and credit unions, are outside it, and the framework says nothing about whether those agencies will follow.

It is not mandatory, and the OCC goes out of its way to say so. The operative audience is the examiner: the OCC “has instructed examiners that they should tailor their examination of banks' use of SI based on the materiality of the SI use case”, and the framework exists to help them do that. The text uses “may” and “could” throughout — a bank “may document” a purpose statement, controls “could help” contain a misfiring agent — and the tiering is labelled “illustrative” in every heading. There is no effective date, no comment period and no deadline, because nothing in it binds a bank.

Community banks get their own paragraph. Examiners “may use the framework for supervising community banks' SI use”, but have been instructed to tailor examinations “to the bank's size, complexity, and risk profile, proportionate to the nature, consequences, autonomy, and complexity of the bank's SI use cases”. The framework repeats the point: examiners “will likely encounter various levels of SI or agentic SI sophistication and should apply judgement”. In practice a community bank that uses a vendor's drafting assistant and nothing agentic should expect light attention; one that lets an agent release fraud holds should not.

Why read a document that imposes nothing? Because it is the examiner's question list. Every “illustrative consideration” is a thing an examiner may ask to see, and the summary table of SI-specific risks is, in effect, the list of findings the OCC is prepared to write. The rest of this guide treats the framework that way: as a map of the examination, not as a set of duties.

How does the OCC define Super Intelligence, generative SI, agentic SI and autonomy?

The definitions sit in Appendix A, the lexicon, and in the autonomy factor of the tiering methodology. They matter because the framework's own scope depends on them: footnote 1 says the model risk principles of Bulletin 2026-13 apply to “non-generative and non-agentic SI models”, so whether a system is generative or agentic decides which OCC document an examiner reaches for. Terms marked with an asterisk in the lexicon come from the AIEOG AI Lexicon; the rest are the OCC's own.

One definitional choice has consequences for scope. “Super Intelligence” is defined as everything the statute called AI, so the framework technically covers machine-learning scorecards too; it is footnote 1, not the definition, that hands those back to model risk management. A bank that wants to know which document applies to a system should therefore ask the two lexicon questions — does it generate content, does it act independently — rather than ask whether it is “SI”, because under the OCC's definition everything is.

What is the overarching principle, and what are the six pillars of the OCC Super Intelligence framework?

Section 1.1 states the principle in one sentence: “A bank's control intensity could increase with the potential consequences of an SI agent's failure or misuse.” Higher-consequence use cases “may warrant greater restrictions on autonomy, stronger controls, more direct human oversight, more independent validation, and more robust resilience measures” — the five dials that the rest of the framework turns. 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”, and the OCC gives the example that makes the point: “a simple rules-based agent authorized to initiate transactions could present greater risk than a sophisticated model limited to internal drafting assistance.” The framework may also help a bank “identify transmission channels” from SI into its risk categories, “while not inferring any requirement to aggregate SI risk”.

Section 1.2 groups the sixteen components into six pillars, each with “a principal supervisory consideration”. Several components appear under more than one pillar, which is the OCC's way of saying that human oversight is both a control and an oversight question, and that cybersecurity is both a control and a resilience question.

Read together, the principle and the pillars describe a graduated model. Section 3 says so directly: the goal is “light-touch for low-risk, low-autonomy use, materially heavier for anything approaching customer-impacting, irreversible, or highly autonomous action”. The next two sections explain how the tiering produces that gradient and what each component asks.

How does the consequence-based risk classification work, and what does each tier demand?

Section 3.1 scores “every SI and agentic use case” against seven factors “independent of business line, so that a comparable risk gets a comparable control regardless of where it originates in the bank”:

• Decision consequence — does the system inform a human decision, make a decision directly, or take an action directly (moving funds, updating a customer record, market interaction)? “Direct action carries materially higher risk than decision support.”
• Reversibility — can an erroneous output be caught and undone before harm, or is it “effectively irreversible once executed (e.g., a payment sent, a disclosure made, an account closed)”?
• Customer/financial impact — the magnitude of harm to a customer, the markets or the bank if the system is wrong: a single transaction against a portfolio-level decision, a low-dollar against a high-dollar threshold.
• Autonomy level — human-in-the-loop, human-on-the-loop or fully autonomous.
• Data sensitivity — whether the system touches regulated, confidential or personally identifiable data, and whether inputs or outputs could create a privacy or consumer-law exposure.
• Explainability — whether the output can be traced to a rationale sufficient for legal, regulatory or customer-disclosure obligations, with adverse action notices given as the example.
• Provenance — built in-house, fine-tuned from a third-party base model, or consumed as an external vendor service; “each origin carries a different visibility and control profile”.

The factors “combine into a ‘composite tier’”. The framework does not publish weights or a scoring formula; it gives the two ends of the scale: “a simple internal productivity tool with no customer or financial data exposure sits at Tier 4, whereas a fully autonomous, customer-facing payment agent sits at Tier 1, regardless of how well it performs in testing.” That last clause is the one to remember: test results do not move a use case down a tier.

Section 3.2 defines the four tiers. The table below reproduces the OCC's profile characteristics and its own illustrative use cases, and adds what the overarching principle implies for control intensity at each level. The framework does not prescribe a control list per tier; the “what escalates” column is the five dials of Section 1.1 applied to the gradient Section 3 describes.

Three readings follow from the OCC's own placements. Credit: “real-time credit decisioning” is Tier 1 but “SI-assisted underwriting” is Tier 2 — the difference is whether the system decides or assists, not what it decides about. Code: “code assistance” appears at Tier 4 and again at Tier 2 when it concerns “internal code or data access changes”, so the same tool moves two tiers on what it touches. Chatbots: the framework never places a customer-facing chatbot by name; the nearest listed examples are “agent-initiated customer communications” (Tier 2) and “general employee Q&A” (Tier 4), and the factors that would separate them are customer impact, data sensitivity and whether the bot can take an action. The compliance component (Section 2.8) separately warns that hallucinations “concerning fees, rates, account status, or policies could contribute to legal or customer-harm exposure”.

Section 2.2 adds a factor the tiering table does not: aggregate exposure. “Shared providers, data, permissions, infrastructure, and control weaknesses could create concentration or correlated risk across otherwise separate use cases.” Two Tier 3 agents on one vendor platform with one set of credentials are, for an examiner, one exposure.

What are the sixteen framework components, and what SI-specific risk does each one carry?

Section 2 is the body of the framework. Each component follows the same pattern — how SI could affect the control area, the key concepts, and a list of “illustrative considerations” — and the framework's summary table pairs each with the SI-specific risk an examiner would be looking for. That table is reproduced here verbatim because it is the closest thing in the document to a list of possible findings.

The first two components are the entry point. Defined Purpose and Permitted Use (2.1) asks a bank to document, before deployment and after any material change, “what an SI system or agent is designed to do, what it is not designed to do, who or what may invoke it, the data and systems it is permitted to access, the actions it could take, and the circumstances that may require human review or suspension”. Permissions should be stated “in terms that can be tested rather than as a general capability description”, and the most quotable line in the framework follows: “Activity outside the approved purpose may be treated as a control failure even when the resulting output or action appears reasonable.” Risk Classification (2.2) then runs the factors described above and feeds the inventory, which the framework expects to “link these boundaries to ownership, provenance, autonomy, monitoring, and continuity arrangements”. The sections that follow take the remaining components by theme.

What does the framework expect of the board, senior management, audit and reporting?

Governance & Accountability (2.4) starts from a diagnosis: “rapid deployment, technical complexity, and distributed development or ownership could make accountability more difficult to identify.” The board and senior management “may establish an SI risk appetite, identify accountable executives and use-case owners, assign responsibilities and receive information on material SI use” — note that this is the same document that says a separate SI risk appetite is not required; the appetite it describes can live inside the existing one, and “could address autonomy, permitted actions, customer and financial impact, legal and operational exposure, and concentration in addition to model-performance measures”. Decision rights are expected at the lifecycle gates: “development or procurement, risk classification, testing, deployment, material change, exception approval, suspension, and retirement”. Board members, senior management, independent risk management, validation and audit “may need technical knowledge and access proportionate to the bank's use cases”, and where development or hosting is distributed across vendors, “accountability for managing the bank's risk generally remains with the bank”.

Internal Audit & Independent Challenge (2.15) distinguishes validation (does the system operate as designed?) from audit (does the whole SI risk framework work?). Effective challenge “may depend on independence from both the group that develops or owns the system and the group that validates or monitors it”, and the framework lists what audit may need to see: “model and system documentation, data lineage, validation results, vendor contracts, monitoring, incidents, overrides, remediation, and underlying evidence rather than only management summaries”. Where a control agent, fallback agent, circuit breaker or human process serves as a backstop, audit “may assess whether the backstop is independently governed, tested, and effective”.

Reporting & Transparency (2.16) closes the loop. Internal reporting “may be risk based and may include material use cases, accountable owners, significant changes, control exceptions, incidents, customer remediation, concentrations, and assurance results”; escalation and notification thresholds may be set “based on severity, duration, customer impact, financial exposure, legal requirements, and potential systemic effects”; and reports “may be reconciled to the SI inventory, incident records, validation results, audit findings, and board reporting so that material differences are identified”. The framework also notes, without listing them, that “various notifications required by laws and regulations, as well as contracts, could be applicable to SI use cases”. For the wider picture of what supervisors expect of AI governance see our AI governance hub.

What do human-in-the-loop and human-on-the-loop have to mean under the OCC framework?

Section 2.3 is the component most likely to produce a finding, because its risk is “a named human reviewer without practical authority, competency, capacity, or a meaningful review standard”. The framework's test is that “human oversight is most effective when the bank defines the nature of the involvement and can demonstrate that the control operates as intended”. The level of involvement “may be calibrated to the potential consequences, autonomy, reversibility, and operating volume of the use case”.

• Competency and authority. The reviewer “may need sufficient expertise, information, and authority to evaluate, reject, modify, pause, or halt the system's output or action”.
• Meaningful review. Triggers, evidence and procedures should make approval “more than a nominal click”; “high volumes or bulk approval could reduce review quality and contribute to alert fatigue”.
• Span of control. A bank “may evaluate how many agents, accounts, processes, alerts, or actions one person can credibly monitor and the time available to intervene”.
• Override, logging and escalation. Override authority, reasons and patterns “may be logged and reviewed”; “a misfire, hallucination, or control breach may justify temporarily increasing human involvement”.
• Independence. Where appropriate, the reviewer “may be separate from the team that developed or owns the system”.

The tiering table turns these into expectations by level: Tier 3 carries a “mandatory human-in-the-loop”, Tier 2 a human on the loop, and Tier 1 is “autonomous or partially autonomous” — which is why Tier 1 draws the heaviest controls everywhere else. The framework does not say that every AI decision needs a human; it says the human involvement must be defined, proportionate and demonstrable. The agents playbook on this site treats the same question from the bank's side in its control plane and what regulators say pages.

How does the framework extend model risk management, data governance, testing and documentation to generative and agentic SI?

Model risk management extensions (2.5)

Generative and agentic systems “may not conform to more traditional assumptions of model stability, reproducible outputs, a single output type, or directly traceable decision logic”. The framework's answer is not to abandon model risk management but to adapt it: certain MRM principles “may be instructive for development, use, validation, governance, and ongoing monitoring”, while “the scope, frequency, and independence of those activities may be adapted to the use case's potential consequences, rate of change, non-determinism, and reliance on third-party or continuously updated models”. Four specifics follow. Adaptive models, retraining, prompt changes or vendor updates “could alter behavior between periodic reviews and may justify more frequent monitoring or re-validation”. Explainability tools “do not reveal the SI's reasoning and provide a verified source”, so examiners may ask whether the method suits the use case and its legal obligations. For non-determinism, “repeated testing, defined samples, distributional measures, and consistency thresholds may provide more useful evidence than a single successful run”. And “traditional champion-challenger methods may not fit open-ended generative outputs”, so benchmarks, reference sets, expert review or controlled comparisons may stand in. The SR 11-7 vocabulary a bank already has is explained in our SR 11-7 guide.

Data governance (2.6) and privacy (2.7)

Reliability “depends on the quality, lineage, representativeness, and permitted use of the data used to train, fine-tune, and operate” an SI system, and the bank is expected to think about “both data provided to the system and new data created through prompts, outputs, embeddings, logs, feedback, or synthetic generation”. Lineage reaches into vendors' products: the origin, licensing, transformations and limitations of data “including data embedded in third-party foundation models”. Synthetic data “may be subject to quality, approval, representativeness, and bias review because deficiencies can be difficult to identify and may be amplified through training”. Technical controls “may limit the system to approved data sources”. Privacy adds risks “beyond conventional data-handling concerns”: a model “might reproduce specific training examples or infer sensitive characteristics that were not expressly provided”; prompts, outputs, embeddings and logs “could become repositories of sensitive information” warranting access controls and risk-based retention; contracts and configurations “may clarify whether bank data can be used to train or improve models made available to other customers”; and the location of processing “could affect data-residency, transfer, notice, consent, and third-party obligations”. The data-management standard behind these questions is explained in our BCBS 239 guide.

Performance monitoring (2.12) and testing (2.13)

Pre-deployment testing “evaluates performance in a controlled environment”; ongoing monitoring “evaluates production behavior as data, usage patterns, prompts, permissions, providers, and underlying models change after deployment”. Metrics the framework names include “accuracy, precision and recall, task completion, hallucination, abstention, complaint, override, exception, and remediation rates”; monitoring may watch for upstream version changes that “alter behavior without a traditional model release”, and for feedback loops where outputs influence future training data, with thresholds that “trigger review, re-validation, reduced autonomy, or suspension”. Testing is “central to managing risk from the use of SI” and runs through design, pre-deployment (“functional, comparative, scenario, stress, adversarial, compliance, resilience, human-oversight, and acceptance testing”) and use. The SI-specific methods the framework describes are subjective expert review where no verified source exists (with reviewer qualifications, sampling and rater consistency “calibrated to the undesirable-outcome rate the bank is attempting to detect”), adversarial testing, red teaming (“independent or external expertise may be useful when internal capability is limited”) and LLM-as-a-judge, for which the bank “may consider the judge model's validation, independence, position or verbosity bias, correlated failure modes, and the need for human review”. A dedicated passage on hallucination asks for measurement “under representative and adversarial prompts”, assessment of verified sources, confidence and abstention behaviour, categories that require human verification, live sampling after deployment, and defined responses for outputs that cannot be verified. Footnote 4 keeps a door open for conventional methods: where outputs can be compared objectively, “such as a default prediction”, traditional testing “may be appropriate”.

Documentation and auditability (2.14)

Documentation “enables individuals other than the system's developers to understand, evaluate, and audit its design and operation” and, for SI, may cover “purpose, ownership, design, data, providers, versions, prompts, permissions, assumptions, testing, validation, monitoring, decisions, approvals, incidents, and changes”. The standard the framework sets is reconstruction: records “may support reconstruction of material outputs or actions even when the model cannot produce a rule-based rationale”, which means “inputs, outputs, context, retrieved sources, tool calls, approvals, overrides, and actions” are the evidence. Prompt, fine-tuning, configuration, provider, tool and permission changes “may be logged and linked to testing and approval evidence”. And a proportionality clause worth quoting to any procurement committee: documentation may be scaled to complexity and consequence “without creating incentives to select a less suitable system solely because it is easier to document”.

How does the OCC framework treat third-party and vendor SI, including provider agents?

Section 2.9 starts from the fact that “banks frequently obtain SI capabilities from third parties rather than develop them internally”, which “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”. The framework positions itself as a supplement, not a replacement: third-party risk management for SI “may supplement existing interagency third-party risk management guidance” — in the OCC's case Bulletin 2023-17, the 2023 interagency guidance, which the OCC proposed to replace in Bulletin 2026-46 of September 11, 2026. The additional considerations apply “where the provider's SI can affect the bank's decisions, customers or data”.

Vendor SI also appears through the other components: provenance is one of the seven tiering factors (“consumed as a fully external vendor service” being the least visible origin); data lineage reaches “data embedded in third-party foundation models”; privacy asks whether bank data trains models offered to other customers; performance monitoring watches for “upstream version changes”; and the lexicon carries four definitions of service-provider concentration and concentration risk, at the institution and at the sector level. The summary-table risk for the component — “opaque provider chains, weak contractual rights, switching constraints, or concentration in common models and infrastructure” — is the finding to avoid.

What does the framework say about operational resilience, kill switches and cybersecurity for SI agents?

Operational Resilience (2.10) redefines the problem for agents: resilience “includes both loss of service and incorrect operation”, because “an agentic system could remain available while taking inappropriate or harmful actions”. For more consequential or autonomous use cases a bank “may document and test detection, containment, suspension, continuity, recovery, escalation, and remediation arrangements”, covering internal systems, fallback processes and “external SI agents that interact through bank channels”. The containment toolkit is listed: “monitoring, observability tools, control agents, deterministic rules, circuit breakers, rate limits, least-privilege permissions, and kill switches could help identify and contain an agent that is operating but acting incorrectly”. Continuity may be tested through “trained personnel, a narrower fallback agent, or another approved process”; recovery exercises may include “rollback, data correction, restoration of decision support, root-cause analysis, model-risk review, and controlled return to service”. When a misfire reaches customers the framework expects “a separate workstream to identify the complete affected population, assess individual harm, provide notice or correction, and independently verify completion”.

Two resilience considerations look outward. External SI agent interactions: “customer, counterparty, fintech, or agentic-commerce systems that the bank does not control could present channel risk”, so “identity, provenance, delegation, authentication, monitoring, velocity limits, dispute handling, suspension, and revocation may be calibrated to the action requested” — the OCC's first word on agents that arrive at the bank rather than run inside it. Stress and systemic effects: “high-speed agent activity could affect liquidity, fraud losses, service availability, or market behavior”, and scenario analysis “may consider correlated or cascading activity across customers, agents, and providers”. Which outside agents the large banks currently admit, block or partner with is tracked on our agent access page.

Cybersecurity (2.11) treats SI as both target and weapon. “Prompts, model inputs, training and fine-tuning pipelines, connected tools, and non-human identities create attack surfaces that may not be fully addressed by controls designed for conventional code and network perimeters”, and “the breadth of agent permissions and tool access may be treated as part of the attack surface”. The five named threats are prompt injection and jailbreaking (inputs that “cause an agent to misuse connected tools without a conventional network breach”), data and model poisoning, model extraction and data leakage through repeated queries, “tool use and excessive agency” (broad credentials letting a compromised agent “cause fraud, data exposure, or operational disruption at machine speed”) and non-human identities, whose credentials, logs and data use “may be governed in a manner comparable to privileged users”. None of this is new to security teams that follow NIST's generative-AI work; what is new is an examiner document naming it. The playbook's agent lifecycle page maps these to build-time gates.

Does OCC Bulletin 2026-54 raise consumer-compliance, BSA and fair-lending issues?

Yes, in Section 2.8, and the framing is careful: “SI does not change the bank's underlying legal obligations and has the potential to facilitate a bank's compliance with them.” The risk is that SI's “complexity, opacity, speed, and capacity to act may make it more difficult to identify how a requirement applies, explain an outcome, detect noncompliance, or prevent use outside approved boundaries”. The framework asks banks to consider compliance “through design, development, procurement, deployment, monitoring, change management, and retirement”, and then names three areas.

• Bank Secrecy Act and sanctions. Banks “may use SI in transaction monitoring, risk assessment, case management, reporting, and sanctions screening”; “inaccurate, incomplete, or unrepresentative data, or poorly calibrated thresholds could increase false negatives, false positives, or other compliance risks”. AML alert disposition sits at Tier 2 in the tiering table.
• Consumer compliance. SI used in “customer service, marketing, servicing, collections, disclosures, or other consumer-facing activities could create consumer compliance risk when executing tasks, especially if outputs are materially inaccurate, misleading, or inconsistent with product terms”; banks may consider whether “data, model design, testing, monitoring, and human overrides support compliance with the consumer rules and regulations”.
• Hallucinations. “Hallucinations concerning fees, rates, account status, or policies could contribute to legal or customer-harm exposure”; the controls the framework suggests “limit automated representations, require verification in higher-impact contexts, and support prompt correction and remediation”.

Fair lending is not named as such. What the framework does say is that explainability — a tiering factor — means “whether the system's output can be traced to a rationale that is sufficient to meet legal, regulatory, or customer-disclosure obligations (e.g., adverse action notices)”, and that “real-time credit decisioning” is a Tier 1 use. The consumer-protection rules themselves, and the CFPB's position on adverse-action notices from complex models, are covered on our CFPB page; the framework does not restate them, and it does not mention ECOA, Regulation B, UDAAP or disparate impact by name.

How will OCC examiners assess SI inside the existing risk categories?

The framework is explicit that it supplements rather than replaces the examination. Examiners “may use the framework to identify SI-specific considerations that supplement existing model risk management, governance, technology, compliance, and operational-risk practices and to tailor supervisory work to the nature and potential consequences of a bank's SI use cases”. SI “can introduce, amplify or modify risk in existing risk categories, such as operational, compliance and credit”, and those risks, “including SI's contribution to them, should be identified, measured, monitored and controlled according to the bank's risk management framework”. The figure below draws the sequence the components imply: bound the use case, classify it, scale the controls, prove they work, and record the result where the bank already records risk.

Three things follow for a bank preparing for an examination. First, there will be no “SI section” of the report of examination in the way there is a BSA or an IT section; findings will land in operational, compliance, credit or other existing categories with SI as the cause. Second, the materiality lens the OCC instructed examiners to use is the framework's own: the tier of the use case, set by consequence, decides how much of the sixteen-component menu an examiner opens. Third, the framework is explicitly a living document — “expected to change as technology, use cases, and supervisory understanding change and mature” — so the question list will grow. Our OCC authority page tracks each revision.

What is the OCC Super Intelligence framework explicitly not?

• Not a rule or guidance for banks. The bulletin: the framework “does not establish supervisory expectations for banks”; “nothing in this guide is intended to establish new regulatory expectations or set forth enforceable standards or prescriptive requirements”.
• Not a self-assessment tool. “Banks are not expected to use this document to assess their use of SI or their SI risk management.”
• Not a new risk category. Examiners “should not treat SI as a separate and distinct risk category”, and banks “are not required to define a separate SI risk appetite”; the framework does not infer “any requirement to aggregate SI risk”.
• Not a replacement for model risk management. Footnote 1 keeps non-generative, non-agentic models under Bulletin 2026-13; Section 2.5 says MRM principles “may be instructive” for SI.
• Not a replacement for third-party guidance. SI third-party risk management “may supplement existing interagency third-party risk management guidance”.
• Not a scoring formula. The tiering is “illustrative” throughout; the seven factors are listed, their weights are not.
• Not final. “The intention is for this examiner framework to be updated regularly”; the lexicon too “should be treated as a living Lexicon”.
• Not interagency. It is an OCC document; the Federal Reserve and FDIC are not mentioned, and the framework does not mention the interagency request for information on AI and model risk that the three agencies promised in April 2026.

How does Bulletin 2026-54 fit with Bulletin 2026-13, SR 11-7 and the third-party risk guidance?

The framework refers to two other supervisory texts. Footnote 1 cites OCC Bulletin 2026-13: its model risk management principles “apply to non-generative and non-agentic SI models. As such, the supervisory framework described herein is more applicable to generative and agentic SI.” Section 2.9 refers, without a number, to “existing interagency third-party risk management guidance”, which for OCC banks is Bulletin 2023-17. Bulletin 2011-12 and SR 11-7 are not mentioned; they were rescinded by Bulletin 2026-13 in April 2026 and are history, explained in our SR 11-7 guide.

The relationship with Bulletin 2026-13 is complementary, and the easiest way to see it is side by side. The April document is interagency, written to banks, about models, organised around materiality, and in force. The November document is OCC-only, written to examiners, about generative and agentic systems, organised around consequence and transfer of agency, and expressly not an expectation. The shared ground is Section 2.5 of the framework, where model risk management's disciplines — development, use, validation, governance, monitoring — re-enter as things that “may be instructive” once adapted for non-determinism and continuous change.

On the third-party side, timing matters. Bulletin 2026-54 says SI vendor risk management “may supplement” the existing interagency guidance, but that guidance is itself under revision: on September 11, 2026 the OCC, with the Federal Reserve, FDIC and NCUA, proposed guidance in Bulletin 2026-46 to revise and replace the 2023 text. Whether the final third-party guidance absorbs the SI-specific considerations of Section 2.9 — provider agents, SI incident vocabularies, liability for model errors, notice of new SI features — is one of the things to watch. For the comparison of the two generations of US model risk guidance cell by cell see SR 11-7 vs SR 26-2; for every document tagged to generative and agentic AI across the authorities this site tracks, see rules by use case.

What should bank risk, compliance and technology leaders do in the next 90 days?

The OCC says banks are not expected to use the framework to assess themselves, and nothing here is legal advice. But the framework is the list of things an OCC examiner may now ask to see, and every item below is drawn from its own “illustrative considerations”. Grouped by who usually owns the answer:

Risk

• Build or reconcile one SI use-case inventory that records, per use case, “the use case, owner, provider, permissions, deployment status, monitoring, and fail-over arrangements” (2.1), and tag each entry generative, agentic, both or neither so that the Bulletin 2026-13 / 2026-54 boundary is visible.
• Score each use case on the seven factors of Section 3.1 and assign a composite tier; check that Tier 1 candidates — anything that moves funds, decides credit in real time, releases fraud holds or touches markets autonomously — are treated as Tier 1 “regardless of how well it performs in testing”.
• Write the SI dimensions into the existing risk appetite — “autonomy, permitted actions, customer and financial impact, legal and operational exposure, and concentration” (2.4) — rather than creating the separate SI risk appetite the OCC says is not required.
• Map aggregate exposure (2.2): shared providers, shared credentials, shared infrastructure across otherwise separate use cases.
• For generative and agentic systems, adapt the MRM calendar (2.5): what triggers re-validation when a vendor changes the model or a prompt changes, and what the consistency thresholds are for non-deterministic outputs.

Compliance

• For each consumer-facing use, document how “data, model design, testing, monitoring, and human overrides support compliance with the consumer rules and regulations” (2.8), and which categories of output require verification before they reach a customer.
• Define the hallucination controls for fees, rates, account status and policies: limits on automated representations, verification in higher-impact contexts, and the correction and remediation route (2.8, 2.13).
• For BSA and sanctions uses, show the data-representativeness and threshold-calibration evidence behind alert generation and disposition (2.8).
• Check the explainability factor against disclosure duties: where a system contributes to an adverse action, can its output “be traced to a rationale that is sufficient” for the notice (3.1)?
• Map privacy exposures per use case — memorization and inference, prompt and output retention, vendor data use, cross-border processing (2.7).

Technology and operations

• Make purpose boundaries testable: authorised data sources, connected systems, tools, accounts and actions stated “in terms that can be tested rather than as a general capability description” (2.1).
• Give every agent a non-human identity governed “in a manner comparable to privileged users”, with least-privilege permissions and logging of credentials and tool use (2.11).
• Install and test containment for agents that keep running while acting wrongly: circuit breakers, rate limits, kill switches, a narrower fallback agent or a human process, and a rehearsed rollback and return to service (2.10).
• Instrument monitoring for the metrics the framework names — hallucination, abstention, override, exception and remediation rates alongside accuracy — and for upstream version changes (2.12).
• Stand up adversarial testing and, for higher tiers, red teaming; if LLM-as-a-judge is used, document the judge's validation, independence and bias checks (2.13).
• Make material decisions reconstructable: log inputs, outputs, retrieved sources, tool calls, approvals and overrides, with retention set for legal, supervisory, audit and remediation needs (2.14).
• Review vendor contracts for the four Section 2.9 items — provider-agent scope, an SI incident vocabulary and notification timelines, liability for model errors, and notice of new SI features — and for whether bank data may train models offered to others (2.7).

For the board, the one-page version is Section 2.16: a report that lists material use cases, their owners, changes, exceptions, incidents, customer remediation, concentrations and assurance results, reconciled to the inventory. The site's briefing for bank executives and orientation for compliance officers put this document in the wider 2026 reading order.

Which other terms does the OCC lexicon define, and what do they mean in plain English?

Appendix A runs to some fifty entries. The core definitions are in the definitions section above; these are the remaining terms a banker is most likely to meet in an examination conversation. Definitions marked * in the framework come from the AIEOG AI Lexicon with “AI” changed to “SI”; the plain-English column is ours.

1. Super Intelligence: Supervisory Framework (full text, PDF) — Office of the Comptroller of the Currency, Nov 4, 2026 (occ.gov) · our page on OCC Bulletin 2026-54
2. OCC Bulletin 2026-54: Super Intelligence: Supervisory Framework — Office of the Comptroller of the Currency, Nov 4, 2026 (occ.gov) · our page on OCC Bulletin 2026-54
3. News Release 2026-97: OCC Issues Supervisory Framework on Bank Use of Super Intelligence — Office of the Comptroller of the Currency, Nov 4, 2026 (occ.gov)
4. OCC Bulletin 2026-13: Model Risk Management: Revised Guidance — Office of the Comptroller of the Currency, Apr 17, 2026 (occ.gov) · our page on OCC Bulletin 2026-13
5. SR 26-2: Revised Guidance on Model Risk Management — Federal Reserve Board, Apr 17, 2026 (federalreserve.gov) · our page on SR 26-2
6. OCC Bulletin 2026-46: Third-Party Risk Management: Proposed Guidance and Request for Comment — Office of the Comptroller of the Currency, Sep 11, 2026 (occ.gov)
7. OCC Bulletin 2023-17: Third-Party Relationships: Interagency Guidance on Risk Management — Office of the Comptroller of the Currency, Jun 6, 2023 (occ.gov) · our page on OCC Bulletin 2023-17
8. OCC Bulletin 2021-17: Request for Information on Financial Institutions' Use of Artificial Intelligence, Including Machine Learning — Office of the Comptroller of the Currency, Mar 31, 2021 (occ.gov) · our page on 2021 Interagency AI RFI (OCC Bulletin 2021-17)
9. OCC Bulletin 2011-12: Sound Practices for Model Risk Management (rescinded archive) — Office of the Comptroller of the Currency, Apr 4, 2011 (occ.gov) · our page on OCC Bulletin 2011-12