Your AML Transaction Monitoring Runs on AI. Your Examiner Is About to Treat It Like a Model Under SR 26-2.

TL;DR

• SR 26-2 (April 2026) governs AI-powered AML transaction monitoring systems — these are models, and your examiner will treat them as models
• Institutions remain responsible for validating third-party AML models; vendor documentation does not substitute for institution-specific validation
• Examiners now expect quarterly drift monitoring evidence, documented alert tuning rationale, and a designated model owner in your model inventory
• GenAI features in AML tools (investigation assistants, SAR drafting) fall OUTSIDE SR 26-2 and require separate governance under the FSB’s 12 Sound Practices
• The Canaccord Genuity enforcement action (this week) illustrates human BSA failure; the SR 26-2 gap exposes a different kind of risk — one where the model never generates the alert the human would have reviewed

This week, FinCEN and FINRA hit Canaccord Genuity’s broker-dealer with an $80 million combined penalty for employees who deliberately chose not to file 160 SARs. A compliance system that worked the way it should have, with employees who decided to ignore it.

That is a human failure. It is not the failure this post is about.

The failure this post is about is quieter and harder to detect: the AML transaction monitoring system that never generates the alert. No human sees the suspicious transaction. No human makes a judgment call. The model simply does not fire. And when the examiner arrives and the SARs are missing, the conversation is not about employee discipline — it is about whether your model worked, whether you validated it, and whether you were monitoring it.

SR 26-2, the interagency model risk management guidance the Fed, OCC, and FDIC issued in April 2026, applies to that system. And most BSA teams have not processed what that means.

What SR 26-2 Actually Is — and Why AML Teams Need to Read It

SR 26-2 replaced SR 11-7, the 2011 guidance that has governed model risk management at supervised institutions for the last fifteen years. The update was the first comprehensive revision since the original guidance, and it arrived with the full weight of three agencies behind it.

The core definition is unchanged: a model is any quantitative or algorithmic method that transforms inputs into outputs that inform decisions. AML transaction monitoring systems, whether rules-based with tuned thresholds or machine learning-based with behavioral scoring, produce outputs (alerts, risk scores, case referrals) that inform decisions (SAR filings, enhanced due diligence, account closures). They are models under SR 26-2. They have been models since SR 11-7. What changed is the examination standard for what governance of those models must look like.

SR 26-2 updates expectations in four areas that directly affect AML programs:

Materiality-based validation tiering. SR 26-2 establishes a tiered approach to model risk: higher-risk models receive more rigorous validation; lower-risk models receive lighter-touch review. Your AML transaction monitoring system is not a low-risk model. It is the primary control for suspicious activity detection, a core BSA obligation, and an examination focus. Institutions that have treated AML model validation as a checkbox — annual review, tick the box — will find that SR 26-2 requires documentation proportionate to the model’s materiality, which for most BSA programs means comprehensive validation.

Ongoing monitoring, not just initial validation. SR 26-2 draws a clearer line between model validation (a structured test of whether the model works) and ongoing model monitoring (continuous or periodic tracking of whether the model continues to work). The examiner expectation that has emerged from banks’ recent exam cycles is quarterly monitoring evidence for high-materiality models — including AML transaction monitoring. That means quarterly documentation of alert rate trends, alert disposition rates, and the actions taken when monitoring flags potential degradation.

Third-party model accountability. SR 26-2 is explicit: purchasing a model from a vendor does not transfer the validation obligation. If your institution deploys a vendor AML transaction monitoring system, you are responsible for ensuring it has been validated and that the validation is adequate for your portfolio. Vendor-provided validation documentation — and every major AML vendor produces some form of it — is a starting point, not a conclusion. The institution must review that documentation and determine whether it is sufficient for your specific customer base, product mix, and risk profile.

Model inventory completeness. SR 26-2 requires a complete model inventory with a designated model owner for each entry. For many institutions, AML transaction monitoring systems are not in the model inventory — or they’re listed as IT systems rather than models, with no designated MRM owner. That gap is an immediate finding if an examiner asks to see your model inventory and the BSA team cannot point to the entry.

The Difference Between Human Failure and Model Failure

The Canaccord Genuity enforcement action is instructive as a contrast. The facts as alleged: employees with supervisory sign-off did not file SARs they knew should be filed. That is a governance, training, and supervision problem. The AML system presumably generated the alerts; humans decided not to escalate.

AML model failure looks different. The pattern is:

