FIDA Open Finance: Sovereign API Infrastructure and Jurisdiction Risk

The Financial Data Access regulation, published by the European Commission as COM(2023) 360, extends the open-banking logic of PSD2 and PSD3 into a broader obligation: banks, insurers, pension funds, and other financial institutions must make customer data accessible to authorised financial information service providers (FISPs) through standardised APIs. That obligation sounds primarily like a product or commercial decision. In practice, it is a jurisdictional decision of the first order, because every API endpoint, permissioning system, and audit log through which that data flows represents a point at which foreign law can reach European customer data.

The Jurisdictional Problem That FIDA Creates

When the infrastructure hosting a FIDA-compliant API gateway is operated by a US-parented entity, the US CLOUD Act of 2018 applies. It gives US federal authorities the power to compel disclosure of data stored or transmitted anywhere in the world, with no geographic limitation and no requirement to notify the data subject or the relevant EU supervisory authority. The same data may simultaneously be subject to FISA 702, which authorises mass collection of non-US persons’ communications transiting US-linked networks.

A financial institution that routes FIDA data flows through AWS, Microsoft Azure, or Google Cloud (all US-parented entities) therefore operates under a dual legal regime by default. The institution believes it is GDPR-compliant because it has signed SCCs; the cloud provider’s legal team knows that a National Security Letter or FISA order takes precedence over those same SCCs. This is not a theoretical scenario: Microsoft’s own transparency reports confirm that the company receives thousands of government data requests per year, the majority of which are subject to non-disclosure orders.

For institutions processing insurance claim data, transaction histories that reveal health expenditure, or investment profiles linked to politically exposed persons, the stakes are compounded by GDPR Article 9. Financial transaction data can qualify as special category data where it reveals health conditions, trade union membership, or religious behaviour (certain charitable transactions, for instance). Article 9 requires explicit consent and, crucially, a higher standard of technical protection that purely contractual arrangements with a foreign-parented provider cannot guarantee.

Designing FIDA Scheme Participation Under Sovereign Control

The only technically defensible architecture is one in which the API gateway, the permissioning engine, and the audit logging infrastructure are hosted on servers subject exclusively to EU jurisdiction, operated by an entity with no legal parent or subsidiary relationship that would bring it within the scope of the CLOUD Act or Chinese Cybersecurity Law Article 37.

Sovereign architecture in the FIDA context means that the financial institution, or a third-party FISP it engages, must demonstrate corporate independence from non-EU legal jurisdiction. Swiss hosting, while outside the EU, provides an alternative that the revised Federal Act on Data Protection (revFADP) brings into close alignment with GDPR adequacy, and Switzerland’s non-participation in US mutual legal assistance arrangements that bypass judicial review offers a structural, not merely contractual, protection. EU-incorporated hosting in jurisdictions such as Germany, France, or the Netherlands under national data centre operators provides the most direct jurisdictional certainty for regulated entities subject to ECB or national competent authority oversight.

DORA Obligations and the ICT Register of Information

DORA, Regulation (EU) 2022/2554, applies from 17 January 2025 and explicitly covers third-party ICT service provider relationships. Article 28 requires that contracts with ICT providers supporting critical or important functions include provisions on data location, audit rights, and exit strategies. A FISP platform through which FIDA data flows qualifies as an ICT provider for DORA purposes, and depending on the volume and criticality of data processed, may qualify as a Critical ICT Third-Party Provider subject to direct oversight by the joint ESA oversight framework.

The European Central Bank’s 2023 cyber resilience assessment identified third-party ICT concentration in a small number of global cloud providers as one of the highest systemic risks to the European financial sector. This directly affects how FIDA dependencies should be recorded and managed.

The DORA ICT Register of Information must capture several specific elements for each FISP dependency arising from FIDA participation:

• The legal jurisdiction of the FISP and its ultimate beneficial owner or parent entity.
• The data categories processed, with explicit flagging of any Article 9 special category data.
• The geographic location of servers hosting the API gateway and audit logs.
• The applicable foreign law exposure, including any CLOUD Act or equivalent legal framework that could compel disclosure.
• The contractual exit rights available under the EU Data Act, with a tested and timed exit plan.
• The residual jurisdictional risk, accepted at board or equivalent governance level, with a documented rationale.

Where the FISP operates on infrastructure controlled by a US-parented entity, that residual risk cannot be reduced to zero by any available contractual mechanism. The register entry must reflect this honestly, and the institution’s board-approved ICT risk appetite statement must explicitly address whether that residual exposure is acceptable for the data categories involved.

GDPR Consent, Article 9 Complexity, and What Sovereign Operators Must Implement

FIDA introduces a customer permission model that is distinct from, but must coexist with, GDPR’s lawful basis requirements. The FIDA permission authorises a FISP to request data; it does not by itself constitute a valid GDPR Article 6(1)(a) consent or, for Article 9 data, the explicit consent required under Article 9(2)(a). Financial institutions and their sovereign infrastructure operators must implement technical controls that enforce this distinction at the API layer, not merely through documentation.

