SR 26-2 and Existing SR 11-7 Model Documentation: What Carries Forward and What Needs Updating

What SR 26-2 says about SR 11-7

SR 26-2 transmits the Revised Guidance on Model Risk Management issued by the Federal Reserve, the OCC and the FDIC. It states that it supersedes and replaces SR 11-7 (issued April 4, 2011) and SR 21-8 (issued April 9, 2021, covering systems that support BSA/AML). The Federal Reserve's SR 26-2 page is dated April 17, 2026. As of November 2026, SR 11-7 is therefore not the current guidance.

The agencies describe the revision as reflecting supervisory experience and industry feedback over the past fifteen years, along with advances in modeling practices. They say it clarifies principles and emphasizes a risk-based approach tailored to a model's risk profile and the size and complexity of the organization's operations.

For documentation and validation inventories, the first consequence is about citation. Policies, inventories and validation reports that name SR 11-7 or SR 21-8 as the governing standard now point at superseded guidance. A changed citation does not say anything about the quality of an artifact, though. The useful test is whether its content supports what SR 26-2 asks for.

What the SR 26-2 text emphasizes

SR 26-2 states that model risk management practices vary among banking organizations and that each organization is responsible for adopting practices appropriate and effective for its own risks. Model purpose together with model exposure determines materiality, and sound practice assesses model risk both individually and in aggregate.

Validation follows the same logic. Its nature and rigor generally align with the model's approach, use and materiality. Timing, nature and frequency vary with model purpose, methodology, the frequency and scope of changes, data limitations and other practical constraints. Validation generally occurs before first use. When a model is extended beyond its original application, sound practice involves additional analysis of the new usage and its limitations, plus a review of existing controls. When performance deviates meaningfully from expectations, organizations generally consider adjustment, recalibration or redevelopment.

SR 11-7 was more specific in places. It expected validation of all model components, including vendor models, by staff not responsible for development or use. It expected ongoing validation, a periodic review at least annually, and described full validation at a fixed interval as generally good practice. Where an artifact was built around one of those specifics, test it against the SR 26-2 text for that model instead of assuming either carryover or removal. A fixed-cadence validation may be right-sized to materiality rather than thrown out.

Governance cautions during the transition

Do not drop a control because the guidance changed. SR 11-7 set expectations for board and senior management reporting, internal audit testing of update procedures, and policy language. Confirm how the full SR 26-2 text treats each before retiring any of them.

Independence needs the same care. SR 11-7 expected validation by staff not responsible for development or use. Do not weaken independence arrangements on the assumption that the revision relaxes them.

Materiality is the main lever for efficiency. If the reassessment shows a model's validation rigor or frequency exceeds what its purpose and exposure support, SR 26-2's risk-based framing gives a basis for right-sizing. If it shows the opposite, the validation belongs in the update or gap bucket. Either way, the written rationale matters as much as the outcome.

Where runtime evidence can supplement documentation for AI systems

Static documentation and periodic validation describe a model at a point in time. SR 26-2 places weight on appropriate use, limitations and extension beyond original application, which are the areas where documented intent is most likely to be compared with production behavior. For AI systems, teams may therefore want evidence of what the system was permitted to do and did. This is an interpretation, not a stated requirement of SR 26-2.

Runtime records, such as policy decisions and logged actions in the execution path, can be cross-referenced to a model's documented intended use and limits. They supplement documentation and validation. They do not substitute for validation, and they do not show whether a model is conceptually sound. To be usable, each record must map to a specific inventory entry, model version and documented intended use, and any tool's ability to do that should be confirmed against its own documentation.

Trussed enforces policy in the execution path, with actions such as allow, redact, block, rate limit and escalate for human approval, at the level of individual interactions and tool calls. Enforcement produces audit-ready evidence of what the AI was allowed to do and did. That evidence is meant to sit alongside model documentation and validation reports. It does not replace them, and Trussed does not provide model lineage or model provenance.