OCC Bulletin 2026-54: The Examiner Framework for AI Underwriting

Short answer: OCC Bulletin 2026-54 gives OCC examiners a framework for evaluating how banks use AI, which the bulletin calls super intelligence (SI). It sets no expectations for banks. The OCC says banks "are not expected to use this document to assess their use of SI or their SI risk management."

It still matters for exam preparation at a national bank or federal savings association, because it shows what the examiner was handed. The framework sorts use cases by potential consequences, transfer of agency and human oversight rather than by how advanced the technology is. Its illustrative tier table names underwriting directly: "SI-assisted underwriting" sits in Tier 2 and "Internal document summarization for credit memos" sits in Tier 3.

It also picks up the question April left open. OCC Bulletin 2026-13 left generative and agentic AI out of scope. Footnote 1 of the new framework says the 2026-13 principles apply to non-generative and non-agentic models, and that this framework "is more applicable to generative and agentic SI."

What the bulletin does

The bulletin uses a new word for a familiar thing. Its footnote 2 defines super intelligence as the technologies previously covered by the term artificial intelligence in 15 USC 9401(3), plus their rapidly advancing capabilities, and cites Executive Order 14434. The lexicon leaves out common commercial products with embedded SI, "such as a word processor or map navigation system." We read a memo-drafting assistant or an analyst chat as inside the definition. We use AI on this page except when quoting the OCC.

The OCC's release pairs the framework with a standing point: it expects bank activities, traditional or novel, to be "conducted in a safe and sound manner." The framework adds no standard, and the existing ones keep applying. Section 2.8 says the same about law: SI "does not change the bank's underlying legal obligations."

Who it reaches

The bulletin defines banks as national banks, federal savings associations, and federal branches and agencies of foreign banking organizations. A state-chartered bank answers to the FDIC or the Federal Reserve, and a credit union answers to the NCUA. As of November 4, 2026, we found no counterpart from those agencies.

In our view, a state-chartered bank or credit union can still read the framework as a list of questions one federal banking regulator considers relevant, as long as nothing in its files describes the document as binding on it. For the credit-union version of this program, see AI underwriting for credit unions.

How it fits with the guidance you already use

Nothing was rescinded, so a typical AI underwriting product now touches all four. A statistical risk score reads against 2026-13. A memo-drafting feature reads against 2026-54. The vendor relationship around both reads against OCC 2023-17, and OCC 2025-26 sizes the validation work at a community bank. The examiner readiness guide walks that whole file.

Where underwriting lands in the risk tiers

Section 3 of the framework offers a four-tier method. The OCC labels all of it illustrative, and the table follows its wording.

The framework classifies use cases, and a commercial lending product holds several. In our view, a bank should tier each one on its own. Automated credit decisioning reads like Tier 1. Reminders that go to a borrower with nobody reviewing each one look more like the "agent-initiated customer communications" in Tier 2 than like memo drafting. An extraction step whose every output an analyst approves carries a different autonomy score from one that passes values through on a monitoring dashboard.

The Tier 3 example needs care. It names credit memo summarization, but its profile calls for "limited data sensitivity," and a commercial loan file holds tax returns and personal financial statements. We would not assume a memo tool lands in Tier 3 because the example mentions memos. Write down the reasoning factor by factor, since that reasoning is what an examiner can test.

In the OCC's method, sophistication does not set the tier. Its own example: "a simple rules-based agent authorized to initiate transactions could present greater risk than a sophisticated model limited to internal drafting assistance." A fully autonomous, customer-facing payment agent sits in Tier 1 "regardless of how well it performs in testing," so a vendor's accuracy figure does not settle the classification.

The seven factors, applied to a commercial loan file

Section 3.1 suggests scoring each use case on seven factors that combine into a composite tier. The right-hand column is our translation for commercial underwriting, and the OCC does not prescribe it.

Human review has to work in practice

Section 2.3 will get the most attention in lending, because "a human decides" is the standard answer for AI underwriting. The framework separates human-in-the-loop, meaning review and approval before an output is used, from human-on-the-loop, meaning active monitoring with the authority and practical ability to intervene. It then asks whether the control works: review procedures may be defined "so that approval is more than a nominal click," and "high volumes or bulk approval could reduce review quality and contribute to alert fatigue." Its summary table names the risk as "a named human reviewer without practical authority, competency, capacity, or a meaningful review standard."

