OCC Issues Supervisory Framework for Bank Use of “Super Intelligence”

On November 4, 2026, the Office of the Comptroller of the Currency (OCC) issued a supervisory framework (the Framework) to assist OCC examiners in evaluating the use by national banks, federal savings associations, and federal branches and agencies of foreign banking organizations (together, banks) of artificial intelligence in normal-course business activities, such as credit decisioning, payments, fraud detection, customer service, and risk management.¹ Consistent with Executive Order 14434, the Framework uses the term “Super Intelligence” (SI) to refer to the technologies and systems encompassed by the term artificial intelligence (AI), as well as the potential and rapidly advancing capabilities of those technologies.

The Framework, in certain respects, fills a gap in the revised interagency model risk management guidance that the OCC, the Board of Governors of the Federal Reserve System, and the Federal Deposit Insurance Corporation issued in April 2026 (the MRM Guidance), which determined that generative and agentic AI models were outside the scope of the guidance as “novel and rapidly evolving.”² According to the OCC, the MRM Guidance continues to apply to non-generative and non-agentic SI models, and the Framework is more applicable to generative and agentic SI. The Framework was issued nearly two months after the Conference of State Bank Supervisors (CSBS) released its Artificial Intelligence Supervisory Framework for state examiners (the CSBS Framework).³

This Advisory summarizes the Framework and highlights important takeaways for OCC-supervised banks.

Overview

The Framework is non-binding, does not establish new supervisory expectations, and does not set enforceable standards or prescriptive requirements; banks are not expected to use it to assess their own SI risk management. Examiners are instructed not to treat SI as a separate and distinct risk category, and OCC-supervised banks are not required to define a separate SI risk appetite. The OCC describes the Framework as a living document, and the agency intends to update it regularly, including in response to stakeholder feedback. The Framework includes an illustrative four-tier risk-tiering methodology and a lexicon of relevant terms.

The Framework’s Overarching Principle and Six Pillars

The Framework’s organizing principle is that banks should increase the intensity of their controls to be commensurate with the potential consequences of an SI agent’s failure or misuse. As the OCC explains, 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 OCC also explains that the technical sophistication of the SI tool or agent may not be as determinative of the risk classification as those consequences, degree of delegation to the tool or agent, and level of human oversight. In its issuing release, the OCC instructed its examiners to tailor their reviews to a bank’s size, complexity, and risk profile, such that examiners’ supervisory expectations are proportionate to the nature, consequences, and complexity of a bank’s SI use cases. Accordingly, the Framework is structured to be applicable to all OCC-supervised institutions, regardless of asset size or other common defining characteristics. The OCC has reiterated that it expects bank activities, whether traditional or technologically novel, to be conducted in a safe and sound manner and in compliance with applicable law.

The Framework sets out 16 components that are grouped under six “pillars,” each representing a principal supervisory consideration related to SI: (1) Purpose (what the system or agent is permitted to do); (2) Risk (the consequences if its output or action is not fit for purpose); (3) Control (preventing unauthorized, inappropriate, or unsafe actions); (4) Oversight (who monitors the system and who is accountable); (5) Resilience (detecting, containing, recovering from, and remediating failures); and (6) Assurance (evidence that controls continue to operate effectively).

Framework Components

For each component, the Framework explains how SI may change the risks in an established control area and lists illustrative considerations for examiners. Key aspects of each of the components are listed below.