1. Customers engage in activity that would meet the regulatory threshold for suspicious activity
2. The transaction monitoring system does not generate an alert — thresholds are miscalibrated, a rules set hasn’t been updated for a new product type, or model drift has degraded detection rates
3. BSA reviewers never see the transactions
4. No SARs are filed
5. Examination reveals the pattern; institution cannot explain why the monitoring system failed to generate alerts
6. Examiner cites inadequate model validation and monitoring

The examination finding is a BSA failure because SARs were not filed, but the root cause is model governance. The remediation path — revalidation, threshold recalibration, retroactive look-back — is different from the remediation for a human failure. The enforcement history reflects this: institutions have faced MRAs and enforcement actions specifically for model governance deficiencies in AML programs, separate from the underlying BSA violation.

What Examiners Are Now Looking For

The examination standard for AML model governance under SR 26-2 has sharpened. Specifically, examiners are now asking for:

Alert Rate Trend Documentation

Across examinations in 2026, examiners from OCC and the Fed have requested quarterly reports showing alert volume trends, broken down by alert type (structuring, unusual wire activity, cash-intensive businesses, etc.) and compared against prior periods. A meaningful decline in alert rates without a corresponding documented change in the customer base, product mix, or model configuration is a red flag.

If your alert rates dropped 30 percent year-over-year and you cannot point to a documented reason — customer attrition, business line wind-down, intentional threshold adjustment — an examiner will treat that as potential model degradation and will ask for validation evidence.

Alert Disposition Rate Tracking

Alert disposition rates track what happens to generated alerts: what percentage escalate to case review, what percentage close at the alert stage, and what percentage of cases result in SAR filings. SR 26-2’s ongoing monitoring requirement means institutions need to be tracking these metrics and documenting what happens when they move.

A disposition rate that trends toward fewer SARs per case reviewed is either good news (your alert quality improved and reviewers are closing low-quality alerts faster) or a warning sign (reviewers are closing alerts that should escalate). You need evidence to distinguish those.

Threshold Justification

Every alert threshold in your transaction monitoring system should have documented justification: why this amount, why this frequency, why this counterparty type. For systems using machine learning scoring, the equivalent is documented rationale for the score cutoff used to generate alerts.

This documentation requirement trips up institutions that have run the same monitoring system for five or more years. The thresholds were set at implementation, the vendor’s professional services team made recommendations, and no one documented the rationale. Now the examiner asks why your structuring alert threshold is $9,800, and the institution cannot produce a business justification — only “that’s what it was set to.”

Model Change Documentation

When thresholds are adjusted — in response to alert volume changes, business growth, new product launches, or examiner feedback — those adjustments need to be documented as model changes. SR 26-2 extends model change management to updates that materially affect model outputs. A threshold change that meaningfully shifts alert volume is a material change. The documentation should include the business rationale, who approved the change, what testing was done before implementation, and any monitoring scheduled post-implementation.

Vendor Validation Review Evidence

If your AML transaction monitoring system is a vendor product, examiners will ask to see your review of the vendor’s validation documentation. This is not the same as receiving and filing the vendor’s documentation. The institution needs to demonstrate that someone with model risk expertise reviewed the vendor materials and formed a judgment about whether they were adequate for the institution’s risk profile.

The GenAI Carve-Out You Need to Know About

Here is where SR 26-2 creates a governance gap that many institutions are not tracking.

SR 26-2 explicitly excludes generative AI and agentic AI from its scope. The agencies acknowledged that those technologies are “novel and rapidly evolving” and outside the framework of traditional model risk management.

That matters for AML programs because vendors are moving fast. FinTech BSA platforms and legacy AML vendors are adding GenAI features:

• AI-generated SAR narrative drafting
• Large language model-powered investigation assistants that summarize case history
• Agentic AI that can query transaction history and pull related customer records
• Natural language interfaces for BSA analyst queries

None of these fall under SR 26-2. They are not traditional models in the quantitative sense. But they are in your BSA program, they are influencing compliance outputs, and they are not ungoverned — they just fall under a different framework.

The FSB’s 12 Sound Practices for responsible AI adoption, published June 2026 with a final report due this month, covers the full AI lifecycle including GenAI and agentic systems. Practice 5 (materiality assessment), Practice 9 (performance monitoring), and Practice 10 (human oversight) apply directly to GenAI features in your AML tools. If a GenAI investigation assistant is producing inaccurate case summaries that lead BSA analysts to close cases they should escalate, that is a governance failure — just not an SR 26-2 governance failure.