A policy line saying the analyst reviews all output names a reviewer and stops there. In our view, a stronger version says what the analyst checks on a spread or a memo section, how many files one analyst carries, what authority that analyst has to reject or halt, and who looks at the override log. Section 2.3 mentions logging and reviewing override patterns. A reviewer with no overrides across a long run of files is worth a conversation, and so is one who overrides the same field on every file. Our guide on reviewing AI-generated spreads covers the mechanics.

Questions to add to the vendor file

Section 2.9 says AI reliance can introduce risks "not fully addressed by conventional service-level and information-security reviews," and section 2.4 says accountability "generally remains with the bank." In our view, a SOC 2 report answers few of these. The sections below are the framework's. The questions are our translation, written for an AI underwriting vendor.

What to have in the file before the next exam

The bulletin requires none of this. It is the paper we would want on hand if an OCC examiner opened the framework at the first meeting. Section 2.14 says documentation may be scaled to complexity and consequence, so at a community bank this can be a page per use case.

• A purpose statement. Section 2.1 lists what the system is designed to do and not do, who may invoke it, the data and systems it can reach, the actions it can take, and when human review or suspension applies. It also treats activity outside that purpose as a control failure "even when the resulting output or action appears reasonable."
• An inventory entry. Use case, owner, provider, permissions, deployment status, monitoring and fallback.
• A classification with reasons. The seven factors, scored per use case, revisited after a material change.
• A review standard. What a reviewer checks, how many files one person carries, and who reviews overrides.
• A fallback plan. Section 2.10 asks whether the process can continue through trained personnel if the system is restricted. For underwriting, that means analysts who can still spread a return by hand.
• Per-file evidence. Section 2.14 lists inputs, outputs, context, retrieved sources, tool calls, approvals, overrides and actions as the record that can reconstruct a material decision.

Common misreadings

• Treating it as a compliance standard. The framework speaks in "may" and "could," and the OCC disclaims enforceable standards. A vendor sheet that says "compliant with OCC 2026-54" claims something the document does not offer.
• Building a separate AI risk appetite. The bulletin says one is not required. Section 2.4 says a board "may" establish one, which reads as an option. The risks belong in the existing operational, compliance and credit categories.
• Reading it as interagency. It is an OCC issuance, unlike 2026-13 and 2023-17.
• Adopting a vendor's tier. A vendor can supply facts. The tier depends on how the bank uses the tool, and the accountability stays with the bank.
• Assuming it is finished. The OCC intends to revise it, so date any internal mapping to the November 2026 version.

Where Aloan sits

The classification is the bank's. These are the facts about Aloan that a classification would draw on, and our AI data security page has the detail.

• Decision consequence. Aloan makes no credit decision. It produces no credit score and no approval or denial recommendation, and protected-class attributes are not model inputs.
• Human oversight. Low-confidence extractions route to human review, every extracted value is editable with the original preserved, and a credit memo advances only through analyst review and a named approval.
• Traceability. Every AI-drafted statement cites its source, extracted values carry the page range they came from, calculated metrics show their formulas, and overrides record who, when and why. An approved memo freezes the analysis behind it.
• Testing. A fixed set of sample loan packages with known answers runs regularly, and always before a model change. In production, an automated pass checks each document's extracted figures against its own printed arithmetic. Our post on how we think about accuracy explains why we avoid a single accuracy number.
• Prompt injection. Free-text AI surfaces separate user content from system instructions and run behind guardrails covered by automated tests. The January 2026 penetration test included prompt-injection testing.
• Provenance. Aloan is an external vendor service that runs on Google Gemini and AWS Bedrock under no-training terms. We notify you in writing before a provider that receives customer data is added or removed.

Two answers to the vendor questions above may fall short of what your program wants. A model version change within a provider under unchanged terms runs under our change management process and the regression set above, and it is not separately notified. Our standard agreement's 48-hour notice covers security incidents and does not define a category for hallucination, misfire or drift. If your program wants either one in writing, raise it during review.

Frequently asked questions