TL;DR: Choosing a cloud provider is a compliance decision for any fintech handling EU, US, or cross-border customer data. GDPR, DORA, PCI DSS, and state-level rules like New York's 23 NYCRR 500 each set different requirements for where financial information can sit and who can access it. DLA Piper's January 2026 survey puts cumulative GDPR fines at €7.1 billion, and regulators are increasingly targeting the cloud vendor relationship itself, alongside the fintech's own IT systems. A provider's regional data centers alone don't satisfy any of this. Contracts, encryption key ownership, and subcontractor visibility do.
Key terms
- Data residency: the physical location where an organization stores and processes its data, typically to meet a specific regulatory or contractual requirement
- Data sovereignty: the principle that data is subject to the laws of the country where it is collected or stored, regardless of where the company that owns it is headquartered.
- DORA (Digital Operational Resilience Act): an EU regulation requiring financial entities and their critical technology vendors to manage information and communications technology (ICT) risk, report major incidents, and submit to direct regulatory oversight.
- Critical ICT third-party provider (CTPP): a cloud or technology vendor formally designated by European Union regulators as systemically important to the financial sector, subjecting it to direct supervision.
- Standard Contractual Clauses (SCCs): European Commission-approved contract terms that create a lawful basis for transferring sensitive data outside the EU.
Data residency rules settle something most fintechs don't realize is on the table when they pick a single cloud provider: which government can compel access to their customer data, and when. GDPR, DORA, PCI DSS, and a growing set of US state rules each answer that question differently, and a provider that satisfies one can still leave you exposed under another.
That's the tension this piece works through. A cloud provider's marketing page will tell you it has regions in Frankfurt, Dublin, and Virginia. What it won't tell you, and what determines whether you're compliant, is who can compel access to the data in those regions and through what legal process.
What are data residency requirements, and how are they different from data sovereignty laws?
About 80% of countries have legislation on data protection and privacy. Data residency is about geography. It refers to the physical or geographic location where an organization stores and processes its data, usually because a contract, an internal policy, or an industry-specific regulation requires it.
Data sovereignty is about jurisdiction. A dataset can reside on a server in Frankfurt and still be legally accessible under a US government order, because the company operating that server is headquartered in the United States. Renting a data center in the right country changes the geography. It does not change which countries' courts and law enforcement agencies have legal authority over the data.
The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) allows US authorities to compel a US-based cloud provider to hand over data it controls, even when that data is stored on virtual servers in the EU. A European bank using AWS, Azure, or Google Cloud can be compliant on paper with an EU residency requirement and still be subject to a US legal order, because residency and sovereignty answer two different questions.
Which of your data falls under data residency laws?
98% of US and European IT departments have data sovereignty strategies. Customer personal data, payment and transaction records, KYC (Know Your Customer) and anti-money-laundering files, credit data, and biometric identifiers all fall under residency rules, and that obligation doesn't stop at the record itself. It follows the data into the encryption keys used to protect it, the application logs that capture fragments of it, and the training data pulled from that same customer base. A cloud contract written around customer records alone typically misses all three.
Before comparing different providers, you need a working inventory of what you store. Each category can trigger a different rule, and a residency plan built around only the obvious ones, like customer records, leaves the rest unaddressed.
What does GDPR require of fintechs that store EU customer data?
The General Data Protection Regulation (GDPR) does not require that the personal data of EU residents remain within the EU. Many teams build their compliance checklist on the opposite assumption. What the GDPR requires, instead, is a lawful basis for any transfer outside the European Economic Area, such as an adequacy decision or Standard Contractual Clauses.
In practice, this means a fintech can use a cloud provider with servers outside the EU and stay compliant, provided the transfer mechanism is documented, and the provider can demonstrate adequate protections. Teams often treat "the provider has an EU region" as the compliance step. Few update the Article 30 Record of Processing Activities to reflect where backups, logs, and support access land. DLA Piper's January 2026 GDPR Fines and Data Breach Survey reports cumulative GDPR penalties of €7.1 billion since the regulation took effect, with cross-border transfer failures among the most heavily penalized categories.
How does DORA change cloud vendor selection for EU financial firms?
DORA takes GDPR's transfer questions and adds a layer most fintechs don't expect: the regulation reaches the cloud provider directly. Earlier EU frameworks reached only the financial firm using the technology. Since the compliance deadline took effect on January 17, 2025, EU financial entities have had to manage ICT risk, report major incidents within strict timelines, and maintain ongoing oversight of technology vendors as part of a formal, audited program.
One of the clearest signals of how seriously EU regulators are taking this arrived on November 18, 2025, when the European Supervisory Authorities designated the first group of critical ICT third-party providers under DORA, including Microsoft Ireland Operations Limited and Google Cloud EMEA Limited. A CTPP designation puts a cloud vendor under direct regulatory oversight. Its contracts with financial-sector customers are no longer the only lever regulators have. If you're evaluating providers, that changes the conversation: ask whether the provider is a designated CTPP, and if so, what oversight obligations flow down to you.
What do US rules like NYDFS and PCI DSS require instead?
The US has no single federal law requiring financial data to remain physically within the country. Coverage instead comes from a patchwork of sector-specific and state-level rules, and a fintech operating across multiple states can end up subject to several at once.
New York's Department of Financial Services regulation, 23 NYCRR 500, is one of the most detailed. It applies to any covered entity doing financial business in New York, and its most recent amendments extended third-party service provider requirements: covered entities must confirm that cloud vendors and other providers meet the regulation's cybersecurity standards and provide documentation to prove it. PCI DSS runs alongside this for any fintech handling card data, and it governs how cardholder data is encrypted, segmented, and access-controlled regardless of which cloud region it lives in. Neither framework mandates data residency the way the EU rules do. What they mandate instead are controls, and those controls turn the question of where your provider stores backups and logs into a practical problem, not a theoretical one.
Does moving to the cloud transfer your compliance responsibility?
No. Regulators treat a cloud contract as an outsourcing arrangement, and outsourcing a function doesn't outsource accountability for it. The EBA's Guidelines on outsourcing arrangements state plainly that a financial institution's responsibility for its own activities can never be outsourced, regardless of the cloud provider's certifications. DORA and NYDFS share the same principle: the fintech remains responsible for the security, resilience, and audit trail of the outsourced function.
A fintech should document what happens if the provider is compromised, how changes to subcontractors are communicated, what exit and migration support the provider commits to, and how quickly the provider can produce audit evidence after an incident. A provider with strong certifications but no workable audit or exit process can still leave the fintech exposed.
What should a fintech ask a cloud provider before signing a contract?
Most of the risk in this decision sits in the contract. A provider's regional data center map answers where data starts. It says nothing about where backups replicate to, which subcontractors get access for support, or whether the provider will contest a foreign government's demand on your behalf, and through what process. A short list worth working through before signing:
| Question to ask the provider | Why it matters |
| Where do backups, logs, and disaster recovery replicas live | The primary region can be compliant while the copies sit somewhere else entirely |
| Who holds the encryption keys | Customer-controlled keys held outside the provider's infrastructure mean a compelled disclosure order yields unreadable ciphertext |
| Is the provider a designated CTPP under DORA | CTPP status brings direct regulatory oversight and flow-down reporting obligations for you as the customer |
| Which subcontractors and support staff can access the environment, and from where | Support access from an unexpected jurisdiction can undo an otherwise compliant setup |
| What audit rights and exit provisions apply if the regulatory picture changes mid-contract | A locked-in vendor relationship is a liability once a framework like DORA adds new obligations |
| How does the provider handle retention and deletion across backups, logs, and snapshots | Deleted data can persist in backups or caches long after the primary record is gone, which undercuts a retention-limit or deletion obligation |
Encryption key ownership deserves particular attention here because it's the one control that does real work across several frameworks at once. Keys held in the customer's own infrastructure, outside the cloud provider's reach, satisfy GDPR's technical safeguard requirements. They also give a fintech a clear answer when a regulator asks what happens if the provider itself is compelled to disclose data.
What happens when a fintech gets this wrong?
Meta's €1.2 billion GDPR fine for unlawful EU-US data transfers remains the largest single penalty issued under the data residency regulation, and it was a transfer mechanism failure, not a data breach. TikTok received a €530 million fine from Ireland's Data Protection Commission in 2025, split between an unlawful transfer of EEA user data to China and a related transparency failure.
US regulators bring a different kind of pressure. NYDFS has treated inadequate oversight of third-party technology providers as an enforcement issue in its own right under 23 NYCRR 500. The EU and US are heading the same way: away from checking a fintech's own existing systems and toward harder questions about the vendors it relies on and how well those relationships are governed.
Choosing a cloud provider is a compliance decision
The uncomfortable truth underneath all of this is that no cloud provider can hand a fintech compliance out of the box. GDPR, DORA, PCI DSS, and NYDFS each pull in a different direction, and local data centers in the right region satisfy none of them on their own. What satisfies them is the contract behind that data center: who holds the keys, which subcontractors have access, and whether the provider will show up as a designated party in your own regulatory filings.
That's a heavier lift than most fintechs budget for when they're comparing pricing tiers. Svitla works with financial services teams on this exact evaluation, from vendor assessment through migration and ongoing compliance monitoring.
