FiDA Explained: The EU's New Open Finance Rules for Crypto Assets

Financial Data Access (FiDA) Regulation Explained for EU Open Finance

The EU’s Financial Data Access (FiDA) regulation is designed to expand open finance in the EU beyond payment accounts, creating standardized rules for how financial institutions share customer-permissioned data, explicitly including crypto assets. 

For fintechs, banks, and market infrastructure providers, FiDA is less about “more APIs” and more about operating a compliant data-access model across products, entities, and jurisdictions.

Data sharing obligations for financial institutions: who does what under FiDA

FiDA sits inside a broader EU push to create a single market for data, alongside initiatives like the European data strategy and digital finance strategy. It also complements the EU Data Act (in force since Jan. 11, 2024) and builds on the direction of travel set by PSD2 and its successor PSD3, but with a wider scope than payment account data.

FiDA’s core concept is customer-driven sharing of data across financial services:

• Customer: an individual or legal entity using financial products/services
• Data holder: a financial or insurance sector entity, including banks, insurers, investment firms, and crypto-asset service providers, that collects, stores, and processes in-scope data
• Data user: an eligible entity that can access customer data with the customer’s authorization

How sharing is organized: Financial Data Sharing Schemes (FDSS)

Under the proposal, data sharing is governed through Financial Data Sharing Schemes (FDSS), which are framework agreements among data holders, data users, and representative customer/consumer organizations. 

The intent is to standardize how members manage access, interfaces, and operational rules, while keeping the model industry-led.

Under the Council’s December 2024 clarifications, FDSSs must also meet minimum representativeness thresholds in a given market and be visible to supervisory authorities, reinforcing interoperability and market coverage.

Obligations of data holders

A data holder must make requested customer data available:

• To the customer: electronically, without undue delay, free of charge, on an ongoing basis, and in real time
• To a data user (when authorized by the customer): Provide data in a standardized format and at least the same quality as the holder’s own access
• Maintain secure communication and appropriate security in processing/transmission
• Ensure the data user can prove it has the customer’s permission
• Provide an authorization management dashboard so the customer can monitor, renew, and revoke permissions
• Respect trade secrets and IP rights when providing access

Data holders may receive appropriate remuneration for providing access, including cost recovery and a reasonable margin, as defined within applicable Financial Data Sharing Schemes.

Obligations of data users

A data user that receives customer data must:

• Use data only for the specific purposes tied to the service the customer explicitly requested
• Respect trade secrets and IP rights
• Implement measures to ensure adequate security for storing, processing, and transmitting nonpersonal data
• Not use customer data for advertising, except direct marketing that complies with EU and national law

How this connects to payments and stablecoin rails

For payments leaders, the practical implication is that what is considered financial data increasingly spans:

• onboarding and suitability data
• product holdings and performance
• and (now explicitly) crypto-asset-related data

That affects how payment providers, stablecoin issuers, custodians, and platforms design consent flows, dashboards, and downstream data controls—especially where crypto and fiat experiences are converging in a single app stack.

Read more about Stablecoin payments

Scope of regulated data (including crypto assets): what must be shareable

FiDA’s proposal requires data accessibility across multiple product categories.Unlike earlier open-banking regimes, FiDA names crypto assets explicitly, placing crypto data on the same regulatory footing as traditional financial products. In-scope categories include:

• Mortgages, loans, and accounts (except payment accounts already covered under PSD2)
• Savings and investments, including:

• investments in financial instruments
• insurance-based investment products (IBIPs)
• crypto assets
• real estate and other financial assets
• associated economic benefits (and data gathered for suitability/appropriateness assessments)

• Retirement products
• Non-life insurance products (as defined in Directive 2009/138/EC), excluding health and health risk coverage, including information gathered for demands and needs tests and appropriateness/suitability assessments
• Creditworthiness assessment data collected during a loan or rating application

Why “crypto assets” in scope matters operationally

By naming crypto assets directly, FiDA moves crypto-related data sharing from an implicit edge case to a regulated data category. 

For institutions, that typically raises three immediate design questions:

1. Data mapping: What internal systems are the system of record for crypto holdings, transfers, fees, and suitability data?
2. Consent + purpose limitation: How will you technically enforce “only for the specific purposes requested” when crypto data is reused across risk, fraud, and product analytics?
3. Security model: Which controls apply to personal vs. nonpersonal datasets, and how do you evidence compliance across vendors and partners?

Open finance in the EU: objectives and the compliance baseline

FiDA targets long-standing friction in financial data access: data users have struggled to obtain data from institutions that hold it, access has not been consistently regulated, and interfaces have created cyber risk.

The proposal’s objectives operate on two levels:

1. Enable broader data sharing across financial services operators to support more tailored products
2. Strengthen privacy and security protections by requiring high standards of confidentiality and ensuring data is used only with the customer’s consent

FiDA is positioned to align with:

• GDPR, which governs processing and movement of personal data within the EU
• DORA, which sets operational resilience expectations (effective Jan. 16, 2023)

For enterprise teams, the key point is that FiDA is not just a product requirement. It is a cross-functional program spanning legal, security, data governance, and platform engineering.

Non-compliance can trigger material sanctions, including financial penalties, public enforcement actions, and potential restrictions on regulated activity.

Financial information service providers (FISPs): a new regulated actor

FiDA introduces financial information service providers (FISPs), which are entities that can access customer data if authorized by a competent authority in an EU member state to provide financial information services.

Notably, FISPs operating outside the EU can access EU financial data without establishing an EU entity or branch, but they must appoint a legal representative (natural or legal person) in an EU member state from which they intend to access data.

For institutions, this expands the set of potential third-party data users and increases the importance of:

• authorization verification,
• vendor risk management,
• and technical enforcement of consent and scope.

Impact on the financial services industry: what changes for banks, fintechs, and crypto platforms

FiDA’s impact is likely to be most visible in product design and competitive dynamics:

• More product variety: Third parties can build new financial, investment, and insurance services using shared data, increasing the range of offerings.
• More personalized services: With access to broader datasets, providers can tailor products and experiences more precisely to customer needs.
• More competition: Easier access to data reduces distribution advantages held by incumbents and can lower costs for end users.
• Higher stakes for security and privacy: Wider sharing increases exposure. Firms will need strong security controls and compliance with data protection and operational resilience requirements to maintain trust.

Timelines for implementation: when to plan for change

Under the proposal:

• FiDA would generally take effect 24 months after it becomes law
• Provisions on FDSS and FISP authorization requirements would take effect 18 months after it becomes law

In practice, implementation is staggered by product category, with different data sets coming into scope over 24, 36, and 48 months, and corresponding FDSS requirements applying earlier for each phase.

For large institutions, that timeline is short once you account for procurement, architecture changes, security reviews, and multi-country rollout planning.

Conclusion

FiDA formalizes open finance in the EU across a broader set of financial products and it explicitly includes crypto assets as a required data category. 

The practical takeaway for enterprise teams is to treat FiDA as a data-access operating model: consent, purpose limitation, secure interfaces, and auditable controls across internal systems and third parties.

Where blockchain fits: if your payments or treasury stack touches tokenized money (for example, stablecoins) or tokenized assets, you’ll want clean system boundaries between onchain activity, offchain customer data, and consent-driven data sharing, all of which a chain like Polygon provides, so you can meet EU expectations without slowing down settlement and reconciliation.

Learn about Stablecoin settlement and reconciliation

Learn more about Tokenization and RWAs

‍