Ongoing Monitoring of LLM Behavior in Banks After SR 26-2

What SR 26-2 changes, and what it leaves to the bank

SR 26-2 is the interagency model risk management guidance issued by the OCC, the Federal Reserve Board and the FDIC on April 17, 2026 (OCC Bulletin 2026-13). It rescinds prior model risk management guidance and takes a risk-based approach. It covers model development and use, validation and monitoring including outcomes analysis, governance and controls, and vendor and third-party products.

Two points shape how risk leaders should frame their program. First, the guidance states that it sets no enforceable standards or prescriptive requirements, and that non-compliance will not result in supervisory criticism. It also says practices suitable for one bank may be inappropriate for another. Examiner scrutiny of your monitoring is therefore best understood as a review of whether your own documented, risk-based approach is sound and followed, not a check against a fixed list.

Second, the guidance addresses models generally. It defines ongoing monitoring as an evaluation of the extent to which a model is performing as expected given changes in products, exposures, activities, clients, data relevance or market conditions. It describes outcomes analysis, including back-testing and outlier analysis, and refers to performance thresholds each organization establishes. It does not supply LLM-specific monitoring values. As of November 2026, the agencies had said at release that they planned a request for information on model risk management and banks' use of AI, including generative and agentic AI. Applying the principles to LLMs is currently a matter of bank judgment, which is why the design choices below need to be documented.

Breaking LLM monitoring into four components

Periodic back-testing against a fixed answer set fits poorly with LLMs. Outputs are non-deterministic and shift with prompts, retrieved context and tool access. The practical response is to monitor behavior continuously at the interaction level and to define each component explicitly in policy.

• Behavioral signals: Choose measurable signals per use case: policy violations, sensitive data exposure, tool-call actions, refusals, escalation rates, and the model version or snapshot that produced each output.
• Policy thresholds: Set institution-defined thresholds and targets, with frequency scaled to model risk. Document the rationale, since no LLM-specific values are prescribed.
• Escalation: Define required actions when a threshold is crossed or a deviation persists, who reviews monitoring results, and how issues are reported.
• Evidence retention: Decide what each interaction and each threshold breach leaves behind, how long it is kept, and where it resides, based on your own policy and legal advice.
• Scope by materiality: Start from the model inventory. Higher-risk LLM use cases warrant tighter signals, shorter review cycles and more reviewer attention.
• Effective challenge: Have objective experts review the monitoring design and results, not only development and validation.

Choosing signals and setting thresholds

The supporting literature is general rather than prescriptive. NIST's generative AI profile describes monitoring generated content for personal or sensitive data exposure and real-time monitoring that triggers alerts for human intervention. NIST work on deployed AI notes that policy violations are often inadequately monitored and that policy complexity is a barrier. FINRA's 2026 oversight report lists ongoing monitoring of prompts, responses and outputs as a generative AI control, though in a broker-dealer context rather than bank guidance. These are useful reference points, not bank requirements.

A workable approach is to translate each written policy statement into something testable on a single interaction. A rule against disclosing customer identifiers becomes a detectable pattern in a response. A restriction on what an assistant may do becomes a permitted list of tool calls. Thresholds then apply to rates over time, such as the share of interactions flagged or the number of blocked tool calls, with a lower trigger for higher-risk use cases.

Version identity deserves its own signal. One public comment letter on file with the Federal Reserve reports that vendor-driven model updates can materially change financial risk assessments even when the bank changes no inputs, prompts or processes, and argues that recording only a model-family name is insufficient. The letter is not regulator policy. Still, recording the exact version with every interaction, and comparing old and new versions on identical inputs before a planned change, is a sound way to treat vendor changes as governance events.

Monitoring detects; runtime enforcement prevents

Monitoring and runtime control answer different questions. Monitoring asks whether behavior is staying within expectations and produces signals for people to review. Runtime enforcement acts on an individual interaction or tool call while it happens: allow it, redact part of it, block it, rate limit it, or hold it for human approval. A review performed after the fact can describe a gap between what a model was permitted to do and what it did. It cannot close that gap for the interaction already completed.

That distinction matters for the design. Enforcement can reduce exposure for rules that can be evaluated on a single interaction, such as sensitive data in a response or a tool call outside an approved list. Monitoring remains necessary for patterns that no single interaction reveals: drift in refusal rates, rising escalation volume, or behavior change after a vendor update. A sound program uses both, and each enforcement decision also becomes monitoring input.

The limits should be stated plainly. Interaction-level enforcement does not establish model lineage, does not validate the model's conceptual soundness, and does not by itself trace a multi-step agentic workflow from start to finish. Those needs call for other controls within the model risk framework.

Evidence an examiner can review

The FDIC examination manual directs examiners to evaluate how ongoing monitoring results are reported and who reviews them, and it expects policies to define thresholds and required actions. Evidence should therefore be organized around those questions rather than around raw volume.

For each monitored LLM use case, a bank should be able to show the policy in force and its version, the thresholds and escalation procedures, the enforcement decision made on each interaction, the model version involved, the reviewer and outcome for each escalation, and periodic reporting to the accountable owner. Traceability matters most: an examiner should be able to follow a flagged event back to the specific policy rule that governed it.

Retention periods and data residency are decisions for the bank, set by its own policy, regulatory obligations and counsel. The guidance supplied no fixed figures. What the evidence architecture needs is flexibility, so that those decisions can be configured and later changed without rebuilding the pipeline.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval. Enforcement happens at runtime, not after the fact, and each decision produces audit-ready evidence mapped to frameworks including NAIC, NYDFS and NIST. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency.

The scope is individual interactions and tool calls. Trussed does not provide model lineage or end-to-end tracing of agentic workflows. It has been in continuous production in a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic, and generates over 30 GB of audit evidence per day. Insurance is the regulated financial sector where it is deepest. It does not claim bank customers or deployments; the relevance here is the control and evidence pattern for model risk management review.