RBI Payment Data Localisation: Storing Payment Data Only in India

RBI data localisation for payments is one of India's clearest data residency rules. Since October 2018, the Reserve Bank of India has required payment system operators to store the entire data relating to payment systems only in India. Card networks, wallets, payment aggregators, banks and their technology vendors all fall within the chain of responsibility, and RBI has restricted global card networks from onboarding new customers for failing to comply.

The rule allows payments to be processed abroad, but the data must be deleted overseas and brought back to India within one business day or 24 hours. This guide explains who is covered, what data counts, the processing exception, cross-border transactions, audits, enforcement and how SaaS and IT vendors should design systems that handle Indian payment data.

What is the RBI payment data localisation rule?

In its first bi-monthly monetary policy statement for 2018-19, RBI noted that not all payment system providers stored payment data in India, and that unfettered supervisory access to this data was essential for monitoring. On 6 April 2018 it issued a circular on Storage of Payment System Data (DPSS.CO.OD No. 2785/06.08.005/2017-18) under the Payment and Settlement Systems Act, 2007. The core requirement is that all system providers ensure the entire data relating to payment systems operated by them is stored in a system only in India. Operators had six months, until 15 October 2018, to comply, and had to report compliance and submit an audit report.

After industry questions, especially from global card networks and foreign banks, RBI published FAQs on 26 June 2019 clarifying scope, processing abroad and cross-border transactions.

Why RBI introduced the rule

RBI's stated reason was supervisory access. Payment volumes in India were growing quickly, and some operators stored data mainly abroad, which made it harder for RBI to monitor the payment system, investigate fraud and act on incidents without depending on foreign jurisdictions. Storing data in India gives RBI and Indian law enforcement direct access through the operator. The rule also reflected wider policy interest in data sovereignty, which later appeared in debates on personal data protection. For businesses, the practical effect is that payment architecture for India must be planned as a separate, India-resident deployment rather than a regional extension of a global system.

Who must comply?

• Payment system operators authorised or approved by RBI under the Payment and Settlement Systems Act: card networks, ATM networks, prepaid payment instrument issuers (wallets), cross-border money transfer operators, payment aggregators and others.
• Banks, as operators or participants in systems such as RTGS, NEFT, NPCI systems and card schemes.
• Service providers, intermediaries, payment gateways and third-party vendors engaged by operators in the payment chain.

Authorised operators are responsible for compliance across their chains, which is why the rule reaches software and cloud vendors through contracts.

Is it mandatory or voluntary?

Mandatory for authorised operators and, through them, their vendors. There is no certification. RBI relies on System Audit Reports and supervisory action.

What data is covered?

According to the FAQs, payment data includes end-to-end transaction details and information collected, carried or processed as part of the payment message or instruction. This includes:

• Customer data: name, mobile number, email, Aadhaar number, PAN and similar identifiers.
• Payment sensitive data: customer and beneficiary account details.
• Payment credentials: OTPs, PINs, passwords and similar.
• Transaction data: originating and destination system information, transaction references, timestamps and amounts.

Data not related to payments, such as general product analytics without payment details, is outside this rule, though other laws such as the DPDP Act still apply.

Processing abroad and the 24-hour rule

The FAQs allow payment processing outside India if operators choose, but:

• The data must be stored only in India after processing.
• Data processed abroad must be deleted from systems abroad and brought back to India within one business day or 24 hours from payment processing, whichever is earlier.
• Subsequent activities, such as settlement processing, done abroad must be in near real time.
• Chargeback handling and similar activities can access the data stored in India whenever needed.
• Data cannot be kept abroad for dispute resolution windows; disputes must be handled using data in India.

Cross-border transactions

For cross-border transactions with a foreign component and a domestic component, a copy of the domestic component may also be stored abroad, if required. For example, when an Indian cardholder pays a foreign merchant, the transaction data can exist in both places. Purely domestic transactions, such as an Indian cardholder paying an Indian merchant, must be stored only in India.

Foreign banks and regulator access

