Data residency is eating global KYC

There is a quiet assumption baked into most KYC stacks built before 2024: identity data can live wherever your vendor happens to run. A customer in Mumbai uploads a passport, the image lands in a US-East bucket, a liveness check runs in Dublin, and the verdict is logged in whatever region the vendor's Postgres lives in.

That assumption is dead. It didn't die from one law. It died from twelve of them arriving at once.

Data residency — the requirement that certain data be stored, processed, or at minimum copied within a specific jurisdiction — has moved from procurement checkbox to regulatory hard line. And KYC data sits at the worst possible intersection: it is personal data, it is often biometric data, and it is financial-crime data. Three regulatory regimes claim it simultaneously. If you verify identities in more than one market, residency is no longer a feature you buy. It is a property your architecture either has or doesn't.

What changed: soft guidance became hard law

For a decade, residency was mostly a GDPR transfer-mechanism problem — annoying, paperwork-heavy, survivable with SCCs and a good DPA. The last three years replaced that with binding, dated, penalty-backed obligations across every corridor that matters.

The EU. The AML Regulation (Regulation (EU) 2024/1624) applies directly in all 27 member states from 10 July 2027 — no national transposition, no local softening. It arrives with AMLA, the Frankfurt-based supervisor established under Regulation (EU) 2024/1620 and operational since July 2025, carrying sanction powers of up to €10 million or 10% of group turnover, and a mandate to standardize exactly how CDD records are kept, evidenced, and produced. Layer GDPR on top (Regulation (EU) 2016/679) — biometric data used for identification is special-category data under Article 9 — and every face-match your onboarding flow runs in the EU is now double-regulated: AML rules dictate what you must retain, GDPR dictates where and how you may keep it. Records that must survive five to ten years for a regulator must simultaneously satisfy transfer restrictions for their entire lifetime.

India. The DPDP Act, 2023 and its implementing DPDP Rules, 2025 — notified in November 2025 and phasing in through 2027 — form the operative regime. The government can designate high-volume, high-risk processors as Significant Data Fiduciaries — a category most verification providers and their fintech customers will plausibly fall into — and SDFs face India-based data protection officers, annual audits, and localisation restrictions, including Rule 13's bar on transferring specified traffic and personal data outside India. This sits on top of what already existed: the RBI's directive on Storage of Payment System Data (DPSS.CO.OD No.2785/06.08.005/2017-18, 6 April 2018) already forces payment system data to be stored only in India, and Aadhaar-linked verification has never been allowed to leave. India is not converging toward the global norm. India is a residency regime, and it is expanding.

The Gulf. Saudi Arabia's PDPL (Royal Decree No. M/19 of 2021, as amended by Royal Decree No. M/148 of 2023, with SDAIA's Regulations on Personal Data Transfers outside the Kingdom), the UAE's federal law (Federal Decree-Law No. 45 of 2021) plus the separate DIFC Data Protection Law No. 5 of 2020 and ADGM Data Protection Regulations 2021, and Qatar's framework all restrict cross-border transfer of personal data, with financial-sector overlays that are stricter still. The GCC financial-hub buildout — the same one generating cross-border onboarding volume — comes with residency terms written into central-bank licensing conditions, not just privacy law.

Singapore. No blanket localisation law — and still one of the strictest regimes in practice, because three frameworks stack. The Transfer Limitation Obligation in section 26 of the Personal Data Protection Act 2012 permits offshore transfers only where the recipient jurisdiction or contract guarantees comparable protection. MAS's outsourcing and third-party risk requirements — the Guidelines on Outsourcing (Banks) together with Notices 658/1121 — then make the regulated entity accountable for knowing precisely where customer data sits in every vendor's stack, with audit, inspection, and retrieval rights that must reach every subcontractor in every region, and survive the vendor relationship. And MAS Notice 626 mandates five-year CDD record retention with prompt production. Government rails add a fourth layer: Singpass-sourced identity attributes carry their own handling and onward-disclosure restrictions. Singapore's model is residency by supervision — data may leave the island, but control may not.

The UK. Post-Brexit, the UK runs its own transfer regime: the UK GDPR (retained Regulation 2016/679) with the ICO's IDTA and Addendum as transfer instruments, amended by the Data (Use and Access) Act 2025 (c. 18). There is no localisation mandate. What there is instead: the PRA's Supervisory Statement SS2/21 and FCA operational-resilience rules requiring firms to map where data is processed, maintain tested exit plans, and guarantee unimpeded supervisory access wherever data sits — plus five-year retention under the Money Laundering Regulations 2017 (SI 2017/692). The strategic wrinkle is adequacy. UK–EU free flow rests on an adequacy decision that is reviewed, not permanent; an architecture that hard-codes the UK into its EU data plane carries renewal risk in both directions. Treat the UK as its own residency zone with a bridge to Europe, not as part of the European zone.

