What Does RBI Data Localisation Actually Require?

Every conversation about this starts the same way. Somebody asks whether the infrastructure is compliant with RBI data localisation, and the answer comes back: yes, we are in the Mumbai region.

That answer is usually given honestly and it is usually wrong. Not because the region is wrong, but because the region is the one part of the problem that is easy to see. Everything that quietly carries a copy of the data somewhere else is invisible until an auditor asks the right question, and by then the architecture is three years old.

This is the engineering side of that problem. Not the legal reading, which your counsel owns, but the list of places we keep finding data that nobody meant to send anywhere.

What does the requirement actually say?

The relevant instrument is the RBI circular on storage of payment system data, issued in April 2018, and the clarifications that followed it. In substance, for entities operating a payment system authorised by the RBI: the full end-to-end transaction data must be stored only in India. That includes the information collected, carried and processed as part of the payment message or instruction.

Two parts of it catch teams out more than the headline does.

Only in India means only. A copy elsewhere is not a mitigated risk, it is the thing the requirement prohibits. This is where the backup discussion starts, and it is why the answer to "but it is only a backup" is that a backup is a copy.

Processing abroad is treated differently from storage. Where processing happens outside India, the data is expected to be brought back within a defined window and deleted from the foreign systems. If any part of your pipeline processes offshore, that deletion is now a thing you have to actually do and actually evidence, not a thing you intend.

Read the current text before you design against this. Circulars are amended, FAQs are issued, and a blog post is a starting point rather than a source. What follows is the part that does not change: where the copies are.

Where does data leave India without anyone deciding it should?

In our experience this list covers almost every finding. None of them are exotic. All of them are defaults.

Cross-region backups

Somebody enabled cross-region replication on the backup vault, years ago, for a good reason: durability. The destination was whichever region the console suggested or whichever one the disaster recovery plan named, and that was frequently Singapore or Frankfurt.

This is the single most common finding, and it is the one people argue about hardest, because losing cross-region durability feels like a step backwards. The honest answer is that durability within India is achievable across availability zones and a second Indian region, and that a backup which cannot legally exist is not a backup.

Log shipping

Application logs contain more than people think. A payment service logs request bodies during debugging, somebody forgets to remove it, and now the transaction payload is in the log stream. If that stream is shipped to an aggregator outside India, the data left the country in a form nobody classified as payment data because it was, in their mind, just logs.

Check two things: where the log pipeline terminates, and what the application actually writes into it. The second is more work and finds more.

Observability and APM vendors

Most monitoring platforms process in whichever region your account was created in, and the default at signup is usually the vendor's home region rather than yours. An APM agent capturing request traces is capturing payloads.

Several vendors offer an Indian or regional data residency option. It is generally a setting chosen at account creation and difficult to change afterwards, which is a reason to ask about it before signing rather than during an audit.

Error tracking

The same problem in a smaller package and with a worse blast radius. An exception handler that attaches request context to a crash report is exporting whatever was in that request. Error tracking is often adopted by a single developer without procurement ever seeing it, so it rarely appears on the vendor list the compliance team is working from.

Transactional email and messaging

Payment confirmations, statements, OTP delivery. The content is transaction data, the provider may process in another region, and this is almost never in the diagram because email is thought of as a channel rather than as storage.

Managed services replicating by default

The one that surprises engineers rather than compliance people. Some managed services replicate across regions unless you configure them not to, and some carry a global endpoint whose behaviour is not obvious from the console. Read the replication behaviour of every managed service in the path, particularly anything described as global.

What about the third-party services you did not choose?

Two categories worth a specific look, because both tend to sit outside the normal vendor review.

Anything a partner integrates on your behalf. If a payment aggregator, a KYC provider or a reconciliation service touches the data, their residency is your problem too. Ask where they store it and ask for it in writing.

Anything a developer added with a credit card. Feature flags, session replay, analytics, a queue-as-a-service used for one thing. These accumulate quietly and each one is a potential export. An inventory of every outbound integration is unglamorous work and it is where the surprises are.

Session replay deserves its own sentence. A tool that records what a user saw on a payments screen is recording payment data, in a form that is stored on somebody else's infrastructure, and it is almost never on the compliance radar.

How do you prove it rather than assert it?

The difference between a team that passes this cleanly and one that spends a month on it is not architecture. It is whether the evidence exists already.

A data flow diagram that matches reality. Not the one drawn at design time. One derived from what is deployed, listing every system the data touches and the region each one runs in. If it is generated from infrastructure as code rather than drawn by hand, it stays true.

A region constraint enforced in code. A policy that prevents resources being created outside the permitted regions is worth more than a document saying they should not be. It also converts a future mistake from an audit finding into a failed deploy, which is the cheapest possible place to catch it.

A vendor list with residency recorded against each entry. Every external service, where it processes, and the contractual basis. Maintained as things change rather than assembled when asked.

Deletion evidence, if anything processes abroad. Logs showing the data came back and was removed. Intent is not evidence.

Note also that authorised payment system operators are generally required to submit a system audit report from a CERT-In empanelled auditor. That auditor will ask for the four things above. Having them ready is the difference between a review and a project.

What does this cost you in architecture?

Being straight about the trade-offs, because pretending there are none is how teams end up resenting the constraint.

Disaster recovery is harder. Two Indian regions is a smaller blast-radius separation than two continents. It is workable and it needs designing rather than assuming.

Some services arrive later. New AWS capabilities do not land in every region simultaneously. Occasionally the thing you wanted is not available in an Indian region yet, and the answer is to wait or to solve it differently rather than to reach for another region.

Some vendors will not work. A tool with no Indian data residency option is a tool you cannot use for this workload. That is a real cost and it is better paid at selection time than at audit time.

Latency is usually a non-issue. Your users are in India. Serving them from India is faster, not slower. This one lands in your favour.

What happens if you find this out late?

Late is expensive in a specific way: the data is already in the wrong place.

Turning off cross-region replication stops new copies. It does not remove the copies already there, and removing them means finding every one, deleting it, and evidencing the deletion. If the destination is a vendor rather than your own account, deletion now depends on their process and their timeline.

This is why the finding is worth chasing before a funding round, an audit or a partnership review rather than during one. Every one of those has a clock, and this is not work that compresses well.

Where should you start?

Half a day gets you most of the picture.

1. List every region with anything in it. Not the regions you use. The regions with resources, which is a different and usually longer list. Check every region, not the ones you remember choosing.
2. Follow the backups. Every vault, snapshot schedule and replication rule. Write down the destination of each.
3. Follow the logs. Where the pipeline ends, and what the application writes into it.
4. List every outbound integration. Monitoring, error tracking, email, analytics, session replay, feature flags. For each: what data reaches it, and where does it process.
5. Write down what you found before fixing anything. The list is the deliverable. Fixes are easier to prioritise when you can see all of them.

That exercise is roughly what our free cloud audit does in its first session, and it is worth doing whether or not somebody else does it with you.

The short version

The region is the easy part and it is the part everyone checks. The data leaves through backups, logs, monitoring, error tracking, email and default replication, and every one of those is a setting somebody chose without thinking about residency because at the time there was no reason to.

Find them now, while finding them is a list. Later, it is a migration with a deadline attached.

This is engineering guidance, not legal advice. The circulars are amended and clarified over time; read the current text and take your compliance position from counsel. What is stable is the list of places copies hide, which is what this post is about.