EU Financial Data Access (FiDA) and Open Finance Architectur

Systems and architecture analysis only. This is not legal, regulatory or investment advice. FiDA is still a legislative proposal as of this writing; every article number and timeline below should be checked against the final text once it is published in the Official Journal.

PSD2 gave European consumers a legal right to push their payment-account data to a third party, and it took roughly five years of supervisory arguments before the APIs were reliable enough to build products on. The proposed Financial Data Access Regulation, universally shortened to FiDA, tries to repeat that trick for everything else a customer has with a financial institution: loans, savings, investments, pensions and insurance. The difficulty is that the PSD2 recipe does not transfer. Payment accounts look alike across banks. A pension record at an occupational fund, a mortgage file and a motor-insurance policy do not.

That mismatch is why the open finance architecture in FiDA looks different from open banking. Instead of mandating one regulated API and leaving the market to argue about it, FiDA pushes the hard decisions (data model, interface standard, liability, compensation) into industry-run financial data sharing schemes, with the customer’s permission dashboard as the control surface. If you build or buy systems that will have to expose or consume this data, the architecture matters more than the legal text, and the legal text is still moving.

This article covers the full stack as proposed, the status in late 2026, and where the design differs from PSD2. What this covers: the regulatory state of play, a reference architecture with four diagrams, the consent and permission-dashboard mechanics, how data sharing schemes are meant to form and run, a PSD2-versus-FiDA comparison, the failure modes you should plan for, and a practical build checklist.

Context and Background

FiDA is the Commission’s proposal for a Regulation on a framework for financial data access, published on 28 June 2023 as COM(2023) 360 alongside the PSD3 and Payment Services Regulation (PSR) package. It sits under the Commission’s 2020 Digital Finance Strategy, which promised a move from open banking to open finance. Its legal sibling is the horizontal Data Act (Regulation (EU) 2023/2854), which applies from 12 September 2025 and creates general data-access rights for connected products but deliberately leaves sector-specific regimes such as FiDA to do the financial work.

The state of play matters because articles on this topic go stale quickly. Here is what the sources I could verify say. The Commission proposed FiDA in June 2023. The Council reached a general approach in December 2024, according to Norton Rose Fulbright’s analysis; the Parliament had already settled its first-reading position earlier (treat the exact vote date as unverified in this post). Trilogue negotiations opened in spring 2025, and secondary reporting says they stalled after a June 2025 round without a clear outcome. On 6 April 2026 the Cypriot Council presidency circulated a non-paper aimed at unblocking the file, focused on whether designated gatekeepers (the large platforms under the Digital Markets Act) may access customer data held by financial institutions, an issue described as still contentious in Council. A July 2026 analysis from Thede Consulting reports that the Commission’s own non-paper proposes narrowing scope and phasing the rollout over roughly four years. I could not find evidence of a political agreement as of the date of this post.

Why does the delay matter to architects? Because the shape of the final text is converging even where the dates are not. Three design decisions have survived every round: customer-controlled permissions, sector schemes rather than a single mandated API, and a regulated class of data user. The scope is the part that is shrinking. According to the reported Commission non-paper, credit rating agencies, large corporates and some smaller financial firms would be excluded, and only data that has not been substantially processed would fall in scope. The practical reading: design for the stable core, treat scope as a configuration parameter.

For the payment side of the same package, the Council and Parliament announced a provisional agreement on PSD3 and the PSR on 27 November 2025. That deal matters here because it carries a permission-dashboard obligation for payment accounts, which gives a preview of the dashboard UX regulators expect. For deeper background on the payment-initiation half of European open banking, see our analysis of variable recurring payments and payment initiation API architecture. The primary legal text for the proposal is available on EUR-Lex under COM(2023) 360.

Incumbent infrastructure is worth naming too. On the payment side the market converged on API standards such as the Berlin Group NextGenPSD2 framework and STET, each a bank-led interpretation of the PSD2 regulatory technical standards. FiDA’s bet is that no such organic convergence will happen for pensions or insurance without an organising body, so it legislates the body (the scheme) rather than the API.

The FiDA Reference Architecture

In one paragraph: FiDA lets a customer authorise a regulated data user to pull defined non-payment financial data from a data holder. Access runs through a financial data sharing scheme that fixes the common standards, liability and compensation, while a permission dashboard at the holder records and revokes every grant. Supervisors authorise data users, and the European Banking Authority keeps the public register.

