CopiedWhy PSD2 doesn’t solve PAD – and why FiDA could be the missing piece

Compliance teams at investment firms know the frustration well. Every quarter, employees are asked to log into a portal, manually upload brokerage statements, and self-certify their holdings. The system works, but not perfectly. It is built almost entirely on trust.

There is no automated data feed, and no way for the compliance officer to independently verify the contents of an employee’s investment account at another institution. This is how PAD (Personal Account Dealing) compliance works at most firms today.

Below, we unpack the operational problem that PSD2 created for PAD/PDMR teams, the opportunity FiDA presents, and the three caveats that will determine whether that opportunity becomes reality.

The PSD2 gap few talk about Copied

When PSD2 came into force, it marked a major shift for open banking. For the first time, customers could consent to sharing their payment account data, including current accounts and payment transactions, with authorised third parties via standardised APIs. It was transformational for retail banking.

But PSD2 has a major limit: it only covers payment accounts.

Investment accounts, brokerage holdings and securities portfolios are not in scope. A compliance platform cannot use PSD2 to retrieve an employee’s equity holdings at their broker, because brokers are not covered under PSD2’s definition of an Account Servicing Payment Service Provider.

PSD2 was originally designed for payments, not broader financial data sharing. But for compliance teams responsible for MiFID II’s Article 29 PAD obligations, or MAR’s PDMR notification requirements, that limitation creates real operational problems.

The workaround today is manual uploads and self-reporting, which leaves firms relying heavily on employee honesty. In some firms, this works well. In others, particularly those with large and geographically dispersed employee populations, it is a material compliance risk. Data quality suffers, audit trails are incomplete, and the burden on employees is unnecessarily high.

The US already solved this – partly Copied

In the US, service providers already support aggregation of investment account data (holdings, transactions, portfolio values) via consented API access to brokerage accounts. US financial services firms already use this data for compliance purposes.

Europe does not have an equivalent. Not because the technology is unavailable, but because the regulatory framework has not yet required financial institutions to open up their investment data infrastructure in the same way PSD2 opened up payment accounts data.

Euroclear does not provide individual holdings data to third parties. Banks do not expose investment account APIs. Custodians and brokers each maintain their own data silos.

FiDA is designed to change this.

What FiDA actually proposes Copied

FiDA (the EU’s Financial Data Access Regulation), proposed by the Commission in June 2023 and, per early May 2026, still in advanced trilogue negotiations, extends the open finance principle well beyond payments. It would require a broad range of financial institutions (including investment firms and brokers) to make client data available via standardised APIs, subject to client consent.

The data types in scope are significant for compliance purposes. The draft regulation includes, in its Phase 2 (within 36 months of entry into force):

• Investments in financial instruments
• Crypto-asset holdings
• Plus, the MiFID II data on whether products are suitable and appropriate for the customer

Phase 2 compliance by data holders is expected around 2028–2029, given the anticipated timeline for formal adoption.

Phased implementation (post‑entry into force)

• Phase 1 (24 months): savings, credits, motor insurance
• Phase 2 (36 months): investments in financial instruments, crypto and mortgages
• Phase 3 (48 months): non‑life insurance, IBIPs, credit ratings

The FDSS governance structure Copied

The governance structure FiDA introduces is the Financial Data Sharing Scheme (FDSS) – a framework within which data holders (brokers, banks, investment firms) and data users (including authorised third-party platforms) operate under common technical standards, liability rules and API specifications.

In practice, regulated firms would need to participate in an FDSS. For the first time, a compliance platform could, in principle, become a licensed data user and receive consented investment account data directly from a client’s broker.

What this could mean for PAD and PDMR compliance Copied

Personal Account Dealing (PAD) Copied

The implications for PAD compliance are potentially significant. Rather than asking an employee to export a PDF from their brokerage account and upload it manually, a FiDA-enabled workflow would look quite different:

• The employee consents once, at onboarding, to their broker sharing holdings and transaction data with their employer’s compliance platform
• From that point, the platform receives data automatically
• The compliance team has a continuous, verified view of employee portfolios

