What FiDA means for fintech product roadmaps

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.

The problem FiDA is solving

PSD2 created open banking in the EU. It worked, imperfectly, for payment accounts. A customer at a bank could authorise a third-party application to access their transaction history, initiate payments on their behalf, and build services on top of that data. That worked well enough to produce a functioning ecosystem of account aggregators, personal finance tools, and payment initiation services.

What PSD2 did not touch was the rest of a customer’s financial life. Their investment portfolio, held at a brokerage. Their pension entitlements, spread across two or three schemes. Their insurance policies, their mortgage, their savings account that does not support direct debit. All of that data sat in silos, each institution providing no standardised access route, each requiring the customer to log in separately, provide statements manually, and reassemble their own financial picture by hand.

The Financial Data Access Regulation, known as FiDA, is the legislative proposal that changes this. Proposed by the European Commission in June 2023 as part of the same digital finance package as PSD3 and the Payment Services Regulation, FiDA extends the open banking model across the full spectrum of financial services. It mandates standardised, API-based access to customer data across mortgages, savings, investments in financial instruments, crypto-assets, non-life insurance products, occupational and personal pension rights, and creditworthiness data held on firms.

It is still in trilogue as of July 2026. The timeline to application is uncertain. But the destination is not in serious doubt, and the product and infrastructure decisions that FiDA requires are the kind that cannot be made in six months. This article covers what FiDA actually requires, who it applies to, how it is likely to land after the current negotiations, and what fintechs should be doing now.

What FiDA requires: the core obligations

The proposal establishes a framework built around three interlocking obligations.

Data holders must share on customer request

Any regulated financial institution holding in-scope customer data becomes a data holder under FiDA. When a customer requests that their data be shared with an authorised third party, the data holder must make it available without undue delay, continuously, and in real-time, through a standardised API. The data must be delivered in a format based on generally recognised standards, and at the same quality as the data holder uses internally. There is no charge to the customer. There is potential compensation from the data user to the data holder, set through the scheme framework described below.

The data categories in scope are defined in Article 2 of the proposal and cover:

• Mortgage credit agreements, loans, and accounts (excluding payment accounts already covered by PSD2), including balance, conditions, and transaction data
• Savings and investments in financial instruments, insurance-based investment products, and crypto-assets, including suitability and appropriateness assessment data
• Occupational and personal pension rights
• Non-life insurance products (excluding life, health, and sickness insurance), including data from demands and needs assessments
• Creditworthiness data on firms, collected as part of a loan application or credit rating request

Payment accounts are explicitly excluded. They remain governed by PSD2 and, when the package is finalised, the PSR. Consumer creditworthiness data is also excluded, specifically to avoid enabling financial exclusion through risk-profile targeting.

Data users must be authorised

Third parties seeking access to this data cannot simply request it. They must be authorised. FiDA creates a new licensing category: Financial Information Service Providers (FISPs). A FISP is a firm that is not already a regulated financial institution but wants to access customer financial data to provide information services on that data: aggregation, analysis, advisory tools, portfolio dashboards, comparison services.

Firms that are already licensed financial institutions (investment firms, payment institutions, credit institutions, crypto-asset service providers, insurance undertakings, and others listed in Article 2(2) of the proposal) can act as data users without a separate FISP licence. A licensed CASP that wants to pull a customer’s investment and pension data alongside their crypto holdings is already in scope as a regulated entity. An independent fintech building a financial management platform that is not itself a regulated financial institution needs a FISP authorisation.

FISP authorisation is granted by a national competent authority in the member state where the FISP has its principal establishment. It carries an EU passport, allowing the FISP to access data from data holders in other member states once authorised. EBA will maintain a public register of authorised FISPs and financial data sharing schemes.

All FISPs are also required to comply with DORA, the Digital Operational Resilience Act, with requirements scaled to their size and risk profile. This is not a light obligation. For an unregulated fintech seeking FISP status, it means building ICT risk management, incident reporting capability, and business continuity planning before the licence is granted.

Financial Data Sharing Schemes govern the mechanics

