Sovereign Open Finance: FIDA Compliance Without Foreign-Jurisdiction Risk

The EU Financial Data Access Regulation, proposed by the European Commission as COM(2023) 360, will fundamentally restructure how regulated financial institutions share customer data. Unlike PSD2, which was limited to payment account data, FIDA extends mandatory data sharing to savings, investments, pensions, insurance, and consumer credit products. The mechanism is a standardised API architecture that lets authorised third parties pull customer financial data on demand, subject to explicit consent. That architecture, if built on US-controlled cloud platforms or SaaS middleware, introduces a category of foreign-jurisdiction exposure that most compliance teams have not yet fully mapped.

What FIDA Actually Mandates and Where the Jurisdiction Risk Enters

FIDA creates two roles: the financial data holder, typically a bank, insurer, or investment firm, and the financial data user, an authorised third party who accesses data via API. The data holder must provide a standardised, always-available interface; the data user must be authorised under a financial data sharing scheme overseen by the competent authority in each member state.

The risk is not in the concept but in the implementation layer. Most commercially available API gateway products, developer portals, OAuth 2.0 authorisation servers, and consent management platforms are operated by companies incorporated in the United States: AWS API Gateway, Azure API Management, Google Apigee, MuleSoft (Salesforce), and similar. When a European financial institution routes customer financial data through any of these services, even with Standard Contractual Clauses in place, that data becomes reachable under the CLOUD Act (18 U.S.C. §2713) and, for intelligence purposes, under FISA Section 702. The US parent company can be compelled to produce data held anywhere in the world, and the European data subject will not be notified.

According to the European Commission’s impact assessment accompanying COM(2023) 360, the FIDA framework will cover more than 40 categories of financial data across over 5,000 regulated entities in the EU. At that scale, the choice of API infrastructure is not a technical detail: it is a systemic data sovereignty decision.

DORA Closes the Loophole That FIDA Opens

DORA Regulation (EU) 2022/2554, fully applicable from January 2025, does not treat ICT third-party risk as a matter that can be contractually delegated. The regulation requires financial entities to maintain a register of all ICT third-party service providers, conduct risk assessments for each, ensure audit rights and exit strategies, and demonstrate that concentration risk is managed. The European Banking Authority has been explicit on this point:

“DORA makes it crystal clear: ICT third-party risk is not outsourced when you outsource a function. Accountability stays with the regulated entity.” (European Banking Authority, DORA Implementation Guidance, www.eba.europa.eu)

An API gateway or consent management platform operated by a US entity is an ICT third-party service provider under DORA. The financial entity using it must assess whether it can exercise the audit rights DORA requires, whether the provider can contractually guarantee that law enforcement access will be disclosed, and whether it has a credible exit plan. For most US-headquartered providers, the honest answer to all three questions is no. The CLOUD Act contains a gag-order mechanism that can prohibit the provider from notifying customers of a disclosure request.

The EBA also reported that ICT and security incidents at EU financial institutions increased by 36 percent between 2021 and 2022, a trajectory that makes the addition of mandatory open API infrastructure a material risk amplifier without sovereign-grade controls.

GDPR Article 46 Transfer Impact Assessments for FIDA Data Flows

Every time customer financial data flows from a FIDA-compliant API endpoint through a US-controlled intermediary, that transfer requires a legal basis under GDPR Chapter V. Standard Contractual Clauses under Article 46 are the most common mechanism, but the Schrems II ruling of the Court of Justice of the EU (Case C-311/18, July 2020) established that SCCs are only valid when the data exporter can demonstrate, through a Transfer Impact Assessment, that the receiving country provides essentially equivalent protection.

For financial data routed through US infrastructure, a TIA must evaluate FISA 702, Executive Order 12333, and CLOUD Act authorities. The European Data Protection Board’s Recommendations 01/2020 on supplementary measures make clear that technical measures (encryption, pseudonymisation) only satisfy the TIA if the importer cannot access the data in clear. An API gateway, by definition, processes data in clear to route it. There is no technical supplementary measure that resolves this contradiction for a US-controlled gateway handling financial API traffic.

Sovereign hosting eliminates the TIA requirement for the infrastructure layer entirely. A financial institution operating its own API gateway and consent platform within the EU, or in Switzerland under the adequacy decision covering the revised Swiss Federal Act on Data Protection (revFADP) (in force September 2023), does not transfer data to a third country. There is no Chapter V obligation to assess, no SCCs to negotiate, and no residual jurisdictional risk to document.

The Sovereign Infrastructure Stack for FIDA Compliance

A fully sovereign FIDA implementation comprises three self-hosted components: an API gateway, an OAuth 2.0 / OpenID Connect authorisation server, and a consent management platform. Each must run on infrastructure where the operator has no US corporate parent and where the physical servers are located in a jurisdiction not reachable by extraterritorial US law.

Swiss hosting adds a specific layer of protection relevant to financial institutions with Swiss operations or Swiss-resident customers. Swiss banking secrecy under Article 47 of the Banking Act (BankG) imposes criminal liability for unauthorised disclosure of client data, and the revised FADP aligns data protection standards with GDPR adequacy requirements. A FIDA-adjacent data sharing infrastructure hosted in Switzerland by a Swiss-domiciled provider is protected by both legal regimes simultaneously. Notably, the EU-Switzerland adequacy decision means that data flows from EU member states to such infrastructure do not require a TIA or SCCs.

IDSA Connectors and Gaia-X: A Sovereign Financial Data Space

The International Data Spaces Association (IDSA) Reference Architecture Model defines a connector as a certified component that enforces data usage policies at the point of exchange. Unlike conventional API gateways, which route data without intrinsic policy enforcement, an IDSA connector cryptographically binds each data flow to the conditions under which it was authorised: the identity of the data user, the permitted use case, the retention period, and the prohibition on onward transfer.

