SR 26-2 vs Interagency Third-Party Risk Guidance: Who Owns Vendor AI Model Risk?

Scope and status: model-based versus relationship-based

SR 26-2, the Revised Guidance on Model Risk Management, was issued on April 17, 2026 by the Board, OCC and FDIC. It supersedes SR 11-7 and SR 21-8. Its vendor section covers vendor and other third-party products, including data, parameter values or complete models. It says these can present unique challenges for validation and other model risk management activities, but that the principles of model risk management still apply.

The interagency guidance on third-party relationships, final as of June 2023, is organized around the relationship. It covers any business arrangement between a banking organization and another entity, by contract or otherwise, and sets out principles for all stages of the relationship life cycle. It also notes that third parties using new technologies may present elevated risks.

That difference in unit of scope is why a vendor AI model can fall under both. As a model, it sits within model risk management. As a service delivered under a business arrangement, it sits within third-party risk management. This is an inference from how each document defines its scope. Whether a particular AI service is a "model" under SR 26-2 is a judgment each institution has to make and document.

Status matters for how you describe expectations. Both documents are supervisory guidance, not enforceable standards. The FDIC release states that the revised model risk guidance sets no enforceable standards or prescriptive requirements and that non-compliance will not result in supervisory criticism. The 2023 guidance imposes no new requirements. As of November 2026, the agencies have proposed to rescind and replace the 2023 guidance, with the proposal published on September 15, 2026. It is not final, so the 2023 text remains the reference point. It is sound practice to describe examiner expectations as sound practice, not as mandates.

Side-by-side: what each framework says about vendor models

The table maps the two frameworks to the questions a risk committee usually asks about a vendor AI model. Entries reflect the language of each document. They do not assume any AI-specific provisions.

• Unit of scope: SR 26-2: models, including vendor products such as data, parameter values or complete models. Interagency guidance: any business arrangement with another entity, by contract or otherwise.
• Status: SR 26-2: issued April 17, 2026; supervisory guidance, not enforceable standards. Interagency guidance: final June 2023; supervisory guidance imposing no new requirements; replacement proposed September 2026 and not final as of November 2026.
• Responsibility when a vendor is used: SR 26-2: each organization is ultimately responsible for practices that are appropriate and effective for its risks. Interagency guidance: using third parties does not diminish responsibility, to the same extent as if the activity were performed in-house.
• Validation versus due diligence: SR 26-2: validation of vendor products, by internal or outside parties, is an important element. Interagency guidance: due diligence assesses the third party's ability to perform as expected, adhere to the institution's policies, comply with laws and operate safely.
• Inventory and documentation: SR 26-2: an inventory with enough information to understand risk individually and in aggregate, and documentation that supports effective model risk management. Interagency guidance: principles applied across all stages of the relationship life cycle.
• Proportionality: Both are risk-based. SR 26-2 is tailored to the model risk profile and the institution's size and complexity. Interagency oversight and due diligence are proportionate to the risk of the relationship and the institution's risk appetite.

Institution, vendor or shared: where accountability lands

The two documents agree on the principle that matters most. The institution is accountable. A vendor can supply the model, the data or the service, and it can support validation or due diligence, but the banking organization cannot transfer the obligation to operate safely and soundly. Where the institution cannot inspect a vendor model's internals, SR 26-2 does not remove the expectation. It acknowledges the difficulty and keeps the principles in place. It also expects that external resources used to help manage model risk are overseen and integrated into the broader model risk program.

In practice, responsibility is shared in execution and held by the institution in accountability. The vendor performs the work it controls. The institution decides whether that work is adequate for its use and keeps the records that show it made that decision.

The documents stop short of assigning internal owners, so the following split is practitioner design. Model risk management owns the inventory standard, the validation approach for the vendor product, and oversight of any outside validators. Third-party risk management owns relationship due diligence, contract review and ongoing oversight proportionate to risk. The business owner owns the use case, accepts residual risk, and triggers re-assessment when use extends beyond the original application, which SR 26-2 says calls for additional analysis of the new usage and its limitations. Technology owns the integration points and the technical enforcement of approved use.

Duplicated effort tends to appear when two teams each assess the same vendor with different questionnaires. Gaps appear when each team assumes the other holds the record. A single linked entry that ties the model inventory record to the third-party relationship record, with a named owner for each part, addresses both.

Where runtime enforcement fits, and where it does not

Validation and vendor due diligence are the core obligations, and runtime controls do not replace them. Neither framework treats runtime enforcement as a substitute for validating a vendor product or for assessing a third party's ability to perform. What a runtime layer can do is narrower. It can enforce the institution's approved-use policy on individual interactions and tool calls and produce records of what happened.

Trussed operates in that part of the problem. It enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, or escalate for human approval. The enforcement itself generates audit-ready evidence, so the record of what the AI was allowed to do and what it did is produced at runtime, not reconstructed after the fact. That evidence can support the ongoing monitoring and documentation expectations for interactions that pass through the path. It does not cover interactions outside it, and it does not address model provenance or lineage, which Trussed does not provide. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. Its deepest experience is in insurance, a regulated financial sector.

For a risk leader, the practical test is whether the approved-use decision made by model risk, third-party risk and the business owner is enforced where the vendor model is actually called, and whether the resulting records can be tied back to the inventory entry. If the answer depends on manual review after use, the control is weaker and the evidence is thinner.