How Banks Should Assess Foundation Model API Vendors When SR 26-2 Excludes Generative AI

What the SR 26-2 exclusion changes and what it leaves in place

The OCC, Federal Reserve and FDIC issued updated interagency model risk management guidance on April 17, 2026 (SR 26-2 and OCC Bulletin 2026-13). It rescinds prior model risk management guidance. Footnote 3 describes generative and agentic AI as novel and rapidly evolving, then states that the principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI. A Federal Reserve speech on May 1, 2026 describes the guidance as clarified so that it does not apply to generative or agentic AI. The same speech treats third-party risk-management expectations for vendor-provided AI tools as an open question. As of November 2026, banks should expect supervisory thinking in this area to continue to develop.

The exclusion therefore removes SR 26-2 as the framework that defines how generative AI is validated. It does not remove accountability. The guidance states that each bank is ultimately responsible for adopting model risk management practices that are appropriate and effective for the specific risks it faces or is likely to face. A foundation model API in a customer-facing or decision-support workflow is such a risk, whatever the guidance says about scope.

Three starting steps follow. Inventory every foundation model API use. Record that each falls outside SR 26-2's stated application. Then write the bank's own internal standard, so that diligence is consistent across business lines and someone owns it. The guidance's treatment of vendor products is a useful reference even though it is not binding here. It acknowledges that proprietary components may mean the bank receives no underlying code, data or methodology, and says the principles still apply. It also describes understanding vendor design, development data and performance, and ongoing outcome analysis.

Vendor-side diligence: what a bank can learn from the provider

The interagency third-party relationships guidance gives a workable structure, although its excerpted text does not mention AI. Applying it to AI vendors is a reasonable reading rather than a stated requirement. Due diligence covers the third party's overall risk management, including policies, processes and internal controls. It also covers governance, roles and segregation of duties, and whether the third party's controls are subject to effective audit assessments such as independent testing and objective reporting. The use of subcontractors is a factor in the nature of the arrangement.

NIST AI 600-1, a voluntary framework, suggests updating vendor assessments for generative AI to cover intellectual property, data privacy and security. It also suggests addressing embedded generative AI technologies and ongoing monitoring, alerting and real-time reporting.

In practice, the assessment file should answer a short set of questions. What customer data is retained, for how long, and is it used for training or evaluation by the vendor or its subprocessors? How are model and version changes announced, and can the bank test or defer a replacement? Which subprocessors take part in service delivery, and how are changes to them notified? What independent audit assessments, security attestations and incident-notification commitments exist, and does the contract provide audit rights? What will the vendor document about design, data and performance, and what will it withhold as proprietary?

The last question matters most for risk acceptance. Where documentation is limited, the bank cannot close the gap through diligence. It should record the limit, assign an owner, and compensate with controls it operates itself.

Where each risk is resolved

Vendor diligence is point-in-time and vendor-side. The split below is an analytic framing, not a regulatory requirement. It helps teams decide which evidence comes from a questionnaire or contract and which must come from the bank's own systems.

• Data retention and training use: Contractual and due-diligence review. The vendor states terms; the bank negotiates and records them.
• Subprocessors and subcontractors: Contractual and due-diligence review, including notice of changes.
• Attestations, incident notice, audit rights: Due-diligence review and contract terms, refreshed on a defined cycle.
• Version and model changes: Contract notice terms plus bank-side testing before and monitoring after a change.
• Sensitive content in prompts: Bank-side runtime enforcement: allow, redact or block before content leaves the bank's path.
• Outputs and tool calls: Bank-side runtime enforcement, with escalation for human approval and retained decision records.

Bank-side controls in the execution path

A vendor can describe its controls, but it cannot decide what a specific prompt, output or tool call is permitted to do inside the bank's workflow. That decision depends on the bank's data, its customers and its risk appetite, so the control must sit in the bank's own execution path. Four outcomes cover most cases. A request is allowed. Sensitive content is redacted. A request or response is blocked. An action is escalated for human approval. Each decision is also a record, and retained records show what the AI was permitted to do and what it did. This is a design inference, since no regulator has prescribed it, but it follows from the accountability the guidance places on each bank.

The tradeoffs are real. Runtime enforcement adds a processing step, and policies that are too broad produce false positives and escalation queues that reviewers cannot clear. Policies also need an owner and version history, because a rule that changes without a record weakens the evidence it produces.

Trussed addresses this bank-side gap. It enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit and escalate for human approval. Its scope is individual interactions and tool calls. Enforcement produces audit-ready evidence, and it can be deployed self-managed in the customer's cloud with configurable retention and data residency. Trussed does not assess the vendor's internals, and it is not a substitute for due diligence.

Version changes and shared exposure

Vendor-controlled version changes deserve their own procedure. One public commenter on the interagency proposal argues that such changes can alter a service's risk profile even when the contract and internal processes are unchanged. This is a commenter's view, not agency guidance. The commenter recommends comparing the existing and replacement versions on identical inputs, using institution-defined materiality thresholds. Where feasible, differences above a threshold would trigger escalation before deployment.

A bank can build this as a replay harness. Keep a representative set of inputs for each use case, run them against both versions, and compare results against thresholds the bank sets and documents. Where the vendor gives no advance notice or no ability to defer, the harness cannot run before the change. Runtime enforcement and ongoing monitoring then become the backstop, and the contract's notification terms become more important.

The same commenter notes a concentration issue. Banks relying on the same upstream model may share exposure to a provider-driven change. Within one bank, several business lines may depend on the same model through different intermediaries. The inventory should record the upstream model, not only the contracting counterparty.