Third-Party Risk Management for AI Vendors: An Interagency TPRM Playbook for Banks

Why TPRM Is the AI Topic Examiners Are Asking About First

The 2023 interagency guidance (SR 23-4 from the Fed, OCC Bulletin 2023-17, FDIC FIL-29-2023) replaced the agency-specific TPRM playbooks with one risk-based framework. The guidance does not mention AI vendors specifically, and it does not have to. The framework is generic by design. The examiner question that follows is specific: show me how you apply this framework to your AI vendors. Two years in, examiners have started opening AI-related exams with the TPRM file rather than the model file.

We are on the vendor side of this conversation every week. The diligence packs that banks send us have gone from PDF questionnaires to structured assessments with the right controls. The banks that have built this muscle close exam findings faster and ship AI workflows sooner. The framework below is what we see work.

The TPRM Lifecycle Applied to AI

The interagency guidance walks through five stages. Each looks different when the third party is an AI vendor.

Planning

The bank decides whether the activity itself is appropriate for a third-party relationship. For AI, this is a "build vs. buy" question that has to be settled before the diligence begins. We have written separately on that decision. The TPRM file should reference the build-vs-buy memo and the conclusion. Examiners want to see that the question was asked.

Due diligence and third-party selection

The diligence has to cover the standard topics — strategy, financials, business experience, qualifications, fee structure, reputation, legal and regulatory compliance, risk management, information security, operational resilience, incident reporting, physical security, human resources, reliance on subcontractors, insurance coverage, and conflicts of interest — and the AI-specific ones we will get to below.

Contract negotiation

The contract is where the controls become enforceable. The clauses an AI vendor contract needs are different in three places from a generic SaaS contract: model risk, data, and incident response.

Ongoing monitoring

This is where most TPRM programs are weakest, and it is where AI vendors break the most. Models drift, vendors change underlying foundation models, and incidents are different in kind from a generic outage. The monitoring plan has to be built for this.

Termination

The exit plan is not optional. For AI vendors, it has specific items — model and prompt portability, data return and destruction, transition support — that have to be agreed in the contract, not at termination.

The AI-Specific Diligence Pack

A standard SaaS diligence pack does not get the bank to a defensible posture. The AI-specific items we see banks build out:

Model lineage and dependency map

Which foundation models does the vendor use, from which providers, at which version. What happens when the foundation model is updated by the upstream provider. How is the vendor notified, what is their evaluation process, what is the bank's notification cadence. Programs that cannot answer this fail the first deep-dive question on AI risk.

Model validation evidence

The vendor's own SR 11-7 file for the components they own. Test sets, validation reports, monitoring evidence, change control. We tell banks: if the vendor cannot produce this, the bank's second line has to validate the entire stack. The cost shifts to the bank.

Data flow and segregation

What data leaves the bank's environment. Where it is processed. Where it is retained. Whether it is used to train any model — and the answer should be no, with a contractual prohibition. Whether the vendor's foundation model providers have the same prohibition. The data-flow diagram is the artifact.

Information security

SOC 2 Type II is table stakes, not the answer. The deeper questions: penetration testing cadence, vulnerability management evidence, encryption posture for AI-specific assets (prompts, retrieval indexes, model weights), access controls on the prompt and configuration management systems, and incident-response playbooks specific to AI failure modes.

Concentration risk

If the AI vendor is built on a single foundation model provider, the bank now has a concentration risk it may not see. The diligence has to surface the vendor's substitutability story. What happens if the foundation model provider has an outage, a price change, a policy change. We expect every AI vendor to have a documented fallback plan.

Fair-lending and UDAAP exposure

For any vendor whose AI affects a consumer credit outcome, the diligence covers the vendor's fair-lending testing methodology, the testing cadence, the less-discriminatory-alternative search, and the sign-off on the bank's own portfolio. A vendor that says "the bank owns fair lending" without producing their testing is a vendor the bank should reconsider.

Geopolitical and supply chain

Where the foundation model providers and the vendor's own infrastructure operate. Which jurisdictions the data flows through. Whether any sanctioned-party exposure exists in the supply chain. With the export-control rules tightening on advanced AI in 2024 and 2025, this question has gotten harder to answer and more important to ask.

The Contract Clauses That Matter

The contract is where the TPRM file becomes enforceable. The clauses we see banks add — and that we agree to as a vendor because they are reasonable:

• Right to audit, with reasonable notice. Including the right to inspect the vendor's controls, eval harnesses, and incident logs
• Notice of material model changes. The vendor will notify the bank within a defined window when underlying foundation models change in ways that could affect outputs
• Use of bank data prohibition. The vendor will not use bank data to train any model, including any foundation model provider's model
• Fair-lending and disparate-impact attestation. Where applicable, the vendor will attest annually to the testing it has run and provide the test artifacts
• Subcontractor management. A list of subcontractors at execution, notice of changes, and the bank's right to object to material changes
• Incident response. Specific notice triggers, timing requirements, and escalation paths for AI-specific incidents (hallucination spike, model failure, prompt injection)
• Service level agreements. Including agent uptime, latency, and the eval harness quality metrics the vendor commits to maintaining
• Records retention. Retention of all decisions, logs, and audit pack artifacts for the bank's record retention period, not the vendor's
• Data return and destruction. At termination, a defined process and timeline
• Indemnification, with carve-outs for regulatory exposure. AI vendors will not indemnify the bank for the bank's own fair-lending exposure, but they will indemnify for breaches of their own controls

