SR 26-2 Glossary: Key Terms for Bank Risk Officers and Model Validators

What changed, and what the guidance does not cover

On April 17, 2026 the FDIC, OCC and Federal Reserve issued revised model risk management guidance and rescinded the existing guidance. The Federal Reserve issued it as SR 26-2, Revised Guidance on Model Risk Management. It discusses the factors that influence model risk, the features of effective model development and use, model validation and monitoring, and governance and controls. It also states that model risk management should be tailored to the size, complexity and model risk profile of the banking organization.

Two practical consequences follow. First, internal policies that cite the earlier guidance should be reviewed against the revised text, particularly where older wording was carried forward. Second, a footnote states that generative AI and agentic AI models are novel and rapidly evolving and are not within the scope of the guidance. That does not prevent a bank from applying model risk practices to such systems voluntarily. It does mean a bank should not describe those systems as covered by SR 26-2, and should document its own treatment of them separately.

The entries below follow the model lifecycle. Each gives a definition, what it means for practitioners, and the records that typically support it.

Scope and inventory terms

Model. SR 26-2 defines a model as a complex quantitative method, system or approach that applies statistical, economic or financial theories to process input data into quantitative estimates. The definition excludes simple arithmetic calculations, such as those within spreadsheets, and deterministic rule-based processes and software that have no statistical, economic or financial theories underpinning their design or use. For practitioners, this is the inventory test. Supporting evidence is a written rationale for each borderline system explaining why it was included or excluded.

Model inventory. The inventory is the bank's record of the systems it treats as models. Its value depends on consistent application of the definition. Examiners reviewing it would reasonably look for the criteria used, the rationale for exclusions, and evidence that the list is kept current as systems are added or retired.

Tailoring. The guidance scales expectations to the bank's size, complexity and model risk profile. Many banks implement this through internal risk tiers. Tiering is a bank-defined mechanism, not a term the guidance prescribes here, so the criteria and the link between tier and validation depth should be written down. The supporting evidence is documentation showing how tailoring was decided and applied.

AI scope footnote. Generative AI and agentic AI models are outside SR 26-2. The practical entry in the inventory is a bank decision: which internal policy governs these systems, and where that decision is recorded.

Development and use terms

Model risk. In practice, model risk is the possibility that a model is wrong, or used in a way it was not designed for, and that decisions based on its output cause harm. The guidance discusses the factors that influence it, which is why tailoring is tied to a model risk profile and not to size alone. Practitioners should be able to show how those factors were considered for each model in scope.

Model development and use. The guidance describes features of effective development and of use. For validators, the key point is that use is part of the lifecycle. A model that is sound at approval can still carry risk if it is applied outside its intended purpose. Supporting evidence includes documented intended use, approval records, and the controls that keep use within that purpose.

Model limitations. An effective ongoing monitoring plan may include regularly assessing model limitations at development and over time, with procedures for responding to issues before and after approval for use. Treat limitations as a living record. A limitation noted at development and never revisited is a weak entry. Evidence is a dated list of limitations, who assessed them, and what response followed.

Validation and effective challenge terms

Validation. Validation is the set of activities that evaluates whether a model performs as intended and within the bank's risk tolerance. Its elements can identify material errors or persistent deviations outside the bank's established performance thresholds. Validation reports should state scope, methods, findings and the status of each finding.

Outcomes analysis. This compares model outputs with actual results. It is tied to performance thresholds the bank sets itself, so the thresholds are evidence in their own right. Keep the threshold values, the rationale for them, the deviations observed, and the responses taken.

Performance thresholds. Thresholds should be defined before results are reviewed and changed only through a recorded decision. A threshold revised after a breach, with no explanation, undermines the monitoring record.

Effective challenge. SR 26-2 describes effective challenge as critical analysis conducted by objective experts who evaluate model risk and effect appropriate changes throughout the model lifecycle, from development to ongoing monitoring. The 2017 FDIC adoption of the earlier guidance quoted it as critical analysis by objective, informed parties who can identify model limitations and assumptions and produce appropriate changes. The wording differs, and internal policies often retain the older phrasing. Align the policy with the current text. Evidence that challenge operates in practice includes the challenger's independence from developers, the issues raised, the changes made, and records of issues that were not accepted, with reasons.

Ongoing monitoring and governance terms

Ongoing monitoring. Monitoring covers both the assessment of model limitations over time and the procedures for responding to issues. Evidence includes the monitoring plan, the metrics and thresholds, results by period, and the escalation path used when results fell outside thresholds.

Governance and controls. The guidance states that all components of the model lifecycle benefit from model governance supported by clear policies and effective controls. A policy states intent. A control is what makes the intent operate. Examiners are likely to look for the second, so each policy statement should map to a control that can be shown to have run.

Documentation. Documentation supports continuity of operations. It includes tracking recommendations, responses and exceptions, and it helps manage remediation. Depth should scale with the bank's size, complexity and model risk profile, and the scaling should itself be documented.

Internal audit. Internal audit's role is generally to evaluate whether model risk management practices are rigorous and effective and whether related policies are implemented accordingly. It depends on the same records validators produce, so gaps in monitoring evidence surface here first.

Where runtime policy enforcement bears on these terms

The terms with the closest connection to runtime behavior are ongoing monitoring, controls over use, and documentation. SR 26-2 does not describe runtime enforcement, and it does not cover generative or agentic AI. Any link between the two is the bank's own interpretation. Where a bank chooses to apply model risk practices to AI-enabled systems, the question is what evidence shows the controls operated, not only that they were designed.

Trussed enforces policy in the execution path of AI systems, across models, agents, tools, MCP servers and coding assistants. Actions are allowed, redacted, blocked, rate limited or escalated for human approval, at the level of individual interactions and tool calls. Because policy is enforced at runtime, not reviewed after the fact, each enforcement decision produces audit-ready evidence as a by-product. That evidence can support a bank's records for controls and monitoring. It does not replace validation, outcomes analysis or effective challenge, which remain human and analytical activities.

Trussed is deepest in insurance, a regulated financial sector, and its evidence is mapped to frameworks including NIST. It runs self-managed in the customer cloud, with configurable retention and data residency.