On November 4, 2026, the Office of the Comptroller of the Currency gave its bank examiners a supervisory framework for how banks use what the agency now calls Super Intelligence. The OCC’s release lists OCC Bulletin 2026-54, “Super Intelligence: Supervisory Framework”, among its related links. The term covers the technologies and systems previously described as Artificial Intelligence. Examiners are the audience, but in our reading the first firms to feel it are the fintechs that supply AI to national banks or run on a sponsor bank’s rails, because a bank that has to answer these questions is likely to hand them on through the contract.
What the framework says
The document sets out sixteen components, grouped into six pillars: purpose, risk, control, oversight, resilience and assurance. Its scope is SI in everyday banking work, such as payments, credit decisions, fraud detection, operations, customer service, risk management and market activities. That list likely covers most of what a bank buys from a fintech.
What drives the risk rating is consequence, not sophistication. The framework lets classification turn on what could go wrong, how much agency is handed to the system and how closely people oversee it, rather than on how technically advanced the SI is. Its own illustration is that a basic rules-based agent able to start transactions may carry more risk than an advanced model confined to drafting internal text. The factors it names run from how consequential and how reversible a decision is, through customer and financial impact, autonomy, data sensitivity and explainability, to provenance, the scope of permissions and dependencies on other systems. For a fintech, this means a modest model that moves money will probably sit in a higher tier than a large model that drafts internal memos.
In our reading, three components carry the most weight for a vendor. The first is defined purpose: before a system goes live, and again after any material change, a bank may record its intended function and its exclusions, who or what can call it, and the data, systems and actions within its reach. Use beyond that approved purpose can count as a control failure, even if the result looks sound. The second is human oversight, where the named reviewer may need the expertise, information and authority to assess the system’s output or action and then reject it, change it, pause it or stop it. Approval, the framework says, should mean more than a nominal click, and large volumes or approving in bulk could weaken the review. The third is third-party and vendor risk, which addresses the supplier directly.
What the vendor component asks for
Under that component, a bank may set limits for a provider’s agents that reach into bank systems and data, covering their authority, identity, which tools they can use, how they use data and when they must escalate. It may also adopt its own vocabulary for SI incidents, with notification deadlines covering events like hallucination, misfire or drift. On liability, the bank should think about how its contracts allocate responsibility when a model’s errors cause losses. When a vendor adds SI features, the bank may ask to be told and to see what changed, and may reassess the relationship or retest the model before or as the change takes effect. Elsewhere, in the governance component, the framework notes that even when vendors build or host the system, responsibility for managing the bank’s risk generally stays with the bank.
The privacy component raises a question every AI vendor contract is likely to face: contracts and technical settings may make clear whether a bank’s data may be used to train or improve models that other customers can use. A fintech that cannot answer that question in one sentence should expect the contract negotiation to stall on it.
A bank that has to show an examiner a purpose statement, a risk tier and a named reviewer with real authority will ask its AI vendor for the evidence behind all three.
Why it matters for fintechs
The OCC did not write this document for fintechs. But the framework’s logic suggests that bank diligence questionnaires will converge on the same sixteen headings, and a vendor that cannot produce the underlying evidence may find its use case tiered higher, restricted or retested. We expect four asks to arrive first.
A purpose statement in testable terms. The framework prefers a purpose written as testable limits on the data sources, systems, tools and actions a product is allowed to use, rather than a general account of what it can do. A one-page product description is unlikely to satisfy that.
Hallucination testing evidence. On testing, the framework suggests checks for hallucination under both ordinary and adversarial prompts, verification of sources, review of how the system handles confidence and declines to answer, a defined set of outputs that need human checking, and sampling of live output once deployed. A bank partner will probably want the results, not a statement that testing was done.
Decision traceability. To rebuild a material decision or event after the fact, the framework points to records of inputs and outputs, context, sources retrieved, tool calls, approvals, overrides and actions. If those logs sit only inside the fintech’s stack, the bank will likely want access rights and retention terms written down.
Containment. For an agent that keeps running but behaves wrongly, the resilience component names kill switches, circuit breakers, rate limits, least-privilege permissions and deterministic rules as ways to contain it. Expect to be asked who can pull the switch, how fast, and whether it has been tested.
What did not change
Readers over-read every headline, so three points deserve weight. The OCC’s release is explicit that examiners are not to treat SI as its own risk category, and that banks need not set a separate risk appetite for it. SI leaves the bank’s underlying legal obligations unchanged. For SI models that are neither generative nor agentic, the model risk management principles in OCC Bulletin 2026-13 still apply, which leaves the new framework aimed mainly at generative and agentic systems. A fintech supplying a conventional scorecard should expect its bank partner’s existing model risk questions to continue, not to be replaced.
The framework’s wording is permissive throughout: it mostly says what a bank may or could do, and it labels its controls and risk tiering illustrative. It is a lens for examiner judgment, not a rulebook. That cuts both ways. Nothing in it is a hard requirement on a vendor, but nothing in it stops a bank from making any of it a contractual one.
What firms should do
Treat the sixteen components as the table of contents for your next bank diligence response and build the evidence pack now, before the questionnaire arrives.
- Write a purpose statement for each AI product you supply to a bank, in terms the bank can test: who may use it, which data it reads, which systems it connects to, what it may do, and which actions need a person to review or escalate.
- Assign each use case a risk tier using the framework’s own factors, and be ready to explain why a transaction-initiating agent sits higher than a drafting assistant regardless of model size.
- Name the human reviewer on your side and on the bank’s side, document their authority to pause or halt the system, and record override reasons and patterns so the review can be shown to be more than a click.
- Assemble your hallucination and adversarial test results, with how you sampled and who reviewed them, and keep decision records with retention terms the bank can rely on.
- Review your bank contracts for incident definitions and notification timelines, liability for model-related errors, notice of new AI features, and whether bank data can train models offered to others.
- Map all of this to your audit file. Taft’s guide to audit readiness for financial firms sets out how to keep that file current between reviews.
Taft’s AI and Automation Studio helps fintechs and bank-partnered lenders assemble this evidence pack: purpose statements, risk tiering, oversight design, testing records and traceability, built to the headings a bank partner is likely to use. Where contract terms on liability or data use are at stake, take legal advice; Taft does not provide it.
Sources
- OCC Issues Supervisory Framework on Bank Use of Super Intelligence, OCC
- OCC Supervisory Framework on Bank Use of Super Intelligence, OCC
Taft does not provide legal advice. Content is for informational purposes only and subject to regulatory guidance.