Under PSD2 a bank could comply on its own. Build the endpoint, publish the specification, meet the availability target, done. The European Commission's Financial Data Access proposal removes that option. Compliance runs through a Financial Data Sharing Scheme — a framework agreement negotiated between data holders, data users and customer representatives — and no institution can constitute one alone. The technical work is the smaller half. The larger half is a commercial negotiation about scope, standards, liability and price, and it is happening now, while most banks wait for a final text.
Executive Summary
- Status matters before strategy. FiDA was proposed in June 2023 as part of the financial data access and payments package. It appeared on a leaked 2025 withdrawal list, survived into the final work programme, and remains in trilogue. Nothing below is settled law.
- The scheme is the regulatory object. Financial Data Sharing Schemes set the common standards, interface requirements, liability terms and dispute mechanisms. A bank's exposure is determined by rules it either helps write or inherits.
- Compensation reframes the whole exercise. Once access carries a price linked to the cost of provision, a bank needs a defensible cost model, not just an API gateway. Very few have one.
- The build is not the API. Most institutions can expose an endpoint. Far fewer can locate, normalise and quality-assure mortgage, pension and insurance data that has never left its product silo.
The Regulation That Nearly Did Not Happen #
Any strategy built on FiDA has to start with an honest statement of where the file actually is.
The Commission proposed it in June 2023, alongside the payments package that carries PSD3 and the Payment Services Regulation. In early 2025 a leaked draft of the Commission's work programme suggested FiDA might be withdrawn — reported at the time as a response to concerns about the burden on EU financial institutions. The final work programme kept it among pending proposals, and negotiation continued. It has been through trilogue and the institutions are working toward political agreement, with obligations expected to phase in after adoption as schemes are established.
Two things follow from that history, and they pull in opposite directions.
The proposal is politically survivable but not politically safe, so a programme that assumes the current text will emerge unchanged is exposed. Scope, timing and the compensation mechanism are precisely the provisions that move in trilogue.
At the same time, the parts most likely to survive are the structural ones — scheme-based governance, permission dashboards, compensation in principle — because they are the architecture of the proposal rather than its parameters. Those are also the parts with the longest build lead time.
The correct posture is therefore neither "wait for the final text" nor "build to the current draft". It is to build the capabilities that every plausible version requires, and to be present where the parameters are decided.
Three Structural Breaks From PSD2 #
Treating FiDA as PSD2 with a wider endpoint list is the mistake that will cost the most.
Table 1: What actually changes #
| Dimension | PSD2 | FiDA as proposed |
|---|---|---|
| How you comply | Build and publish an interface; a unilateral act | Join a Financial Data Sharing Scheme; a multi-party agreement |
| Data in scope | Payment accounts | Mortgages, loans, savings, investments, crypto-assets, pensions, non-life insurance |
| Cost of access | Free to the third party | Data holders may seek reasonable compensation linked to the cost of provision |
| Who sets the standard | The regulator sets outcomes; each bank picks an implementation | The scheme sets common standards and interface requirements |
| Customer control | Consent per-connection | A permission dashboard the data holder must provide |
| Where the risk sits | Availability and security of your interface | Also: scheme terms, contractual liability allocation, and dispute outcomes |
The first and third rows are the ones that change the shape of the programme.
The Scheme Is the Regulatory Object #
Under PSD2, a bank's compliance surface was its own API. Under FiDA as drafted, the compliance surface is a rulebook negotiated with counterparties, including the firms that want your data.
A Financial Data Sharing Scheme is a framework agreement among data holders, data users and consumer or customer representatives. It is expected to develop the common standards for data sharing and interface requests, set the contractual liability of its members, and provide a working dispute-resolution mechanism.
Read that list as a risk register and the implication is uncomfortable. Someone is going to decide how liability is allocated when a data user mishandles customer data obtained through your interface. Someone is going to decide what data quality standard you are held to, and what constitutes a valid request. If a bank is not in the room, those decisions are made by parties whose commercial interest is to have broad access, low prices and liability that sits with the holder.
This is the single most under-resourced part of the average FiDA programme. Institutions have assigned architects and no negotiators.
Compensation Turns a Duty Into a Product #
PSD2 obliged banks to give payment-account access away. The FiDA proposal takes a different position: data holders may seek reasonable compensation from data users, tied to the cost of making the data available, on a methodology that is objective, transparent and non-discriminatory.
That single change converts an obligation into something closer to a regulated product line — and it demands a capability most banks have never needed.
Table 2: What a defensible compensation position has to answer #
| Question | Why it is hard | What you need before you can price |
|---|---|---|
| What does provision actually cost? | Costs are spread across infrastructure, security, support and compliance, none of which are currently allocated to a data product | A cost model attributing shared platform cost to data provision |
| Is the methodology non-discriminatory? | Different data users will have very different volumes and margins | A published schedule that survives scrutiny from a scheme member who dislikes it |
| Does it scale down? | Compensation is meant to be oriented toward the market's lowest levels, not to price access out | A structure that works for a small data user, not only a large one |
| Can you evidence it? | A price is a supervisory and competitive artefact once it is published | Auditable derivation, not a negotiated number |
The institutions that will handle this well are the ones that start costing data provision now, while it is still an internal exercise, rather than in a scheme negotiation where the number becomes a position they have to defend.
The Build Is Not the API #
The technical work that matters is not the interface. It is everything behind it.
Payment-account data was already structured, already real-time, already owned by a single system with a single owner. Mortgage, pension, investment and insurance data is none of those things. It sits in product silos of different ages, with different customer identifiers, different reference data and different definitions of the same field. Some of it exists only in documents.
Three capabilities carry the lead time, and none of them depends on the final text.
A customer-entity resolution layer. Serving a data request means knowing that the mortgage customer, the pension holder and the current-account holder are the same person, with confidence high enough to release data on it. Most institutions discover their identity resolution is weaker than assumed at exactly the moment they try.
Product data normalisation. A scheme will define common formats. Whatever they turn out to be, the work of mapping legacy product data to any external standard is the same work, and it is the largest item in the plan.
Permission state as infrastructure. A dashboard is a view. Underneath it must sit a durable, auditable record of which permission was granted, by whom, over what data, for how long, and when it was withdrawn — queryable in real time by every system that serves a request. Institutions that build the dashboard before the permission ledger build the thing they will have to rebuild.
The Operating Playbook #
- Put someone in the scheme conversation. Not an architect — a commercial negotiator with a mandate on liability and pricing. This is the highest-leverage action available and the one most often deferred.
- Cost data provision now. Build the attribution model while it is an internal question. A compensation methodology invented under negotiating pressure will not survive scrutiny.
- Start entity resolution before scope is settled. Every version of FiDA requires knowing your customer is one customer. Nothing about that changes in trilogue.
- Build the permission ledger, not the dashboard. The visible artefact is a week of front-end work. The record underneath it is the part with a two-year tail.
- Inventory the silos honestly. Identify which in-scope products cannot currently produce structured, current data at all. That list is the real programme plan.
- Track scope, not headlines. The parameters most likely to move in trilogue — which products, which data, what timing — are exactly the ones your plan should be able to absorb without redesign.
PSD2 taught banks to treat open data as a compliance cost to be minimised. That instinct is the wrong starting point here. When access is priced, scoped by negotiation, and covers the products a bank actually earns on, the institutions that treat it as a market will set terms for the ones that treat it as a burden.
Frequently Asked Questions #
Is FiDA law yet?
No. It was proposed in June 2023 as part of the financial data access and payments package and remains in the EU legislative process, having gone through trilogue. It was included on a leaked withdrawal list in early 2025 and then retained in the Commission's final work programme. Scope, timing and the compensation mechanism are all provisions that can still move.
How is it different from PSD2 in practice?
Three ways that matter. Compliance runs through a Financial Data Sharing Scheme rather than an interface you build alone; data holders may seek reasonable compensation instead of providing access free; and the data in scope extends well beyond payment accounts to mortgages, loans, savings, investments, crypto-assets, pensions and non-life insurance.
What is a Financial Data Sharing Scheme?
A framework agreement among data holders, data users and customer or consumer representatives. It is expected to set the common data and interface standards, allocate contractual liability among members, and provide dispute resolution. Because it defines the terms you will be held to, membership and influence are strategic rather than administrative questions.
If the text is not final, what can we usefully build now?
The parts every version needs: customer entity resolution across product silos, normalisation of legacy product data toward an external standard, and a durable permission ledger beneath the dashboard. None of those depend on how scope or timing settle, and all three have long lead times.
Should we resist FiDA or lean into it?
Resisting a proposal that has already survived a withdrawal attempt is a poor use of the remaining window. The more productive question is whether your institution is a net data holder or a net data user in the segments you care about — because that determines whether you want the compensation methodology high or low, and that argument is settled in the scheme, not in Brussels.
References #
- European Commission, 2023. Financial data access and payments package. Brussels: Directorate-General for Financial Stability, Financial Services and Capital Markets Union. Available at: European Commission, 2023..
- European Commission, 2023. Proposal for a Regulation on a framework for Financial Data Access, COM(2023) 360. Brussels: European Commission. Available at: European Commission, 2023..
- European Parliament, 2026. Legislative Train Schedule: a new open finance framework. Brussels: European Parliament. Available at: European Parliament, 2026..
- European Parliament and Council of the European Union, 2015. Directive (EU) 2015/2366 on payment services in the internal market (PSD2). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2015..
Last reviewed .