AI vendor diligence: the OCC 2023-17 and 2024-11 checklist

The community-bank CRO’s guide to building an AI vendor file that survives an OCC examination — from planning through termination.

The CRO at a $1.5B community bank has been handed a contract from an AI vendor — twelve pages, no indemnification clause specific to model outputs, no exit obligation, no sub-processor transparency. When the examiner asks about the bank’s OCC 2023-17 vendor diligence file for that tool six months later, the CRO has a signed contract and no lifecycle documentation. That gap is an MRA. This article covers every stage of the OCC 2023-17 and 2024-11 lifecycle applied to AI vendors — the artifacts each stage requires, the contract provisions no community bank should waive, and the red flags that disqualify a vendor before the contract is signed.

The problem in CRO vocabulary

The CRO owns third-party risk at most community banks between $1B and $3B. Under OCC Bulletin 2023-17 (June 2023), the CRO is responsible for a documented lifecycle for every third-party relationship — planning, due diligence, contract, ongoing monitoring, and termination. For a bank managing 150–300 active vendor relationships, that lifecycle already strains the team. Now add AI vendors.

AI vendors are not like the payroll processor or the IT infrastructure company. They create documentation obligations on two regulatory bases simultaneously: the OCC 2023-17 third-party risk file and the SR 11-7 model risk file. Same vendor, two separate regulatory obligations — and most community banks build them as separate exercises, producing two files with inconsistent data that the examiner reads in parallel and finds gaps between.

Then there is sub-processor risk. The community bank that signs with an AI vendor for credit memo drafting may not realize that vendor’s generation layer runs on Azure OpenAI — itself a third party with its own service continuity, data-handling, and sub-processor obligations. A bank that does not ask about sub-processors has a vendor file silent on where the data actually flows.

Finally, AI vendor relationships have an exit risk qualitatively different from standard SaaS vendors. When the bank exits a payroll processor, data leaves. When the bank exits an AI vendor that has incorporated bank data into model fine-tuning, what “exit” means for the trained model is rarely answered in the vendor’s standard agreement.

Why community bank AI vendor diligence differs from standard TPRM

The most common failure mode is treating AI vendors like standard SaaS vendors and running the same questionnaire. Standard questionnaires ask about SOC 2 reports, business continuity plans, and information security. Those questions matter for AI vendors too. They miss the AI-specific risks OCC examiners are now probing.

Model transparency. The bank’s credit decisioning, BSA triage, or deposit-retention model may be partially built on an AI vendor’s proprietary model. SR 11-7 requires the bank to understand its models — including vendor-supplied models used in bank processes. A vendor who cannot describe, in writing, how their model works, what data it consumes, and how it was validated cannot satisfy the effective-challenge requirement.

Training data and data flow. The AI vendor may be training or fine-tuning on customer-identified data or transaction data the bank transmits. Where does that data go after the contract ends? Who retains it? Can it be purged? The GLBA Safeguards Rule (16 CFR Part 314, amended 2021) requires controls over customer information transmitted to service providers. A vendor agreement that does not specify data deletion upon termination has a GLBA exposure.

Model update governance. SaaS vendors update software on a change-management schedule. AI vendors update models. A model update that changes the false-positive rate in the BSA system is a material model change under SR 21-8. Without a contract clause requiring advance notice of model updates, the bank’s monitoring protocol cannot function.

Sub-processor chain. Azure OpenAI, Google Vertex, AWS Bedrock — generative-AI infrastructure layers that many AI vendors sit on top of. Each sub-processor is a link in the chain where the bank’s data flows and where a service disruption propagates. A bank with no sub-processor inventory has an OCC 2023-17 gap in its vendor file regardless of how complete the rest of the file is.

A bank that runs standard TPRM on an AI vendor and believes it has satisfied OCC 2023-17 has a governance posture the examiner will open in the first technology-risk discussion.

The OCC 2023-17 lifecycle for community bank AI vendor diligence

OCC Bulletin 2023-17 describes five lifecycle stages. For AI vendors, each stage carries requirements that sit on top of the standard lifecycle. What follows is the stage-by-stage structure that community-bank engagements have converged on across 2024–2026.

1. Stage 1 — Planning

   Before vendor evaluation begins: document what the AI tool will do, what data it will consume, what decisions it will influence, and where it sits in the bank's model-risk taxonomy under SR 11-7. Assign materiality — high (model affects credit, BSA, deposit pricing), medium (model affects operations), low (model affects internal-only outputs). Materiality tier drives diligence depth. A bank that has not completed its SR 11-7 model inventory first cannot complete this stage with any precision.