Figure 1: The FiDA open finance architecture as proposed. The scheme sits between holders and users and carries the common standards, compensation model and liability rules. Supervision is national; the register is European.

Figure 1 shows the actors and the control relationships. The customer, who can be a consumer or a business, is the legal source of authority. The data holder is any in-scope financial institution that collects, stores or processes the covered data, other than account information service providers. The data user is an entity that, with the customer’s permission, lawfully accesses the data. A subset of data users, the financial information service providers (FISPs), are new licence holders whose business is financial information services built on this data. The scheme is the contractual and technical substrate joining holders and users. National competent authorities enforce; the EBA keeps the register of FISPs and schemes (Article 15 of the proposal).

What data is in scope

The proposal’s scope covers mortgage, loan and non-payment account data (balances, conditions and transactions); savings, investments, insurance-based investment products, crypto-assets and real estate; occupational and pan-European personal pension rights; non-life insurance products excluding sickness and health; and data used in creditworthiness assessments for consumers and firms. Payment-account data is excluded because PSD2 and its successors already govern it. The Parliament’s economic committee (ECON) proposed adding credit card accounts and clarifying savings products such as term deposits.

From an architect’s view the scope list is really a data catalogue problem. “Non-payment account data” is not a schema. A mortgage has a rate-reset schedule and a collateral record; an investment account has lots, cost basis and corporate actions; a non-life policy has coverage terms and a claims history. Each category needs its own canonical model before any API can be standardised, and that is exactly the work FiDA hands to schemes.

The three core obligations

The proposal builds on three primitives. Article 4 requires data holders to make in-scope data available to the customer without undue delay, free of charge, continuously and in real time. Article 5 lets the customer ask the holder to share that data with a data user, subject to a valid GDPR legal basis where personal data is involved. Article 6 constrains the data user: it may only access what the customer authorised, use it only for the agreed purposes, and not retain it longer than necessary.

Note the order. The first right is a direct customer right. The sharing right derives from it. That sequencing has an architectural consequence: the same API surface that serves the customer’s own app must serve the data user, and the holder cannot satisfy FiDA with a screen-scraping-grade export for the first right and a polished API for the second. Teams that treat “customer access” and “third-party access” as separate products will build the interface twice.

Where the hard parts live

Most open-banking pain came from four places: authentication friction, interface reliability, inconsistent data semantics and unresolved liability. FiDA moves three of those into the scheme. Authentication and consent remain regulatory-defined and reuse GDPR plus the strong customer authentication ecosystem. Semantics, interface reliability targets, liability and the compensation model are all scheme business. The result is a federated model: one regulation, many privately governed rule books, one public register tying them together.

This is the part most summaries underplay. FiDA is less an API mandate than a governance mandate. If you are a bank CTO, the question is not “which endpoint do I build” but “which scheme will define my endpoints, and do I have a seat at the table when it does.”

The permission dashboard is the single most visible FiDA component, and also the easiest to under-engineer. Article 8 of the proposal requires holders to provide a dashboard that shows the permissions customers have granted to data users and lets them withdraw those permissions. The PSD3/PSR provisional agreement carries a comparable tool for payment accounts, so a bank will probably run one dashboard concept across both regimes. Whether it is one product or two is an implementation choice; the customer will not tolerate two.

Figure 2: The consent lifecycle for a FiDA data request. The holder is the system of record for permissions; revocation must propagate to the token layer before the next data call.

Figure 2 traces one full lifecycle. The sequence has six stages that each need a design decision, and each is a place where real implementations will diverge.

Stage one: the scoped request

The data user does not ask for “the customer’s data”. It asks for a defined scope, a purpose and, by implication, a duration. Article 6 binds the user to that scope and purpose, which means the holder needs a machine-readable scope vocabulary or the dashboard cannot present anything meaningful. “Mortgage balance and monthly payment history for the last 24 months, for the purpose of affordability assessment, 90 days” is a scope a human can judge. “Read all financial data” is not, and a well-built holder should reject it at the API edge.

Scope design is where scheme standards earn their keep. If every holder invents its own scope strings, the data user must implement N dialects and the dashboard shows N inconsistent vocabularies. The sensible target is a scheme-level scope taxonomy that maps one-to-one onto the data catalogue discussed earlier, with purpose codes drawn from a controlled list.

