Regulated engineering: PCI-DSS, data residency and the RBI rulebook

Payment data localisation

The RBI's direction on Storage of Payment System Data, issued 6 April 2018, is short and consequential: all payment system operators must ensure that the entire data relating to payment systems operated by them is stored in a system only in India. That includes end-to-end transaction details and the information collected, carried or processed as part of the message or payment instruction.

The provisions that matter in design:

Storage is in India; processing abroad is conditionally permitted. Data processed outside India must be deleted from the foreign systems and brought back to India not later than one business day or 24 hours from payment processing, whichever is earlier. The same 24-hour repatriate-and-delete pattern reappears in the RBI (Digital Lending) Directions, 2025 for offshore-processed lending data, which is a useful signal of how the regulator thinks about this.

Cross-border transactions are the carve-out. For a transaction with a foreign leg, a copy may be stored abroad. For a domestic transaction, no copy may.

The obligation reaches the whole chain. Payment system operators are responsible for their service providers, intermediaries, third parties and payment gateways. This is why due diligence on vendors is an engineering question and not only a procurement one.

The practical failures are rarely the primary database, which everyone gets right. They are the periphery: an observability platform whose storage region is US-East, an analytics warehouse replicating to a global instance, a support tool that caches transaction detail, a managed service whose control plane sits offshore, a machine learning platform where training data is copied to wherever the GPUs are. Every one of these is a real finding we have seen cited in a diligence process.

The design implication: data residency has to be a property of the platform, enforced by policy, rather than a property of each service, enforced by memory. Region-locked accounts, infrastructure-as-code guardrails that refuse non-Indian regions for payment-tagged workloads, and a data catalogue that labels what is in scope. Organisations that rely on engineers remembering will eventually have an engineer who did not.

Tokenisation and the card data perimeter

Card-on-file tokenisation changed the architecture of Indian e-commerce payments. Merchants and payment aggregators no longer store actual card numbers; they store network-issued tokens that are specific to the merchant and the card.

The engineering consequences are larger than they look.

The token has a lifecycle. Issuance on customer consent, binding to a specific merchant, updating when a card is reissued, deletion on customer request, and handling the case where a token becomes invalid. Each of these is a state transition with a customer-visible consequence if it goes wrong.

The token is not a card number and does not behave like one. Systems that treated the stored PAN as a customer identifier, or used it to deduplicate, or displayed the last four digits from storage, all needed rework. Some of that rework is still outstanding in older estates.

The guest checkout path diverged. Transactions without a stored token follow a different flow with different conversion characteristics, and the two paths need separate instrumentation.

The perimeter shrank, which is the point. The scope of PCI DSS assessment contracts when card data is not stored. This is the main commercial benefit and it is only realised if the perimeter is genuinely enforced rather than nominally declared.

PCI DSS v4.0.1

The Payment Card Industry Data Security Standard applies to any entity that stores, processes or transmits cardholder data. For Indian fintechs handling cards, the current version is v4.0.1, and the set of requirements that were future-dated when v4.0 was published became mandatory on 31 March 2025.

The ones with the largest engineering impact:

Two observations from searches we have run for this area. First, the client-side requirements caught a lot of organisations unprepared, because the marketing and analytics tags on a checkout page are usually governed by a growth team, not by security, and nobody had an inventory. Second, the shift towards risk-based frequencies has increased the documentation burden rather than reducing it: a justified decision needs writing down, and "we do it quarterly because we always have" is not a justification.

The DPDP overlay

The Digital Personal Data Protection Rules, 2025 were notified on 14 November 2025, giving effect to the 2023 Act, with an eighteen-month phased compliance period. For a fintech this is a second data regime layered onto the RBI's, and the two do not have the same shape.

Where the RBI's framework is about where payment data lives, the DPDP framework is about the basis on which personal data is processed at all: notice, consent, purpose limitation, retention limitation, the rights of the data principal, breach notification, and heightened obligations for Significant Data Fiduciaries including independent audits and data protection impact assessments. Consent Managers, where used, must be India-incorporated companies.

The practical engineering questions that follow:

Can you find all of one person's data? Data principal rights require it. Most fintech estates cannot answer this quickly, because personal data is spread across the primary systems, warehouses, logs, support tools and vendor platforms.