For FIDA compliance, this means that a financial data holder can publish data through an IDSA connector hosted entirely within its own controlled environment. The connector authenticates the data user against the relevant financial data sharing scheme registry, checks consent, enforces purpose limitation, and logs the transaction in a tamper-evident audit trail. No data transits a shared SaaS intermediary. The entire interaction is peer-to-peer between two sovereign nodes.

Gaia-X-compliant infrastructure extends this model by requiring that cloud services used within a data space be self-described in machine-readable credentials (Gaia-X Self-Descriptions) that include jurisdiction, sub-processor identities, and certification status. A financial data space built on Gaia-X-labelled nodes and IDSA connectors can demonstrate provably, at audit time, that no US-controlled intermediary was involved in any customer data flow.

This architecture directly addresses the DORA requirement for third-party risk management, because it removes the third party. The financial entity controls the connector, controls the authorisation logic, and controls the audit log. The IBM Cost of a Data Breach Report 2024 recorded the average global breach cost at USD 4.88 million, the highest ever measured. For financial institutions, breaches involving open API infrastructure tend to carry both direct financial exposure and supervisory sanction risk under DORA, making the investment in sovereign API infrastructure a defensible cost-reduction measure as well as a compliance obligation.

Former ECB Supervisory Board Chair Andrea Enria captured the stakes precisely: “Financial data is among the most sensitive personal data there is. Sharing it through open APIs without robust sovereignty controls is not open finance, it is open risk.” (ECB Supervisory Newsletter, www.bankingsupervision.europa.eu)

PSD3 and PSR: The Parallel Payment Data Layer

FIDA does not operate in isolation. The parallel legislative package of PSD3 and the Payment Services Regulation (PSR) modernises the PSD2 framework and tightens requirements for payment account data access. Together with FIDA, these instruments create a layered open finance architecture where payment data flows (PSR) and broader financial data flows (FIDA) must both be API-accessible, both subject to explicit consent, and both governed by the same GDPR and DORA obligations. Institutions building sovereign infrastructure for FIDA compliance should design it to handle PSR-mandated payment data flows on the same stack, avoiding a situation where payment data remains on sovereign infrastructure while broader financial data is routed through a US-controlled FIDA gateway.

Building the Compliance Evidence Chain

Compliance officers and DPOs facing FIDA implementation need an evidence chain that satisfies at least four parallel frameworks simultaneously: FIDA scheme membership requirements, DORA ICT risk management documentation, GDPR data transfer lawfulness records, and national financial supervisory reporting. Sovereign infrastructure simplifies this substantially. When the API gateway, authorisation server, consent platform, and IDSA connector all run on jurisdiction-confirmed infrastructure under the financial entity’s control, the evidence chain collapses into a single set of system logs, configuration records, and hosting contracts rather than a complex web of SCCs, TIAs, sub-processor agreements, and DORA third-party risk assessments.

The practical recommendation for CISOs and compliance officers beginning FIDA readiness assessments is to map every proposed component of the FIDA technical stack against three questions: Is the operator a US person or entity within the reach of the CLOUD Act? Can the provider guarantee notification of any government access request? Can the financial entity exercise meaningful audit rights consistent with DORA Article 30? If the answer to any of these questions is unfavourable, the component should be replaced with a sovereign alternative before FIDA technical standards are finalised and the implementation clock begins.

FAQ

Does FIDA require financial institutions to share data in real time through standardised APIs?

COM(2023) 360 mandates that data holders make customer financial data available through standardised interfaces on request from authorised data users. The exact latency requirements will be set in implementing technical standards, but the architecture clearly assumes API-based, near-real-time access rather than batch file transfers.

Can a financial institution use a US-based API gateway to fulfil FIDA obligations if it includes Standard Contractual Clauses?

Standard Contractual Clauses alone are insufficient when the data processor is subject to the CLOUD Act or FISA 702, because those statutes can compel disclosure regardless of contractual obligations. A Transfer Impact Assessment under GDPR Article 46 would need to demonstrate that supplementary measures reduce residual risk to essentially equivalent protection, which is extremely difficult for financial data flowing through a US-controlled gateway in clear text.

How does DORA change the risk calculus for FIDA infrastructure choices?

DORA Regulation (EU) 2022/2554 requires financial entities to manage ICT third-party risk within their own risk framework, maintain exit strategies, and ensure contractual provisions include audit rights and data location controls. A US-headquartered API aggregator or consent platform may not be able to satisfy DORA requirements for oversight, subcontracting transparency, and jurisdiction-specific data access controls, making it a material ICT risk concentration that supervisors can directly challenge.

What makes Swiss hosting under the revised FADP particularly relevant for FIDA data flows?

The revised Swiss Federal Act on Data Protection, in force since September 2023, aligns with GDPR adequacy standards and is reinforced by Swiss banking secrecy rules under the Swiss Banking Act. A consent platform or API gateway hosted in Switzerland by a Swiss-domiciled provider with no US parent is not reachable by CLOUD Act warrants or FISA 702 orders, and data flows from EU member states to such infrastructure do not require a TIA under the EU-Switzerland adequacy decision.

What is an IDSA connector and why does it matter for sovereign FIDA compliance?

An IDSA connector is a certified software component that enforces data usage policies at the point of exchange, binding each data flow to the consent conditions, permitted purposes, and identity of the authorised data user. In a FIDA context, deploying IDSA connectors on sovereign infrastructure means customer financial data never passes through a foreign-controlled intermediary: usage policy enforcement happens entirely within the data holder’s own jurisdiction-controlled environment, with a tamper-evident audit trail directly usable for DORA and GDPR documentation.