RBI payment data localisation: what the 2018 circular requires, and who signs the SAR

The circular of 6 April 2018 requires all system providers to ensure that “the entire data relating to payment systems operated by them are stored in a system only in India”. It defines that data as the full end-to-end transaction details and information collected, carried or processed as part of the message or payment instruction. For the foreign leg of a transaction, the data can also be stored in the foreign country if required.

The Reserve Bank gave its reason in the circular: unfettered supervisory access to data held by system providers and by their service providers, intermediaries, third-party vendors and other entities in the payment ecosystem. The direction was issued under Section 10(2) read with Section 18 of the Payment and Settlement Systems Act, 2007, which gives it the force of a direction rather than guidance.

The FAQ of 26 June 2019 answers this directly. The direction applies to all payment system providers authorised or approved by the Reserve Bank to set up and operate a payment system in India. Because banks operate payment systems or participate in them — RTGS and NEFT, the systems run by CCIL and NPCI, and the card schemes — it applies to all banks operating in India.

It then reaches further: to transactions through the system participants, service providers, intermediaries, payment gateways, third-party vendors and other entities that authorised providers retain or engage. The FAQ is equally clear about where the responsibility sits. It remains with the authorised or approved provider. If you are a vendor in that chain, the provider that engaged you carries the compliance risk for your part of it, which is why it will ask you to prove where you store its data.

More than most teams first assume. The FAQ lists four kinds: customer data such as name, mobile number, email, Aadhaar number and PAN; payment-sensitive data such as customer and beneficiary account details; payment credentials such as OTPs, PINs and passwords; and transaction data such as originating and destination system information, transaction reference, timestamp and amount.

The practical consequence is that the data rarely lives only in the payment database. It is in application logs, message queues, observability tools, fraud and analytics platforms, customer support systems and backups. Each of those is a storage location, and a single log pipeline shipping to a region outside India is enough to make the word “entire” untrue.

Yes, within limits the FAQ sets out. There is no bar on processing payment transactions outside India, but the data must then be stored only in India. Where processing is done abroad, the data must be deleted from the systems abroad and brought back to India not later than one business day or 24 hours from payment processing, whichever is earlier.

Settlement processing done outside India afterwards must be performed on a near real time basis. For later activity such as chargebacks, the data can be accessed from India, where it is stored, whenever required — the FAQ explicitly rejects keeping it abroad until the dispute window closes. For cross-border transactions, a copy of the domestic component may also be stored abroad. Sharing with an overseas regulator needs the Reserve Bank’s approval.

The SAR is the evidence that localisation was completed. The circular required system providers to submit it on completion, said the audit “should be conducted by CERT-IN empaneled auditors certifying completion of activity”, and required the SAR to be approved by the provider’s board and submitted to the Reserve Bank by 31 December 2018.

The FAQ adds the scope: the SAR, from a CERT-In empanelled auditor, should include among other things data storage, maintenance of database, data backup restoration and data security. So the auditor is not certifying a policy. It is certifying where data is stored, how the database is maintained, that backups restore, and how the data is protected.

Only a firm on CERT-In’s list of empanelled information security auditing organisations meets that requirement. A consultancy that is not empanelled — ours included — can prepare you for the audit but cannot conduct it or sign the report.

Not under the 2018 circular, and this is commonly misstated. The circular asked for a SAR on completion of the localisation requirement, with a deadline of 31 December 2018; it did not create a recurring cycle. The obligation that does recur is the underlying one, to keep storing the data only in India.

Some directions have since added recurring audits. The Master Direction on Regulation of Payment Aggregators of 15 September 2025 requires a payment aggregator to comply with the storage requirements of the 2018 circular, and separately requires an annual system audit, including a cyber security audit, conducted by CERT-In empanelled auditors, with the report submitted to the regional office of the Department of Payment and Settlement Systems. Whether a recurring audit applies to you depends on the directions and authorisation conditions that govern your business, so read those rather than a summary.