SR 26-2 vs PRA SS1/23: US and UK Model Risk Expectations for Cross-Border Banks

What SR 26-2 establishes, as of November 2026

SR 26-2, titled Revised Guidance on Model Risk Management, was issued on 17 April 2026 as revised interagency guidance. It discusses the factors that influence model risk and the features of effective model development and use, model validation and monitoring, and governance and controls. Those three lifecycle components are a useful backbone for any cross-border comparison, because they give a common structure against which a second regime can be laid.

The guidance is explicit about its character. It states that it does not set forth enforceable standards or prescriptive requirements, and that non-compliance with it will not result in supervisory criticism. It also stresses proportionality: model risk management should be tailored to the size, complexity and model risk profile of the banking organization, and each organization is ultimately responsible for adopting practices that are appropriate and effective for its own risks. It 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.

The practical consequence is that SR 26-2 cannot be compared to another regime as a checklist. It has to be compared principle by principle, and by the evidence a bank would use to show each principle is met. PRA SS1/23 should be read the same way: against its own text, expectation by expectation, rather than through assumptions carried over from the US guidance.

Comparing the two frameworks by supervisory expectation

The table sets out the SR 26-2 position where it is clear, and the question each row should put to the PRA SS1/23 text. Record the answer to each question in a single mapping document that both US and UK model risk teams own.

• Scope and model definition: SR 26-2: applicable to any type of model, with greatest expected usefulness for models supporting significant business lines and functions. PRA SS1/23 question: does the model definition and scope match, and do AI and machine learning systems fall inside it on the same terms?
• Proportionality and tiering: SR 26-2: practices are tailored to size, complexity and model risk profile, with a policy framework for assessing the magnitude of model risk. PRA SS1/23 question: how specific is the expected tiering approach, and can one tiering method satisfy both?
• Governance and accountability: SR 26-2: governance supported by clear policies and effective controls across the lifecycle, with responsibility resting on the institution. PRA SS1/23 question: what accountability structures and named responsibilities are expected, and how do they map to existing US roles?
• Validation and monitoring: SR 26-2: validation and monitoring are named lifecycle components. PRA SS1/23 question: what independence, frequency and escalation expectations apply, and do existing validation reports satisfy both?
• AI and third-party models: Compare how each text treats AI-enabled and vendor-supplied models, including what the bank must be able to show about models it did not build.
• Status and enforceability: SR 26-2 is non-enforceable guidance. Establish how the PRA text is used in supervision, and do not assume the same posture applies to both.

Which controls and evidence can be shared, and which cannot

Most of the reuse opportunity sits in the structural artifacts. A single model inventory, one risk-tiering method with documented rationale, one model policy hierarchy and one set of validation and monitoring standards can usually serve both regimes, provided the model definition used in the inventory is the broader of the two. Where definitions differ, the inventory should carry a flag per model for each jurisdiction rather than maintaining two inventories.

Because SR 26-2 is built on proportionality, the tiering rationale is the artifact that most needs to be documented. An examiner reading a proportionate framework will ask why a model received the level of control it did. A recorded assessment of size, complexity and risk profile per model answers that question and gives the UK team the same input to test against its own expectations.

Jurisdiction-specific work tends to cluster in three places: the wording of accountability and attestation, the format and cadence of reporting to each supervisor, and any difference in how AI-enabled and third-party models must be treated. Tag each artifact in the mapping document as shared, shared with a local annex, or local only. That tag is what prevents duplicated control work and keeps documentation consistent when the two teams revise policies at different times.

Where runtime policy enforcement fits

Governance and validation programs define what a model should do. They do not by themselves produce a record of what an AI-enabled model did on a given day. That gap matters in an examination, because a policy document and a validation report are not evidence of production behavior.

Trussed addresses one part of this problem. It enforces policy in the execution path for AI interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Enforcement happens at runtime, not reviewed after the fact, and each decision generates audit-ready evidence. Trussed does not perform model validation and does not provide model lineage or dataset provenance, so it supports a model risk program rather than replacing any part of it.

The approved operating context is a regulated enterprise running in continuous production for more than 18 months, with 100+ models under one policy plane and 99.95% uptime on live production traffic. Trussed has customers in insurance, pharma, healthcare and education, and insurance is where it is deepest. It does not claim bank or other financial-services deployments, and its evidence mappings cover HIPAA, NAIC, NYDFS, EU AI Act and NIST. A bank would assess it against its own examiner requests, using the evidence artifacts above as the test.