Third-Party AI Vendor Risk: What Banks Must Govern — and What Regulators Now Require

Every vendor contract for an AI model comes with a validation report the vendor wrote about its own model. Banks have treated that report as if it were independent evidence for years, because it worked that way for a credit bureau score with a published, static methodology. It doesn't work that way for a model whose behavior emerges from training data and architecture choices the bank never sees, and RBI's draft eMRM approach is built around closing exactly that gap.

The point that should change how your bank buys AI

RBI's extended model risk expectations put the validation burden where it actually belongs: with the bank, not the vendor, regardless of who built the model. A vendor's self-validation is not independent validation under this standard — full stop — and a bank that has deployed vendor credit scoring, fraud detection, or LLM-based services on the strength of a vendor's own attestation has a remediation problem today, not a future one to plan around. The three requirements worth internalizing: validation has to be independent of the vendor, it has to cover the same ground as internal-model validation (performance, stability, bias, explainability, adversarial robustness), and the model has to sit in the bank's own inventory with a risk tier, whether the bank built it or bought it.

Eight things to actually check before signing

Technical documentation and performance benchmarks on data representative of your own borrower population — not the vendor's training population — are the foundation, because distribution shift between a vendor's training data and your deployment population is the single most common reason a vendor model underperforms once it's live. Independent validation follows directly: either your own model risk team evaluates it with real independence from whoever made the purchase decision, or you commission a genuinely external validator, and for any LLM-based vendor service, you need to document how you're independently validating the layer you built on top of the foundation model, not just trust the foundation model provider's own claims about it.

Bias and fairness testing is where vendor claims fail Indian banks most predictably: a vendor that tested for gender or race bias against a US or EU benchmark has tested for nothing relevant to caste-based or religion-based disparate impact in an Indian customer base, and the bank has to run that testing itself, with its own data, because no vendor is going to do it unprompted. Explainability access is a contractual issue as much as a technical one — a vendor model that's a black box at the API level cannot satisfy an adverse-decision explanation requirement, so get SHAP-equivalent attribution access written into the contract before you need it in an examination, not after.

Data residency — get the actual rule right, because the stakes are high

Get this distinction right in vendor contracts: a vendor inference endpoint hosted outside India handling payment-system data triggers the RBI localization rule regardless of DPDP Act status, while general customer personal data processed abroad is a DPDP Act consent-and-transfer-restriction question, not an automatic localization violation. Treating the two as the same rule will either leave a real gap uncovered or create unnecessary contractual friction over data flows the law doesn't actually restrict.

Concentration risk is underrated and easy to fix on paper, hard to fix in practice

If three Indian banks run customer-facing AI on the same LLM vendor's endpoint, a single vendor outage is a sector event, not an isolated incident, and RBI's systemic-risk posture would reasonably expect a documented contingency plan for exactly this scenario. Most banks don't have one, because vendor concentration risk for AI services has been treated as a procurement line item rather than the operational resilience question it actually is.

Contract terms that matter more than price

Technical access for independent validation, explainability API access or a contractual attribution commitment, explicit data-residency and processing-location terms, incident-notification SLAs, and portability of records at contract termination are the five terms worth fighting for in negotiation — not because they're exotic, but because every one of them is the specific thing a bank discovers it's missing during an examination or an incident, at the worst possible time to discover it.

What to do this quarter

• [ACCURACY FLAG applies here too] Separate your data-residency compliance tracking into two distinct obligations — RBI payment-data localization and DPDP Act cross-border transfer rules — rather than treating them as one requirement.
• Audit every vendor AI model currently in production against the eight-point due diligence list, starting with whichever ones were deployed on vendor attestation alone.
• Get SHAP-equivalent explainability access written into every vendor contract renewal from here forward, not just new agreements.
• Run India-specific bias testing (caste, religion, language, disability proxies) on every vendor credit or risk model using your own customer data — a vendor's generic bias report doesn't cover this.
• Document a concentration-risk contingency plan for any AI vendor your bank shares with other institutions in the same product category.