Can you delete it, and do you know what you may not delete? Erasure rights sit against retention obligations under financial regulation, which generally win. The system has to encode which data is retained under which legal basis for how long, rather than deleting on request and discovering the conflict afterwards.

Is consent recorded as evidence? Not a flag in a user table, but an artefact showing what was presented, when, and what was agreed.

Is purpose limitation enforced in the data platform? Data collected for underwriting being used for marketing is the textbook violation, and the only reliable control is at the platform level.

Is the breach process engineered? Notification to affected individuals in plain language, describing what happened, the likely consequences and the remedial steps, is an obligation with a timeline. It needs a tested runbook, which is the CISO's responsibility.

The two regimes interact awkwardly in places, most visibly on retention: RBI and tax rules require records to be kept, DPDP requires them not to be kept longer than necessary, and the resolution is a documented retention schedule per data category that reconciles the two. FinTechs that have not written that schedule are exposed to both sides.

Cloud, outsourcing and the RBI's IT frameworks

Three further frameworks sit over the architecture.

The Cybersecurity, Technology Risk and Resilience Framework Directions, 2026, issued 31 July 2026, apply to commercial banks other than Small Finance Banks, Payments Banks and Local Area Banks, with foreign bank branches on a comply-or-explain basis for selected chapters. They are the current high-water mark for what the regulator expects of financial infrastructure, and they are worth reading even by entities outside their scope, because supervision tends to converge. The architecturally significant requirements are a near-zero recovery point objective and minimal recovery time objective for critical systems, disaster recovery sites that are geographically well separated and configured identically to primary, half-yearly disaster recovery drills, full operational testing from beginning of day to end of day, and incident reporting within six hours of detection to the RBI's DAKSH platform alongside proactive notification to CERT-In. The implications for a core platform replacement are set out in core banking migration.

The IT Governance, Risk, Controls and Assurance Practices Master Directions set the governance structure: a board-level IT Strategy Committee of at least three directors with an independent chair meeting quarterly, an IT Steering Committee, a CISO reporting to the executive director responsible for risk rather than to technology, and board approval and annual review of IT strategy, business continuity and incident response. The hiring consequences are set out in hiring a fintech CISO.

The outsourcing of IT services framework governs the vendor estate: due diligence, contractual rights of audit and inspection extending to the regulator, exit and business continuity planning, and the principle that outsourcing never outsources accountability. For a cloud-native fintech, this frames the entire relationship with hyperscalers and SaaS providers, and it is the reason a procurement conversation about a monitoring tool can become an architectural one.

Taken together with localisation, these frameworks explain a pattern that surprises engineers joining from unregulated technology: in Indian fintech, the choice of a managed service is a governance decision. The engineering merits are necessary but not sufficient.

Who can do this work

The profile that commands a premium is the architect who can hold a design conversation with engineers and a governance conversation with a board committee in the same week. Most strong platform engineers can do the first. The second is learned by exposure, and the people who have that exposure are concentrated in banks, the large payment companies and a handful of scaled fintechs.

A note on hiring from outside the sector. Engineers from large unregulated technology companies are often technically stronger and genuinely faster, and they consistently underestimate one thing: that a design can be excellent and still not permitted. The adjustment is cultural more than technical, and the candidates who make it well are the ones who become curious about the rulebook rather than treating it as an obstacle. That curiosity is assessable at interview, and it is worth assessing.

How to assess

Ask them to draw the boundary. "Draw where payment data is allowed to live in your current architecture, and tell me every place it crosses that line." Candidates who have owned this answer with specifics including the awkward cases. Others describe the primary database.

Ask about an observability or analytics finding. The periphery is where localisation breaks, so a candidate who has found and fixed one has done the real work.

Ask what they would do about a non-compliant managed service they want. The good answer involves a documented risk assessment, a conversation with the CISO and compliance, and a decision made by someone with the authority to make it. The weak answer is either "use it" or "don't use it".

Test retention reasoning. "A customer asks for erasure. Walk me through it." Strong answers immediately distinguish what is retained under financial regulation from what is not.

Probe the governance conversation. "Explain data residency risk to a non-technical board director in two minutes." This is a real quarterly requirement in a regulated entity and a lot of excellent engineers cannot do it.