What the Cloud and AI Data Act Means for FIDA Infrastructure Teams

The European Commission adopted the Cloud and AI Data Act (CADA) on 3 June 2026, as part of its digital tech sovereignty package. Most FIDA compliance teams have not yet mapped the connection to open finance infrastructure. Here is why they should.

CADA and FIDA converge on the same infrastructure layer. Both create obligations on how and where financial institutions process and share data. Both arrive in overlapping timeframes. The organisations that understand this now will build their data infrastructure once. The ones that treat them as separate compliance projects will build twice.

What CADA Is

CADA is the EU's framework for cloud data sovereignty. Where the GDPR governs how personal data is used, CADA governs where sensitive EU data — including financial, health, and judicial data — is processed and stored. The Commission's proposal introduces requirements that would apply to cloud providers handling designated categories of sensitive data, with specific restrictions on providers subject to non-EU government access laws such as the US CLOUD Act.

CADA's core provisions are expected to include cloud data residency requirements for sensitive EU data, restrictions on hyperscale cloud platforms subject to foreign government access laws, EU data centre capacity targets to reduce dependency on non-EU providers, and sovereignty requirements extending to AI systems processing designated data categories. CADA is now a Commission proposal entering standard EU legislative procedure — co-decision with the European Parliament and Council — and will likely take 18 to 24 months to reach final adoption.

Why CADA Matters for FDSS Infrastructure

Financial Data Sharing Schemes (FDSS) under FIDA will operate as the central trust infrastructure of the EU open finance ecosystem. They route permissions between Financial Information Service Providers (FISPs) and data holders, maintain FISP registries, manage consent flows, and govern access rules. This infrastructure will almost certainly be cloud-hosted.

If CADA designates financial data processed through FDSS routing infrastructure as sensitive EU data requiring sovereignty-compliant processing, FDSS operators face a direct architecture constraint. Building FDSS infrastructure on hyperscale cloud platforms subject to non-EU jurisdiction may create a compliance gap when CADA is law. Organisations planning to operate as FDSS should include CADA sovereignty criteria in their infrastructure procurement decisions now, before architectural commitments are locked in.

The Impact on FISP API Architecture

FISPs processing customer financial data under FIDA — account balances, transaction histories, insurance policy data, pension fund values — will face a dual compliance question: does our cloud infrastructure meet DORA's ICT risk management requirements, and does it meet CADA's data sovereignty requirements?

For FISPs that have designed their architecture on the assumption of unrestricted access to major hyperscale cloud providers, CADA introduces a potential compliance gap. Cloud infrastructure spend committed in 2026 and 2027 — before CADA is final law — may need to be restructured when it is. The earlier this gap is identified, the lower the cost of addressing it. FISPs committing cloud architecture decisions now should model both DORA and CADA constraints before signing infrastructure agreements.

Three Regulations, One Infrastructure Decision

DORA, CADA, and FIDA each impose requirements on the same infrastructure layer — and they are typically managed in separate compliance workstreams. This creates a structural risk.

DORA requires resilience and ICT third-party risk management for financial entities' cloud providers. CADA adds a sovereignty dimension — where data is processed and by whom. FIDA requires open, certified API access to customer financial data through this infrastructure. A FIDA-compliant API running on cloud infrastructure that fails either DORA's concentration risk framework or CADA's sovereignty requirements is a compliance liability when both regulations are simultaneously in force.

Compliance teams assessing FIDA infrastructure readiness should evaluate their planned cloud providers against DORA and CADA criteria simultaneously. The interaction is not theoretical — it is the architecture decision being made right now, before CADA is finalised.

What to Do Before CADA Is Final Law

CADA will take 18 to 24 months to reach final adoption — but the infrastructure decisions it will constrain are being made today. Three actions for organisations building FIDA compliance infrastructure:

• First, audit your planned FIDA API and FDSS infrastructure against CADA's sovereignty criteria as published in the Commission proposal. Do this before committing cloud architecture spend.

• Second, add CADA to your FIDA programme governance as a standing watch item — the proposal text is published and the risk assessment can begin now.

• Third, engage with FDSS scheme formation processes with CADA sovereignty requirements in mind. Scheme rules will need to reflect these requirements, and early participants influence how those rules are drafted.

InfraFIDA provides FIDA-compliant data sharing infrastructure and tracks the intersection of CADA, DORA, ESAP, and FIDA for compliance infrastructure teams. If you are building FIDA readiness and have not yet assessed your cloud architecture against CADA's sovereignty framework, that assessment belongs at the start of your architecture review — not the end.