Every Indian bank with a fraud detection AI system, a credit scoring model, or a customer service LLM has trained that system on data that includes payment system data within the scope of RBI's April 2018 localization circular. Most of that training was done on global cloud infrastructure. Whether this creates regulatory exposure depends on a legal interpretation RBI has not officially provided.
This article maps the three relevant regulatory frameworks (RBI payment data localization, RBI IT Outsourcing Directions 2023, and DPDP Act 2023/2027), identifies the specific unresolved legal questions, and describes the prudent compliance approach pending RBI guidance.
The Core Question RBI Has Not Answered
RBI Circular DPSS.CO.OD No.2785/06.08.005/2017-18 (April 6, 2018) requires all payment system data to be stored only in India. AI model training on payment data uses compute that may be outside India. No RBI circular, guidance, or FAQ has stated whether this constitutes processing payment data outside India in violation of the circular.
Two reasonable interpretations exist:
- Narrow: Only operational storage covered. The 2018 circular targets operational data at rest — transaction records, customer credentials, payment logs. Model training is a derived analytical use, not operational storage. Weights are derived representations, not the underlying payment data. Localization does not extend to derived computational products.
- Broad: All processing of payment data covered. The circular covers data "related to payment systems" without qualification and requires that data to be "processed" and "stored" in India. Training a model IS processing payment data. Weights derived from payment data carry the obligation to the extent they represent that data.
Banks should document their interpretation and seek RBI guidance. The broad reading is the prudent treatment pending clarification.
Three Regulatory Frameworks Intersecting on AI Training Data
RBI Payment Data Localization Circular
Applies to all Payment System Operators (PSOs) — banks, NBFCs, payment aggregators, card networks, UPI apps, payment gateways. Scope of data covered:
Customer data: name, mobile, email, Aadhaar, PAN, address, account/card/wallet details. Payment sensitive data: customer and beneficiary account details, payment credentials, OTP. Payment transaction data: originating and destination system information, transaction reference, timestamp, amount. Other payment data collected, transmitted, or processed as part of a payment message.
Requirements: (1) Store entire payment system data in India only. (2) Systems for data processing can be outside India subject to ensuring 24-hour return of data to India and deletion from foreign systems. (3) For data processing outside India: report to RBI, submit a list of all existing overseas data storage systems, compliance report by June 30, 2018 (extended multiple times; current enforcement ongoing).
AI training implication: if an Indian bank's AI model is trained on any of the above data categories using compute infrastructure outside India — whether AWS US, Azure global, or GCP multi-region — it may constitute "data processing" outside India.
RBI IT Outsourcing Directions 2023
Applies to regulated entities (banks, NBFCs, payment system providers) outsourcing IT services. Relevant provisions for AI outsourcing:
Due diligence on AI vendors: RE must assess AI vendors and model providers for financial soundness, business reputation, security controls, and regulatory compliance. This covers LLM API providers (OpenAI, Anthropic, Azure OpenAI, Google Gemini) as IT service providers whose services are used in regulated financial services contexts.
Contractual requirements: contracts must include (a) audit rights for RE and RBI over the AI vendor, (b) RBI access to data, (c) data security and business continuity obligations, (d) prohibition on sub-outsourcing without RE approval (relevant for AI vendors who themselves use cloud providers for inference).
Concentration risk: REs must assess concentration risk where multiple REs use the same AI/ML vendor — a scenario that is universal in India banking given concentration in OpenAI, Azure OpenAI, and AWS Bedrock for LLM inference.
Offshore outsourcing: where AI workloads involve data processing outside India (including model training on global infrastructure), offshore outsourcing provisions apply including enhanced monitoring and potentially prior RBI approval for critical operations.
Digital Personal Data Protection Act 2023 — AI Inference Requirements
DPDP Act applies to processing of digital personal data in India or processing of personal data outside India "in connection with any activity related to offering of goods or services to Data Principals in India." Covers virtually all Indian bank customer AI applications.
Purpose limitation for AI training: DPDP requires a specific, clear, and lawful purpose for processing personal data. Payment data collected for transaction processing cannot be repurposed for AI model training without a separate, specific consent from the data principal. Banks using transaction history to train fraud detection or credit models must assess whether their existing consent covers this purpose.
Data minimization for AI inference: processing must be "necessary for the specified purpose." AI inference pipelines that load broad customer profiles (transaction history, demographics, behavioral data) must justify each data element against the specific inference task. Over-broad data loading violates DPDP's minimization principle.
Cross-border transfer restrictions: DPDP Rules 2025 finalization is ongoing. The original DPDP Bill restricted cross-border transfers of certain personal data. If these restrictions survive in the final Rules (expected May 2027), Indian bank customer data used in AI inference faces additional localization beyond RBI's payment-data requirements. Cross-border inference (India customer data → global LLM endpoint → India) may require explicit justification.
Significant Data Fiduciaries (SDFs): DPDP Rules will designate banks as SDFs, imposing additional obligations: Data Protection Impact Assessments for high-risk AI processing, mandatory AI audits, annual data protection assessments.
The Derivation Principle: Do Model Weights Inherit Data Localization?
The derivation principle addresses a genuinely novel legal question: what obligations do derived computational products (model weights, embeddings, summaries, classifications) inherit from the data they were derived from?
The argument for inheritance: model weights trained on payment data encode the statistical structure of that data. They are not independent of it — remove the payment data and the weights would be different. The weights are therefore a form of derived representation of the payment data, and the localization obligation that attaches to the payment data should attach to its derived representations.
The argument against inheritance: localization obligations attach to data, not to derived computational artifacts. A fraud detection model's weights do not contain any specific customer's payment record in a recoverable form. They are the output of a mathematical transformation, not the storage of the underlying data. Data protection law attaches to information, not to the weights of neural networks that were trained on information.
| Scenario | RBI 2018 Circular | IT Outsourcing 2023 | DPDP 2027 | Derivation Principle |
|---|---|---|---|---|
| Train model on India payment data, using India compute (AWS Mumbai only) | Compliant | Compliant | Compliant (with consent) | No issue — India-resident throughout |
| Train model on India payment data, using global compute (AWS US, Azure global) | Ambiguous — possible violation | Offshore outsourcing provisions apply | Cross-border transfer question | Weights may inherit localization obligation |
| Serve model inference: India customer data sent to global LLM endpoint | Likely violation if payment data sent | Offshore outsourcing provisions apply | Cross-border transfer restriction (DPDP Rules pending) | Data in-flight leaves India — clear issue |
| Use OpenAI API / Azure OpenAI to process India customer financial queries | Payment data cannot be sent to US endpoint | Due diligence, audit rights, concentration risk | Cross-border transfer depends on data sent | If payment data in prompt — possible violation |
| Fine-tune global LLM on India payment transaction data (stored outside India during fine-tune) | Fine-tune is "processing" — likely violation | Offshore outsourcing provisions apply | Purpose limitation: fine-tune ≠ transaction purpose | Most exposed scenario — clear derivation concern |
| RAG pipeline: India payment data in vector DB, queries routed to global LLM | Query routing sends payment data offshore | Due diligence on vector DB and LLM vendors | Personal data in RAG context window — cross-border question | Vector embeddings of payment data — derivation question |
What Indian Banks Should Do Now
With DPDP full enforcement expected May 2027 and RBI's localization circular already binding, the planning horizon for remediating AI training and inference pipelines is 18 months. Starting now allows architecture changes; waiting until DPDP Rules are final leaves 12 months for what may require significant infrastructure changes.
- Audit AI training pipeline data geography now. Map where every AI model's training compute was located. Identify models trained on RBI-scope payment data using non-India compute. Document the interpretation applied (narrow or broad) and why. This creates the audit trail that demonstrates the bank assessed the issue — essential regardless of the interpretation outcome. Where training occurred outside India on payment data, assess remediation: retrain in India compute, or seek RBI guidance on the circular's scope for derived uses.
- Map all LLM inference data flows for RBI payment data scope. For every LLM application (customer service chatbot, document processing pipeline, fraud narrative generator), identify whether RBI-scope payment data enters the prompt or context window. If yes, and if the inference runs on a global endpoint (OpenAI, Azure OpenAI with non-India deployment, GCP global), the data leaves India in a way that likely violates the 2018 circular. Remediation: route inference through India-region deployments (Azure OpenAI India Central, AWS Bedrock Hyderabad region, GCP Mumbai region), and verify that vendor data processing agreements confirm India-resident processing.
- Audit AI vendor contracts against IT Outsourcing Directions 2023. Review contracts with AI vendors (LLM API providers, AI model platforms, vector database providers) for the four required provisions: audit rights for RE and RBI, RBI data access, data security and BC obligations, sub-outsourcing restrictions. Many standard AI vendor contracts were written for US/EU enterprises and do not include RBI audit access provisions. These contracts need amendments before RBI examination identifies them as gaps. Assess concentration risk across AI vendors — document where multiple REs share the same AI/ML provider.
- Build DPDP consent architecture for AI training before full enforcement. DPDP full enforcement with Rules creates purpose limitation requirements. Banks must have specific consent for AI model training on customer data — separate from transaction processing consent. Design the consent architecture now: what data elements are in scope for which AI models, what purposes are captured in existing consent, what new consent is required. This is a 12–18 month architecture and legal project, not a 30-day remediation. Starting before DPDP Rules finalize allows design flexibility; starting after rules finalize adds timeline pressure simultaneously with other DPDP compliance obligations (DPIA, audit, SDF designation).