An authorised payment system operator in India must keep the entire data for its payment system stored only in India, under the Reserve Bank of India's direction of 6 April 2018. The RBI's FAQ confirms processing abroad is permitted provided the data is deleted from the foreign systems and brought back to India within one business day or 24 hours of processing, whichever is earlier. The company wants one fraud model trained on all of its markets. Design the split.

The requirement that drives the structure

Read the obligation precisely, because the design follows from a single distinction. The storage location is fixed; the processing location is not. That one sentence is the difference between a global fraud capability and a per-market fork.

It also sets a clock. Anything that does cross the border for processing has to be deleted there and returned inside 24 hours, which rules out the normal pattern of a central data lake that accumulates every market's transactions for model training.

The design

• Data stays home, the model travels. Keep the Indian transaction store in India. Train globally by shipping gradients or aggregated feature statistics, not rows. Federated or sequential training over per-market partitions gives you one model's weights without one copy of the data.
• Inference runs in market. The scoring service, the feature store it reads and the decision log it writes all sit in India. A scoring call that leaves the country to be decided elsewhere makes the transaction detail foreign-resident, which is the thing the direction forbids.
• Define the crossing set explicitly and keep it in code. Model weights, hyperparameters, aggregate counts over a minimum cohort size, and alert metadata cross. Primary account numbers, tokens, device identifiers, amounts tied to an identity and full decision records do not. Enforce it at the boundary with an allow-list, not with a review step.
• Keys in market. Residency survives being undone by a key escrowed abroad. Use a key service in India for anything that decrypts Indian payment data.
• A deletion job with evidence. If any processing does happen abroad, the return-and-delete inside 24 hours needs a scheduled job, a proof of deletion and a report, because an auditor asks for the evidence rather than the design.

The hard part

Rare fraud patterns are exactly what one global model buys you, and they are the hardest thing to learn from gradients alone. A novel enumeration attack seen 40 times in one market produces a weak signal after aggregation. The practical answer is a two-layer model: globally trained base weights plus a locally trained, locally stored residual layer, with a fast path for publishing rule-shaped indicators of compromise, which are patterns rather than data and cross freely.

What it costs

Two serving stacks instead of one, a training pipeline that is materially harder to debug because no engineer can see all the inputs at once, and slower incident response when a model misbehaves in one market. Budget for a per-market model registry and per-market offline evaluation sets, which is where most of the hidden work lands.

When this is the wrong answer

If the second market is small and the fraud rate is low, one local model trained only on local data beats a federated architecture that nobody can operate. Federation earns its complexity when the markets share attackers. Check that before building it: if the overlap in attack signatures between markets is near zero, the global model is paying a residency tax for nothing.