Rail Governance

Ongoing Monitoring Requirements for AI Models in Production Banking

Banks must detect AI failures, explain decisions, and assign accountability.

· 9 min read
Cover illustration for “Ongoing Monitoring Requirements for AI Models in Production Banking”
AI Model Risk Management · October 31, 2026 · 9 min read · 1,972 words

Ongoing monitoring for production banking AI must connect what a system does to evidence, accountability, and action. The April 2026 interagency guidance leaves generative and agentic AI outside its formal scope, but not outside banks’ responsibility. Banks need a monitoring program that can detect trouble, explain decisions, and put a named person in charge of the response.

Why April 2026 left banks without a rulebook for their most consequential AI

On April 17, 2026, OCC Bulletin 2026-13 and SR 26-2 delivered the first overhaul of model risk management in well over a decade. A footnote excluded generative and agentic AI as “novel and rapidly evolving.” That was a deliberate deferral. SR 26-2 tells banks to use their own risk management and governance practices to determine controls for systems it does not cover.

The guidance creates no new enforceable requirements on its own, while supervisory action still follows from unsafe practices. What, then, does the exclusion change for a bank? It removes the prescribed framework without removing accountability. Examiners at the Fed, OCC, and FDIC have embedded AI oversight questions into standard audits, concentrating on unauthorized data access, inability to shut down a misbehaving system, and weak governance of AI vendors and their subcontractors.

Why the standard model-risk playbook cannot be applied directly to production banking AI

Using SR 11-7-style validation for every new AI system sounds simple. The technical assumptions, however, do not travel intact. A credit scorecard or conventional fraud model produces deterministic or near-deterministic results that can be traced and reproduced. Language models produce probabilistic outputs that vary with context, phrasing, or configuration. Accuracy and drift monitoring alone therefore miss prompt injection, hallucination in retrieval-augmented generation pipelines, and failures across agent handoffs.

Delayed outcomes make this problem harder to resolve. A loan may default long after origination, while a fraud signal may remain unconfirmed for weeks. SR 26-2 expects ongoing monitoring against actual outcomes, but neither it nor the EU AI Act specifies how monitoring should operate when those labels are absent.

Agentic systems add a separate problem of attribution. After an agent acts, the bank must explain how models, tools, and inter-agent handoffs produced the result. A final output alone cannot establish that causal chain. APRA’s April 2026 letter identified a related weakness in Australian regulated entities, finding that few continuously validated deployed models for drift, bias, or failure and that point-in-time, sample-based assurance was ill-suited to probabilistic systems.

What institutions are actually deploying and why the monitoring stakes are high

Cornerstone Advisors’ What’s Going On in Banking 2026, published in February 2026, found that nearly half of banks and more than half of credit unions had deployed generative AI. More than half of institutions discussed agentic AI at executive or board level.

By March 2026, Bank of America’s Erica had handled a total of more than 3.2 billion customer interactions. BBVA reported more than a thousand AI use cases in production by July 2026, supported by its AI Factory and common agent-governance framework, “The Frame.” Its voice-agent pilots in Peru and Mexico resolved close to 90% of selected interactions. Back-office deployments extend the range of decisions under scrutiny. FSB case material described an unnamed internationally active bank whose agentic fraud system monitored tens of millions of signals daily across transactions, card, online payments, and digital banking channels.

Many millions of users used Nubank’s AI Private Banker capabilities each month in 2026. Its engineering team describes how it simulates thousands of adversarial conversations to test whether agents leak personal data or go beyond their financial mandate. The legal consequences are not merely hypothetical. In July 2025, the Massachusetts Attorney General reached a settlement with Earnest Operations after its AI underwriting used a Cohort Default Rate variable in ways that led to racial discrimination against Black and Hispanic applicants and an immigration-status knockout rule that automatically denied non-citizen applicants. No human reviewer caught the problem before it caused harm.

The four monitoring layers every production banking AI program needs

Diagram: Four Monitoring Layers for Production Banking AI. Visualizes: Visualize the four monitoring layers every production banking AI program needs, as a stacked or stepped structure showing how they build on each other.

To address these risks, a bank needs four monitoring layers that work together, with a named owner for each and evidence kept in logs. The model behavior layer tracks prediction accuracy against what actually happened, along with input and output drift, feature stability, and the rates at which humans override the model. Overrides deserve attention before headline accuracy figures change. They can reveal that practitioners no longer trust a model. For language models and agents, this layer also needs adversarial and prompt-injection testing, hallucination monitoring, and evaluation of outputs at scale.

IOSCO’s Supervisory Toolkit for AI in Capital Markets, finalized May 25, 2026, calls the use of AI to evaluate AI “AI as a judge.” The FSB’s October 2026 sound practices recommend supplementing human oversight with AI monitoring other AI because continuous human review of individual agent decisions becomes impractical at scale. That monitoring AI itself needs governance. The operational health layer, meanwhile, tracks latency, error rates, throughput, and cost per inference. Quietly multiplying token costs per decision is both a control issue and a finance concern.

The compliance evidence layer turns monitoring into a defensible record. EU AI Act post-market monitoring requirements make documented ongoing monitoring a legal obligation for high-risk banking AI from August 2, 2026. Most credit-scoring and customer risk-assessment AI qualifies, while fraud detection is explicitly excluded from Annex III Point 5(b) and is not automatically high-risk. Passive logging is not enough under Article 72. Banks need active collection and analysis of performance data, dated corrective actions, and records of output scores and the factors behind decisions.

