On 6 April 2018 the Reserve Bank of India issued a circular requiring every payment system operator to store payment system data within India. It is a short document and it has not changed much since, which is precisely why teams skim it, assume they understand it, and then discover during an audit that a logging pipeline or an analytics tool has been quietly shipping regulated data to another continent for three years.
The scope is broader than most engineers expect. It covers the complete end-to-end transaction details collected, carried or processed as part of the payment message or instruction. In practice that pulls in customer name, mobile number, email address, Aadhaar or PAN where captured, beneficiary details, and authentication data including one-time passwords. If your fraud model reads it, your support tool displays it, or your observability stack indexes it, it is in scope. The obligation attaches to the data, not to the database you think of as the system of record.
Processing outside India is permitted, and this is the part people misread as a loophole. It is not. Where data is processed abroad it must be deleted from the foreign system and brought back to India no later than one business day or twenty-four hours from processing, whichever is earlier. That is a hard architectural constraint, not a policy statement. A managed service that retains request payloads for thirty days by default does not become compliant because your policy document says otherwise. For cross-border transactions with both a foreign and a domestic component, a copy of the domestic component may be stored abroad where required.
Compliance is evidenced, not asserted. Operators must submit a System Audit Report conducted by a CERT-In empanelled auditor, and the RBI is entitled to unfettered access to the data. Since 1 April 2021 there is also a half-yearly compliance certificate to be signed by the CEO or Managing Director. That signature requirement changes the conversation internally: it moves data residency out of the engineering backlog and onto a document a director personally attests to, twice a year.
The failures we see are rarely in the primary database. They are in the third and fourth tier of the stack — an error-tracking service capturing request bodies, a customer support platform hosted in another region, a data warehouse in a US project, a machine learning notebook environment, a backup replicated for durability into a foreign availability zone. Each was a reasonable decision made by someone solving a different problem. Collectively they are the finding in the audit report.
If you are building or reviewing a payments product, the useful exercise is not reading the circular again. It is drawing the actual path of a single transaction through every system it touches, including the ones nobody thinks of as systems, and marking where each copy comes to rest and for how long. Most teams find between three and six surprises. Fixing them before an auditor names them is considerably cheaper than fixing them afterwards, and considerably less disruptive than doing it under a deadline.
Data residency also interacts with the DPDP framework, which imposes its own obligations on personal data more generally. The two are not the same rulebook and satisfying one does not satisfy the other. Treating them as a single project, with one map of where data actually lives, is the approach that survives contact with both.
