FiDA Makes Your Wallet a Data Broker Whether You Planned for It or Not

The Financial Data Access regulation — FiDA — is in the final stretch of trilogue, with formal adoption expected in mid-2026. It extends PSD2's data-sharing logic to pensions, insurance, investments and mortgages — and reshapes what a wallet is.

The Financial Data Access regulation — FiDA — is in the final stretch of trilogue. The Council agreed its general approach in December 2024, trilogue negotiations opened in April 2025, and formal adoption is expected in mid-2026. When it lands, it will extend the compulsory data-sharing logic of PSD2 to pensions, investments, insurance contracts, mortgages, and savings products. For a telco or bank operating a wallet, this is not an incremental compliance task. It is a structural change to what the wallet is: a node in a regulated data network, with obligations that attach regardless of whether the operator sought that role.

What FiDA Actually Extends, and What It Does Not

PSD2 mandated access to payment account data. FiDA's scope covers a materially broader set: occupational and personal pension products, non-life and life insurance policies, investments held under MiFID II, savings and consumer-credit data, real estate loans, and — in the current drafts — crypto-assets held under MiCA. The precise category list has moved between the Commission, Council and Parliament texts, so the final scope is one of the things to confirm against the adopted regulation rather than a draft.

The mechanism is the same as Open Banking — permission-based API access through a Financial Data Sharing Scheme (FDSS) — but the data is structurally more complex. A payment transaction is a flat record. A unit-linked pension policy involves valuation methodology, fund allocation, surrender values, and projected benefits under different assumptions. The API standards for these products do not yet exist in ratified form; the FDSS bodies are expected to produce them within 18 months of FiDA entering into force. Operators who assume the technical lift will resemble PSD2 integration are underestimating it.

The Distribution Opportunity Is Real, but Asymmetric

A wallet that can display a user's current account, pension pot, investment ISA, and home insurance renewal date in a single authenticated session has genuine utility. Aggregation at that level is currently impossible without screen-scraping or bilateral commercial agreements. FiDA removes both barriers for authorised data users (FiDA's term: "financial data users," or FDUs).

The asymmetry is this: large telco-bank wallet operators are more likely to be data holders than data users in the first instance. A bank holding pension and insurance products must expose that data via standardised APIs. A wallet that holds only payment accounts — common for telco-led propositions — sits primarily on the user side, able to pull data from incumbents. That is a distribution advantage, but it depends on the incumbents' APIs being functional and the consent infrastructure being in place. Neither is guaranteed at go-live.

The operator who waits for the ecosystem to mature before building consent tooling will find the ecosystem has already decided who the aggregators are.

The Consent Dashboard Obligation Is Not Optional Infrastructure

FiDA (Article 8 of the draft) requires that data holders provide users with a "permission dashboard" — a persistent interface where users can view, modify, and revoke all active data-sharing consents. This is more demanding than the PSD2 consent model, which left revocation largely to the TPP. Under FiDA, the dashboard must be maintained by the data holder and must reflect near-real-time consent state.

For a wallet operator who is also a data holder (a bank with a wallet product), this means building or procuring a consent management layer that integrates with every product line in scope. The dashboard cannot be a static list; it must support granular revocation at the product level. A user must be able to revoke access to their mortgage data without affecting access to their current account data. The technical requirement is a consent store with product-level scoping, audit logging, and an API surface that FDUs can query to verify permission status before each data call.

For a telco-led wallet that is not a data holder, the obligation is lighter — but the wallet still needs to handle incoming consent tokens, manage their expiry, and surface consent state to users in a way that satisfies the forthcoming FDSS scheme rules. Ignoring this on the grounds of "we're just the wallet" is not a defensible position once the scheme is live.

Build vs. Wait: A Decision Framework

With adoption expected in mid-2026, FiDA would enter into force 20 days after publication in the Official Journal, followed by a transitional period (the drafts have discussed staged application of roughly 18-to-24 months for data holders) and a separate timeline for FDSS scheme rules. That gives operators on the order of two to three years before hard obligations bite. The build-vs-wait question therefore has a structural answer, not a political one.

The consent dashboard schema and internal data taxonomy are the two components where early investment is unambiguously recoverable. The API specifications for pension and insurance products will change; building to a draft spec is waste. The authorisation flow sits in the middle — OAuth 2.0 with PKCE is the expected base, but FDSS scheme rules will add scheme-specific claims and token lifetimes that are not yet defined.

What the Regulator Will Look For at Authorisation

FiDA does not create a new licence category for wallets, but FDUs must register with their national competent authority and demonstrate adequate security measures, a legal basis for each data category they access, and a functioning consent interface. For a wallet seeking FDU status, the competent authority assessment will likely follow the pattern established by EBA for PSD2 AISPs: documented data minimisation policy, penetration test results, and evidence that consent revocation propagates correctly within a defined SLA.

Operators who have run PSD2 AISP programmes have a head start on the process documentation. Those who have not should not assume that FiDA authorisation is a lighter-touch process. The data categories are more sensitive — pension and insurance data carries significant profiling risk — and the GDPR Article 35 data protection impact assessment requirement will apply with greater scrutiny than it does for payment transaction data. Building the compliance file in parallel with the technical build, rather than after it, is the operationally sound approach.