Pre-clearance workflows could be transformed. Instead of checking a manually maintained watch list against self-reported holdings, the system could check live portfolio data. Breaches would be detected faster. Audit trails would be complete and tamper-evident. The burden on employees would fall dramatically.

PDMR (MAR Article 19) Copied

For PDMR obligations, the impact could be just as important, even if more limited. A PDMR consenting to data sharing could trigger detection of reportable transactions, with pre-populated notifications ready for review and submission.

Full end‑to‑end automation, in which the platform submits directly to the national competent authority without PDMR involvement, remains beyond what FiDA alone can enable. The legal obligation to notify under MAR Article 19 rests with the individual. However, the reduction in friction and the elimination of missed or late notifications due to oversight, would be material.

Important
FiDA does not change who is responsible for PDMR disclosures. The platform cannot notify the NCA directly. What FiDA enables is better detection and streamlined preparation, but not automated submission.

What about insider lists? Copied

FiDA does not directly affect insider list management (MAR Article 18). That is a data‑about‑company‑insiders workflow, not a personal financial data access workflow. There is no direct FiDA hook here.

The practical constraints Copied

FiDA is not a compliance solution in itself. A few important realities deserve clear acknowledgement.

1. Timing – The investment data that PAD and PDMR compliance needs is in FiDA Phase 2 (not Phase 1). Compliance teams should not expect FiDA-enabled automation before approximately 2028 at the earliest, and realistically 2029 in many markets, given implementation experience from PSD2.

2. Access models – Accessing FiDA data as a compliance platform will require either:

• Becoming a licensed Financial Information Service Provider (FISP), or
• Operating as a data user within an FDSS

Neither is trivial. Licensing regimes, technical standards and FDSS governance structures are still being defined. Compliance SaaS platforms serve regulated entities for specific regulatory purposes, not as general financial information services. FiDA’s rules need to explicitly recognise this distinction. 

3. Implementation friction – PSD2 showed that regulation and real-world implementation are often very different. APIs were mandated, but quality, coverage and adoption varied enormously. FiDA will face similar implementation friction, particularly for investment account data, where custodian and broker infrastructure is considerably more fragmented than retail banking.

The window to shape the outcome Copied

These limitations do not reduce FiDA’s strategic importance for compliance technology. They do, however, show that FiDA’s usefulness for compliance teams will depend significantly on how its details are written:

• In the Level 2 technical standards
• In the FDSS governance frameworks
• In the licensing criteria for data users

That process is happening in 2026. The European standardisation body CEN began work on FiDA technical standards in early 2025. FDSS schemes are beginning to take shape in the banking and insurance sectors. The investment data FDSS, the one most relevant to PAD and PDMR, is still taking shape.

For those building and ensuring compliance technology, the time to engage is now.

To secure effective compliance, FiDA would ideally ensure:

• Compliance SaaS providers serving regulated entities are explicitly recognised as a legitimate “data user” category
• Investment account transaction data (not merely holdings snapshots) is in the Phase 2 scope
• Proportionate FISP / data‑user licensing for narrow‑scope compliance purposes

Conclusion Copied

PSD2 opened the door for payments, but left investment accounts untouched. FiDA is designed to close that gap by extending open finance to securities holdings, transaction histories and MiFID II suitability data.

For PAD and PDMR compliance, the potential is clear: verified data flows, reduced manual burden, and better audit trails. But the investment data sits in Phase 2, with implementation realistically expected in 2028–2029. And the question of whether compliance SaaS platforms can access FDSS data without full FISP licensing remains open.

The technical standards and FDSS rules are currently being written. For compliance technology providers and the regulated firms they serve, the next 12 to 18 months will determine how useful FiDA ultimately is.

Looking for a tailored view of what FiDA means for your firm’s PAD and PDMR framework?

Contact us to discuss the implications for your compliance architecture.

Sources referenced: Copied

• European Commission – Proposal for a Financial Data Access Regulation (FiDA)
• EUR-Lex – PSD2 Directive
• ESMA – MAR guidance
• Finansinspektionen – Inside information guidance
• European Banking Authority – PSD2/Open Banking materials