India BFSI AI Vendor Risk 2026: Third-Party Governance Under RBI FREE-AI and MRMF

India's banking sector has embraced AI at scale — and outsourced most of it. Cloud AI platforms, embedded AI in core banking systems, fraud detection from specialist vendors, AML screening via API: the typical Indian bank's AI portfolio is predominantly third-party. This is not a problem in itself. The problem is that regulatory accountability has not moved with the AI. RBI FREE-AI (August 2025) states it directly: "Outsourcing of technology does not absolve the regulated entity of its regulatory responsibilities." MRMF (June 2026) applies the same logic to model risk management. Between them, the two frameworks place the full weight of third-party AI governance squarely on the bank — regardless of who built, trains, or hosts the AI.

The DSCI/BCG joint report on AI security in India's financial sector (2026) adds a systemic dimension: shared AI vendor ecosystems are identified as India BFSI's primary AI-specific attack surface. A sector where 10 banks use the same fraud AI, the same AML screening API, and the same cloud AI platform is a sector where a single vendor compromise has simultaneous sector-wide effects. This concentration risk has no precedent in traditional IT outsourcing frameworks.

The Core Problem

India's BFSI sector has concentrated AI adoption around a small number of vendors: cloud AI (AWS Bedrock, Azure OpenAI, Google Vertex), model registries (Databricks, Snowflake Cortex), fraud detection platforms (FICO, Experian), and sector-specific AI (FIS, Temenos, Finacle AI). This concentration creates two compounding risks.

Regulatory Accountability Gap

RBI FREE-AI (August 2025) states explicitly: "Outsourcing of technology does not absolve the regulated entity of its regulatory responsibilities." Banks remain accountable for AI systems they procure, deploy, or integrate — regardless of vendor claims about their own compliance. The bank that uses a vendor's fraud detection AI is accountable for that AI's fairness, explainability, and performance — not just its uptime. If the AI makes a discriminatory credit decision, the bank answers to the regulator, not the vendor.

Concentration Risk

The DSCI/BCG joint report (2026) identifies shared AI vendor ecosystems as India BFSI's number-one AI-specific attack surface. A single compromise of a major AI vendor could simultaneously affect multiple Indian banks using the same platform. This is not the same as a data breach or a service outage — it is a correlated failure of decision-making AI across the sector. Traditional IT risk frameworks have no category for this. Concentration risk in AI is a new regulatory obligation without an established compliance playbook.

What RBI FREE-AI Requires from Third-Party AI

RBI FREE-AI's Pillar 4 (Accountability) addresses third-party AI explicitly. Key requirements banks must operationalize:

• Vendor AI inventory: every AI system from a third party must be in the bank's model inventory — not the vendor's inventory, the bank's. A vendor maintaining its own model documentation does not satisfy the bank's MRMF inventory obligation.
• Contractual governance: banks must establish contractual rights to audit vendor AI, access validation documentation, and receive incident notifications for AI system failures. This requires renegotiating existing vendor contracts, not just adding a policy document.
• Independent validation rights: the bank (or its appointed validator) must be able to validate vendor AI performance on India-specific data — not just accept vendor benchmark results. A vendor's internal testing against US or European data does not satisfy FREE-AI's validation requirements for India BFSI deployment.
• Concentration monitoring: banks with significant shared-vendor exposure must quantify and monitor concentration risk. FREE-AI's accountability pillar treats concentration as a governance risk, not merely an operational one.

MRMF June 2026 Third-Party Provisions

RBI MRMF (June 2026) extends model risk management to vendor AI. This is a material expansion of scope: prior to MRMF, banks typically applied model risk management only to internally developed models. MRMF makes explicit that the framework applies equally to procured AI.

Key MRMF Provisions for Third-Party AI

• Vendor AI is in scope: MRMF explicitly applies to models procured from external vendors, not just internally developed models. An AI credit scoring model from FICO or Experian is a model under MRMF and must be treated as one.
• Documentation requirements: vendor AI documentation must satisfy MRMF's model documentation standards — model purpose, architecture, training data, validation results, known limitations. A vendor's marketing materials or feature documentation is not MRMF model documentation.
• Ongoing monitoring: vendor AI is subject to MRMF's ongoing performance monitoring requirements — banks cannot delegate monitoring to the vendor. The bank must independently monitor vendor AI performance on its own data and customer population.
• Third-party model validation: banks must conduct or commission independent validation of material vendor AI models — vendor self-certification is insufficient. For material models (credit scoring, fraud detection, AML), independent validation must be commissioned by the bank, not accepted from the vendor.

Concentration Risk: The Systemic Gap

Traditional IT outsourcing risk frameworks (RBI IT Outsourcing Guidelines 2023) address vendor dependency and service continuity. They were not designed for AI concentration risk. Three AI-specific concentration risks that existing frameworks miss:

Model Monoculture

