SR 26-2 Model Definition: What Counts as a Model and What Falls Outside It

Definition and scope are two separate determinations

The most common source of inconsistent inventories is treating "is it a model?" and "is it covered?" as one question. They are different decisions, and a record should show both.

Some frameworks make the split explicit. The clearing agencies' model risk management framework, for example, defines a model in one section and then provides that only models meeting that definition and supporting the agencies' compliance with their standards are subject to the framework. A system can meet a definition and still sit outside the operative scope. The reverse error also occurs, where a team declares a system out of scope without ever testing it against the definition.

For SR 26-2, build the inventory process so that each system receives a definition result, a scope result, a named decision owner and a written rationale. That structure makes the outcome reproducible when a different reviewer, or an examiner, revisits it.

Reading the definition one component at a time

Model definitions in federal rulemaking tend to share a common structure. The 2024 automated valuation model rule describes a model as a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates. The clearing agencies adopted the same wording. That gives three components worth testing separately: a quantitative method, system or approach; theories, techniques and assumptions of a statistical, economic, financial or mathematical kind; and a transformation of input data into quantitative estimates.

This page uses that decomposition as an analytical frame, and the SR 26-2 wording should be applied to each component in the same way. For each system, write down what the method is, what theory or technique it relies on, what the inputs are, and what the output is. A vague answer on any component is a signal that the classification needs more work, not that the system falls outside the definition.

Output type deserves particular attention. NIST describes an AI system as one that generates outputs such as predictions, recommendations, or decisions influencing real or virtual environments. That is a broader framing than quantitative estimates. A system can be clearly an AI system and still be a boundary case against a definition built on quantitative estimates.

Do not borrow definitions written for other purposes

Federal texts use "model" in purpose-specific ways. The Federal Reserve's stress-test transparency rule, published October 2026, defines "model or models" as the analytical techniques the Board determines are appropriate for use in the supervisory stress test. A 2019 resolution liquidity guidance uses "Model" for the set of calculations estimating net liquidity surplus or deficit by legal entity. The valuation rule applies its definition to computerized models that estimate the value of a consumer's principal dwelling.

None of these is a classification test for SR 26-2. Importing them leads to over-inclusion or under-inclusion that is hard to defend. As of November 2026, a Federal Register document from November 2025 also describes SR 11-7 as applicable to supervised insurance organizations, which shows that supervisory letters on model risk are referenced across supervisory contexts. Classification decisions should cite the SR 26-2 text they rely on, not a neighboring definition.

Worked boundary cases for AI-enabled systems

The cases below are practitioner judgment applied to the component test. They are not statements of the SR 26-2 position, and each outcome depends on the exact definition and exclusion wording.

• Statistical scoring model for underwriting or credit: Quantitative method, statistical technique, data inputs, numeric output. Meets every component and is the clearest case for inclusion.
• Fixed rules or lookup table: Inputs and outputs are present, but there may be no statistical or mathematical theory beyond arithmetic. Test the second component and document the reasoning.
• LLM assistant drafting text: Machine-based and input-driven, but the output is prose rather than a quantitative estimate. A boundary case on the third component. If it also produces scores or classifications, reassess.
• LLM used to classify or score items: The output becomes a label or numeric estimate that feeds a business decision. This is much closer to the definition, and the decision it informs matters for scope.
• Agent with tool access: Classify the underlying model and the surrounding system separately. The actions the agent takes through tools are not settled by the model's classification.

What a scope decision does not settle

Classification determines which model risk processes apply. It does not determine what an AI system may do in production. A generative assistant classified as outside the definition can still receive sensitive data in a prompt, return it in a response, or call a tool that changes a record. The same is true of a system classified as a model.

That is the gap runtime controls address. Trussed enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, or escalate for human approval. Enforcement applies to individual interactions and tool calls. It runs at runtime, not as a review after the fact, and it applies whether or not the system sits in the model inventory.

Each enforcement decision produces audit-ready evidence, mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. For a system a team has classified as not a model, that evidence supports the rationale: it shows what the system was permitted to do and what it did. Trussed does not perform model validation and is not a model risk management tool. It addresses the runtime layer that sits beside classification.