Do Bank Fraud Detection Models Fall Under SR 26-2?

What SR 26-2 says about the model definition and scope

SR 26-2, Revised Guidance on Model Risk Management, is dated April 17, 2026. The OCC issued updated guidance the same day and states that it rescinds prior model risk management guidance and other issuances. It is supervisory guidance, not a rule.

The guidance describes models as simplified representations of real-world relationships among observed characteristics, values and events. They rest on assumptions that make them useful for estimating values and predicting events, and those same assumptions create limitations and model risk. Model risk is the potential for adverse financial consequences from decisions made based on model output.

Three scope statements matter for fraud teams. Practices should be risk-based, tailored and commensurate with an organization's size, complexity and extent of model use. The guidance may be useful for any type of model but is expected to be most useful for models supporting significant business lines, operations, services and functions. And it is expected to be most relevant to banks with over $30 billion in total assets. Models at banks with $30 billion or less are typically subject to internal practices suited to their size and risk profile, though the guidance can still be relevant where model prevalence, complexity or non-traditional activities create significant exposure.

The definition is functional. A fraud tool does not leave scope because it is labeled an operational control. OCC Bulletin 2019-37 itself lists models, monitoring systems and reports designed to detect fraudulent activity among detective controls, so the two labels are not mutually exclusive.

A working classification for fraud detection approaches

The guidance text does not classify fraud tools by technique, so the table below is a reasoned starting position drawn from the definition and from use and materiality. It is practitioner judgment, not a regulator statement. Each row should be confirmed in your own scoping record.

• Statistical scoring (for example, logistic or risk scores): Likely in scope. It estimates the likelihood of fraud from observed characteristics and rests on assumptions.
• Machine learning classifiers: Likely in scope. They predict fraudulent events from learned relationships. Frequent retraining raises monitoring and change-control questions.
• Vendor-supplied scoring or ML components: Same test as internal tools. Who built the tool does not change whether it meets the definition. Record the vendor component in the scoping decision.
• Deterministic threshold rules: Borderline. Value or pattern thresholds with no estimation or prediction may fall outside the definition, but the decision needs a written basis.
• Rules engines combined with a score: Depends on use. Where a rule consumes a model score, the score is the model and the rule is part of how its output is used.
• LLM-assisted triage or agentic components: Depends on use. The OCC describes generative and agentic AI as novel and rapidly evolving. Treat as a distinct governance question and decide by function and materiality.

Rules engines: excluded from inventory is not excluded from testing

Deterministic rules are where scoping decisions diverge most. One public commenter reads SR 26-2 as excluding deterministic rule-based processes from the model definition. A commenter's reading is not agency text, and it sits alongside other supervisory material that points the other way on testing.

A 2021 interagency statement on BSA/AML systems said that systems identifying cash, wire or other activity over value thresholds likely would not be considered models, while some other systems might be. It also said that whatever a bank calls a system, its risk management should be consistent with safety and soundness and promote legal compliance. That statement predates SR 26-2, so its current standing is a point to settle internally before relying on it. The FFIEC BSA/AML manual separately expects filtering parameters to be reviewed before implementation and periodically tested, and the monitoring system's programming methodology and effectiveness to be independently validated. Those are suspicious-activity monitoring expectations, not fraud-specific scoping rules, but they show the same pattern.

The practical conclusion is to separate two decisions. The first is whether a rules engine belongs in the model inventory. The second is what testing, parameter review and effectiveness assessment it receives regardless. A bank that excludes a rules engine from the inventory and keeps no evidence of threshold testing has taken the weakest position available. A bank that records the exclusion rationale and maintains separate testing evidence has a position it can explain.

Retraining, vendors and AI components in the scoping record

Fraud models are often retrained frequently and often include vendor-supplied components. The scoping record should state which components change, how often and who approves the change. This matters because a classification made at one point in time can become stale if a rules engine later adds a score, or if a vendor adds a machine learning feature behind the same interface.

Treat LLM-assisted components deliberately. Public commenters read SR 26-2 as covering traditional quantitative models and non-generative, non-agentic AI, while the OCC release calls generative and agentic AI novel and rapidly evolving. Those two statements do not settle where LLM-assisted fraud triage lands. A defensible approach is to scope the component by what it does. If it summarizes a case for an analyst, the exposure differs from one where it recommends a hold, a decline or an escalation. Record that function, the materiality and the oversight in place, and revisit the decision as the guidance is applied in supervision.

Runtime evidence for AI-assisted fraud decisions

Scoping answers whether a tool is governed as a model. Examiners may also want to see how an AI component behaved in production. Whether and how they request this is not established in the guidance, so treat the following as practitioner judgment rather than a stated expectation.

For a fraud decision that involved an AI component, a useful record shows what the component was permitted to do, what inputs it received, which tool calls it made, and what was allowed, redacted or blocked. That record complements the inventory, validation and monitoring activities. It does not replace them. Validation addresses whether the model is conceptually sound and performing. A runtime record addresses what happened in a specific interaction.

This is where policy enforcement in the execution path applies. Trussed enforces policy in the execution path of AI interactions and tool calls, with actions to allow, redact or block, and produces audit-ready evidence from that enforcement. Policy is enforced at runtime, not reviewed after the fact. Trussed does not replace model validation, model inventory or model lineage. Its depth is in insurance, a regulated financial sector, and it supports regulated enterprises that must show what their AI was allowed to do and what it did.