The incident readiness layer connects thresholds to alerts, escalation paths, and reporting clocks. A Wolters Kluwer survey of 230 banking professionals, published June 10, 2026, found that nearly three in four banks said they were least ready to use kill-switch protocols and report AI failures to regulators. Shutdown capability needs testing, as do exit and substitution plans for critical AI providers.

How agentic AI in payments and transfers raises the monitoring stakes further

An agent that executes a transfer does more than offer advice. Its action has binding legal and regulatory consequences. The bank must therefore substantiate precisely how the transaction or flag was produced, rather than merely show that a model was generally accurate. Each autonomous action needs a record detailed enough to reconstruct, attribute, and explain it afterward.

Within predefined guardrails, agents can flag suspicious transactions, escalate high-risk cases, or adjust controls when regulatory thresholds are met. Well-designed continuous transaction monitoring can improve AML detection while reducing false positives, giving the investment a business purpose beyond compliance. The EU AI Act has required transparency for customer-facing AI since August 2, 2026, and DORA has applied to banks’ ICT third-party risk since January 17, 2025. Treating those obligations as an integrated control makes more sense than separating oversight of the interaction from oversight of its provider.

Who owns monitoring — assigning accountability before the examiner asks

The organizational gap often sits between the data science team that built the model and the operations team that runs everything else. Tools alone do not close that gap. A workable allocation gives the business-line model owner responsibility for behavior, ICT operations responsibility for service health, and second-line risk responsibility for validating that controls work. Each model needs one named accountable owner and a monitoring view that business and operations can both read.

Under DORA, accountability for ICT risk rests with the bank’s management body at board level. Daily work can be shared without dispersing that responsibility. The ibl.ai 90-day governance framework recommends a monthly AI governance committee with compliance, risk, business, IT, and audit representation. That gives monitoring findings a standing escalation route, while pre-deployment review above a defined risk threshold establishes monitoring before go-live.

The responsibility also extends beyond the bank’s systems. A vendor’s SOC 2 report does not replace the bank’s model risk management program. Contracts need to give banks audit rights and require providers to report model updates and incidents, and banks must also oversee the foundation model providers behind the products they buy. APRA calls this fourth-party AI supply chain mapping. Its April 2026 review found that banks relied heavily on a small group of providers and that their contracts often left out expected terms for audits and notifications.

What governance-connected monitoring infrastructure looks like in practice

Monitoring must be designed in. A risk-tiered inventory provides the foundation by covering in-house models, vendor models, and AI embedded in purchased software according to use, materiality, and downstream impact. MAS and APRA require that inventory foundation. SR 26-2 requires an inventory for traditional and non-generative models, but its generative and agentic exclusions mean broader coverage is the bank’s own governance choice.

From that inventory, end-to-end lineage must connect development, deployment, monitoring, and retirement. Can the bank explain how a particular prediction was produced without stitching together disconnected handoff records? Audit logs should capture every prompt, response, and model invocation in the bank’s audit-of-record system, with identity binding to a named user or system through its identity provider. Challenger models, outcomes analysis, and sensitivity tests should also be versioned and reproducible so that effective challenge is more than a one-time memo.

For agents, the record must show what happened in each transaction. Configurable guardrails and tested shutdown capability then give the bank ways to act on what that record reveals. Deploying on existing banking rails reduces the integration surface that must be governed and audited, while keeping business logic inside the institution’s control perimeter. SOC 2 certification is still a baseline expectation, but banks can better defend their controls when what they have documented connects to the monitoring program they actually run.

When monitoring must trigger action — thresholds, escalation, and the response playbook

Every tracked metric needs a threshold, an alert, and a named person responsible for acting on a breach. Those thresholds should reflect materiality. A Tier-1 model used for credit decisions, AML triage, or customer-facing financial advice needs tighter limits and faster escalation than an internal productivity tool.

Performance drift is the first trigger category. When accuracy, override rates, or output distributions cross a materiality-mapped threshold, the model owner initiates formal review, with confirmed drift leading to paused or constrained deployment pending revalidation. Incident triggers start a different response, including the applicable regulatory reporting clock and a pre-documented path to the governance committee and regulators. Kill-switch triggers require suspension rather than further review when there is unauthorized data access, unattributable output, or behavior outside authorized scope.

Agentic response protocols must locate the source of failure across models, tools, and handoffs so that remediation can be targeted. Citi described its September 2026 posture as a “human in the loop” phase centered on support tools rather than replacing judgment in risk, compliance, or client interactions. Each institution should document its own calibration of autonomy and human review.

Building the self-regulatory posture SR 26-2 requires banks to construct

The agencies excluded generative and agentic AI pending further consultation, while major jurisdictions are converging on inventory, continuous validation, proportionate human oversight, and third-party accountability. A program built around those controls is better positioned to absorb later binding rules through configuration changes, reducing the need for a multi-quarter remediation effort.

The cost objection deserves a direct answer. Fragmented regulation creates substantial compliance expense, but building a separate monitoring program for every jurisdiction compounds it. One inventory, monitoring architecture, and accountability model can support APRA, MAS, EU AI Act, DORA, and SR 26-2 principles, with jurisdiction-specific obligations addressed within that common structure.

Production-scale institutions already have to make these choices. BBVA, Bank of America, and NatWest with its Cora agentic assistant are building governance infrastructure while deploying, before a complete rulebook is available. Their position exposes the practical test for every bank in the gap. When AI acts, can the institution substantiate what happened, explain why, and show who took responsibility for the response?

Sources

  1. SR 26-2 Regulates Your Models, Not Your AI Agents: What Banks Need to Know - CIMCON Software

More in AI Model Risk Management