The OCC's AI Risk Tiers and What They Mean for Engineers

If you're building AI inside a bank, you've probably wondered what happens when the examiner shows up. Not whether they'll ask about your model, because they will, but how they'll evaluate a system that picks its own tools, calls its own APIs, and in some configurations decides whether to release a fraud hold without asking a human first.

The assumption is that model risk management covers it. The Fed replaced SR 11-7 with SR 26-2 in April 2026, updating the foundational model risk guidance for the first time in 15 years. But footnote 3 of the new guidance says this: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance."

The Fed's model risk framework does not cover the AI systems banks are deploying right now. On November 4, the OCC published the framework that does: 16 components, six pillars, a four-tier risk scale, and seven dimensions that determine where your system lands. The framework creates no new rules and no enforceable standards. But it gives examiners a rubric, and the tier your AI system falls into depends almost entirely on architecture decisions you've already made.

The gap and who filled it

SR 11-7 was published in 2011, when "model" meant a logistic regression in a spreadsheet. For 15 years it defined how examiners evaluated any system that took inputs and produced quantitative output for decisions. When the Fed finally replaced it with SR 26-2, banks expected the update to cover the AI systems proliferating across lending, fraud detection, compliance, and customer service.

The new guidance covers traditional AI and ML models. It does not cover generative or agentic systems. The carve-out was deliberate: gen AI and agentic AI were evolving too fast for the Fed to commit to stable supervisory expectations.

That left a gap. A bank running an autonomous payment agent had model risk guidance for its logistic regression fraud scorer but nothing for the LLM system making real-time hold decisions. The OCC's November framework fills it with six pillars, 16 components, and a risk-tiering methodology for the systems the Fed chose not to address.

The OCC disclosed in a footnote that the framework was "prepared with the assistance of SI," the agency's term for what everyone else calls AI.

Seven dimensions, one tier

Seven dimensions determine where your system lands: decision consequence, reversibility, customer and financial impact, autonomy level, data sensitivity, explainability, and provenance. Each one maps to something an engineer controls.

The dimensions that move the needle most are the ones engineers choose during system design. Autonomy measures how much human involvement sits between the model's output and the action taken. Reversibility asks whether the action can be undone, which is a question about whether you built a hold or a debit. Provenance tracks where the model came from, and the framework treats in-house development, fine-tuned third-party models, and fully external API access as three distinct control profiles.

Decision consequence and customer impact measure the stakes. A fraud hold that freezes a customer's account during a medical emergency is high consequence with direct consumer harm. An internal email draft suggestion is neither. Data sensitivity covers what the model can see: PII, account numbers, and health data carry higher scores than public information.

Explainability in the OCC's framing means the institution can reconstruct the system's reasoning for a specific decision, which is a documentation capability, not a property of the model architecture. A black-box neural network with full input/output logging may satisfy the requirement, while a transparent rules-based system without logging may not.

These dimensions combine into a tier placement. The framework doesn't prescribe a formula, but the logic is clear: score high on consequence, low on reversibility, and high on autonomy, and you land at the top.

The four tiers

Tier 1 is where most of the engineering burden lands. Autonomous payment agents that release fraud holds, real-time credit decisioning systems, direct market access for trading. These score high on consequence, high on autonomy, and low on reversibility. The framework expects full decision traceability, real-time monitoring, defined escalation paths, independent validation, and stress testing for systemic effects.

"High-speed agent activity could affect liquidity, fraud losses, service availability, or market behavior," the framework notes. If your system can move money without a human, the OCC assumes it can move enough to matter.

Tier 2 is where human-in-the-loop systems land. AI-assisted underwriting where a loan officer reviews each recommendation. Agent-initiated customer communications with compliance checks before send. AML alert disposition where the agent triages and the analyst approves.

The human involvement at Tier 2 is real, but the system's influence on outcomes often dominates. Controls include periodic validation, documented override rates (how often the human actually disagrees), and ongoing performance monitoring.

Tier 3 covers internal systems with limited external impact: document summarization for credit memos, agent-assisted research, internal knowledge retrieval. Outputs inform decisions without directly executing them. Standard model governance with lighter monitoring.

Tier 4 covers productivity tools. Internal Q&A bots, code completion, draft generation. Basic access controls and usage logging. If the system can't reach a customer and can't move money, this is where it sits.

Your architecture is your tier

The seven dimensions evaluate system design. Autonomy, reversibility, consequence, and provenance each map to architecture choices the engineering team made before the model was deployed.

Put a human approval step before fund movement, and your autonomy score drops. Make the output a hold instead of a debit, and the reversibility score changes. Route sensitive data through a DLP layer before it reaches the model, and your data sensitivity profile shifts. Strip the agent's ability to initiate actions and limit it to producing recommendations, and consequence drops.

The same model, doing the same inference, can sit in Tier 1 or Tier 2 depending on where you put the human checkpoint.

When you're building a new AI capability inside a bank, you're simultaneously choosing its regulatory tier. The examiner's first questions won't be about accuracy or F1 scores. They'll ask where the human sits, what happens when the output is wrong, and whether the action reverses.