The holder authenticates the customer and presents the request. Authentication is where PSD2’s experience helps: the strong customer authentication machinery exists, and our deep dive on 3-D Secure 2 and SCA flows describes how the frictionless-versus-challenge trade-off plays out in cards. Whether FiDA reads call for SCA on every grant or only on risk-based triggers is a detail I could not verify in the current drafts; treat it as open.

The legal basis question is different from the authentication question. The proposal states that where personal data is shared, a valid GDPR legal basis must exist. FiDA permission is not automatically GDPR consent; the permission is a regulatory access trigger and the user’s own processing still needs an Article 6 GDPR basis. The practical result is two records per grant: the FiDA permission (scope, purpose, duration, status) and the data user’s lawful-basis evidence. A holder dashboard should store the first; it should never claim to certify the second.

Stage three: the permission record

Think of the permission as an immutable event followed by mutable status. The fields that earn their place in the schema are: a permission identifier, customer identifier (pseudonymised if the dashboard is a separate service), data user identifier and register reference, scope list, purpose code, grant time, expiry, last-used time, and a status of active, expired, withdrawn or suspended. Append-only storage with a derived status view gives the audit trail a supervisor will ask for and costs very little.

A subtle design question is where the record lives. Article 8 puts the dashboard on the holder. A customer with accounts at six institutions therefore has six dashboards, which is the opposite of what the “control” promise implies. Expect third-party aggregation of dashboards to appear, and expect it to raise the same questions about who is allowed to see what that PSD2 account information providers raised. Whether the final text mandates interoperability between dashboards is, as far as I can verify, not settled; I flag this as a genuine gap.

Stage four: token issuance and data calls

The access token should be bound to the permission, not just to the user. In OAuth terms that means issuing tokens whose claims carry the permission identifier and scope, with a short lifetime and refresh bound to the same permission. A holder that issues a long-lived bearer token and checks the dashboard only at grant time has built a revocation hole. FiDA does not prescribe OAuth; schemes will choose. In practice, financial-grade profiles such as FAPI 2.0 from the OpenID Foundation are the natural fit, with sender-constrained tokens (mTLS or DPoP) so a stolen token is useless without the key.

The real-time requirement in Article 4 shapes caching. If the holder serves the API from a read replica that lags the core ledger by an hour, “real time” is arguable. Insurance and pension systems are often batch-oriented, so the legal phrase “continuously and in real time” will collide with systems that settle nightly. The workable engineering response is to publish freshness metadata (an “as-of” timestamp on every record) so the user knows what it received, and let schemes define per-category freshness expectations.

Stage five: revocation propagation

Revocation is the dashboard’s real test. When the customer withdraws a permission, the holder must stop serving the data user on the next call. The sequence in Figure 2 ends with a rejected call, which sounds trivial and is not. Consider three failure modes:

Cached authorisation. The API gateway caches token validity for five minutes to save latency. A revoked permission keeps working for five minutes.
Offline users. A data user that pulled data under a still-valid permission, then lost the permission, retains the data. Article 6 requires the user not to keep data longer than necessary, but nothing in an API can enforce deletion. This is a supervisory and contractual matter, which is why scheme liability rules matter.
Event delivery. If the holder notifies the user of revocation by webhook and the webhook fails, the user keeps polling a dead permission. Use both: push notification plus a clear error on pull.

A pragmatic target is a revocation propagation budget. For example, set a design objective that 99% of revocations take effect on the API within 60 seconds and 100% within 15 minutes. These numbers are illustrative engineering targets, not regulatory ones; the proposal sets no latency.

Stage six: expiry, renewal and fatigue

Permissions need lifecycles, and lifecycles produce fatigue. PSD2’s 90-day re-authentication rule for account information produced well-documented drop-off in the market, and an amendment to the RTS (Commission Delegated Regulation (EU) 2022/2360, applying from July 2023 by my reading; verify before citing) lengthened the exemption period to 180 days and shifted the burden of renewal toward the third-party provider. The FiDA analogue is to avoid designing a fixed interval and instead let the scheme choose risk-based intervals per data category. A mortgage servicing dashboard that expires monthly is unusable; a once-off affordability check should expire in days.

Schemes are the architectural novelty. The proposal (Title IV, Articles 9 to 11) says in-scope data may be made available only to members of a scheme, which makes membership effectively mandatory. A scheme brings together data holders, data users and consumer organisations. Its governance, common data standards and technical interfaces are set out in the proposal’s Article 10, together with the compensation model and liability rules.