• Defined Purpose and Permitted Use. Effective SI risk management starts with a clearly defined and documented purpose of a given system or agent, which establishes the authorized scope of the system or agent and provides a baseline to assess scope drift, unauthorized use, and control failures. Creating an inventory of systems and agents will allow banks to link the scope parameters to the other delineated components.
• Risk Classification and Criticality Assessment. Using a consequence-based assessment can help banks utilize more stringent controls for more significant use cases, while avoiding imposition of such strict controls on lower-risk activities.
• Human-in-the-Loop and Human-on-the-Loop Controls. Human oversight — be it through mere monitoring or consistent approvals — will be most effective in the OCC’s view if a bank defines the nature of human involvement and can show that the human administration of the control is operating as planned. Thresholds or triggers of human involvement, override authority and escalation procedures, and independence standards are cited as important considerations. 
• Governance and Accountability. An effective governance framework establishes accountability for SI risk. Although not mandatory, the OCC suggests that a bank’s board of directors and senior management can establish an SI risk appetite, identify accountable executives and use-case owners, and receive reports on the bank’s material uses of SI.
• Model Risk Management Extensions. The Framework acknowledges that some SI systems may not conform to more traditional model risk-management assumptions. While general model risk-management principles may be instructive, the scope of those activities may be adapted for individual use cases.
• Data Governance. Data governance can address data quality, access, and retention, among other things, during the entirety of an SI system or agent’s lifecycle. A bank can look to both data provided into a system or agent, as well as the system or agent’s outputs.
• Privacy. Privacy issues from SI use encompass more than compliance with applicable law and regulation, and could cover access, retention, notice, consent, and reliance on third-party vendors. Of note, retention policies regarding prompts, outputs, and other sources of potentially protected or otherwise sensitive information may require special consideration. Cross-border and vendor-related privacy issues may also warrant examination in this regard.
• Compliance. The OCC cautions that compliance risk can increase in a number of different scenarios: for example, if an SI system or agent produces inaccurate or inconsistent outcomes, is used outside its intended purpose, or is not supported by appropriate controls. A bank may consider compliance risks through design, development, deployment, monitoring, change management, and termination of an SI system or agent.
• Third-Party and Vendor Risk. Third-party risk management for SI systems and agentic SI may supplement existing interagency third-party risk management guidance.⁴ Banks should consider how SI-related contracts assign responsibility for errors, losses, and customer harm, and they should understand potential liability and indemnification under those agreements. The OCC warns that vendors may add SI features, functionality or change models connected to products already in use by a bank, so banks will need to actively monitor those developments. Banks should consider requiring notice of new SI functionality, which may cause them to perform more testing or even reevaluate the relationship. 
• Operational Resilience. In assessing a bank’s operational resilience for SI, banks should consider both a loss of service and incorrect operation. As examples, the Framework notes that agentic systems could remain available while still continuing to take inappropriate or harmful actions. This might prompt the bank to contain the issue and remediate any harm caused. Additionally, the OCC highlights that high-speed agent activity could affect liquidity, losses relating to fraud, service availability, and market behavior, which may justify the preparation of scenario analysis and corresponding planning. 
• Cybersecurity. The Framework observes that SI systems could be targets of cyberattacks that have advanced speed, scale, and sophistication.
• Performance Monitoring. Ongoing monitoring of SI use should be employed after deployment of a given system or agent. The metrics, thresholds, reporting, and escalation can be calibrated to an individual use case’s potential consequences and how quickly the system or agent is changing.
• Testing. The OCC makes clear that testing is central to managing risk from the use of SI. If a given use case has lower impact, more limited testing may be warranted; but more impactful use cases — or situations where SI systems or agents are more autonomous — could warrant broader testing of performance, design, and controls, over the entirety of the SI lifecycle.
• Documentation and Auditability. The Framework explains that documentation can be proportionate to a given use case and may include, among other things, design, versions, permissions, assumptions, and approvals, as well as results from other components described herein (testing, monitoring, changes, etc.). 
• Internal Audit and Independent Challenge. A bank’s internal audit function is capable of providing additional assurance related to implementation and validation, including through a broader lens of assessing the operation of the holistic SI risk-management framework. Audit scope and reporting can be integrated into a bank’s audit framework.
• Reporting and Transparency. Reporting practices may need to be flexible, as the OCC expects reporting to keep pace with changes in systems, providers, permissions, and operating conditions. Internal reporting may be risk-based and be triggered by significant changes, exceptions, incidents, or assurance results.

