What is FIDA?
FIDA — the Financial Data Access Regulation — is the EU's framework to create a genuine open finance ecosystem, giving customers control over their financial data and enabling authorised third parties to access it.
The European Commission proposed FIDA in June 2023 as part of a broader retail financial services strategy. Where PSD2 applied only to payment accounts, FIDA extends the data-sharing logic to almost every retail financial product: savings, investments, insurance, pensions, mortgages, and beyond.
FIDA creates a permission-based data access system. Financial institutions ("data holders") must make customer data available via standardised interfaces to authorised third parties ("FISPs" — Financial Information Service Providers), but only when the customer has explicitly granted consent through a "financial data sharing scheme."
Think of FIDA as "PSD2 for everything else." If you hold a pension, an insurance policy, or an investment account with a bank or insurer, FIDA would give you — and third parties you authorise — the legal right to access, download, or transfer that data. The institution must provide it via a standardised, machine-readable API.
What Data & Products Are In Scope?
FIDA applies to a broad range of financial products and the customer data associated with them. The scope is significantly wider than PSD2.
| Product Category | Examples | Data Covered | In Scope? |
|---|---|---|---|
| Mortgage & credit | Home loans, personal loans, credit cards | Balances, repayment schedules, rates, arrears status | ✅ Yes |
| Savings & deposits | Current accounts, savings accounts, term deposits | Balances, transactions, interest rates | ✅ Yes |
| Investments | MiFID portfolios, retail funds, ETFs | Holdings, valuations, performance, fees paid | ✅ Yes |
| Insurance | Life, home, motor, health insurance | Policy terms, premium data, claims history | ✅ Yes |
| Pensions | Occupational pensions, PRSAs, pan-European PPP | Contributions, projected benefits, fund allocation | ✅ Yes |
| Crypto assets | MiCA-regulated crypto services | Holdings, transaction history | ✅ Yes (MiCA scope) |
| Payment accounts | Current accounts, e-money wallets | Transactions, balances | ⚠️ PSD2 / PSD3 (not FIDA) |
Payment account data (current accounts, debit/credit card transactions) remains under PSD2/PSD3, not FIDA. FIDA deliberately avoids double-regulation of the payments data already covered by the payments directive framework. In practice, banks will need to manage both regimes simultaneously.
Who Are the Key Players?
FIDA introduces a clear set of roles and responsibilities. Understanding who does what is essential to understanding the regulation's mechanics.
Data Holders
Financial institutions that hold customer financial data — banks, insurers, pension providers, investment firms. They must provide standardised API access to that data when customers give permission. They bear the cost of building and maintaining the interfaces.
FISPs
Financial Information Service Providers — authorised third parties that access customer data via APIs to offer services like financial dashboards, comparison tools, credit scoring, robo-advice, or aggregation. Must be authorised by a national competent authority and registered in a public EU register.
Data Subjects
The customer — individual or business — whose financial data is being accessed. They have the right to grant, modify, and withdraw consent via a "permission dashboard." Access is always customer-initiated; no data can be pulled without explicit authorisation.
Financial Data Sharing Schemes
Industry-led bodies (or potentially supervisory bodies) responsible for developing the common standards, technical specifications, and governance rules that data holders and FISPs must comply with. Similar in concept to the Berlin Group under PSD2.
Competent Authorities
National regulators (e.g. CBI in Ireland, BaFin in Germany) are responsible for authorising and supervising FISPs. The EBA and EIOPA will develop technical standards and guidelines. ESAs have a coordination role across the framework.
ESAs & Commission
The European Banking Authority (EBA) and European Insurance and Occupational Pensions Authority (EIOPA) will draft Regulatory Technical Standards (RTS) governing API design, data formats, security requirements, and customer dashboard specifications.
How Does FIDA Work in Practice?
Below is the end-to-end data-sharing journey under FIDA, from customer consent to data delivery.
Customer Initiates
The customer — through an app, web portal, or FISP interface — decides they want a third-party service to access their financial data (e.g. a financial aggregator wants to show their pension alongside their investments). They are presented with a clear, standardised consent request.
Permission Granted via Dashboard
The customer grants permission via their "permission dashboard" — a standardised interface that data holders must provide. The permission specifies: which data, to which FISP, for how long, and for what purpose. Permissions are granular and revisable.
FISP Authenticates & Requests Data
The authorised FISP connects to the data holder's API using strong authentication. The FISP must present its EU authorisation credentials. The request is scoped strictly to the data for which the customer has granted permission — no broader access is possible.
Data Holder Responds
The data holder's API returns the requested data in a standardised, machine-readable format defined under the relevant Financial Data Sharing Scheme's technical standards. Data holders cannot charge the customer for this access (though compensation arrangements between institutions and FISPs are permitted).
FISP Delivers Service
The FISP uses the data to deliver its service — a consolidated dashboard, a personalised recommendation, a creditworthiness assessment, or portfolio analytics. The FISP may not use the data for purposes beyond those disclosed when seeking consent.
Customer Can Revoke at Any Time
The customer retains the right to withdraw consent at any time via their permission dashboard. Upon revocation, the FISP must immediately cease data access and (subject to scheme rules) delete or return any data previously obtained.
Unlike PSD2 (where data holders cannot charge FISPs for access to payment data), FIDA allows a reasonable compensation model between data holders and FISPs. The rules governing such compensation will be set within Financial Data Sharing Schemes, subject to regulatory oversight. This was a key concession to banks during the proposal process.
FIDA vs PSD2: What Changes?
FIDA is often described as "the extension of PSD2 to all financial data." While the underlying logic is similar, the differences are material.
The Commission is simultaneously revising PSD2 into PSD3 (a Directive) alongside a new Payment Services Regulation (PSR). FIDA is designed to sit alongside, not replace, these instruments. Payment data stays in PSD3/PSR. Overlap between the frameworks — particularly for multi-product institutions — is a key implementation challenge.
FIDA Timeline
FIDA is still moving through the EU legislative process. The below reflects key milestones as of early 2026.
What Does FIDA Mean for Banks?
For established credit institutions, FIDA is both a compliance burden and a strategic inflection point. The impact spans operations, technology, business model, and customer relationships.
Obligations on Banks as Data Holders
Banks must build and maintain standardised APIs for all in-scope product data. This is a significant technical investment — analogous to (but broader than) the PSD2 API buildout. Key obligations include:
🔧 API Build & Maintenance
Banks must develop and operate APIs conforming to the technical specifications set by Financial Data Sharing Schemes. Unlike PSD2 where many banks used third-party API providers, the FIDA scope is wider and will require broader internal data architecture changes — particularly for products like insurance and pensions that may sit in legacy systems.
🖥️ Permission Dashboard
Each data holder must provide customers with a "permission dashboard" — a clear, accessible interface showing all active data-sharing permissions, who can access what data, for how long, and for what purpose. Customers can revoke individual permissions through the dashboard. Banks that lack modern digital channels face added UX complexity here.
📋 Scheme Membership
Data holders must participate in at least one Financial Data Sharing Scheme covering each product category in which they operate. If no scheme exists for a product category (or no scheme meets the regulatory requirements), the Commission may designate a mandatory scheme. Banks operating across multiple product lines may need to participate in multiple schemes.
🔐 Data Security & Liability
Banks remain responsible for the security of data within their systems. Under FIDA, liability is allocated based on fault: if a data breach occurs at the data holder's API, the bank is liable. If the breach occurs at the FISP end, the FISP is liable. Banks must implement robust authentication and logging for all FIDA API calls.
Strategic Considerations
Beyond compliance, FIDA will reshape competitive dynamics in financial services. Banks should assess both defensive and offensive strategic responses.
⚡ Competitive Disruption Risk
Authorised FISPs — including fintechs, neobanks, and BigTech players — will gain direct API access to a bank's customer relationships across insurance, pensions, investments, and credit. This could accelerate customer switching, enable competitive product targeting using a customer's own data, and erode the information advantage that incumbent banks have historically enjoyed.
💰 Revenue Opportunity (FISP Licensing)
Banks can themselves become FISPs — accessing competitor data (with customer consent) to improve their own advisory, aggregation, or switching services. Large universal banks with strong digital channels could use FIDA to build comprehensive financial health dashboards for customers, drawing in data from competitor accounts.
📊 Compensation Negotiations
Unlike PSD2, FIDA permits data holders to seek reasonable compensation from FISPs for API access. The precise parameters will be governed by scheme rules. Banks should actively participate in scheme governance to influence what "reasonable" means — the precedent set in early schemes could define the economics of open finance for a decade.
🌍 Cross-Border Complexity
Banks operating across multiple EU member states must coordinate FIDA compliance centrally, while navigating different NCA supervisory approaches. The "home state" principle should limit duplicative authorisation for FISPs, but data holders may face varying local expectations on dashboard design, audit requirements, and dispute resolution.
For Irish banks (AIB, Bank of Ireland, PTSB), FIDA adds to an already demanding regulatory implementation pipeline alongside PSD3/PSR, DORA, and the EU AI Act. The Central Bank of Ireland will be the lead NCA for FISP authorisation of Irish-domiciled entities. Given the concentration of the Irish market, the competitive disruption from cross-border FISPs — including neobanks already strong in Ireland — may be more acute than in larger EU markets.
Frequently Asked Questions
❓ Does FIDA give third parties the right to make payments on my behalf?
No. FIDA is a read-only framework in its initial form. It grants FISPs the right to access and view financial data, not to initiate transactions or instruct payments. The right to initiate financial transactions (e.g. payments, investments) remains within PSD2/PSD3 for payment services, and is not extended to other financial products under the current FIDA proposal.
❓ How does FIDA interact with GDPR?
FIDA and GDPR are complementary but distinct. GDPR's "right to data portability" (Article 20) already gives individuals the right to receive personal data in a machine-readable format. FIDA goes further by mandating that financial institutions provide standardised, interoperable API access — not just downloads — and covers business customers as well as individuals. FISPs are data processors under GDPR and must have a lawful basis (consent) for processing. The two frameworks must be applied jointly, and DPIAs will be required for many FISP use cases.
❓ What happens if no Financial Data Sharing Scheme exists for a product?
FIDA includes a "backstop" mechanism. If industry fails to establish a compliant scheme for a product category within the required timeframe, the European Commission has the power to designate a mandatory scheme or specify minimum standards directly. This is designed to prevent institutions from delaying compliance by stalling scheme formation — a lesson learned from the uneven PSD2 API rollout.
❓ Will FISPs face lighter regulation than banks?
FISPs will be subject to a new, specific authorisation regime — lighter than a full banking licence, but substantive. Requirements include: fit and proper management, minimum capital requirements, professional indemnity insurance, data security standards, and ongoing supervisory reporting. The framework is analogous in some respects to the AISP regime under PSD2, but broader given the wider data access rights. Critically, FISPs are restricted in how they can use data — only for the purpose stated when consent was obtained.
❓ What are the penalties for non-compliance?
The FIDA proposal includes administrative penalties aligned with the approach used in other financial services regulation. NCAs will have powers to issue fines, impose corrective measures, and — in serious cases — withdraw authorisation from FISPs. The Commission's proposal aligns penalty levels with GDPR-style maximum thresholds (percentage of annual turnover), though final penalty provisions remain subject to trilogue negotiation.
❓ Is FIDA relevant for non-EU banks operating in Europe?
Yes. Third-country banks operating in the EU through branches or subsidiaries that hold in-scope financial product data for EU customers will be subject to FIDA as data holders. Similarly, non-EU fintechs wishing to operate as FISPs in the EU must seek authorisation from an EU NCA. FIDA has explicit extraterritorial reach for data pertaining to EU-based customers, regardless of where the data holder is domiciled.