The operational layer sits in Financial Data Sharing Schemes (FDSS). These are industry-governed contractual frameworks that data holders and data users must belong to in order to exchange data under FiDA. Scheme membership is mandatory for anyone seeking to participate in the FiDA data-sharing ecosystem.

Each scheme must define:

• Common data standards and API specifications for the categories it covers
• A joint contractual framework governing access terms, liability, and dispute resolution
• Governance rules ensuring balanced representation of data holders, data users, and consumer organisations
• Compensation rules, including the methodology for what data holders can charge data users for API access
• Coordination mechanisms for permission dashboards

The Commission’s original proposal gave industry 18 months from the regulation entering into force to establish the required schemes. If no scheme is established for a given data category within that window, the Commission can step in and impose one by delegated act. In the April 2026 non-paper that restarted the stalled negotiations, the Commission proposed moving to a phased rollout, with schemes established first and mandatory data sharing following, with evaluation points between phases.

Permission dashboards give customers control

Every data holder must provide customers with a financial data access permission dashboard. This is an interface, accessible online, where customers can see all active permissions they have granted to data users, grant new permissions, and withdraw existing ones in real-time. Data holders must notify data users immediately when a permission is withdrawn. Data users must notify data holders immediately when a new or re-established permission is granted.

The dashboard must retain a record of withdrawn and expired permissions for up to two years, to give customers a complete picture of how their data has been shared. The proposal specifically prohibits interface design that encourages or unduly influences permission decisions.

For fintechs building on FiDA access, the dashboard is the permission infrastructure on which their product depends. A data user’s access is live only as long as the customer has granted permission through the data holder’s dashboard. Changes in that permission state must flow to the data user in real-time. Products that treat FiDA permissions as a one-time onboarding step rather than a live state will break.

Who this applies to: the entity map

FiDA applies to a broad range of financial institutions as data holders, and an equally broad set as potential data users. The entity categories in scope as either data holders or data users under Article 2(2) of the proposal include:

• Credit institutions
• Payment institutions (including AISPs and exempt payment institutions)
• Electronic money institutions
• Investment firms
• Crypto-asset service providers
• Issuers of asset-referenced tokens
• Managers of alternative investment funds
• UCITS management companies
• Insurance and reinsurance undertakings
• Insurance intermediaries and ancillary insurance intermediaries
• Institutions for occupational retirement provision
• Credit rating agencies
• Crowdfunding service providers
• PEPP providers
• Financial Information Service Providers (newly created by FiDA)

Small institutions for occupational retirement provision (fewer than 15 members in total across all schemes) and small insurance intermediaries (microenterprises and SMEs) are carved out of the data holder obligations. SMEs acting as data holders can establish shared APIs jointly or use pooled external providers to reduce implementation costs.

For fintechs specifically, the key question is whether you are already a regulated financial institution. If you hold a MiCA CASP licence, an investment firm authorisation, a payment institution licence, or any other financial services authorisation listed above, you can act as a data user under FiDA without a separate FISP licence. Your existing authorisation is sufficient. If you are not a regulated financial institution, FISP authorisation is the route to data access, with all the operational resilience and supervisory obligations that entails.

The relationship with PSD3 and PSR

FiDA and the PSD3/PSR package were proposed together and are designed as a coherent legislative architecture, but they are proceeding on different timelines and have distinct scopes.

PSD3 and PSR reached political agreement in November 2025 and are expected to be published in the Official Journal in summer 2026, with application obligations landing in early-to-mid 2028. They modernise the open banking framework for payment accounts, improving API quality requirements, extending consent dashboards to payment data, and closing the regulatory arbitrage that PSD2’s directive structure permitted. See PSD3 and PSR: what changes for fintechs for the detailed breakdown.

FiDA is still in trilogue and substantially later in timeline. The practical relationship is this: PSD3 and PSR set the floor: payment account data, well-defined, applying from 2028. FiDA raises the ceiling to the full financial data estate, on a timeline that is currently somewhere between 2029 and 2031 depending on how the negotiations conclude.

For fintechs, this means two related but distinct compliance programmes. The PSR infrastructure (API connectivity, fraud liability, SCA, consent dashboards for payment data) needs to be operational by 2028. FiDA-specific obligations, including FDSS membership, extended API connectivity, FISP licensing if applicable, and permission dashboard integration for non-payment data, arrive later. But the architectural decisions taken for PSR will directly constrain what FiDA implementation looks like. Firms that treat these as unrelated programmes will rebuild work.