If 10 Indian banks all use the same fraud detection AI from the same vendor, a model evasion technique that works against one works against all — simultaneously. An attacker who discovers that a particular adversarial input pattern bypasses a major vendor's fraud scoring model has effectively bypassed the fraud detection of every bank using that vendor. No traditional IT outsourcing risk assessment captures this correlated failure mode. The systemic risk from AI monoculture is materially different from the systemic risk from shared infrastructure (where failures are operational rather than decision-level).

Training Data Provenance

Shared AI vendors often train on aggregated data from multiple clients. A data poisoning attack targeting shared training infrastructure affects all banks whose data contributed. Banks typically have no visibility into shared training pipelines — they do not know whether their transaction data has been used to train models that are then sold back to them and their competitors. MRMF's training data documentation requirement creates an obligation to surface this visibility gap.

Vendor AI Supply Chain

AI models from large cloud providers are often built on foundation models from a second tier of vendors (OpenAI, Anthropic, Meta, Mistral). Indian banks using cloud AI through Azure/AWS/GCP have multi-layer vendor dependencies that their AI risk assessment does not currently map. A bank that has assessed its dependency on Azure OpenAI has not assessed its dependency on the OpenAI foundation models that underlie Azure OpenAI's service — nor its dependency on the data pipelines and RLHF processes that shaped those models. The AI supply chain extends well beyond the direct vendor relationship.

What Banks Must Build: Six Third-Party AI Governance Controls

1. Third-Party AI Inventory

Extend the MRMF model inventory to all vendor AI — not limited to models the bank "operates," but any AI system whose outputs affect bank decisions (including embedded AI in SaaS platforms). The inventory entry for each vendor AI must include: vendor name, model purpose, data inputs, output type, how outputs affect bank decisions, last independent validation date, and contractual audit rights status.

2. Vendor AI Contract Clauses

Four mandatory clauses for all material vendor AI contracts: (1) audit rights — the bank's right to audit vendor AI methodology, training data documentation, and validation results; (2) incident notification SLA — 24 hours for AI system failures that could affect bank decisions or data; (3) documentation access — the bank's right to receive MRMF-compliant model documentation; (4) exit and substitution provisions — defined transition path if the vendor AI is discontinued, materially changed, or fails validation. Many existing vendor contracts predate MRMF and do not include these clauses. Contract renewal is the natural trigger for renegotiation, but banks should not wait for renewal for material models.

3. Independent Validation for Material Models

Define "material" vendor AI — at minimum, models used in credit scoring, fraud detection, and AML — and commission independent validation. Vendor-provided testing results are not independent validation under MRMF. Independent validation must be commissioned by the bank and conducted against the bank's own data and customer population. For banks that lack internal model validation capacity for vendor AI, third-party validation firms with India BFSI expertise are the practical path.

4. Concentration Risk Dashboard

Quantify shared vendor exposure across the AI portfolio. The dashboard should show: what percentage of fraud detection AI runs on the top three vendors; what percentage of credit scoring AI runs on the top three vendors; what percentage of AML AI runs on the top three vendors; and for each material AI function, the fallback option if the primary vendor fails. Boards should receive concentration risk reporting alongside traditional IT vendor concentration reports.

5. AI Supply Chain Mapping

Map the full vendor chain for each material AI system — cloud provider, foundation model provider, fine-tuning provider, data provider — to surface multi-layer concentration. An Azure OpenAI deployment maps to: Azure (cloud) → OpenAI (foundation model) → potentially a fine-tuning provider → Microsoft/Azure data handling pipelines. Each layer is a concentration point and a potential attack surface. The supply chain map becomes part of the model's MRMF documentation.

6. Vendor AI Incident Response

Extend the AI-ACT&RS incident response playbook to vendor AI scenarios. Specific scenarios to plan: (1) vendor AI system compromised or taken offline — what does the bank do for the AI functions that vendor provides? (2) vendor discloses AI training data breach affecting bank data — what are the bank's notification obligations to RBI and affected customers? (3) vendor AI model produces systematically biased outputs affecting a protected customer class — who at the bank is responsible, and what is the remediation path? These scenarios require pre-planned responses, not reactive improvisation.

Examination Implications for 2026–27

RBI IT examination has traditionally assessed vendor management under the 2023 IT Outsourcing Directions. AI-specific examination of third-party AI governance is new. Banks should expect examiners to ask questions that most banks cannot answer today:

• "Show me your inventory of third-party AI systems" — most banks cannot produce a complete list of vendor AI systems affecting bank decisions, let alone a MRMF-compliant inventory entry for each.
• "What are your contractual audit rights for vendor AI?" — most vendor contracts do not include AI governance provisions. A bank that cannot demonstrate audit rights for its fraud detection AI has a governance gap, not just a contract gap.
• "How have you independently validated your fraud detection AI?" — vendor benchmarks are not examination evidence. The question is whether the bank has commissioned independent validation against its own India-specific customer data.

The examination risk is real: a bank with no third-party AI inventory, no contractual audit rights, and no independent validation for material vendor AI has a complete gap against FREE-AI Pillar 4 and MRMF third-party provisions. The gap is not theoretical — it is the current state of most Indian banks' vendor AI governance posture.

Frequently Asked Questions