Fintech AI Third-Party Oversight Under SR 26-2
How SR 26-2 relates to SR 11-7, what examiners are likely to expect for third-party AI systems, and which documentation and controls compliance teams should maintain now.
SR 26-2 and the Current Verification Gap
Compliance teams researching SR 26-2 should treat the citation as a working reference pending confirmation against the Federal Reserve's official supervisory letter publications. SR letters are issued and archived by the Board of Governors, and institutions should retrieve the primary text directly from the Federal Reserve before revising internal policy language, model risk inventories, or third-party risk taxonomies around it.
This matters operationally because a compliance program built on an unverified citation can create examiner findings if the actual published language differs from what internal policy assumes. Given that gap, the remainder of this guide focuses on the oversight obligations that AI-specific third-party supervisory guidance is likely to address, grounded in the established baseline set by SR 11-7 and current interagency third-party risk guidance, so compliance teams can begin building durable controls regardless of the final SR 26-2 text.
SR 11-7 as the Existing Baseline for AI Vendor Oversight
SR 11-7, Guidance on Model Risk Management, was issued jointly by the Federal Reserve and the Office of the Comptroller of the Currency in April 2011 and remains the primary reference point for how supervised institutions govern models, including those obtained from or hosted by third parties. SR 11-7 established expectations for model validation, independent review, and ongoing monitoring, and it explicitly places vendor-supplied models within scope.
What SR 11-7 does not address, because it predates the technology, is the behavior of autonomous AI agents that make sequential decisions, invoke external tools, or produce outputs that vary between otherwise identical sessions. Traditional model risk management assumes a model produces a describable output that can be validated at a point in time. AI agents complicate that assumption because effective behavior depends on prompts, available tools, and runtime context that can shift independently of the underlying model version.
Any AI-specific third-party guidance, SR 26-2 included once its text is confirmed, is likely to build on this SR 11-7 foundation rather than replace it. Compliance teams should treat existing model risk governance as an inventory to extend rather than a framework to discard.
Technical Controls That Distinguish AI Vendor Oversight From Traditional TPRM
Traditional third-party risk management programs were built around deterministic software: a vendor ships a version, the institution reviews a SOC 2 report and a security questionnaire, and monitoring occurs on a quarterly or annual cycle. AI-enabled vendors break several of these assumptions, which is why oversight architecture needs to account for agent-level behavior rather than only vendor-level behavior.
AI-Specific Oversight Gaps in Traditional TPRM Programs
Four control areas sit outside conventional vendor due diligence and periodic reassessment cycles:
Agent Identity
Distinguishing AI agent activity from human or service-account activity in access logs.
Permissioning
Scoping AI agent tool access more narrowly than standard API credentials.
Runtime Policy Enforcement
Intercepting and evaluating tool calls before execution, not just after the fact.
Audit Logging
Capturing model version, inputs, and output decisions for non-deterministic behavior.
Documentation Compliance Teams Should Maintain
- A current inventory of vendors delivering AI or AI-agent functionality, separate from the general third-party vendor list
- Agent identity and permissioning records showing which AI agents can access which systems and tools
- Runtime policy enforcement evidence showing tool calls were evaluated against defined rules, not only logged
- Audit logs capturing model version, inputs, and outputs for material AI-driven decisions
- Contractual provisions covering model change notification, audit access, and incident disclosure with AI vendors
- Internal records distinguishing vendor-hosted model behavior from institution-configured guardrails
Frequently Asked Questions
Has SR 26-2 been confirmed as an official Federal Reserve supervisory letter?
At the time of this guide's preparation, SR 26-2 could not be independently verified as a published Federal Reserve SR letter. Compliance teams should retrieve the official text directly from the Federal Reserve before building policy around this citation.
How does AI third-party oversight differ from SR 11-7 model risk management?
SR 11-7 addresses model validation and vendor-supplied model risk broadly, but it predates autonomous AI agents. AI oversight adds requirements around agent identity, tool-call permissioning, and runtime policy enforcement that SR 11-7 does not explicitly cover.
What should a fintech do now if SR 26-2 requirements are unclear?
Extend existing SR 11-7 and third-party risk management controls to cover AI-specific behaviors now, since agent identity, permissioning, and audit logging are practical controls regardless of the exact final regulatory text.
Build AI Vendor Oversight on Verifiable Controls
Runtime governance capabilities such as agent identity, least-privilege permissioning, tool approval workflows, and audit logging give compliance teams the operational evidence examiners look for in third-party AI relationships.
Learn About AI Agent Security