Teams that designed for model performance without considering the supervisory dimensions may find their system classified a tier higher than expected, not because the model is risky, but because the architecture doesn't include the controls the lower tier requires.

What the gateway has to log

Component 2.14, Documentation and Auditability, requires that the institution can reconstruct the reasoning behind any decision the AI system made. For a system processing thousands of decisions per day, that's a storage architecture problem.

Reconstructing a decision means capturing the prompt (including system instructions and retrieved context), the model's output, which model version produced it, what tools the agent called, what data those tools returned, and the final action taken. For a single decision in an agentic workflow with five or six tool calls, that's 20 to 30 fields per decision, written to immutable storage, indexed for retrieval under examination.

If you've read my piece on the model gateway as a compliance boundary, this is the same architecture. The gateway that routes model calls and logs requests is the surface where component 2.14 gets satisfied. The OCC framework makes the requirement concrete: not "log your calls" but "reconstruct the full reasoning chain behind any individual decision, including tool calls, within the examination window."

The storage cost compounds quickly. At 30 fields per decision, a system making 10,000 decisions per day generates 9 million fields per month, all in immutable storage indexed for arbitrary retrieval, which is a different system from append-only debugging logs.

Human oversight is a throughput problem

The framework says human-in-the-loop only counts when the person has the skill, authority, and time to say no.

Skill means the reviewer understands the domain well enough to catch errors. A compliance analyst reviewing AML alert triage needs to know what a suspicious pattern looks like.

Authority means the reviewer can actually override the system's output. If the workflow treats review as a formality, approving 99.8% of outputs without examination, the framework considers that reduced review quality. The OCC explicitly names alert fatigue and bulk approval as patterns that degrade oversight.

Time is the dimension engineers control. If the system produces 500 decisions per hour and one person reviews them, that's about 7 seconds per decision. A building inspector assigned to 500 homes a day can stamp the paperwork, but can't inspect the wiring. Whether a loan officer can meaningfully evaluate a credit recommendation in 7 seconds is a question the examiner will ask.

So the design constraint becomes capacity planning. Given your decision volume and the time each review needs, how many reviewers do you need? And what happens to your latency SLA when every Tier 2 decision queues for approval? If the queue grows faster than humans can clear it, your system either needs Tier 1 controls or more staff.

The external agent door

The framework dedicates attention to external AI agents, systems deployed by third parties that interact with the bank. Mercury's MCP usage is growing exponentially. BLIK shipped a working autonomous payment in September. The OCC is writing guidance for a surface that already exists.

For external agents, the framework requires nine controls, each calibrated to the action the agent requests. A read-only data query carries lighter requirements than a fund transfer.

The nine controls are identity verification, provenance tracking, delegation validation, authentication, real-time monitoring, velocity limits, dispute handling, suspension capability, and revocation. If you've followed my coverage of agent identity protocols, this checklist maps closely to the four-layer protocol stack already emerging: PAP for session management, x401 for identity proof, MCP for scoped permissions, and Verifiable Intent for authorization records.

Velocity limits connect to a different piece of existing infrastructure. The policy engine pattern for agent payments, with rolling budgets and atomic reservations, is the engineering implementation of what the OCC calls "controls calibrated to the action requested."

What banks don't have yet is a single integration that covers all nine. Each protocol handles a subset. PAP covers identity and delegation, x401 handles authentication, MCP defines scope, and the policy engine enforces velocity limits.

Dispute handling, suspension, and revocation are operational procedures that sit outside any single protocol. The framework expects the complete set, and assembling it from the current protocol landscape is integration work that nobody has shipped end-to-end.

When the agent misfires

Component 2.10, Operational Resilience, defines the worst case as a system that remains available while acting incorrectly. Not a crash or an outage, but an agent that keeps running, keeps making decisions, and keeps being wrong while every availability metric stays green.

The framework expects circuit breakers that trigger on anomalous output patterns, rate limits that cap agent actions to what the use case requires, kill switches for immediate termination, and least-privilege permissions so a misfiring agent can only damage what it has access to.

The framework also defines "scope drift" as a control failure. If an agent approved for customer service summarization begins generating product recommendations, that's a failure even if the recommendations are good. The output crossed the approved purpose boundary. Detecting that drift requires real-time monitoring against a defined scope, which means the system needs a purpose boundary and infrastructure that alerts when behavior crosses it.

For teams building on agentic compliance stacks, scope drift detection is the monitoring layer they may already have. For teams that haven't built it, this is the requirement that adds it to the roadmap.

What changed on November 4

The OCC framework didn't invent the controls it describes. LedgerDrift has covered model gateways as compliance surfaces, agent identity verification, scoped authorization for agent payments, and risk tiering for autonomous systems as engineering patterns over the past months. The framework codifies them as supervisory expectations.

What changed is that an examiner will now arrive with 16 components and a four-tier scale, and each component maps to infrastructure you either built or didn't. Whether you have the answers before the examiner asks is an architecture question.