Where does identity live?
A practitioner guide to where customer identity data is allowed to sit, and how a business can choose an identity verification solution whose flexible deployment model meets every market’s data privacy and localisation requirements.
Download the whitepaperInside the guide
Plain definitions of data residency, data privacy and data sovereignty.
A market-by-market view across the Gulf, Asia and Europe.
The two layers that bind every provider, the privacy law and the sector regulator.
A vendor assessment checklist to test how a solution meets data privacy and localisation needs.
The One Question a Regulator Always Asks
When you outsource identity verification, you still own one question
When businesses outsource identity verification, they still own one question in the eyes of their regulator: is customer identity data handled, stored and reachable in line with the law of every market they serve? Two layers decide the answer and they do not always agree.
Data localisation does not always come from a privacy law
It can be a rule a financial regulator adds for the material outsourcing of sensitive data. An identity verification solution that meets the data privacy law of a jurisdiction may not always meet the sector-specific localisation requirement within the same market.
The Three Terms, In Plain Words
What data residency, data localisation and data sovereignty mean
Three terms sit at the centre of this topic and they are easy to confuse. Here is what each one means in plain words.
What is Data residency in identity verification
Where a business’s customer identity data physically sits. Residency is often a setting chosen through the solution’s deployment model.
What is Data localisation in identity verification
A legal command to keep, and sometimes process, the data inside a country’s borders. It often comes from a financial sector regulator such as SAMA, the RBI, or OJK, not only the privacy law.
Data sovereignty in identity verification
Whose law governs the data and who can lawfully demand access to it. A solution can give in-country residency and still fall under a foreign government’s reach.
Why Privacy-Law Compliance May Not Be Sufficient
Why an identity verification solution’s compliance with privacy law may not be sufficient
One level comes from the privacy law. The other comes from a sector regulator’s material outsourcing requirements. The second often calls for in-country deployment — and many solutions cannot meet both.
Prove lawful handling across the whole chain
A privacy law such as the GDPR places a real, ongoing set of obligations on a business, well beyond paperwork. A business must show on request that identity data is stored, processed and accessed lawfully, and that any movement across borders is authorised. It must also audit that handling across the solution and every party in the chain. The longer the chain of subprocessors, the harder this is to prove.
A question about the deployment model
A sector regulator may go further. Its material outsourcing requirements can oblige the data to stay inside the country on a local cloud region or on-premises. This is a question about the solution’s deployment model, not its paperwork. A solution that meets the privacy law may still miss the localisation requirement, so both belong in due diligence from the first conversation.
Which Markets Keep Identity Data In-Country
When an identity verification solution may need in-country deployment?
A solution needs in-country deployment in two situations. The first is when the law of the market obliges the data to stay inside the country. The second is when the approval friction around offshore outsourcing makes the in-country route the simpler one. Most major economies allow offshore cloud, so the real need is not in-country deployment everywhere. The real need is a solution that can move between flexible cloud, offshore cloud, in-country cloud and on-premises as each market demands. The pressure for in-country deployment concentrates in the financial sector across the Gulf and parts of Asia.
SAMA pushes customer data inside the Kingdom. Offshore cloud needs SAMA approval.
The Central Bank keeps the master record of confidential data inside the UAE.
The RBI orders payment-system data and the personal data within it to be stored only in India.
OJK obliges banks to keep data centres and recovery sites inside Indonesia.
Offshore outsourcing needs QCB consent. Remote KYC for customers abroad needs prior approval.
Outsourcing of customer data and any offshore arrangement need prior CBB approval.
Public cloud for critical systems needs a BNM consultation. Offshore is fine for non-critical systems.
No localisation. A solution must guarantee MAS and auditor access and a clear chain.
No GDPR mandate. EBA guidance and DORA push material work toward the EEA.
No localisation. The PRA judges data location by risk.
No general mandate, though a sector-specific approval can add friction. Must guarantee Bank of Thailand and auditor access.
A deployment-flexible solution covers the easy and the hard markets from one integration.
How Shufti’s flexible deployment helps businesses comply
The guide sets out the rules market by market, then shows how a flexible deployment model flexible cloud, offshore cloud, in-country cloud and on-premises meets each market's data privacy and data residency requirements from one integration.
Vendor Assessment Checklist
The questions to ask any verification provider
Put these questions to any provider, Shufti included. The answers reveal whether a solution’s architecture matches the markets a business serves.
- 01In which countries can a solution store your data, and can it pin storage to one?
- 02Where does a solution process the data, as distinct from where it stores it?
- 03Can a solution deploy in-country, on local cloud, or on your own servers?
- 01What transfer mechanism does a provider use for each region?
- 02Who are a provider’s subprocessors, where are they, and whose laws apply?
- 03Could a foreign government compel the data wherever a solution stores it?
- 01How does a solution handle biometric data, from consent to storage to retention?
- 02Can a solution delete biometric data right after a verification decision?
- 03How does a solution meet strict biometric rules such as Illinois BIPA?
- 01What default retention periods does a solution set, and can you adjust them per market?
- 02How do a provider’s deletions reach backups and subprocessors?
- 03Which security credentials does a provider hold, and does it own its core technology?
Frequently Asked Questions
No, not always. Compliance with a privacy law such as the GDPR does not automatically satisfy a sector regulator’s localisation rule. A financial regulator can oblige data to stay inside the country even where the privacy law allows offshore storage. Both layers belong in due diligence from the first conversation.
That depends on the deployment model. A flexible solution can store and process data in a shared region, in a local cloud region inside a specific country, or on-premises. A business should confirm both where the data is stored and where it is processed, because the two can sit in different places.
The US CLOUD Act can compel a US-based provider to disclose data it controls, even when that data is stored on servers inside Europe. This is a data sovereignty question rather than a data residency one, because the reach of a government’s law follows the provider, not only the storage location. In-country or in-region storage does not, by itself, place data beyond a foreign government’s request. A business should ask who ultimately owns and controls the provider, whose laws apply to it, and whether a long chain of subprocessors adds further foreign legal reach.
Yes, if it offers in-country deployment. A provider with a flexible model can pin storage to a local cloud region or to on-premises infrastructure inside the border. A business should confirm the provider can guarantee in-country residency for each market that calls for it, not only for one.
A business should ask where the data sits, where it is processed, which deployment models the provider supports, and how those models map to the named regulator such as SAMA, MAS or the RBI. The provider should be able to show audit and access rights for both the business and its regulator.
Subprocessors are the outside parties a provider relies on to deliver verification. A longer chain spreads data across more parties and jurisdictions, which makes audit, accountability and sovereignty harder to prove. A short or wholly owned chain keeps the proof in one place.
Biometric data attracts stricter consent, storage and retention rules, such as Illinois BIPA. A business should confirm how long biometric data is kept, whether it can be deleted right after a verification decision, and how deletions reach backups and subprocessors.
Form submitted successfully!
Thank you for your interest — your report is loading now.
Ready to expand into new markets with identity verification built to meet data residency, data privacy and data sovereignty requirements?
Get the full guide with the market by market breakdown, the vendor assessment checklist and the regulatory sources. Talk to the team for a deeper look.

Back