A bank that gets these clauses into the contract is in a different position at the first incident than a bank that did not.

The Ongoing Monitoring Plan

The monitoring plan is the part of the file most programs underbuild. For an AI vendor, the cadence we recommend:

Monthly

• Vendor's eval harness output on a representative production sample
• SLA performance: uptime, latency, error rates
• Incident log review
• Open issue review

Quarterly

• Fair-lending and disparate-impact metrics on the bank's portfolio
• Hallucination and citation-coverage metrics
• Change log review of every prompt, retrieval source, and configuration change
• Sample audit of the vendor's QA reviews

Semi-Annually

• Refresh of the financial health assessment
• Refresh of the information security assessment
• Refresh of the concentration risk and substitutability analysis
• Tabletop exercise on incident response

Annually

• Full TPRM re-assessment
• Independent validation of the vendor's model risk file
• Renegotiation of any expired clauses

The cadence becomes routine after the first cycle. The first cycle is the heavy lift. Banks that try to do annual-only monitoring on AI vendors are the ones who discover the problem in a quarterly portfolio review three quarters late.

Concentration Risk Done Specifically

Concentration risk is the part of the 2023 guidance that most TPRM programs apply to payment processors and ignore for technology vendors. For AI, this is a mistake.

The concentrations we track for our bank clients:

• Foundation model concentration. What percentage of the bank's AI workload depends on a single foundation model provider. We have seen this go from 0 to 80 percent in 18 months at fast-moving programs.
• Vendor concentration. What percentage of the bank's AI workloads are on a single vendor. The cost of pulling a vendor is high; the cost of being unable to is higher.
• Infrastructure concentration. What cloud providers the vendor's vendor relies on. A bank that has done the careful work to be multi-cloud may discover its AI vendor is single-cloud.
• Skill concentration. Inside the bank, whether the AI program has key-person risk on a single team member or vendor relationship manager.

The mitigation is not "do not concentrate." It is to know the exposure, set a tolerance, and have a documented plan for what happens at each tolerance breach.

What an Incident Looks Like for an AI Vendor

The TPRM file should pre-define what an incident is. For AI vendors, the incident categories that need notice triggers:

• Hallucination rate spike beyond the contracted threshold
• Citation-coverage drop beyond the contracted threshold
• Foundation model version change without prior notice
• Disparate-impact metric anomaly on the bank's portfolio
• Data leakage event involving bank data
• Prompt injection or other adversarial exploitation
• Sub-processor change or compromise
• Material change in the vendor's financial condition

Each of these has a notice window, a remediation expectation, and an escalation path. The bank's vendor manager wakes up to the alert; the vendor doesn't decide whether the bank should know.

The Exit Plan

The exit plan question that hits hardest in an exam: if this AI vendor went away tomorrow, what would happen. The acceptable answer has three parts.

The bank can continue the customer-facing workflow at degraded service for a defined period using a fallback (manual process, alternative vendor, or in-house tooling). The bank can recover its data and the audit pack within a defined window. The bank can stand up a replacement within a defined window with a defined budget.

If any of these three is not true, the exit plan is not real. We have seen exits go badly for banks where the vendor's prompt and configuration management was proprietary and the bank could not lift its workflows out. The contract clauses above prevent this if they are negotiated before the bank is in the dependency.

The TPRM File the Examiner Wants

When the AI exam opens, the file the bank should be able to produce:

• The inventory of AI vendors with a risk classification per vendor
• The diligence pack for each critical vendor
• The contract with the controls and the clauses
• The monitoring plan with the cadence and the artifacts produced in the last 12 months
• The incident log and the resolutions
• The concentration risk analysis with the tolerances and the current posture
• The exit plan for each critical vendor

The file is large for the first vendor. The next vendor uses the same template and produces a smaller marginal cost. Banks that build the muscle in year one ship the next AI workflow in weeks; banks that do not are still arguing about questionnaires.

What the Vendor's File Should Look Like

The flip side of the bank's file. A defensible AI vendor in regulated finance should be able to produce, on request:

• A SOC 2 Type II report with a 12-month observation window
• A model risk file by component, mapped to SR 11-7
• An eval harness output on a representative recent production sample
• A change log for prompts, retrieval sources, and configurations
• A list of subcontractors with the role of each
• An incident log for the last 24 months with the resolutions
• A data flow diagram and a data segregation attestation
• A fair-lending testing attestation where applicable
• An exit-cooperation plan

If a vendor in the regulated-finance AI category cannot produce this, the bank's TPRM team should treat the absence as the answer.

The Pattern That Works

The pattern we see succeed: the bank assigns a single vendor relationship manager who owns the TPRM file for the AI vendor end-to-end. The relationship manager has a cadence with the vendor that is not contract-renewal-driven. The relationship manager is the person who picks up the phone when an incident triggers. The TPRM team supports them with the framework; the model risk team supports them with the validation work; the vendor supports them with the artifacts.

It is a small reorganization with a large payoff. Banks that have made it can deploy their fifth AI workflow in the time it took the first one. Banks that have not are still running their AI program through the procurement queue.