Banks, particularly foreign banks, that were specifically allowed to store banking data abroad may continue to do so, but domestic payment data must be stored only in India, whether or not processed abroad. Data may be shared with an overseas regulator where required, depending on the nature and origin of the transaction, with prior RBI approval.

System Audit Report

Operators had to submit a System Audit Report (SAR) conducted by a CERT-In empanelled auditor, covering data storage, maintenance of database, backup and restoration of data, data security and related aspects, to confirm compliance. Operators should expect auditors and clients to request similar evidence when they change architecture, vendors or hosting.

Enforcement

RBI has used its powers under the Payment and Settlement Systems Act to enforce the rule. In 2021, it restricted American Express, Diners Club and Mastercard from onboarding new domestic customers onto their card networks because they were found non-compliant with the payment data storage directions. The restrictions were lifted later, after the networks demonstrated compliance. These actions showed that RBI treats localisation as a condition of operating in India, not a formality.

Related localisation and storage requirements

• RBI digital lending rules require data collected by digital lending apps for regulated entities to be stored on servers in India, subject to the conditions in those directions.
• Card tokenisation and card-on-file rules prohibit merchants and payment aggregators other than card issuers and networks from storing actual card data, so most merchants store tokens instead.
• Payment aggregator guidelines restrict storage of card data and set security baselines.
• SEBI, IRDAI and government cloud rules have their own residency expectations for regulated sectors and government workloads.
• The DPDP Act allows transfers abroad except to countries the government restricts, but sector rules such as RBI's apply on top.

UPI, wallets and payment aggregators

The rule applies across payment types. UPI payments run through NPCI and banks, but third-party UPI apps, payment service provider banks and their technology partners all handle payment data, so app backends, transaction histories and notification systems must keep that data in India. Prepaid wallet issuers store balances and transaction histories that are payment data. Payment aggregators and gateways sit between merchants and the payment system and are expected to keep transaction data in India and to ensure their own vendors do the same. Merchants that use these services mainly need to avoid copying payment data into systems abroad, such as global order management or analytics platforms.

Questions to ask vendors

• In which regions are primary databases, replicas and backups stored?
• Do logs, traces, error reports or analytics contain any payment data, and where are they stored?
• Do support staff or subcontractors outside India access payment data, and how is that controlled?
• Is any processing done abroad, and how is deletion within 24 hours enforced and evidenced?
• Has a CERT-In empanelled auditor reviewed the setup, and can you share the report or a summary?
• How will you notify us before changing hosting regions or subprocessors?

How to comply, step by step

1. Map payment data flows from the customer through apps, gateways, processors, networks, banks, support tools, logs and backups.
2. Identify every system and vendor that stores or processes payment data.
3. Move storage to India: databases, backups, logs, data warehouses and support tools that contain payment data.
4. Control processing abroad, with automated deletion and return within 24 hours if any processing happens outside India.
5. Scrub payment data from global tools, such as observability, error tracking, analytics and CRM systems hosted abroad.
6. Update vendor contracts to require India-only storage and audit cooperation.
7. Commission a system audit by a CERT-In empanelled auditor.
8. Repeat checks after changes in architecture or vendors.

Documentation you will need

• Payment data flow diagrams and inventory.
• Hosting and region configuration evidence.
• Vendor list with data location commitments.
• Deletion logs for any processing abroad.
• System Audit Report from a CERT-In empanelled auditor.
• Compliance confirmations to RBI or the operator.

Technical design for SaaS and IT vendors

Most compliance problems come from places teams forget: logs, error messages, analytics events, customer support attachments, email notifications and backups. Practical design patterns include:

• Host all payment workloads, databases and backups in Indian cloud regions, with replication within India for disaster recovery.
• Use tokenisation so card numbers never reach your systems.
• Redact payment fields in logs and error trackers before they leave the application.
• Run observability and analytics stacks in India for payment services, or send only non-payment metrics to global tools.
• Prevent support staff abroad from exporting payment data; use in-India support tooling with access controls.
• Keep an automated register of where each data store and replica lives.

