A vendor's AI agent is still the bank's model risk under SR 11-7. The guidance expects vendor products to sit inside the same framework: the bank obtains developmental evidence, validates its own use on its own data, documents customisation, monitors outcomes, and plans for the vendor or model disappearing. Opacity calls for more testing, not less.
What does SR 11-7 say about vendor models?
SR 11-7 addresses vendor and other third-party products directly. In substance:
- Vendor models should be incorporated into the bank's model risk management framework and follow the same principles as models built in-house.
- Banks should require vendors to provide developmental evidence: what the product's components are, how it was designed, and its intended use, so the bank can judge whether it suits its products, exposures and risks.
- Vendors should supply testing results showing the product works as expected, and state its limitations and assumptions.
- The bank should validate its own use of the product, even where the vendor's proprietary design limits what it can see, using techniques such as sensitivity analysis and benchmarking where full access is not possible.
- Ongoing monitoring and outcomes analysis should use the bank's own outcomes.
- Customisation choices the bank makes should be documented and justified.
- The bank should have contingency plans for when a vendor product is no longer available or supported.
For the scope question, see does SR 11-7 apply to AI agents.
Who does it apply to?
Banks supervised by the Federal Reserve and the OCC, and FDIC-supervised banks under the same approach. It covers both cases that arise with agents: an agent bought from a vendor, and an agent the bank builds on a language model from a model provider.
What does this mean for agents in practice?
Third-party agents involve two vendor layers, and SR 11-7 reaches both.
The agent vendor. If you buy an agent, the vendor supplies its design: the brief, the default tools, the limits it ships with. Ask for developmental evidence: what the agent is designed to do, what it was tested on, where it is known to fail. Then validate it as you will run it, on your own cases.
The model provider. Whether you buy an agent or build one, a language model sits inside it. The model provider will not open its model to you. SR 11-7's answer to opacity is testing the behaviour you rely on, with your data, and monitoring whether it changes. A model provider can change its model without your involvement, so detecting changes and retesting after them becomes a core control.
Customisation is the bank's. Agents are almost always customised: the brief is edited, sources are connected, limits are set. Each choice changes behaviour. SR 11-7 asks that customisation be documented and justified, which for agents means versioning the brief, recording the sources and their trust level, and recording why each limit sits where it does.
Contingency is concrete. If the vendor fails or the model is withdrawn, what happens to the work the agent was doing? The answer should be specific: which agents stop, which work returns to staff, how quickly, and what records the bank retains.
Take an illustrative case. A US community bank buys a vendor agent to handle online account opening queries and document collection. The vendor provides a design summary and test results on its own data. The bank's validation replays the agent on several hundred of its own past applications and finds it requests unnecessary documents from sole proprietors. The bank documents a brief change to fix this, records the agent's limits, sets daily checks for model version changes, and writes a contingency plan returning document collection to branch staff within a day if the vendor fails.
How do you meet SR 11-7 for third-party agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Inclusion in framework | Vendor agents and underlying models in the inventory | Inventory entries with vendor and model fields |
| Developmental evidence | Vendor design, intended use and test results obtained | Vendor documentation file |
| Limitations disclosed | Vendor's known limits recorded and reflected in restrictions | Limitations log |
| Validation of own use | Testing on the bank's own cases in the bank's configuration | Validation report |
| Opacity compensated | Sensitivity tests and benchmarking against staff | Sensitivity and benchmark results |
| Customisation | Brief, sources and limits versioned and justified | Customisation record |
| Change detection | Model and agent version changes detected; retesting triggered | Change log; retest results |
| Monitoring and outcomes | Monitoring with the bank's own outcomes | Monitoring reports |
| Contingency | Plan for vendor or model withdrawal | Contingency plan and test |
What will examiners ask?
- Which agents and models come from vendors, and are they all in the inventory?
- What developmental evidence did the vendor provide?
- How did you validate the agent on your own cases?
- How would you know if the model provider changed the model?
- What customisation did you make, and why?
- What is your contingency plan if the vendor fails?
What does SR 11-7 not cover?
It treats the vendor relationship through a model risk lens only. Contracts, due diligence, data handling and exit are covered by third-party risk management guidance. Banks with EU operations also face DORA, which can treat agent providers as ICT third-party service providers; see DORA makes agent providers ICT third parties and DORA ICT third-party risk when your agent runs on a vendor platform. The EU AI Act adds its own provider and deployer split, covered in the EU AI Act and third-party agents you buy. For the full map, see our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme is itself a vendor platform, and is built for this scrutiny. Attest validates each agent on the bank's own cases, not ours; we never update model weights for a customer, so customisation lives in the versioned brief, sources and bounds; and every verdict is filed in an append-only record the bank can produce without us.
Questions people ask
Can a bank rely on a vendor's validation of its agent?
It can use the vendor's evidence as input, but SR 11-7 expects the bank to validate its own use. The vendor tested on its own cases and configuration, not the bank's.
Is a language model from a model provider a vendor model under SR 11-7?
Yes, in substance. It is a third-party product whose outputs feed the bank's decisions through the agent. Record it, test the behaviour you rely on, and monitor for changes.
How much access to the vendor's design should a bank insist on?
Enough to judge suitability and limitations. Where proprietary limits apply, compensate with more testing on your own cases, sensitivity analysis and benchmarking against staff.