Figure 3: Scheme formation under the proposal. Industry drafts the rules; regulators of the largest holders check compliance; recognition is EU-wide; the Commission steps in with a delegated act if no scheme emerges.

The formation path

Figure 3 shows the sequence as described in the Commission proposal. Industry participants draft the scheme. Per Osborne Clarke’s summary, the scheme is notified to the competent authorities of the three most significant data holders in it, who have one month to assess compliance. A compliant scheme is then notified to the EBA and recognised across all member states. If no scheme exists for a data category, the Commission may adopt a delegated act (Article 11) setting out how holders must make that data available. In the Commission draft, the scheme-related provisions in Title IV applied from 18 months after entry into force, with the rest at 24 months; the Council and Parliament positions stretch these considerably, and the reported July 2026 non-paper contemplates phased rollout over roughly four years.

The delegated-act fallback is the lever. It converts “industry should self-organise” into “industry should self-organise or accept a default designed by the Commission”. That is a classic regulatory threat, and its effectiveness depends entirely on the Commission’s willingness to use it. From a bank’s perspective it is rational to join and shape rather than abstain.

What a scheme actually has to contain

From an engineering perspective, a scheme rule book is an unusually complete spec, because it has to resolve everything the regulation leaves open:

Data model. Canonical schemas per category, versioning policy, deprecation windows and an extension mechanism for institution-specific fields.
Interface standard. Transport (REST or otherwise), authentication profile, error model, pagination, rate limits, availability targets and test suites.
Compensation model. The maximum fee a holder may charge for making data available. Unlike PSD2, where access to payment accounts is free of charge, FiDA contemplates compensation for non-payment data, with the scheme setting the method. How “reasonable” is defined is a live negotiation point. ECON’s proposed timetable puts the common standards and compensation model at 26 months after entry into force.
Liability. Contractual allocation between holder and user for inaccurate data, misuse and security incidents.
Dispute resolution and governance. Who admits members, who revises the rule book, and how consumer organisations take part.
Membership rules. Schemes must be open to any holder or user meeting objective criteria, with equal treatment of members.

Worked example: what compensation could mean at scale

Compensation is the part most easily misjudged, so a back-of-envelope illustration helps. These numbers are invented to show the arithmetic, not drawn from any scheme.

Suppose a mid-size insurer with 4 million customers sees 8% of them (320,000) grant a permission to a comparison service. Each permission triggers an average of 12 data calls per year (renewal quote refreshes, claims history checks). That is 3.84 million calls. If the scheme caps compensation at 0.5 euro cents per call, the insurer earns about 19,200 euros a year. If the cap is 5 cents, it is 192,000 euros. Now compare to cost: an insurer running a modern API gateway, security monitoring and support might spend several hundred thousand euros annually to run the interface. At 0.5 cents the fee does not cover the cost; at 5 cents it roughly does. Which band the scheme picks decides whether holders treat FiDA as a cost centre or a business line, and whether data users like the comparison service can afford the volume at all.

The lesson is that compensation design shapes market structure. A high cap protects holders and discourages data-hungry entrants; a near-zero cap, the PSD2 model, may starve holders of the incentive to build quality interfaces, which is precisely the reliability problem open banking had.

Who sits in a scheme

The proposal describes schemes as including holders, users and consumer organisations, which is the first time EU financial law has explicitly seated consumer groups in an API governance body. That is a bigger deal than it sounds. It means the same table that sets rate limits also sets what a “purpose code” means, and consumer representatives can resist purposes that do not serve customers. Whether consumer organisations have decision power or merely observer status is a detail where the final text and each scheme’s constitution will matter.

An honest limitation: multiple overlapping schemes are possible. A pension scheme and an insurance scheme may both claim “savings with an insurance wrapper”. The proposal addresses the problem only by requiring that each data category belong to a scheme, not by resolving boundary cases. Expect boundary disputes to land with the EBA and the national regulators.

What Changes From PSD2: A Structural Comparison

The cleanest way to understand FiDA is to line it up against PSD2 and ask what each design choice was a reaction to. PSD2 (Directive (EU) 2015/2366) was a payments directive that created a right of access to payment accounts for licensed account information service providers (AISPs) and payment initiation service providers (PISPs). It was a Directive, transposed nationally, with technical detail pushed into regulatory technical standards. FiDA is a Regulation, directly applicable, and it pushes technical detail into schemes.

