AI Third-Party Risk in Banking: How to Govern AI When the Model is Not Yours, What Due Diligence Must Cover, RBI Outsourcing Framework Application, and Managing Concentration Risk from AI Vendor Dependency

Third-party AI has become the dominant mode of AI deployment in banking. Banks that lack the data science capacity to build credit AI from scratch procure scoring models from bureaus. Banks deploying LLM customer service use APIs to foundational models. Banks using fraud detection AI rely on vendor platforms. Banks implementing document processing use vendor NLP pipelines.

In each case, the bank owns the customer relationship, the regulatory accountability, and the reputational risk — but does not own the AI system. The vendor owns the model architecture, the training data, and the model update cadence. The bank typically does not know exactly how the model works, which features it uses, or when it will change — and in our experience, most banks do not find this out until something goes wrong and the vendor's answer to "what changed" is slower and vaguer than anyone would like.

This is the third-party AI governance problem: the bank is fully accountable for a system it only partially controls. Standard IT outsourcing governance does not address this — IT vendor management focuses on service continuity, security posture, and contract compliance. AI governance requires additionally: model performance and fairness oversight, independent validation, change notification governance, and India-specific requirements (data residency, proxy variable fairness testing, DPDP Act compliance) that standard vendor contracts rarely address.

Due Diligence Framework: Six AI-Specific Dimensions

1. Model governance documentation. Request model documentation equivalent to what the bank would require for internally developed AI: intended use scope, feature set summary, training data description, performance benchmarks, and known limitations. A vendor that refuses to provide documentation of sufficient depth is a governance red flag — not a data security issue but an accountability one. The bank cannot independently govern what it cannot independently assess.

2. India-specific fairness testing. Standard vendor fairness testing is conducted on the vendor's default customer population, typically North American or European. For India deployment, request fairness testing on India customer data, or a commitment to conduct it on the bank's own data before deployment, with specific coverage of India proxy variable dimensions — geographic or pincode cluster, language or device type, religion-proxy counterparty patterns. A vendor whose fairness documentation does not address India demographics has not conducted fairness testing adequate for India banking deployment, no matter how rigorous its home-market testing looks.

3. Explainability for India compliance. Verify that the vendor's AI system can produce per-decision explanations in plain language — not just technical SHAP output — at the decision level, in the customer's preferred language including Hindi and regional languages, and in a form that can be stored to fulfil a DPDP Act explanation request. Many international vendors provide technical explainability outputs but not customer-facing plain-language explanations or regional-language capability. Assess this before deployment: retrofitting explanation capability to a vendor system after go-live is considerably harder than requiring it at procurement.

4. Data residency and DPDP compliance. Assess where the vendor's AI infrastructure processes Indian customer data, and against the right requirement. Many global AI vendors offer inference only in shared cloud infrastructure without an India-specific regional option — worth confirming before, not after, signature.

5. Security and adversarial robustness. For LLM-based vendor AI, assess whether the vendor has tested against prompt injection, jailbreak attempts, PII exfiltration, and financial-advice-boundary violation attempts. For traditional ML models, assess robustness against domain-specific adversarial examples — synthetic applicant profiles designed to exploit credit scoring decision boundaries, or transaction patterns designed to evade fraud detection. A vendor AI that performs well on validation data but has never been tested against adversarial inputs relevant to BFSI has a security testing gap that validation metrics alone will not reveal.

6. Exit and portability assessment. Before committing to a vendor AI relationship, assess exit options: can the bank obtain its inference data in a standard format for retraining a replacement model? Can a behavioral equivalent be built without triggering a full revalidation cycle? What happens to the bank's data used in vendor training or fine-tuning on termination? A vendor AI with no viable exit path carries materially higher concentration risk than one with a credible transition plan — and this is the question procurement teams skip most often because it has no answer that makes the deal look good.

Ongoing Oversight Requirements for Third-Party AI

India-Specific Third-Party AI Risk Considerations

RBI outsourcing framework and AI accountability. RBI's Master Direction on Outsourcing of IT Services, 2023 makes clear that banks cannot outsource regulatory accountability. For AI specifically, this means the bank's own obligations under RBI's FREE-AI recommendations and existing governance Master Directions apply equally to vendor-developed AI as to internally built AI; the DPDP Act's explanation obligations apply regardless of whether the system was built or procured; and board oversight expectations for material AI systems apply to vendor AI deployed in material banking processes. Banks that try to use a vendor contract as a shield against regulatory accountability for AI decisions will find examination practice unsympathetic to that argument.

BFSI-specific vendor concentration: credit bureaus and data aggregators. India's credit AI landscape has a structural concentration risk: most credit AI models draw on data from CIBIL, Experian, CRIF, or Equifax as primary inputs. If the same bureau data underlies multiple credit AI models across multiple banks, a data quality issue or a methodological change at the bureau becomes a systemic event — multiple banks' credit decisions affected simultaneously by a single upstream failure. Banks should map their credit AI dependency on specific bureaus and manage concentration accordingly — including whether at least one bureau can be substituted within a defined transition period without the model relying on bureau-proprietary features that make substitution impractical.

Shared LLM API infrastructure and DPDP Act. Banks using shared API infrastructure to access foundational LLMs are sending customer data to infrastructure the bank does not control, often outside India. The DPDP Act's purpose-limitation principle applies to this data flow regardless of where processing occurs. Banks using shared LLM APIs for customer-facing applications should assess whether the provider's terms permit this use, whether customer data sent at inference is retained and for what purpose, and whether that processing is consistent with the Act's requirements — this is a purpose-limitation and consent question, not strictly a localization one. Many banks are moving toward deploying foundational model weights on India-domiciled infrastructure anyway, for reasons that are as much about vendor concentration risk and latency as about regulatory requirement.

Third-Party AI Risk Action Checklist

1. Separate the payment-data localization requirement (RBI's 2018 circular) from DPDP purpose-limitation obligations in vendor contracts — they are different rules with different scope, and conflating them creates gaps in both.
2. Require vendor fairness documentation covering India proxy variables as a procurement condition, not a post-deployment request.
3. Map credit AI dependency on specific bureaus across the whole model portfolio and confirm at least one has a viable substitution path.
4. Add an exit and data-portability clause to every AI vendor contract before signature — not as a renewal-time negotiation.
5. Move vendor AI performance monitoring out of IT vendor management and into the Model Risk Management function, with independently computed metrics on the bank's own production data.