Hong Kong. The trap jurisdiction. The Personal Data (Privacy) Ordinance (Cap. 486) has contained a cross-border transfer restriction — section 33 — since 1995, and it has never been brought into force, so teams routinely assume free flow. The binding constraints actually come from the sectoral supervisors: the HKMA's Supervisory Policy Manual module SA-2 requires authorized institutions to know every processing location, secure supervisory and audit access rights over offshore processors, and assess the additional risks of overseas outsourcing; the SFC imposes equivalents on securities firms; and the PCPD's Guidance on Recommended Model Contractual Clauses for Cross-border Transfer of Personal Data, while formally voluntary, is hardening into the de facto standard for demonstrating due diligence. Two forward risks compound this: any flow touching mainland Chinese personal data pulls in PIPL's outbound-assessment regime, and section 33 itself remains on the books, ready to be commenced. The defensible position is to architect as if it were already in force.

East and Southeast Asia beyond the hubs. China's Personal Information Protection Law (adopted 20 August 2021) requires CAC security assessments for outbound transfers and effectively localises identity data at scale. Indonesia (Law No. 27 of 2022, with GR 71/2019) and Vietnam (Decree 53/2022/ND-CP and the 2023 Personal Data Protection Decree 13/2023/ND-CP) impose localisation on defined categories including financial data. The direction across the region is uniform even where the instruments differ.

"Different instruments, one direction. The era of 'our vendor is SOC 2 certified' as a complete answer is over. The question regulators now ask is coordinates: where, exactly, is this customer's passport image, and who can reach it?"

Why KYC gets hit first and hardest

Residency rules touch all customer data, but KYC data is the concentrated case, for three reasons.

It is maximally sensitive by construction. A KYC record is the densest possible bundle of personal data: government ID numbers, document images, facial biometrics, address history, source-of-wealth declarations, sanctions and PEP screening results. Biometric identifiers are special-category or sensitive data in the EU, India, China, Brazil, and most GCC states. There is no 'low-risk subset' of a KYC record to carve out.

It has mandated retention. Privacy law wants data minimized and deleted; AML law wants it kept for five to ten years and producible on demand — under AMLR, within days of an FIU request. You cannot resolve this tension by deleting your way out of it. The data must persist, in-region, queryable, for a decade. That is an infrastructure commitment, not a policy document.

It flows through the most vendors. A single verification can touch a document-capture SDK, an OCR provider, a biometric engine, a government rail (Singpass, DigiLocker, UAE Pass), a sanctions screening service, and a case-management system. Each hop is a potential transfer event. Most teams cannot draw this data-flow diagram for one vendor, let alone the four-vendor stack a multi-market fintech actually runs.

Why 'just use a global vendor' doesn't solve it

The instinctive answer is to pick one large IDV vendor with multi-region infrastructure and let them handle it. Three problems.

First, no single vendor wins every jurisdiction. The vendor with the best EU coverage is rarely the one wired into DigiLocker and CKYC, and neither is the one a Saudi regulator has blessed. Multi-market firms end up multi-vendor whether they planned to or not — and the residency problem returns, multiplied across every vendor's regional footprint.

Second, vendor region support is not the same as your compliance. A vendor offering 'EU data hosting' may still run model inference elsewhere, replicate logs globally, or route support-team access through third countries. MAS-style outsourcing rules make this your problem, not theirs: the obligation to know and control data location sits with the regulated entity.

Third, hard-wiring one vendor to solve residency is how lock-in happens. When your residency posture is an emergent property of one provider's infrastructure map, switching vendors means re-litigating your entire compliance position. That is a strategic tax you pay forever.

How to architect for per-region KYC

Residency done properly is an architecture decision, not a contract clause. The pattern that works — the one we built Omnified around — separates a global control plane from regional data planes.