Figure 4: The structural shift from PSD2 to FiDA. Each PSD2 pillar maps to a FiDA counterpart; both rest on the same GDPR, consent and authentication base.

Dimension	PSD2 open banking	FiDA open finance (proposal)
Legal form	Directive, national transposition	Regulation, directly applicable
Data scope	Payment accounts	Loans, savings, investments, pensions, non-life insurance, creditworthiness data
Who must share	Account-servicing payment service providers	Wide range of financial institutions as data holders
Who may receive	Licensed AISPs and PISPs	Authorised FISPs and other in-scope data users
Interface	Dedicated bank APIs, fallback mechanism rules, market standards (Berlin Group, STET and others)	Scheme-defined common standards
Price of access	Free of charge	Compensation permitted, defined by the scheme
Consent control	Bank-side and TPP-side flows, 90 or 180 day SCA exemption	Permission dashboard at each holder
Liability	Statutory refund rules for unauthorised payments	Contractual, set by the scheme
Governance	Supervisors and national implementations	Schemes plus EBA register

Three shifts that matter more than the table suggests

From a technical standard to a governance standard. PSD2’s central failure mode was inconsistency: every bank implemented the regulatory technical standards a little differently, and the fallback mechanism and exemption procedures became a recurring supervisory topic. FiDA tries to replace one regulator’s attempt at harmonisation with a system in which an accountable body per data category owns it. The risk is that scheme bodies reproduce the problem with better funding.

From free access to priced access. The economic logic of PSD2 was that payment account data belongs to the customer and access is free. FiDA concedes that the economics are different for data that costs real money to expose and that holders have no incentive to modernise. Priced access also invites a new failure mode: holders using price to throttle competitors. The scheme’s equal-treatment rule exists to prevent that, but only supervision will tell whether it works.

From a bilateral relationship to a multilateral one. Under PSD2, a TPP effectively signs up to each bank’s developer portal. Under FiDA, joining a scheme once should open a whole community of holders. If it works, onboarding cost for a data user falls from “N bank integrations” to “one scheme integration plus certification”. That is the single most important commercial argument for the model.

FISPs, gatekeepers and the live political fault line

A new regulated class, the financial information service provider, is created for entities that want to access in-scope data to provide financial information services. The FISP must be authorised, established in the EU or represented by an EU-based representative with liability for non-compliance, and may passport across the Union. The EBA keeps the register, and organisational requirements follow in Article 16.

ECON’s amendments push the design in two directions that deserve attention. First, FISP authorisation may not be used to carry out activities regulated under other EU financial-services law, such as MiFID investment advice. Second, designated gatekeepers could be barred from becoming FISPs (the proposed Article 18a), and gatekeeper-owned data users could be restricted from combining customer data with other data they hold (Article 6(4b)). These ideas are part of the contested core in the April 2026 Council non-paper described earlier. As a systems analyst I would highlight the architectural implication: whatever the outcome, holders must be able to answer “who is this data user, and who owns it” through the register, so the identity of the requesting party must be machine-verifiable at the API edge, ideally by certificate and register lookup in the style of eIDAS-qualified certificates used under PSD2.

How FiDA interacts with the rest of the rule stack

FiDA never operates alone. A holder implementing it must also respect:

GDPR (Regulation (EU) 2016/679). Legal basis, purpose limitation, data minimisation, subject rights. FiDA does not displace GDPR; it adds a sector access right on top of it.
DORA (Regulation (EU) 2022/2554). Digital operational resilience, applicable from 17 January 2025. An API that third parties call is an ICT dependency with incident-reporting and third-party risk implications. A scheme-run shared service would itself raise ICT third-party questions.
PSD3 and the PSR. The payment half of the picture, with its own permission dashboard and a revised open banking regime after the provisional agreement of 27 November 2025.
The Data Act. Horizontal data access for connected products; FiDA is the lex specialis for in-scope financial data.
eIDAS 2 and the EU Digital Identity Wallet. Not mandated by FiDA as far as I can verify, but a natural future authentication and attribute-presentation channel for consent.
Message formats. Data portability rights say little about the format of internal payment and card messages, though modernisation projects on ISO 20022 often provide the cleanest canonical data layer. For that groundwork see our comparison of ISO 8583 and ISO 20022 message formats.