The practical answer is to maintain two parallel governance frameworks:

An institution that applies SR 26-2 to everything AI in the AML system misreads the guidance. An institution that assumes SR 26-2 covers all AML model risk misses the framework for the GenAI features it does cover.

The Model Owner Problem in BSA Programs

One of the more common gaps examiners find when they pull model inventories for AML programs: no designated model owner.

SR 26-2 requires each model in the inventory to have a named owner responsible for model performance, documentation, and escalation. In practice, BSA programs often have a siloed structure: the BSA officer owns the compliance program, IT owns the monitoring system infrastructure, and an outside vendor handles the model. No one owns the model — the risk management artifact — in the way SR 26-2 requires.

The question examiners ask is: “If this model started generating meaningfully fewer alerts next quarter, who would notice and what would they do about it?” If the answer involves three separate departments, none of whom have a documented escalation protocol, that is a gap.

The model owner for the AML transaction monitoring system should be a named individual in the model inventory with:

• Access to alert volume and disposition trend data
• Authority to initiate threshold review or request revalidation
• Documented escalation path to BSA officer and model risk management
• Accountability for ensuring ongoing monitoring is occurring at the required cadence

This does not require restructuring the BSA program. It requires designating someone, documenting it, and making sure that person has the information and authority to act.

The SR 26-2 Governance Action List for BSA Teams

For BSA officers and model risk management teams who need to close the gap before the next examination cycle:

1. Audit your model inventory for AML entries. Confirm your transaction monitoring system is in the inventory with a complete entry: model type, vendor (if applicable), materiality tier, designated owner, last validation date, validation type (full, targeted, ongoing monitoring), and next scheduled review.

2. Pull the last four quarters of alert volume data. Compare quarter-over-quarter alert rates by alert type. Document the trend. If rates have moved meaningfully, document whether there is a business explanation — and if there is not, schedule a validation review before the examiner asks.

3. Document threshold justification. For every alert threshold in your monitoring configuration, create a rationale document: the business reason for the threshold, when it was last reviewed, what data supported it, and who approved it. For ML-based systems, document the score cutoff justification and the testing done when it was set.

4. Review vendor validation materials. For third-party systems, document your institution’s review of vendor-provided validation. The review should address whether the vendor validation was conducted on a portfolio similar to yours, whether the model performs appropriately for your product mix, and any limitations the vendor identified.

5. Map GenAI features to a separate governance framework. If your AML platform has added GenAI or LLM-based features, identify them and route them to your AI governance framework rather than treating them as in-scope for SR 26-2. Document the governance approach for each feature.

6. Establish quarterly monitoring cadence. Implement or formalize a quarterly monitoring process with documented outputs: alert rate report, disposition rate analysis, threshold performance review, and model owner sign-off. The documentation should be examiner-ready — not just internal dashboards, but a documented record of what was reviewed, what was found, and what actions were taken.

So What?

The Canaccord Genuity enforcement action is a useful reminder that BSA failures have human dimensions. Employees can know about suspicious activity and choose not to report it. Training, supervision, and escalation culture matter.

But the examiner’s next question — after the SAR filing statistics — is about the monitoring infrastructure. Did the system catch what it should catch? Can you prove it? When did you last validate it? Who owns it?

SR 26-2 sharpened those questions. The materiality-based tiering, the ongoing monitoring standard, and the third-party accountability provision all apply to your AML transaction monitoring system. BSA programs that have treated model governance as a model risk management team problem, disconnected from the compliance program, will face examination friction.

The connection is not academic. An AML model that drifts and misses alerts produces missing SARs. Missing SARs produce the same examination outcome whether the cause is human failure or model failure — the BSA program failed to detect and report. The difference is in the remediation, and in whether the institution can show an examiner the governance evidence that the model was performing as expected.

The AML/BSA Risk Assessment Template includes a model governance section with documentation requirements for transaction monitoring systems under SR 26-2, including threshold justification templates, quarterly monitoring checklists, and vendor validation review frameworks. See it here.

Sources:

• Federal Reserve / OCC / FDIC: SR 26-2 / Interagency Guidance on Model Risk Management (April 2026)
• Baker Tilly: Updated Interagency Guidance on Model Risk Management
• Stout: Modernizing AML Transaction Monitoring Model Risk Management
• Ankura: Validating Models Under SR 26-2 — What Changes for Regional and Community Banks
• FSB: Consultation on Sound Practices for Responsible Adoption of AI (June 2026)