FiDA also has an explicit relationship with DORA. Both the data holders and data users under FiDA are required to comply with DORA’s operational resilience requirements. For firms already implementing DORA, which applies from 17 January 2025, FiDA adds a new category of ICT third-party relationships (the schemes and their technical infrastructure) and a new class of data access obligations that carry incident reporting implications. See DORA and ICT third-party risk: what financial firms must now prove for what DORA actually requires firms to demonstrate about their vendor and infrastructure relationships.

Where the trilogue negotiations stand and what is likely to change

The Commission’s original proposal was ambitious in scope and generated significant resistance from member states, particularly Germany and France, which pushed back on both the breadth of data categories and the compliance burden on smaller institutions. Trilogue negotiations stalled in June 2025. In April 2026, the Commission published a revised non-paper aimed at restarting the process, accepting several narrowing changes.

The direction of travel from the non-paper and subsequent negotiating positions gives a reasonable picture of how FiDA is likely to land:

Narrower initial scope. The non-paper proposed limiting the initial data-sharing obligation to transaction data from the past ten years and information from current active contracts. Historical data from terminated relationships would be out of scope initially. This changes the product economics for services that depend on long historical records, such as creditworthiness tools and pension aggregators.

Phased rollout. Rather than a single implementation deadline, the current direction is a staged approach: schemes established first, followed by mandatory data sharing, with evaluation points and potential scope adjustments between phases. The Commission estimates approximately four years of phased implementation from entry into force. Different data categories may go live at different points. Pension data and investment data are likely to be earlier phases; more complex insurance data may be later.

Narrower target group. The non-paper proposed focusing FiDA on consumers and SMEs, excluding large corporates (those with annual turnover above €50 million) from the initial scope. This reduces the compliance burden on data holders providing highly customised services to institutional clients, but also narrows the market opportunity for data-driven B2B services.

Simplified FISP licensing. The non-paper proposed reusing PSD2 AISP documentation and reducing duplicate procedures for firms already licensed under existing frameworks. For fintechs with existing payment institution licences, the path to FISP authorisation may be lighter than the original proposal suggested.

Big Tech gatekeeper question unresolved. Whether large non-EU technology platforms (Apple, Google, Meta, Amazon) can participate in FiDA as data users or FISPs remains actively contested. EU financial institutions and several member states favour significant restrictions on grounds of digital sovereignty and competitive balance. US Big Tech firms have substantial financial services infrastructure and the capability to exploit standardised financial data access at scale. How this resolves will materially affect the competitive landscape of the FiDA ecosystem.

Timeline scenarios as of July 2026:

The most contested single item in negotiations is the compensation mechanism between data holders and data users. Data holders, primarily banks and insurers, are resistant to being required to build and maintain costly APIs for free or at nominal cost. Data users want compensation capped at cost or below. The scheme framework is designed to resolve this through industry negotiation, but if schemes cannot reach agreement the Commission intervenes. How commercially viable the compensation structure turns out to be is one of the biggest open questions for the ecosystem’s development.

What product decisions cannot wait for the final text

Given the timeline uncertainty, the natural temptation is to defer FiDA-related planning until there is a final text to plan against. That is the wrong approach for three reasons.

First, the data categories in scope are settled enough to design against. Whether or not the final regulation looks exactly like the proposal, investments, pensions, mortgages, savings, and insurance data will be in scope. A product strategy that depends on accessing any of these data categories is a product strategy that needs a FiDA compliance pathway. The specific implementation details will change; the fundamental data access rights will not.

Second, the FDSS membership requirement means joining an industry structure. FiDA data access is not direct. It flows through approved schemes with standardised interfaces. Firms need to understand which schemes are being established for their relevant data categories and what participation looks like. Scheme governance is being drafted now, before the regulation is final. Firms that engage in that process influence the outcome; firms that wait to engage after the regulation passes implement other people’s decisions.