Illustrative Controls Framework and SI/Agent Risk Tiering

To help scale controls to risk, the Framework offers an illustrative method for sorting SI use cases into risk tiers, in which each use case is assessed against the same seven factors, regardless of the business line in which it is used. The results of the example combine into one of four tiers: critical, high, moderate, and low, although each bank can select its own number and type of categories.

Takeaways

• The OCC’s publication of the Framework demonstrates that the risk management of SI is top-of-mind for the agency, and also evidences its intent to take a leading role among regulators in defining how banks should manage the emerging risks from this technology in the context of the policies established by the current Administration with regard to the promotion and advancement of SI in the U.S..
• The Framework is the clearest statement to date of what OCC examiners will look for in a bank’s risk management regarding a bank’s use of generative and agentic SI, even if it is (currently) non-binding. As explained by the OCC, examiners may use the Framework to identify SI-specific considerations that supplement existing model risk-management, governance, technology, compliance, and operational risk practices, among others. The OCC acknowledges that SI can introduce, amplify, or modify risks that are already present in these areas, so the agency will expect that its supervised banks identify, measure, monitor, and control those risks in accordance with its risk management framework.
• Under the Framework, examiners may tailor their supervisory expectations to the nature and potential consequences of a bank’s SI use cases. How examiners apply these concepts in practice to a given bank will be situation-dependent and could vary to some degree depending on the examination team’s experience with SI. As the OCC acknowledges, examiners are likely to encounter various levels of SI sophistication and are instructed to apply judgment to the situation, considering a bank’s size, complexity, and risk profile.
• The OCC makes clear in several instances that a bank’s use of SI does not displace its ultimate compliance responsibilities and legal obligations, even if SI may be able to facilitate compliance with them. In its discussion of third-party oversight, the Framework notes that although development or hosting of SI could be distributed across vendors, accountability for managing the risk remains with the bank. Because most, if not all, community banks rely on third parties for their advanced technology needs, the OCC is clearly placing third-party risk management with respect to SI near the top of its examination priorities.
• As the Framework recognizes, existing vendors may add SI features or change the models connected to products banks already use. Banks should consider whether their vendor inventories identify embedded SI and, at the negotiation or renewal stages, whether existing agreements address provision of notice of new SI functionality and model changes, limits on using bank data to train models offered to other customers, SI incident notification timelines, access to relevant documentation, and liability for model-related errors and customer harm.⁵
• Banks need not build a standalone SI risk program, but should be prepared to show how their model risk, third-party, cybersecurity, resilience, and compliance programs have been extended to SI.
• Although the OCC’s Framework and the CSBS Framework share a common architecture — both are non-binding examiner tools that scale review to an institution’s risk profile, build on existing supervisory resources (such as third-party and model risk review), and focus on use-case risk tiering, controls over agentic systems, and AI embedded in vendor products — they are not identical.⁶ The CSBS Framework can be seen as more of a procedural toolkit (scoping questions, document requests, and review procedures) for state-chartered banks, and each state decides the extent to which it incorporates the toolkit. The OCC Framework can be seen as a delineation of the types of considerations that OCC-supervised banks should be incorporating into their risk management frameworks and that OCC examiners are likely to ask about in future examinations. States’ decisions around the implementation of the CSBS Framework may lead to divergent supervisory treatment between state-chartered and national banks in this space going forward, influenced by state boundaries and individual state regulators’ experiences.

*          *          *

If you have any questions regarding the Framework or how it may affect your institution’s use of SI, please contact any of the authors of this Advisory or your usual Arnold & Porter contact. The firm’s Financial Services group and Artificial Intelligence team would be pleased to assist.

© Arnold & Porter Kaye Scholer LLP 2026 All Rights Reserved. This Advisory is intended to be a general summary of the law and does not constitute legal advice. You should consult with counsel to determine applicable legal requirements in a specific fact situation.