Financial sovereignty requires infrastructure-layer independence. A ledger hosted on US cloud infrastructure, routing payments through US-controlled networks, governed by US-led capital, is not sovereign regardless of where the bank is incorporated.
The dependency is measurable. 63% of European cloud infrastructure runs on US-controlled providers. More than 90% of European card transactions route through Visa and Mastercard. Every EUR 1 billion-plus funding round in European fintech in 2025 was led by US investors. EUR 9 billion in annual funding would disappear if US capital withdrew from European fintech. The infrastructure dependency and the capital dependency are not separate issues. They compound. Vendors funded by US capital are subject to US regulatory pressure, US export controls, and US court jurisdiction, regardless of where their servers are located.
DORA transforms this from a geopolitical preference into a regulatory requirement.
The Three Dependency Layers
European financial institutions face infrastructure dependencies at three distinct layers. Each layer has different legal implications, different DORA exposures, and different remediation timelines.
Layer 1: Cloud infrastructure. AWS, Azure, and Google Cloud provide the majority of compute, storage, and network infrastructure for European financial institutions. These providers operate data centers in Europe, but the parent entities are US corporations subject to US jurisdiction. The CLOUD Act (2018) allows US law enforcement to compel US cloud providers to disclose data stored anywhere in the world, including European data centers, without requiring European legal process. Data residency in Frankfurt does not create data sovereignty if the provider's US parent can be compelled to produce it.
DORA Article 28 requires financial entities to assess and monitor ICT third-party risk, including concentration risk. Article 30 requires written contractual arrangements with ICT providers that include audit rights, data location requirements, exit strategy provisions, and the right to conduct penetration testing. For US cloud providers, the audit right is real, but what a European institution finds when it audits may be a system it cannot modify, cannot migrate away from quickly, and cannot fully assess because the provider's internal architecture is proprietary.
Layer 2: Payment networks. Visa and Mastercard process more than 90% of European card transactions. Both are US corporations. SWIFT, which routes interbank messaging, is Belgian-incorporated but governed by a board with significant US participation and historically subject to US government pressure. In 2012, the US Treasury compelled SWIFT to cut Iran from its network, affecting European banks' ability to process legitimate transactions with Iranian counterparties.
SEPA provides European-operated infrastructure for credit transfers and direct debits. The European Central Bank operates TARGET2 (and its successor T2) for high-value euro payments. But card payments, which represent the majority of consumer transaction volume, have no European-operated alternative at comparable volume. The EPI (European Payments Initiative) is building Wero as a card payment alternative, but it covers a fraction of current Visa/Mastercard volume as of mid-2026.
Layer 3: Capital and governance. Infrastructure vendors are subject to the governance priorities of their capital providers. A European fintech funded primarily by US venture capital will face pressure to expand into US markets, adopt US infrastructure defaults, and accept US-standard contract terms, including data terms that may conflict with GDPR and DORA.
Finch Capital's State of European FinTech 2026 report quantifies the capital gap: EUR 37.5 billion per year could be unlocked if European pension funds matched the fintech allocation rates of their US counterparts. That gap is not filled. The result is continued US-led capital dominance at the growth stage, which translates into US-aligned governance in the companies that build European financial infrastructure.
What Sovereign Infrastructure Means Technically
Sovereignty is not a certification or a flag on a data center. At the infrastructure layer, it requires four specific properties.
Data residency with jurisdictional control. Data must be stored within the EU/EEA under a legal entity subject to EU jurisdiction exclusively. This means the cloud provider's parent company, not just the operating subsidiary, must be bound by EU data protection requirements. German Sovereign Cloud (operated by T-Systems and SAP on Azure infrastructure) attempts this through a model where Microsoft has no access to data without German trustee approval. EU Sovereign Cloud offerings from AWS and Google are architecturally similar. Each model provides partial sovereignty: US-origin technology with European governance overlay.
Audit access without vendor gatekeeping. DORA Article 30(2)(d) requires that the financial entity can audit its ICT provider, directly or through a third party. For black-box infrastructure where the source code, the dependency chain, and the runtime behavior are proprietary, this audit right is nominal. An auditor can verify that the system produces the expected outputs; they cannot verify how. A system with published source code, a documented dependency chain, and deterministic behavior can be fully audited. The audit right is substantive, not nominal.
Supply chain transparency. DORA Article 9 requires assessment of supply chain risk. For a core banking system, the supply chain includes every library the system depends on, every third-party service it calls, and every data processor it routes data through. A system with 5,000 transitive dependencies cannot have its supply chain audited in any meaningful sense: the dependency graph is too large to reason about. A system with 30 transitive dependencies in its financial core can be.
Exit strategy with bounded migration cost. DORA Article 28(7) requires that concentration risk be managed, which includes the ability to exit a critical ICT provider without unacceptable operational disruption. For a core banking system built on a proprietary vendor's stack (custom APIs, proprietary data formats, vendor-specific tooling), the exit cost is measured in years and tens of millions of euros. For a system with standard interfaces (ISO 20022, open APIs), open data formats, and portable deployment models, the exit cost is bounded.
DORA's Concentration Risk Provisions
DORA Article 28(5) explicitly addresses concentration risk in ICT third-party dependencies. The European Supervisory Authorities are empowered to designate critical ICT third-party service providers (CTPPs) and impose additional oversight requirements, including resilience testing, exit planning, and operational reporting.
For European financial institutions, the concentration risk analysis has two dimensions. First, whether any single ICT provider represents a systemic dependency: if that provider fails or becomes unavailable, does the institution fail too? Second, whether the EU financial sector as a whole has excessive concentration in any single provider or provider category.
The ESAs published their first CTPP analysis in 2025 and found significant concentration in cloud and core banking technology. The regulatory response is not to mandate provider switching, but to require that institutions can demonstrate they have assessed the risk and have plausible exit strategies. An institution that cannot articulate a migration path to a different core banking provider because the current provider's architecture is incompatible with any alternative has a concentration risk that DORA requires it to document and address.
The Transparent Architecture Argument
The sovereignty argument is not primarily about where infrastructure is located. It is about whether the infrastructure can be fully audited, independently operated, and migrated away from on a defined timeline.
A core banking system built in Europe, running on European cloud providers, with source code that is proprietary and opaque provides weaker sovereignty guarantees than a system built anywhere with published architecture, documented interfaces, minimal external dependencies, and standard data formats. The jurisdiction of incorporation is a legal property. The auditability of the architecture is an operational one. Regulators under DORA care about the operational property.
The practical question for a CTO evaluating core banking infrastructure: can you satisfy DORA's audit access, supply chain transparency, and exit strategy requirements with your current vendor? If the answer requires trust in the vendor's assertions rather than verification from your own audit, the architecture does not satisfy the requirement. The requirement is evidence, not assertion.
Trade-offs
Infrastructure sovereignty has costs that are real and should not be minimized.
Narrower vendor selection. European-jurisdiction cloud providers have less capacity and fewer geographic regions than US hyperscalers. A European-only cloud strategy may mean accepting higher baseline infrastructure costs, fewer edge locations, and less mature managed services.
Migration complexity. Moving from an established US cloud provider to a European alternative is a multi-quarter project involving service-by-service assessment, vendor contract renegotiation, and operational validation. For institutions with years of investment in US cloud tooling, the switching cost is high.
Payment network alternatives are incomplete. Wero and other European payment initiatives address some of the Visa/Mastercard dependency, but coverage is partial as of mid-2026. An institution cannot yet build a fully European payment infrastructure stack that matches the acceptance and volume of US-dominated networks.
Regulatory uncertainty. The ESAs' CTPP framework is still being operationalized. What constitutes sufficient exit strategy documentation, acceptable concentration risk, and adequate audit access has not been uniformly defined across jurisdictions. Building infrastructure to satisfy a regulatory requirement that is still being written requires design for flexibility, not for a fixed specification.
Fernel Context
Fernel's financial core is built in Zig with a dependency count of approximately 30 transitive dependencies. The architecture is published: three strictly isolated layers with documented interfaces, ISO 20022 native data models, and standard API contracts that are not proprietary. The source code and dependency inventory are available for audit without vendor gatekeeping. Deployment is portable across cloud providers. There is no vendor runtime required: no proprietary managed service, no black-box execution environment that the institution cannot inspect or replace.
Read more: Security & Compliance | The Architecture of a Financial Operating System | DORA for Financial Infrastructure Providers
Sources:
- Finch Capital, State of European FinTech 2026: cloud concentration data, capital gap analysis, EUR 9B funding dependency
- DORA, Regulation (EU) 2022/2554, Art. 28 (ICT Third-Party Risk Management), Art. 28(5) (Concentration Risk), Art. 28(7) (Exit Strategies), Art. 30 (Contractual Arrangements), Art. 9 (Supply Chain Risk)
- US CLOUD Act, Pub. L. 115-141 (2018), cross-border data access provisions
- SWIFT and Iran sanctions: US Treasury OFAC action, 2012, precedent for extraterritorial payment network control
- European Payments Initiative (EPI), Wero product documentation (2025-2026)
- ESAs, Critical ICT Third-Party Provider (CTPP) Oversight Framework, initial designation analysis 2025
- ECB TARGET2 and T2 consolidation: operational documentation