• Split control from data. The control plane — routing logic, rulebooks, vendor health, orchestration state — is global and holds no raw PII. The data plane — document images, biometric templates, verification evidence, audit records — is regional, deployed per jurisdiction or per residency zone (EU, India, GCC, SEA, US). The control plane operates on references; only the in-region data plane ever touches the payload.
• Make jurisdiction resolution the first step of every verification, not an afterthought. Resolve the customer's jurisdiction and the applicable rulebook before any data moves, and let that resolution pin the residency zone for everything downstream. In Omnified's flow this is step one of verify_customer(): the engine detects jurisdiction, selects the CDD tier, and constrains vendor selection to providers whose processing footprint satisfies that jurisdiction's residency rules.
• Treat vendor selection as a residency decision. Maintain, per vendor, a machine-readable record of where each processing stage runs: capture, OCR, biometric matching, storage, logging, support access. Routing logic should consume this the same way it consumes price and latency. When a vendor changes regions — and they do — the routing table changes, not your application code.
• Store evidence in-region; move verdicts globally. The normalized result of a verification — verdict, risk score, reason codes — is derived data with minimal PII and can flow to your global systems. The evidence behind it — the passport image, the selfie, the raw vendor response — stays in the regional data plane, referenced by ID.
• Localize the audit trail itself. An audit trail that lives in one global region is a residency violation wearing a compliance costume. Every decision record — which rulebook applied, which vendor ran which check, what the raw response was, who reviewed the case — must be written to the same region as the evidence it describes, and exportable in the format the local supervisor expects.
• Put key management inside the region. Encryption at rest means little for residency if the keys are held — or escrow-able — outside the jurisdiction. Regional data planes need regional KMS roots. For markets with government-access sensitivities, this is increasingly the difference between an acceptable architecture and a rejected one.
• Design deletion and retention per rulebook. Retention clocks differ by jurisdiction and by check type. Encode retention in the rulebook layer, next to the CDD logic, so that the same engine that decides what to check also decides how long the evidence lives — and executes deletion in-region when the clock expires.

The table-stakes test

If you are evaluating your current stack — or a vendor pitching you — the residency questions that matter are concrete:

• Where, by region, is every processing stage of a verification executed, and can you show it per check rather than per contract?
• Can a single customer's complete evidence set be produced to a regulator from within their jurisdiction, without a cross-border export?
• When a vendor changes its infrastructure map, what in your system has to change?
• If a regulator in one market ordered you to stop transferring data out tomorrow, is that a config change or a re-architecture?

Teams that can answer those four questions cleanly have residency as a property. Everyone else has it as a promise.

Residency regimes at a glance

The uncomfortable conclusion

Residency requirements will not converge. AMLR harmonizes Europe internally while hardening its external boundary. India's regime is expanding, not relaxing. The GCC hubs are writing residency into licenses. Every serious market is concluding the same thing: identity data about our citizens, verified for our regulated entities, stays where we can reach it.

For a fintech operating in one country, this is absorbable. For anyone operating across corridors — remittances, global neobanking, multi-market wealth — it is the defining infrastructure constraint of the next five years. The firms that treat it as such will expand market by market with a routing-table change. The firms that don't will discover their architecture has a passport problem of its own.

"One API. Every market. Evidence where the regulator expects it."

Primary sources

All citations point to the issuing regulator or official legislation portal. EU — Regulation (EU) 2024/1624 (AMLR, EUR-Lex); Regulation (EU) 2024/1620 (AMLA, EUR-Lex); Directive (EU) 2024/1640 (AMLD6, EUR-Lex); Regulation (EU) 2016/679 (GDPR, EUR-Lex). India — DPDP Act 2023 and DPDP Rules 2025 (MeitY Data Protection Framework); RBI Storage of Payment System Data DPSS.CO.OD No.2785/06.08.005/2017-18 (6 April 2018). Singapore — PDPA 2012 (Singapore Statutes Online); MAS Notice 626; MAS Guidelines on Outsourcing (Banks); MAS Notices 658/1121. UK — UK GDPR (legislation.gov.uk); Data (Use and Access) Act 2025 (c. 18); Money Laundering Regulations 2017 (SI 2017/692); PRA SS2/21 (Bank of England). Hong Kong — PDPO Cap. 486 (e-Legislation); HKMA SPM SA-2; PCPD Guidance on Recommended MCCs. Saudi Arabia — PDPL Royal Decree M/19 (2021), amended M/148 (2023); SDAIA transfer regulations. UAE — Federal Decree-Law 45/2021; DIFC DPL 5/2020; ADGM DPR 2021. China — PIPL, adopted 20 August 2021. Indonesia — Law 27/2022; GR 71/2019. Vietnam — Decree 53/2022/ND-CP; Decree 13/2023/ND-CP.