2. Stage 2 — Due diligence

   Collect the pre-meeting artifact set (see checklist below). Require the vendor to identify every sub-processor in writing. Require sample SR 11-7 documentation from a named community-bank deployment at your asset tier. Any vendor who cannot produce a named reference at $500M–$5B should be given time to find one. If they cannot, the deployment record does not support the community-bank diligence requirement and the evaluation should pause.

3. Stage 3 — Contract negotiation

   OCC 2023-17 provisions apply: performance standards, audit rights, sub-contractor disclosure, data return and destruction, business continuity, and termination rights. AI-specific additions: advance notice of material model updates (minimum 30 days); data deletion certification within 30 days of termination; sub-processor change notification; model validation documentation delivery on request; and explicit indemnification for model output errors in regulated processes. These clauses are negotiating starting points — the bank that accepts the vendor's standard agreement on these points has accepted the vendor's risk, not the bank's.

4. Stage 4 — Ongoing monitoring

   Annual performance review minimum; quarterly for high-materiality AI tools. Monitoring includes: SOC 2 Type II currency (within 12 months), model performance metrics against the bank's baseline, sub-processor changes, regulatory actions against the vendor, and any material model updates. The ongoing monitoring artifact for the AI vendor and the SR 11-7 model file cover the same vendor relationship. Reconcile them once, not as separate exercises.

5. Stage 5 — Termination readiness

   The bank's exit plan must answer: Can the bank operate the relevant process without this vendor for 90 days? What is the vendor's contractual obligation to return data and purge training data? What documentation does the bank retain? The exit plan is not optional under OCC 2023-17 — it is a documented artifact the examiner reviews. A bank with no exit plan for a high-materiality AI tool has an incomplete vendor file before the ink on the contract is dry.

Field evidence

Venminder and Prevalent are the other two vendors with material community-bank TPRM adoption. Venminder’s standardized control assessments provide the bank with vendor responses against OCC-aligned frameworks without requiring custom questionnaires from scratch. Prevalent’s AI-assisted risk scoring maps vendor risk levels to the bank’s materiality tiers automatically, reducing analyst time on annual vendor reviews.

The pattern across community-bank deployments at the $1B–$3B tier: the TPRM platform reduces questionnaire and tracking burden but does not eliminate the need for bank-authored analysis. The vendor file that passes an OCC examination contains vendor-supplied data plus a bank-authored narrative explaining how that data supports the bank’s risk conclusion. Exporting a vendor platform report and attaching it to the vendor contract is not a complete diligence file — it is a starting point.

What to do in the next 90 days

A CRO who has signed one or more AI vendor agreements in the last 18 months without building the OCC 2023-17 lifecycle documentation has a retroactive filing gap. The OCC examiner will find it. The question is whether the bank finds it first.

A 90-day sequence for a $1B–$3B bank that needs to build or rebuild its AI vendor files:

Days 1–21. Inventory every AI tool in use, sanctioned or not. Map each to the OCC 2023-17 materiality tiers. Identify any tool that touches credit decisioning, BSA, or deposit pricing — those are the critical-tier files the examiner reads first. Identify any tool without a current SOC 2 Type II report (within 12 months) — those are the immediate risk items, regardless of how long the vendor relationship has been active.

Days 22–45. For each critical-tier vendor: request the full pre-meeting artifact set from the checklist above. Identify the sub-processor chain in writing. Assess whether the current contract contains the AI-specific provisions — model update notice, data deletion certification, sub-processor change notification, indemnification for model output errors. Mark each provision absent and begin contract amendment conversations before the exam cycle opens.

Days 46–75. Draft the bank-authored analysis layer for each critical-tier vendor file. The file is not complete until a bank staff member has written, in institutional voice, why the bank concluded the risk is acceptable and what monitoring the bank will perform. Reconcile the vendor file with the SR 11-7 model file for every AI vendor where the tool sits inside the model-risk perimeter. The structured questionnaire at phase-7/vendor_risk_questionnaire.md provides the documentation framework for this reconciliation.

Days 76–90. Produce the board Risk Committee summary: number of AI vendors by tier, file completeness status, open contract gaps, monitoring cadence, and any termination-readiness gaps. The board summary converts the compliance exercise into governance evidence the exam team reviews. A CRO who can walk an examiner through this summary in twenty minutes has demonstrated a functioning TPRM program, not a folder of vendor contracts.

The board-ready one-page version of this conversation is at phase-7/one_pager_bank_vendor_diligence.md — formatted for the Risk Committee and usable in the same meeting where you present the 90-day plan.