A delivery marketplace of Swiggy's shape serves five countries from two regions. Its India payments partner points at the Reserve Bank of India's directive of 6 April 2018 requiring payment system data to be stored only in India. Finance asks what a dedicated in-India cell would cost annually before the partnership is signed. Work the number and say what it rules out.

The assumptions, stated

The directive (circular DPSS.CO.OD.No 2785/06.08.005/2017-18, 6 April 2018) gave system providers six months to ensure the entire data relating to their payment systems is stored in a system only in India, with a system audit report as evidence. Assume the platform has 25 services, a Postgres primary with two replicas across three availability zones, Kubernetes, an observability stack, a key store, backups and a warm disaster-recovery target. Assume a six-person platform team on fully loaded cost of roughly $150k a year each.

The arithmetic

1. Infrastructure floor. A cell's cost does not scale down with its traffic, because high availability multiplies the base by three and the security and observability stack is per-cell. Even at near-zero volume the smallest defensible footprint lands around $15k to \(30k a month**, so **\)180k to $360k a year.
2. First-cell build. If the platform has never been regionalised, the work is identity, configuration, deployment targeting, data routing and the classification of which fields are payment system data. Call it 3 to 6 engineer-months, roughly $40k to $80k, plus a similar amount of product-team time to fix the flows that assumed one database.
3. The per-release tax. Every change now ships to two targets, every incident has two blast radii, every schema migration runs twice. This is 10% to 20% of the platform team forever, so roughly $90k to $180k a year.
4. Assurance. The system audit report, then its annual repeat, plus the evidence gathering behind it: order of $50k a year including internal time.

Year one lands at roughly $400k to \(700k**. Steady state is roughly **\)320k to $590k. Treat these as order-of-magnitude figures that move with the region and the team's loaded cost, not as a quote.

Which assumption dominates the error

Not the infrastructure. The per-release tax dominates, because it scales with release frequency and service count rather than with users or revenue. A team shipping ten times a day pays it ten times a day whether the Indian cell serves 1% of orders or 30%. If you want one number to challenge, challenge the service count: a cell of 25 services costs far more to run twice than a cell of 5.

What the number rules out

A market that cannot produce roughly $2M to $3M of annual contribution cannot carry its own full cell at a sane share of margin. That rules out the instinct to replicate the whole platform, and points at the answer the directive actually permits: scope the cell to the regulated data, not to the product. The obligation is about payment system data. The restaurant catalogue, the search index, the imagery and the recommendation models are not payment system data and do not belong in the cell. A narrow in-India payments store with its own key material, fronted by a routing layer, is a fraction of the cost above.

When not to build the cell at all

Read the obligation before designing. India's DPDP Act 2023 takes the opposite shape to the RBI directive: its section 16 permits cross-border transfers by default and lets the government restrict named countries, while section 16(2) preserves stricter sector rules like the RBI's. A storage obligation is not a processing obligation and not a sovereignty obligation. Where the rule is storage-only, an in-country primary with asynchronous export beats a full cell and costs a tenth as much. Ask which of the three you are being held to, in writing, before anyone draws a second region.