Foundation Model Vendor Oversight for Banks: A Governance Checklist
Foundation model vendor oversight means applying existing third-party risk management and model risk frameworks (interagency guidance, SR 11-7, PRA SS2/21, EBA outsourcing guidelines) to vendor products built on foundation models, with added controls for opacity, post-deployment drift, fourth-party dependencies, and integration-layer risks such as prompt injection and tool-call misuse. No regulator currently defines a separate "foundation model vendor" category, so banks must document how they extend current frameworks to cover these engagements, both at procurement and throughout the vendor relationship.
Four Oversight Pillars for Foundation Model Vendors
Extending existing third-party and model risk frameworks to foundation model vendors works best as a continuous lifecycle rather than a single approval gate. The four pillars below map to that lifecycle, from initial due diligence through ongoing production monitoring.
- 1
Due Diligence
Pre-procurement assessment of model transparency, criticality, and fourth-party dependencies.
- 2
Contractual Controls
Audit rights, update notification, and data usage terms negotiated before signing.
- 3
Runtime Controls
Least-privilege access, logging, and segmentation for how the model connects to bank systems.
- 4
Ongoing Monitoring
Recurring review of model behavior, updates, and incidents across the vendor lifecycle.
Regulatory Reference Points
None of the sources below define a distinct category for foundation model vendors. Each is written for third-party technology relationships and model risk generally, and each already applies to vendor products that happen to be built on foundation models.
Interagency Guidance on Third-Party Relationships (2023)
Issued jointly by the OCC, Federal Reserve, and FDIC. Formalizes a lifecycle of planning, due diligence, contract negotiation, ongoing monitoring, and termination, applicable to any technology service provider.
SR 11-7 and OCC Bulletin 2011-12
Require banks to understand the conceptual soundness and limitations of vendor-supplied models, even when the vendor withholds full technical detail. This obligation is harder to satisfy with foundation models and more important to document.
PRA/FCA Supervisory Statement SS2/21 (UK)
Requires firms to maintain a register of outsourcing arrangements and assess concentration risk, with enhanced expectations for critical or material outsourcing.
EBA Outsourcing Guidelines (2019)
Require a pre-outsourcing risk assessment and an ongoing register, applicable to cloud and technology providers generally, including those embedding foundation models.
NIST AI Risk Management Framework and Generative AI Profile (2024)
Voluntary reference points for identifying risks across the AI lifecycle, including those introduced through third-party and supply-chain components.
Why Foundation Models Change the Third-Party Risk Equation
Banks have managed vendor risk for decades using established third-party risk management (TPRM) processes. The June 2023 interagency guidance from the OCC, Federal Reserve, and FDIC formalized this into a lifecycle of planning, due diligence, contract negotiation, ongoing monitoring, and termination, applicable to any technology service provider. Foundation models embedded in vendor products do not require a new framework so much as an extension of this one. What changes is the nature of what banks are being asked to trust. Traditional software vendors ship deterministic code that behaves predictably given the same inputs. Vendors embedding foundation models introduce components that are probabilistic, frequently updated by the vendor without the bank's direct involvement, and often opaque with respect to training data, weights, and fine-tuning history. Federal Reserve SR 11-7 and OCC Bulletin 2011-12 already state that banks remain responsible for understanding the conceptual soundness and limitations of vendor-supplied models even when full technical detail is withheld. Foundation models make that obligation harder to satisfy and more important to document.
Ongoing Oversight After Deployment
Procurement approval is not the end of the oversight obligation. Because foundation models may be updated by the vendor more frequently than traditional software releases, banks need a recurring review cadence rather than a one-time assessment. This means periodically re-verifying model behavior against the original risk assessment, confirming that update notification commitments are being honored, and reviewing logs of prompt, output, and tool-call activity for anomalies. Internal ownership should be assigned across risk, technology, and the relevant business line, not only for initial approval but for continuous monitoring of vendor model behavior. Traditional model risk validation, built around deterministic statistical models under frameworks like SR 11-7, requires adaptation for non-deterministic foundation model outputs. Runtime governance tooling that enforces least-privilege access, monitors tool-call activity, and produces audit-ready logs can support this ongoing obligation, but it supplements rather than replaces the underlying TPRM and model risk processes already required of the bank.
Fourth-Party Risk and Regulatory Alignment
UK and EU regulators reinforce the same lifecycle logic. The PRA/FCA supervisory statement SS2/21 requires firms to maintain a register of outsourcing arrangements and assess concentration risk, with enhanced expectations for critical or material outsourcing. The EBA's 2019 outsourcing guidelines require a pre-outsourcing risk assessment and an ongoing register, applicable to cloud and technology providers generally. None of these sources name foundation models specifically, and banks should treat that gap as a documentation requirement rather than a reason to relax scrutiny. NIST's AI Risk Management Framework and its 2024 Generative AI Profile provide voluntary but useful reference points for identifying risks across the AI lifecycle, including those introduced through third-party and supply-chain components. Board and senior management oversight expectations under existing interagency third-party guidance extend naturally to AI-enabled vendor products, which means risk appetite, escalation paths, and fourth-party dependency mapping should be documented with the same rigor applied to any other critical outsourcing arrangement.
Pre-Procurement Checklist
Before a foundation model vendor is approved, document how the following points are addressed within your existing third-party and model risk frameworks.
- Assess vendor transparency regarding training data, weights, and fine-tuning history to the extent it can be documented.
- Map fourth-party dependencies and evaluate concentration risk before signing.
- Confirm contractual commitments on update notification and audit rights.
- Document how existing frameworks, including SR 11-7 and OCC Bulletin 2011-12, apply to this specific engagement.
- Assess criticality and materiality consistent with PRA/FCA SS2/21 and EBA outsourcing guidelines.
- Reference the NIST AI RMF and 2024 Generative AI Profile as voluntary guidance for identifying AI-specific risks.
Post-Deployment Monitoring Checklist
Because vendor updates and model outputs are non-deterministic, ongoing monitoring requires a recurring cadence rather than a single point-in-time review.
- Establish a recurring review cadence rather than treating approval as a one-time assessment.
- Re-verify model behavior periodically against the original risk assessment.
- Confirm that vendor update notification commitments are being honored.
- Review logs of prompt, output, and tool-call activity for anomalies.
- Assign internal ownership across risk, technology, and the business line for continuous monitoring.
- Adapt model validation practices for non-deterministic outputs, beyond traditional SR 11-7 statistical validation.
- Maintain an outsourcing register with concentration risk assessment consistent with SS2/21 and EBA guidelines.
- Document board and senior management oversight, escalation paths, and risk appetite for AI-enabled vendor products.
Frequently Asked Questions
Do regulators define a specific category for foundation model vendors?
No. Interagency third-party guidance, SR 11-7, PRA SS2/21, and the EBA outsourcing guidelines do not name foundation models specifically. Banks should treat that gap as a documentation requirement, showing how existing frameworks are extended to cover these engagements, rather than a reason to relax scrutiny.
Does a bank need an entirely new risk framework for these vendors?
Generally no. Foundation model vendor products fit within the existing TPRM lifecycle of planning, due diligence, contracting, ongoing monitoring, and termination. What changes is the depth of diligence required around opacity, update frequency, and fourth-party dependencies.
What is different about ongoing monitoring compared to traditional software vendors?
Foundation models may be updated by the vendor more frequently than traditional releases, and their outputs are probabilistic rather than deterministic. This calls for a recurring review cadence, log review of prompt and tool-call activity, and adapted model validation practices, rather than a one-time approval.
What role can runtime governance tooling play?
Runtime governance tooling can enforce least-privilege access, monitor tool-call activity, and produce audit-ready logs. It supports the ongoing monitoring obligation but supplements rather than replaces the underlying TPRM and model risk processes already required of the bank.
Extend Your Existing TPRM Framework to Foundation Model Vendors
Runtime governance can help enforce least-privilege access, tool approval, and audit logging for vendor-integrated foundation models once they are in production.
Request a Demo