Keeping compliance current

Localisation is not a one-time project. New features, new vendors and new tools can quietly create copies of payment data outside India. Good practice is to include a data residency check in architecture reviews and vendor onboarding, run automated scans of cloud accounts for resources outside approved regions, review logging and analytics pipelines each quarter, and refresh the system audit when hosting changes. RBI has also been consolidating its instructions into entity-wise directions, so operators should confirm which current direction carries the storage requirement for their category and update policy references accordingly.

Timeline and cost considerations

For a new product, designing for India-only payment data storage from the start adds little cost. Migrating an existing global platform can take months and require separate regional deployments, data migration, logging changes and new vendor contracts. Audit costs depend on scope and auditor.

Common mistakes

• Payment data in global logs, error trackers or data warehouses.
• Disaster recovery replicas outside India.
• Support tickets with transaction details stored in foreign SaaS helpdesks.
• Assuming tokenisation alone solves localisation; transaction data and identifiers still count.
• No deletion evidence for data processed abroad.
• Not updating the audit after moving to new cloud services.

Best practices, tools and technologies

• Use cloud policy controls to block resource creation outside Indian regions for payment accounts.
• Apply data loss prevention rules for card and account numbers.
• Use field-level encryption with keys held in India.
• Integrate with Indian payment gateways that already meet the rule.
• Combine with PCI DSS controls for card data security.

We build payment integrations and India-hosted architectures with redacted logging and clear data flow maps through our API integration and e-commerce services.

How it relates to other frameworks

Framework	Relationship
RBI cybersecurity and IT directions	Broader technology risk rules for RBI-regulated entities.
PCI DSS	Card data security standard; does not require localisation but applies alongside it.
DPDP Act	General personal data law; sector localisation rules prevail where stricter.
CERT-In Directions	Log retention and incident reporting for the same systems.
MeitY cloud empanelment	Government cloud requirement with its own India-hosting rules.

Real-world example

A Singapore-headquartered SaaS company offers subscription billing to Indian merchants and integrates with an RBI-authorised payment aggregator. Its Indian deployment runs in Mumbai and Hyderabad cloud regions, stores only tokens and transaction records in India, redacts payment fields before sending errors to its global error tracker, and routes support tickets from Indian merchants to an India-hosted helpdesk instance. The aggregator's auditor reviews its architecture as part of the aggregator's system audit.

Next steps

1. Map all payment data and copies.
2. Move storage, backups and logs to India.
3. Remove payment data from global tools.
4. Update vendor contracts.
5. Get a system audit by a CERT-In empanelled auditor.

Frequently asked questions

What does RBI's data localisation rule require?

The entire data relating to payment systems operated in India must be stored only in systems located in India.

Who must comply?

RBI-authorised payment system operators, banks in payment systems, and the gateways, intermediaries and vendors in their payment chains.

Can payments be processed outside India?

Yes, but the data must be deleted abroad and brought back to India within one business day or 24 hours, whichever is earlier.

Can cross-border transaction data be stored abroad?

For cross-border transactions, a copy of the domestic component may also be stored abroad if required.

What counts as payment data?

Customer identifiers, account details, payment credentials and transaction data such as references, timestamps and amounts.

Who audits compliance?

A CERT-In empanelled auditor produces a System Audit Report.

Does the rule apply to SaaS vendors?

Yes, through the payment operators that use them, if the vendor stores or processes payment data.

Can payment data be kept abroad for chargebacks?

No. Disputes and chargebacks must be handled using the data stored in India.

What happens if an operator does not comply?

RBI can restrict its business, as it did in 2021 when it stopped some card networks from onboarding new customers.

Does tokenisation remove the need for localisation?

No. Tokens reduce card data exposure, but transaction and customer data are still covered.

Can backups be stored outside India?

No. Backups containing payment data are storage and must remain in India.

Does the DPDP Act change the RBI rule?

No. The DPDP Act does not override stricter sector rules, so RBI's localisation requirement continues to apply.