Where BFSI AI Compute Must Sit: RBI Localisation Meets DPDP

Overview

The question “where must our AI compute physically sit” has a more precise answer for Indian financial institutions than for most sectors, and it is not primarily answered by the DPDP Act. DPDP takes a comparatively permissive approach to cross-border transfer — as of mid-2026 no restricted-country list had been notified — but sectoral rules are stricter and prevail. The RBI’s payment-data directive requires payment system data to be stored in India, and SEBI and IRDAI impose their own obligations. This article maps which rule governs which data, and what that means for GPU placement.

Two regimes, not one

DPDP governs personal data broadly and adopts what practitioners describe as a negative-list approach to cross-border transfer: transfers are permitted unless the government notifies restrictions on specific countries. As of mid-2026, no such list had been notified, so DPDP alone does not force localisation.

Sectoral regulation is a separate layer and is not softened by DPDP. The RBI’s directive on storage of payment system data requires the full end-to-end transaction details and related data to be stored only in India. SEBI and IRDAI maintain their own record-keeping and access requirements. A regulated entity must satisfy both frameworks, and where they differ the stricter applies. The practical implication is that a BFSI infrastructure decision should start from the sectoral rule and treat DPDP as an additional, largely orthogonal, obligation.

What counts as the data when a model is involved

This is the question that most often goes unexamined. If a fraud model is trained on transaction records, the resulting weights are a derived artefact of that data. If a RAG system embeds customer correspondence, the vector index encodes it. If an agent produces a trace containing retrieved account details, that trace is customer data. Treating only the source database as regulated, while the derived artefacts travel freely, is a position that is difficult to defend.

The workable stance is to classify by derivation. Anything computed from regulated data inherits its handling requirements until it has been demonstrably de-identified or aggregated beyond re-identification. That covers embeddings, fine-tuned adapters, evaluation datasets, prompt logs and inference traces — and it means the storage tier for those artefacts is in scope, not just the model server.

Placing each workload

The pattern is that steady-state, customer-facing inference is the workload with the least flexibility, and it is also the one with the best economics for owned infrastructure because volume is predictable. Experimental and public-data work is the most flexible and the most bursty, which is exactly the profile suited to rented capacity — including India’s subsidised national compute, where empanelled capacity of roughly 38,000 GPUs is reported heading toward around 100,000 by end-2026 at rates near a dollar per GPU-hour.

What the 2027 enforcement date changes

Full DPDP enforcement is expected from May 2027, with penalties reaching up to Rs 250 crore. The date matters less for the transfer question, which is already governed by sectoral rules, than for the security-safeguards and breach-notification obligations that apply regardless of where data sits.

For an AI platform that means three things to build now rather than later: a data inventory that includes model artefacts and inference traces, not just databases; demonstrable access control and encryption covering the GPU platform, where hardware-rooted approaches described in GPU confidential computing strengthen the evidence; and retention policies that actually execute. Retrofitting a data inventory across a deployed AI stack is substantially harder than designing one.

Practical architecture for a bank

A defensible pattern has emerged among Indian institutions. Keep a controlled in-country inference and retrieval estate for anything touching customer data, with the vector index, prompt logs and traces co-located and governed under the same policy. Keep model artefacts derived from institutional data in the same estate, with versioned lineage back to the training data. Use external or rented capacity only for work on public or genuinely synthetic data, and document that boundary so an auditor can see where the line was drawn.

Two supporting controls make this durable. A model registry recording, for each production model, its training data provenance, the jurisdiction it was trained in, and its approval status. And an egress control that prevents regulated artefacts from leaving the estate by accident — the failure mode is rarely a deliberate transfer, it is an engineer copying an index to a laptop or a notebook environment. The design detail is developed in BFSI private AI GPU server controls, with the broader planning frame in on-prem AI for BFSI.

Frequently asked questions