AI Vendor Due Diligence in Banking: What to Assess Before Procurement

Why Vendor AI Due Diligence Is a Governance Function, Not a Procurement Checkbox

When a bank buys a third-party AI system — a fraud model, a document-extraction API, an LLM wrapped into a chatbot — the vendor's engineering mistakes become the bank's regulatory findings. RBI does not examine the vendor. It examines the bank that deployed the vendor's model into a regulated decision. That means procurement has to ask a different question than "does this tool work" — it has to ask "can we govern this if RBI asks us to explain it in eighteen months."

A due diligence process built around demos and SOC 2 reports misses this. A due diligence process built around the six checks below gives the bank what it actually needs: the ability to meet its own governance obligations using what the vendor is contractually required to hand over.

Check One: Model Documentation the Bank Can Independently Validate

Ask for model cards, training data provenance, performance benchmarks by segment, and fairness testing results — not a sales deck. If a vendor's standard package is marketing collateral, the bank cannot run independent validation, and a model that cannot be independently validated cannot be classified as Critical or High tier with any confidence. Banks that accept "trust our testing" from a vendor are the ones that get the examination finding, not the vendor.

Check Two: Change Notification Terms That Actually Let the Bank Govern

A vendor that silently updates its model has quietly replaced the system the bank validated. Push for a minimum notice period for major model or base-model version changes — 30 days is a reasonable floor for anything that could shift decision logic — plus the contractual right to delay or decline an update until the bank's validation function has reviewed it. Without that clause, the bank's change-management governance has no trigger: it finds out about the change when behavior shifts in production, not before.

Check Three: Data Flow, Localization, and Training Use

Map exactly where customer data goes: which subprocessors touch it, whether it crosses borders, and — the question most contracts leave vague — whether the vendor trains or fine-tunes its models on the bank's customer data. For payment-related data, RBI's data storage requirements under its outsourcing and payment system guidance require that certain payment system data be stored only on systems located in India; a vendor contract that is silent on data residency is not an acceptable gap for a payments-adjacent AI deployment. Under the DPDP Act 2023, the bank is typically the data fiduciary and the vendor a data processor, which means the bank — not the vendor — carries the compliance exposure if the vendor mishandles the data.

Check Four: Incident Notification Fast Enough to Matter

A vendor that tells the bank about a security incident a week later has made the bank's own regulatory notification clock run out before the bank even knew the clock had started. Negotiate for prompt notification of confirmed security incidents — same-day to 24 hours is the working standard most banks push for — plus a post-incident report with root cause and remediation. This is a contractual term, not a regulatory one; RBI does not set the vendor's notification SLA, but it does expect the bank to have one.

Check Five: Audit Rights the Vendor Cannot Quietly Refuse

Contracts should grant the bank (and, by extension, its regulators) the right to audit the vendor's AI system and cooperate with regulatory examinations. A vendor that resists audit access, has never been through a regulated-customer examination, or treats its model as fully proprietary and unreviewable is not a vendor a regulated bank can safely concentrate critical functions on — regardless of how good the model's accuracy numbers look in a pitch.

Check Six: What Happens When the Vendor Fails or Exits

Assess operational dependency honestly: if this vendor disappeared tomorrow, how long would the bank's affected function be degraded, and is there a fallback? For critical functions, this is also a sector-level question — if three of the top five banks use the same fraud-detection vendor, a vendor outage is a systemic event, not just a single-bank incident, and RBI's outsourcing risk framework treats concentration in critical service providers as a supervisory concern.

India BFSI Context: Outsourcing Rules, Localization, and the DPDP Processor Chain

For Indian banks, AI vendor due diligence sits inside RBI's existing outsourcing risk framework, not a separate "AI vendor" category RBI has invented. **** Critical AI vendors require board approval, not just business-unit sign-off. Payment-related data localization is a hard requirement, not a negotiable contract term, for any vendor touching payment system data. And under the DPDP Act, the bank's data-fiduciary obligations do not transfer to the vendor just because the vendor caused the problem — the bank answers to the regulator either way.

Action Checklist Before Signing

1. Obtain model cards, benchmarks, and fairness test results in a form your validation function can independently review — reject "trust our testing."
2. Write a minimum 30-day change-notice clause for major model updates, with the right to delay adoption pending internal review.
3. Map the full subprocessor chain and get explicit contractual confirmation on data residency and whether customer data trains the vendor's models.
4. Negotiate same-day-to-24-hour security incident notification plus a mandatory post-incident report.
5. Secure audit rights and regulatory-cooperation commitments in writing before the contract is signed, not after an examiner asks for them.