Third, FISP authorisation is a licensing process. If your product requires FISP status, the authorisation process involves DORA compliance, a national competent authority application, documentation of organisational requirements, and a passport notification for cross-border activity. That is not a six-month exercise. Firms that are not regulated financial institutions and want to access FiDA data need to begin scoping their authorisation pathway now, not when the final text is published.

The specific product questions worth resolving now:

Does your current product access data that will fall within FiDA scope? If you aggregate investment data, display pension information, or use insurance data as part of a product, you are in scope as a data user once FiDA applies.

Is your firm already a licensed financial institution under one of the categories in Article 2(2)? If yes, your existing authorisation is likely sufficient for data user status. If no, FISP licensing is your route, and you should start sizing that programme.

Which data categories are commercially most important to you? The phased rollout means some data will be available earlier than others. Prioritising your integration roadmap against likely phase sequencing gives you the right order of investment.

What does your consent and permission architecture look like? FiDA permissions are live state, not static grants. Your product’s data access will depend on real-time permission signals from data holders. A permission management layer that can receive and act on permission changes is a core infrastructure requirement, not a compliance add-on.

The FISP licensing pathway in outline

For fintechs that are not already regulated financial institutions, the FISP authorisation process under the proposal requires:

An application to the national competent authority in the member state of principal establishment, including documentation of the services to be provided, the data categories to be accessed, and the financial data sharing schemes of which the firm is or intends to be a member.

Organisational requirements covering governance structure, ownership, management body fit and proper assessment, and internal control frameworks. These mirror the requirements applied to other regulated financial entities.

DORA compliance across ICT risk management, incident reporting, business continuity and disaster recovery, third-party risk management for ICT suppliers, and digital operational resilience testing. The DORA requirements for FISPs are scaled to size and complexity, but they are substantive: they require documented policy frameworks, not just risk awareness.

A capital or insurance requirement to cover professional liability. The specific level will be set out in regulatory technical standards.

Once authorised, the FISP receives an EU passport and can access FiDA data from data holders in any member state. EBA adds it to the public register. National competent authorities can withdraw authorisation for ongoing non-compliance.

The simplified pathway proposed in the April 2026 non-paper would allow firms already holding PSD2 AISP licences to carry forward relevant documentation rather than starting from scratch. The extent of that simplification depends on the final text, but it is directionally positive for fintechs that already operate within the PSD2 framework.

What to watch

Trilogue progress. The April 2026 non-paper restarted negotiations that stalled in June 2025. The Danish Presidency of the Council of the EU, which runs from July to December 2026, has indicated an intention to reach provisional political agreement on FiDA during its term. That would put final text and Official Journal publication in 2027, with application beginning approximately 24 months later. Monitor the Parliament’s ECON committee and Council working group outputs for negotiating positions as they develop.

FDSS establishment. Financial industry associations are already working on scheme frameworks in anticipation of the regulation. The Banking Industry Architecture Network (BIAN), the Berlin Group, and sector-specific bodies are among those with active workstreams. The schemes that get established, the standards they adopt, and the compensation models they agree will define the practical shape of the FiDA ecosystem more than the regulation text itself.

EBA and EIOPA mandates. Both authorities receive significant delegated mandates under FiDA. EBA is tasked with guidelines on the data use perimeter for consumer credit scoring. EIOPA is tasked with guidelines on data use for life, health, and sickness insurance risk assessment and pricing. These guidelines will determine whether data that is technically in scope can actually be used for commercially sensitive purposes. Their development will begin once the regulation passes, but the consultation processes are worth engaging with early.

The Big Tech question. If large non-EU technology platforms are restricted from participating in FiDA, either as FISPs or as scheme members, the competitive dynamics of the resulting ecosystem shift significantly in favour of EU-licenced fintechs. If they are not restricted, the firms with the largest existing consumer relationships and data infrastructure arrive into the FiDA ecosystem with substantial advantages. The resolution of this question is one of the most commercially significant outstanding decisions in the negotiations.

For compliance professionals and fintech founders tracking FiDA through the trilogue as the final text develops, Forseti monitors EU financial regulation continuously, including legislative proposals, Commission non-papers, and EBA and EIOPA consultation outputs, anchored to verified official sources with full CELEX traceability. Start for free.