SR 26-2 and BSA/AML Model Expectations: Validating AI Transaction Monitoring and Screening

What changed, and why the old framing no longer holds

Many teams still describe this problem as two guidance sets: general model risk management and a BSA/AML-specific one. That framing is out of date. SR 26-2, the Revised Guidance on Model Risk Management from the Board, OCC and FDIC, was issued on April 17, 2026. It supersedes SR 11-7 (April 2011) and SR 21-8 (April 2021), the statement on model risk management for bank systems supporting BSA/AML compliance. Language from SR 21-8, including its "model, tool, or application" phrasing, should not be relied on.

BSA/AML expectations now sit mainly in the FFIEC BSA/AML Examination Manual. Its suspicious activity monitoring section says management should periodically review and test monitoring thresholds and filtering criteria, and that the monitoring system's programming methodology and effectiveness should be independently validated. Separately, a proposed rule published July 9, 2026 would require Board-supervised banks to maintain effective AML/CFT programs consistent with FinCEN and the other agencies. It is a proposal, not final.

Two features of SR 26-2 shape everything below. It is risk-based, tailored to a banking organization's model risk profile and the size and complexity of its operations. And it states that it does not set enforceable standards or prescriptive requirements. That makes the documented rationale for your tailoring decisions the main thing an examiner can evaluate.

Side-by-side by validation dimension

The table compares SR 26-2 with the FFIEC manual's monitoring-system language for AI-driven transaction monitoring and screening. The two are not mirror images. SR 26-2 is organized around models, while the FFIEC language is organized around the monitoring system.

• Model definition and inventory: SR 26-2 scope turns on its model definition. The FFIEC independent-validation language applies to automated monitoring systems and is not limited to machine learning. Inventory each component, state whether you treat it as a model, and record why.
• Conceptual soundness: SR 26-2 calls for assessing and documenting design, key modeling choices, assumptions, qualitative judgments, data selection, construction and developmental testing. The FFIEC manual asks for independent validation of programming methodology.
• Outcomes analysis and tuning: SR 26-2 compares model outputs with real-world outcomes against model objectives and business use. The FFIEC manual asks management to periodically evaluate filtering criteria and thresholds and to test system capabilities.
• Ongoing monitoring: SR 26-2 treats ongoing model monitoring as its own component alongside validation. The FFIEC manual frames it as periodic review and testing. Retain results from both.
• Change management: SR 26-2 ties validation timing, nature and frequency to the frequency and scope of model changes, among other factors. Threshold and filtering changes in AI systems should fall inside the periodic review cycle.
• Governance and independence: SR 26-2 is guidance without enforceable standards, so document your tailoring. The FFIEC context expects validation independent of development. State who owns BSA/AML model validation, since the old separation no longer exists.

Where the two sets overlap, diverge and leave gaps

The overlap is substantial. Both expect validation to evaluate whether the system performs as intended, both expect periodic re-examination rather than a one-time exercise, and both expect independence from the build team in practice. SR 26-2 says validation generally occurs before a model's first use. The FFIEC manual keeps attention on tuning and effectiveness after deployment. For an AI monitoring model, a clean pre-deployment validation file answers only the first of those.

The main divergence is scope. A model definition determines which components SR 26-2 reaches. Deterministic rule-based processes may sit outside it, yet the FFIEC manual still treats rule-based surveillance systems as needing independently validated methodology and effectiveness. A hybrid architecture, for example a learned alert-scoring model sitting on top of fixed screening rules, can therefore be partly in and partly out of SR 26-2 while being fully inside FFIEC language. Map each component to one of three categories: within SR 26-2 model scope, outside the definition but covered by FFIEC independent validation, or neither. Write down the rationale for each.

Gaps appear with vendor-supplied models and with generative or agentic components, where it is less clear that a traditional model definition applies. Whatever your reading, the validation boundary should be drawn deliberately and documented, not left to default. Depth and frequency should scale with materiality and with how often the system changes, and the criteria you used should be on record.

What runtime enforcement can address, and what it cannot

Pre-deployment validation and runtime control answer different questions. Validation asks whether the design is sound, the data appropriate and the outcomes acceptable. Runtime control asks what the system was allowed to do on a specific interaction, and what it did. The first cannot be reconstructed from the second, and the reverse is equally true.

Policy enforced in the AI execution path can address the last checklist item: records for individual interactions and tool calls showing whether an action was allowed, redacted, blocked or escalated for human approval. That helps close the gap between what was validated and what the system does in production. It also supports evidence for human-review steps, since an escalation and its outcome are recorded at the point they occur.

It does not replace conceptual soundness review, outcomes analysis, threshold tuning review or independent validation. It does not establish model lineage or dataset provenance. Treat its examiner value as complementary and confirm with your own examiners and validators how they weigh it. Any claim that runtime enforcement satisfies model validation should be rejected.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, so policy is enforced at runtime, not reviewed after the fact. Each enforcement decision produces audit-ready evidence for individual interactions and tool calls, with configurable retention and data residency and self-managed deployment in the customer cloud. Trussed has run continuously in production in a regulated enterprise for 18+ months, at 99.95% uptime on live production traffic, with 100+ models under one policy plane.

Insurance is where Trussed is deepest. Trussed does not claim financial-services customers or deployments, and it does not provide model lineage, dataset provenance or transaction-level governance across agents. For AI transaction monitoring and screening, it addresses the per-interaction evidence layer only. Conventional validation and independent review remain separate and necessary.