The upshot: a single “open finance platform” at a bank is really a composition of consent management, data virtualisation, API gateway, identity and audit components, each with its own regulatory anchor.

Building It: A Holder-Side and User-Side Implementation View

Architecture without implementation advice is a diagram. Here is how I would shape the stack, with the usual caveat that FiDA’s final text and each scheme’s rule book will override anything generic.

Holder-side reference stack

A holder needs five layers. At the bottom are the systems of record: core banking, loan servicing, policy administration, pension administration, custody. None of them was designed to serve a real-time external API. Above them goes a data product layer, a set of curated read models per FiDA category, each mapped to the scheme’s canonical schema and refreshed by change-data-capture rather than nightly extract. Above that sit the consent and permission service (the dashboard backend), the authorisation server and the API gateway that enforces scope, rate limits and register-based identity checks. An audit and reporting service wraps the whole thing.

The data product layer is the crucial expense. Mapping a legacy loan system to a canonical mortgage schema involves hundreds of field decisions. Budget this honestly. In my experience with enterprise data programmes the mapping and quality remediation work usually dwarfs the gateway and OAuth work, though I cannot cite a published benchmark for FiDA specifically; treat that as informed opinion.

Capacity planning, with illustrative numbers

Consider a pension provider with 2 million members. Suppose 5% grant permissions and each active permission averages one refresh a day with occasional bursts at tax season. That is 100,000 permissions and roughly 100,000 calls a day, about 1.2 calls per second on average. Even a 20x peak is under 25 calls per second, easily handled. The numbers change when a popular data user, say a budgeting application, polls aggressively or when a permission re-grant wave hits after an expiry cycle. The design question is not raw throughput but burst control, so the scheme should define rate limits per data user, and the holder should shed load deterministically with documented error codes.

Compare that with the cost of the permission store: 100,000 active permissions at a few kilobytes each is tens to hundreds of megabytes. Storage is trivial. The expensive part is the audit and analytics layer if the holder chooses to log every call with full request metadata for supervisory evidence.

User-side stack

A data user (FISP or other) needs a mirror image: a register client that checks the EBA register and its own authorisation status; a scheme SDK implementing the standard interface; a consent orchestration service that builds scope requests, tracks the permission lifecycle across many holders and handles revocation events; a data minimisation and retention engine that enforces Article 6 limits by deleting or aggregating data when the permission ends; and a normalisation layer that makes holders’ data comparable even when schemes allow extension fields.

The retention engine is the one teams forget. If the user holds data past its lawful lifetime, the legal exposure is the user’s, and no API can prevent it. Build deletion as a first-class workflow with auditable evidence from day one.

Trade-offs, Gotchas, and What Goes Wrong

The FiDA design has real strengths, but its failure modes are specific and predictable. A fair analysis names them.

Scheme capture. Schemes are governed by their members, and the incumbent holders are usually the best-resourced members. A scheme could set compensation high, standards complicated and certification slow, giving the appearance of access without the substance. The safeguards are open membership, equal treatment, consumer representation and the delegated-act fallback, but each depends on enforcement. If you are a new entrant, push for objective, published membership criteria and transparent fee methodology.

Fragmentation. If the number of schemes multiplies (one per data category, perhaps one per country or product), the “join once” promise erodes into “join eleven times”. The EU-wide recognition via EBA helps, but it does not remove the cost of integrating different standards.

Real-time against batch reality. As discussed, many pension and insurance systems cannot honestly serve real-time data. Two outcomes are plausible: schemes define realistic freshness windows, or holders deploy facades that look real-time and serve stale data. The second outcome is a quality problem a customer will blame on the data user, not the holder. Freshness metadata is the cheap mitigation.

Dashboard fragmentation and consent fatigue. Six institutions, six dashboards, dozens of permissions. Customers will not manage this manually. Without interoperable dashboards the control promise degrades to a formality. The PSD2 experience, where users abandoned flows because of repeated re-authentication, is the warning.

Liability gaps. Scheme-level contractual liability binds only members. A customer harmed by inaccurate data has a statutory remedy against nobody in particular. The question of who compensates an end customer for bad data flowing through a chain of three parties is not answered by contract alone.

Scope churn. The reported Commission non-paper would exclude certain firms, limit data to what is not “substantially processed”, and shorten historical look-back to perhaps two years. Anyone who built a data model around the 2023 scope may have to cut it back or hold it as optional.