The European Banking Authority has stated that financial institutions need to ensure that open finance frameworks do not inadvertently create new channels for data exfiltration by placing API infrastructure outside effective EU legal control. A sovereign infrastructure operator implementing FIDA permissioning must therefore build granular, purpose-bound API responses, with real-time audit logging of every data element returned, every FISP identity verified, and every consent or permission token used. These logs must themselves be stored on sovereign infrastructure, because a log of who accessed what financial data is itself sensitive and subject to GDPR.

The Council’s December 2024 Agreement and What It Signals

The Council of the EU reached a general approach on FIDA in December 2024 that strengthened the Commission’s original COM(2023) 360 proposal in two directions relevant to infrastructure jurisdiction. First, it introduced enhanced authorisation requirements for FISPs incorporated outside the EU or operating infrastructure controlled by non-EU entities. Second, it explicitly referenced the Digital Markets Act’s gatekeeper framework as a potential instrument for regulating large platforms that achieve systemic intermediary status in European open finance.

For CISOs and compliance officers, this means that routing FIDA data flows through a US-parented API platform is not simply a current technical risk: it is a forward-looking regulatory risk. Institutions that lock in foreign-controlled FISP dependencies now may face mandatory migration requirements, supervisory enforcement actions, or DMA-triggered obligations within the FIDA implementation period. The prudent posture is to treat sovereign infrastructure as a baseline requirement for new FIDA scheme participation, not as an upgrade to be considered later.

Documenting Residual Jurisdictional Risk: A CISO’s Practical Approach

Even where a financial institution has implemented SCCs, a Data Act exit clause, and a contractual data residency commitment, the CISO’s responsibility is to document what those safeguards do not cover. The residual jurisdictional risk assessment for a FIDA data flow transiting US-parented infrastructure should address four specific questions:

1. Is the infrastructure operator’s ultimate parent entity incorporated or listed in the United States, bringing it within CLOUD Act personal jurisdiction?
2. Does the data transiting the infrastructure include any element that qualifies as Article 9 special category data under GDPR, or any data relating to a politically exposed person, where foreign government interest is plausibly elevated?
3. Is there a credible, tested exit plan that allows migration to sovereign infrastructure within the timeframe specified in the DORA exit strategy, without loss of data integrity or audit log continuity?
4. Has the residual risk been formally accepted by the board or a delegated risk committee, with a documented review date?

If the answer to question one is yes and the answer to question three is no, the institution is carrying an undocumented concentration risk that DORA Article 28 and the applicable regulatory technical standards require to be surfaced and managed. The DORA ICT Register of Information is the formal home for that documentation, and national competent authorities are now reviewing registers for exactly this type of gap during supervisory assessments.

FAQ: FIDA, Sovereign API Infrastructure, and Jurisdiction

Does FIDA require financial institutions to use a specific type of API infrastructure?

FIDA (COM(2023) 360) mandates participation in a financial data sharing scheme and requires API-based data access, but it does not prescribe a specific infrastructure vendor. Financial institutions remain responsible for ensuring that the infrastructure they use does not expose customer data to foreign jurisdiction. In practice, this makes sovereign hosting the only technically defensible architecture when sensitive financial data is involved, even though FIDA itself is technology-neutral.

Can Standard Contractual Clauses under GDPR adequately protect FIDA data flows that transit US-controlled cloud infrastructure?

No, not on their own. The CLOUD Act and FISA 702 allow US authorities to compel disclosure of data from US-parented providers regardless of where data is stored or what contractual protections are in place. SCCs are a private-law instrument and cannot override a US government court order. A CISO must document this residual risk explicitly in the DORA ICT Register of Information and in the institution’s data protection impact assessment under GDPR Article 35.

How does FIDA’s consent model interact with GDPR Article 9 for sensitive financial data?

FIDA relies on customer permission as the trigger for third-party data access, but this permission does not automatically constitute valid GDPR consent under Article 6 or a lawful basis for processing special category data under Article 9. Where financial data reveals health conditions, political affiliations, or religious behaviour (for example, certain insurance or donation transaction patterns), Article 9 restrictions apply. A sovereign infrastructure operator must implement granular purpose-limitation controls at the API layer to enforce this distinction technically, not just contractually.

What must appear in the DORA ICT Register of Information for a FIDA-related FISP dependency?

Under DORA Article 28 and the related regulatory technical standards, the register must identify the FISP as a third-party ICT provider, classify whether the function is critical or important, document the data categories processed (including any Article 9 special category data), specify the jurisdiction of the provider and its ultimate parent, and record the contractual exit rights available under the EU Data Act. Where the FISP operates on foreign-controlled infrastructure, the residual jurisdictional risk must be recorded and formally accepted at board or equivalent governance level.

What did the Council’s December 2024 agreement on FIDA change regarding foreign FISPs?

The Council’s December 2024 general approach introduced enhanced regulatory requirements for FISPs incorporated outside the EU or using infrastructure controlled by non-EU entities. It also opened the door to Digital Markets Act gatekeeper-style obligations for large platforms that could become systemic intermediaries in European open finance. For financial institutions, this signals that routing FIDA data flows through foreign-controlled API platforms will attract increasing regulatory scrutiny and may require prior supervisory approval in some member states during the FIDA implementation period.