SR 26-2 AML Pipeline Scoping: ML Scoring Is In Scope, LLM Triage Appears to Be Out

What changed and why the earlier framing no longer holds

Many scoping exercises started from the assumption that an LLM, its prompts, its retrieval sources and its tool calls were all candidates for model risk management scope. That assumption needs revisiting. SR 26-2 revised the Federal Reserve's model risk management guidance in a letter dated April 17, 2026. The letter says practices appropriately vary with a banking organization's risk profile and model usage, and that it is expected to be most relevant to Fed-regulated banking organizations with over $30 billion in total assets. The guidance also ties the relevance of model risk to the nature, scale and use of models in relation to business risk.

On May 1, 2026, a Federal Reserve speaker said the Fed, together with the OCC and FDIC, had recently amended the guidance to clarify that it does not apply to generative or agentic AI, and that supervisors had expanded the earlier guidance beyond its original purpose. This is the most direct statement on LLM scope available, and it came in a speech. Document your reasoning against the final guidance text and have counsel confirm it before the LLM layer is formally classified as out of scope.

Out of scope for SR 26-2 is not the same as out of supervision. The 2021 interagency statement describes BSA/AML suspicious activity monitoring and reporting systems as critical internal controls, and names effective challenge as a central principle. The proposed AML/CFT program rule, published in the Federal Register on April 10, 2026 and not final as of November 2026, would require risk-based policies, procedures and controls reasonably designed to identify, assess, document and mitigate money laundering and terrorist financing risks. An examiner can reach an LLM triage layer through those expectations even if model risk guidance does not.

Stage-by-stage scoping of a mixed ML and LLM AML pipeline

The table gives a working position for each stage. Where the guidance is silent, the position is an interpretation to confirm, and your classification record should say so.

• ML scoring model: SR 26-2: in scope as a model. Apply ongoing monitoring of limitations, change control, documentation and effective challenge. Owner: model risk management. Evidence: validation and monitoring records, change history.
• Deterministic rules: SR 26-2: on a common reading, outside the model definition. Other framework: FFIEC examination language says surveillance monitoring systems include rule-based and intelligent systems and that their programming methodology and effectiveness should be independently validated. Owner: BSA/AML compliance. Evidence: rule logic, threshold change records, evidence of detection effect.
• Retrieval and prompt assembly: SR 26-2: not addressed specifically. Treat as part of the LLM layer and confirm with counsel. Other framework: NIST AI RMF as a voluntary reference. Owner: assign explicitly. Evidence: which sources and templates fed each interaction.
• LLM summary, priority and routing output: SR 26-2: appears excluded as generative AI. Other framework: BSA/AML program expectations and NIST AI RMF. Owner: enterprise risk, compliance or BSA/AML governance. Evidence: per-interaction inputs, outputs and policy decisions.
• Tool calls: SR 26-2: not addressed specifically. Calls that read or write case systems change what analysts see and do. Owner: technology risk with compliance. Evidence: call, parameters, policy decision, any approval.
• Analyst action and final disposition: SR 26-2: not described as a model output. Governed as part of BSA/AML monitoring and reporting controls. Owner: BSA/AML operations. Evidence: disposition, rationale, any override of an LLM-influenced priority.

Where the boundary is ambiguous and how to own it

Three ambiguities matter most for risk leaders. First, an ML score that feeds an LLM: the ML model stays in scope, but the LLM that consumes the score does not appear to be. Keep the two separate in documentation, monitoring and ownership. If the LLM re-ranks alerts, the ML model's monitoring will not show the effect, because that effect is produced downstream of it.

Second, influence without decision. An LLM that reorders a queue or suggests a routing is not making the final disposition, but it shapes what the analyst reviews first. Examiners reading a case file will want to see that influence and the analyst's independent judgment. Because no model guidance clearly governs this layer, an explicit owner under enterprise risk, compliance or BSA/AML governance prevents validation and monitoring from falling between functions.

Third, the relationship between the 2021 interagency statement and SR 26-2. The 2021 statement refers to the earlier guidance and says banks may use some or all of its principles to support an effective BSA/AML program. Whether it has been updated is unclear, so cite it for the effective challenge principle and avoid claiming more.

For components outside SR 26-2, NIST AI RMF is a reasonable voluntary reference. Its GOVERN function applies across the AI risk management process, while MAP, MEASURE and MANAGE can be applied to specific systems and lifecycle stages. No regulator is described as requiring it. Internal audit evaluates whether risk management practices are rigorous and effective. It does not replace them, so decide who tests the LLM controls before audit is asked to.

What runtime enforcement covers at the interaction and tool-call level

Runtime policy enforcement sits in the execution path between the application and the model or tool. For each LLM interaction or tool call, a policy decision is made before the action completes: allow, redact, block, or escalate for human approval. Because the decision happens at runtime rather than being reviewed after the fact, the record of the decision is produced by the enforcement itself.

In an AML pipeline this fits specific cases. Redaction can limit what customer data reaches an LLM. Blocking can stop a tool call outside an approved set. Escalation can require analyst approval before a disposition-affecting recommendation or a write to a case system proceeds. Each decision yields evidence tied to that one interaction or call.

The limits are as important. Runtime enforcement does not validate the ML model or the LLM. It does not establish model lineage or dataset provenance, and it does not trace a whole alert through every stage and agent. Those remain with model risk management, data governance and workflow-level controls. Trussed operates at this interaction and tool-call layer, enforcing policy in the execution path and producing audit-ready evidence. It is one input to an examiner file, not the file.