Security surface. Every new API is attack surface. A permission dashboard is also an attractive social-engineering target: a fraudster who gets a victim to approve a grant gains persistent access. The PSD3/PSR fraud measures, including impersonation-fraud refund rules, make this a liability matter for payment providers; expect equivalent pressure here.

Anti-patterns to avoid. Do not build the customer-facing export and the third-party API separately. Do not store permissions only as OAuth token metadata, because you will not be able to show them to the customer. Do not wait for the final text before building the data catalogue; that is the one asset that survives every legislative outcome.

Practical Recommendations

If you are a data holder, treat the next twelve months as a data-readiness project, not an API project. Inventory the in-scope categories you actually hold, map them to a provisional canonical model, and measure the freshness and quality of each source system. That gives you a defensible position in whichever scheme you join. Then decide whether you will run your own permission service or buy one, keeping in mind that PSD3/PSR will force you to build a dashboard for payment accounts anyway.

If you are a prospective data user or FISP, the central question is business model. Compensation means data is no longer free, so unit economics must include per-call cost. Model your breakeven under fee scenarios of a fraction of a cent through several cents per call, as in the worked example above. Design for consent lifecycle from the start, and think hard about which data you can minimise away.

If you are a technology vendor, there are three buildable products: consent and permission management, scheme-compatible API gateways and canonical data-mapping tools. The tooling that emerged around PSD2 suggests a market for certification test suites too.

For everyone, a short checklist:

Build a data catalogue per FiDA category, with owner, source system and freshness.
Separate the permission record (event log plus status view) from token metadata.
Bind tokens to permission identifier and scope; use sender-constrained tokens.
Set an internal revocation latency target and test it end to end.
Publish an as-of timestamp on every record you serve.
Monitor the legislative file and the Cyprus and following presidencies’ non-papers for scope changes; keep scope as configuration.
Join scheme discussions early; membership terms and fee methodology are decided before the legal text bites.
Treat data retention at the user side as a deletion workflow with evidence.

Frequently Asked Questions

What is the Financial Data Access (FiDA) regulation?

FiDA is a proposed EU Regulation, COM(2023) 360, that would give customers the right to share non-payment financial data, such as loans, savings, investments, pensions and non-life insurance, with authorised third parties. It extends the open banking idea of PSD2 to open finance. Data sharing runs through industry-governed schemes, and customers control permissions through a dashboard. As of late 2026 it has not been adopted.

What is the difference between PSD2 and FiDA?

PSD2 covers payment accounts and requires free access for licensed AISPs and PISPs through bank APIs. FiDA covers other financial data and routes access through financial data sharing schemes that set common standards, liability and compensation. PSD2 is a Directive transposed nationally; FiDA is a Regulation. FiDA permits compensation for data holders, and it introduces the FISP, a new authorised data user, with an EBA-kept register.

A financial data sharing scheme is an industry-governed framework that brings together data holders, data users and consumer organisations. It defines common data and interface standards, the compensation holders may charge, and the contractual liability between parties. In the proposal, membership is effectively required for in-scope data, schemes must be open on objective criteria, and the Commission can adopt a delegated act if no scheme forms for a data category.

What is the FiDA permission dashboard?

The permission dashboard, Article 8 of the proposal, is a tool that data holders must provide so customers can see which data users hold permissions to their data, grant new ones and withdraw existing ones. It is the customer’s control surface. The PSD3/PSR provisional agreement carries a similar dashboard for payment accounts, so banks will likely converge on one consent management capability across both regimes.

When will FiDA apply?

No date is certain. The Commission proposed 24 months after entry into force, with scheme-related provisions at 18 months. Parliament and Council positions stretch these, and a reported 2026 Commission non-paper proposes a phased rollout over about four years. Trilogue talks stalled after June 2025 and, as of the sources I could verify, no political agreement existed. Plan for obligations beginning around 2028 to 2030, treating that as an estimate, not a forecast.

No. FiDA adds a sector-specific access mechanism on top of GDPR. Where personal data is shared, a valid GDPR legal basis is still required, and the data user remains bound by purpose limitation and data minimisation. In practice, systems should record the FiDA permission (scope, purpose, duration) separately from the data user’s GDPR lawful-basis evidence, because they serve different legal functions.

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories

Open Finance Architecture: EU FiDA, Consent and Data Schemes vs PSD2