PSD3 Migration Guide: What to Rebuild in Your Payment Platform

The EU Parliament and Council reached a provisional agreement on PSD3/PSR on 27 November 2025. Formal adoption follows in early 2026, with an 18-to-21-month transition period. That puts your compliance deadline somewhere in H2 2027 or early 2028. If your payment platform runs on PSD2 architecture, some components will survive the transition. Others need a complete rebuild.

We have built and maintained PSD2-compliant payment platforms for EMIs, PSPs, and neobanks since 2018. We know which architectural decisions age well and which ones create migration debt. 

This guide draws on our partnership with Salt Edge, whose open banking compliance infrastructure and data aggregation APIs underpin the open banking layer in many of the platforms we build. Salt Edge provides the compliant API rails; Kindgeek builds the product and integration layer around them. Together, we cover the full migration scope from a single engagement.

Here, we share that combined perspective: what changes at the technical level, what you can reuse, and where your PSD2 shortcuts will cost you under PSD3.

What Does PSD3 Mean for Payment Platforms?

PSD3 and the Payment Services Regulation (PSR) require payment platforms to rebuild or significantly modify eight core areas:

• consent management dashboards
• Verification of Payee (VoP)
• SCA accessibility and dynamic linking
• fraud data-sharing infrastructure
• open banking API reliability
• fraud liability and spoofing detection
• EMI/PI licensing compliance
• payment system access for non-bank PSPs

Before starting your gap analysis, it is important to understand what technical changes are required for PSD3 compliance. Some PSD2 components survive; others require a full rebuild. 

The compliance deadline is expected in H2 2027 or early 2028.

Why PSD2 Needed an Overhaul

PSD2 entered force in 2018 with ambitious goals: open banking adoption, stronger authentication, and a level playing field between banks and non-bank PSPs. The European Commission’s 2022 evaluation found mixed results. SCA reduced fraud measurably. But open banking adoption stalled behind poor-quality bank APIs, persistent TPP access barriers, and non-bank PSPs locked out of key EU payment systems.

Meanwhile, fraud evolved faster than the regulation. Social engineering attacks (“spoofing”) blur the line between authorized and unauthorized transactions. EU electronic payments reached over 240 trillion euros in value by 2021, up from 184.2 trillion euros in 2017. The attack surface outgrew PSD2’s defenses.

The Commission responded by splitting PSD2’s successor into two instruments: PSD3 as a directive covering licensing and supervision (requiring national transposition), and the Payment Services Regulation (PSR) as a directly applicable regulation covering SCA, fraud prevention, open banking obligations, and consumer rights. Together, they replace both PSD2 and the Electronic Money Directive (EMD2).

PSD3 vs PSR: What Payment Teams Need to Understand

PSD3 is a directive. It establishes licensing, authorization, and supervisory frameworks for payment institutions across EU Member States. Each Member State must transpose it into national law, which means slight variations in implementation timelines and local requirements.

PSR (Payment Services Regulation) is a directly applicable regulation. It governs conduct rules, including SCA, fraud prevention, open banking obligations, and consumer rights. PSR applies uniformly across all EU Member States from the moment it enters into force, with no national transposition required.

For engineering teams, the practical difference is this: PSD3 affects your licensing and compliance reporting layer. PSR affects your technical architecture, including authentication flows, consent systems, fraud infrastructure, and API standards.

The 8 Technical Changes That Impact Your Payment Platform

What do payment platforms need to rebuild for PSD3? Not every part of your PSD2 architecture needs replacing. But eight areas require concrete engineering work. Here is what changes and what it means for your codebase. 

Consider this a PSD2 to PSD3 migration roadmap at the component level.

1. Consent Management Dashboard (New Build Required)

Under PSD2, consent management was an afterthought in most implementations. A simple “allow/deny” toggle buried in settings, if that. PSD3/PSR mandates a consumer-facing permission dashboard that is a core product feature. Users must see, in real time, which third-party providers access their data, what permissions they granted, and when. They must be able to revoke access through this dashboard instantly.

The critical engineering challenge: this is not a one-way display. PSD3 requires two-way, real-time consent synchronization between account-servicing PSPs (ASPSPs) and TPPs. When a user revokes consent in the dashboard, the TPP must be notified immediately. When a TPP updates its access scope, that change must reflect in the dashboard without delay. In practice, this means building event-driven infrastructure between your ASPSP layer and every connected TPP, with guaranteed delivery and state reconciliation.

Victor Colta, Open Banking/Finance Compliance Product Owner at Salt Edge, states, “In both cases, the goal is the same: ensure that consent state is always consistent, up to date, and immediately reflected across all involved parties.”

If you are a bank or EMI operating open banking APIs, this is likely the biggest single build in your PSD3 migration. If you are a TPP, you need infrastructure to receive and process consent state changes in real time, and you need to share your permission data back with ASPSPs to keep the dashboard accurate.

2. Verification of Payee (Scope Expansion)

The Instant Payments Regulation already mandated IBAN-name matching for euro instant credit transfers. PSD3/PSR extends this to all credit transfers across the EU. How does Verification of Payee affect payment platforms? Significantly.

Before executing any transfer, the payee’s PSP must verify whether the IBAN and the name provided by the payer actually match. If there is a discrepancy, the payer’s PSP must notify the payer before the transaction completes. The payer then decides whether to proceed or cancel. This verification must be provided free of charge to consumers. Payers also have the right to opt out of the service entirely.

Here is where the liability becomes real: if the verification service fails to detect a mismatch and the transaction turns out to be fraudulent, the consumer can claim damages from their PSP. From an engineering perspective, this means your payment processing pipeline needs a synchronous verification step before transaction authorization, with clear UX flows for discrepancy notifications and explicit user confirmation screens when a mismatch is detected.

3. Stronger SCA With Accessibility Requirements (Modify Existing)

PSD2 introduced SCA. PSD3/PSR refines it in ways that touch nearly every authentication flow in your platform.

First, dynamic linking gets explicit teeth. For remote payments, the specific amount and the payee must be explicitly linked to the transaction being authenticated. If your current SCA implementation handles dynamic linking loosely (and many do), tighten it now.

Second, explicit exemption rules. Merchant-initiated transactions and certain non-electronic payment orders get clear exemption criteria, removing ambiguity that caused inconsistent implementation across Member States.

The direction of PSD3/PSR also overlaps with the upcoming European Digital Identity Wallet (EUDI Wallet) framework. As EU-wide digital identity wallets mature, authentication flows may increasingly rely on standardized identity credentials and trusted consent mechanisms shared across financial services. This has direct implications for SCA design: onboarding, wallet enrollment, merchant mandates, and recurring payment authorizations could gradually shift toward interoperable identity-based authentication models rather than standalone bank-specific mechanisms.

Third, simplified SCA for account information services. Banks apply SCA only on the first access by an AISP. The AISP then handles SCA for subsequent data accesses. This changes the authentication handshake between your AISP integration layer and the bank’s API. If you run an AISP, you now own the SCA lifecycle after initial access.

Fourth, wallet enrollment gets stricter. SCA must be performed at the moment a payment instrument is enrolled in a digital passthrough wallet (Apple Pay, Google Pay), under the responsibility of the issuing PSP. If you issue cards or enable wallet enrollment, this directly affects your onboarding flow and tokenization pipeline.

Fifth, and most impactful for your UX: accessibility. SCA methods must not depend on a single technology, device, or mechanism. Smartphone-only authentication is no longer compliant. You must provide alternatives for users without smartphones, users with disabilities, and users with limited digital literacy.

4. Fraud Data Sharing Infrastructure (New Build Required)

PSD3/PSR creates an explicit legal basis for PSPs to share fraud-related information with each other, in compliance with GDPR. Under PSD2, privacy concerns made banks hesitant to share data about fraudulent payees or compromised accounts. PSD3 removes that legal ambiguity.

Specifically, PSPs will exchange data on confirmed fraud cases: mule account details, scammer identifiers, IBANs used in fraud, and modus operandi patterns. The European Banking Authority will develop Regulatory Technical Standards specifying the format and mechanisms for this data exchange.

The engineering implication: if you process payments, you need both an ingestion pipeline (consuming fraud signals from the network) and a reporting pipeline (sharing your fraud data outward). You also need transaction monitoring that integrates these shared signals into real-time risk scoring. From a production standpoint, this is similar to building a 3DS risk engine, but for cross-institutional fraud intelligence rather than single-transaction authentication.

5. Open Banking API Standardization (Modify Existing)

PSD2 mandated dedicated interfaces (APIs) for open banking. In practice, many banks did the bare minimum: slow APIs, frequent downtime, and throttling of TPP traffic that effectively blocked access. 

How does PSD3 affect open banking APIs? PSD3/PSR raises the bar on performance in ways that make those tactics explicitly illegal. 

One notable simplification is that banks no longer need to maintain a permanent fallback interface alongside their dedicated API. Colta puts it plainly: “Why bother developing it in the first place?” The fallback was largely a regulatory safety net with minimal real-world use. Its removal reduces edge-case handling and maintenance overhead. 

Providers like Salt Edge already deliver highly reliable open banking APIs even at peak volumes, with many clients achieving a 100% success rate without the fallback channel. Colta also flags the 6-month sandbox pre-launch requirement as a longtime pain point.

The practical implication here is that your open banking APIs must meet stricter uptime and performance requirements: API monitoring, incident response, and SLA tracking.

Additionally, the list of prohibited obstacles to data access gets formalized. If your API artificially throttles TPP requests, requires unnecessary redirects, or degrades performance for TPP traffic compared to your own channels, regulators now have explicit grounds to intervene and impose penalties.

6. Expanded Fraud Liability Architecture (Rebuild Required)

Under PSD2, liability for unauthorized transactions was relatively clear. PSD3/PSR dramatically expands the scope.

PSPs now face explicit liability for impersonation (“spoofing”) fraud. If a fraudster contacts a customer pretending to be your employee (using your actual phone number or email address), and the customer authorizes a payment under that manipulation, you must refund the full amount within 10 business days. 

Three conditions apply: the customer must file a police report, notify you without undue delay, and the spoofing must be convincing (replicating the bank’s exact email or phone number). Refund does not apply if the customer acted with gross negligence, including falling victim to the same type of fraud more than once.

The engineering implication: your transaction monitoring, anomaly detection, and real-time alerting systems need to catch spoofing patterns before they result in completed transactions. Behavioral analytics, device fingerprinting, and communication channel verification move from “nice to have” to direct liability mitigation. Every spoofing case you fail to prevent is a refund you pay out of your own pocket.

Additionally, the provisional agreement introduces liability for online platforms where fraud originated. In certain cases, platforms must reimburse PSPs that have already reimbursed defrauded customers. If your platform facilitates payments, factor this into your risk architecture.

7. EMI/PI Licensing Consolidation (Adapt Existing)

PSD3 merges the Electronic Money Directive into the payments framework. EMIs and PIs operate under a single licensing regime. Existing EMIs will transition into the unified framework under revised authorization requirements. The Commission aims to harmonize the two regimes to the extent possible, so expect a structured transition rather than a full re-licensing process from scratch.

Adapting compliance reporting, capital adequacy calculations, and regulatory interfaces are among the core PSD3 requirements for EMIs and PSPs making this transition. Operational processes built around EMD2-specific requirements (issuance, distribution, and redeemability of e-money) will need mapping to the new PSD3 categories.

For platforms serving both EMIs and PIs, this simplification reduces complexity in your multi-tenant compliance architecture.

8. Payment System Access for Non-Bank PSPs (Infrastructure Update)

PSD3 explicitly includes payment institutions as possible participants in designated payment systems. This is a structural change that removes the dependency of non-bank PSPs on commercial banks for settlement.

If you are a PI building direct connectivity to payment infrastructure (SEPA, Faster Payments equivalents), your integration layer needs to account for the new participation rules and risk assessment requirements that payment system operators must apply. Member States have just 6 months to transpose this specific provision, reflecting its urgency.

What You Can Reuse From Your PSD2 Architecture

Not everything needs rebuilding. Here is a summary of what survives the PSD2 to PSD3 migration and what does not:

Platform component	Reuse from PSD2?	PSD3/PSR impact
Core SCA logic	Partly	Needs dynamic linking & accessibility updates
Consent management	Mostly rebuild	Requires real-time permission dashboard
Open banking APIs	Modify	Higher reliability and anti-obstacle standards
Fraud monitoring	Rebuild / extend	Needs fraud data-sharing and spoofing detection
VoP / IBAN-name check	Extend / modify	Required before all credit transfers
Licensing / compliance reporting	Adapt	EMI/PI regime changes under PSD3

Your core SCA implementation survives, though it needs modification for the changes described above. The two-factor authentication logic, risk-based exemption engine, and 3DS2 integration remain valid. You are extending and refining, not replacing.

Your open banking API infrastructure (if built to Berlin Group or Open Banking UK standards) provides a solid foundation. PSD3 adds requirements on top, but the underlying architecture (OAuth2 flows, consent tokens, data models) carries forward.

Your PCI DSS and GDPR compliance frameworks remain fully relevant. PSD3/PSR adds specific data minimization requirements for open banking access: TPPs can only request the minimum data necessary for delivering the specific payment initiation or account information service the user requested. Your existing data protection infrastructure is the base, but expect tighter enforcement on data scope. 

One forward-looking consideration: AISPs will eventually migrate from PSD3/PSR to the Financial Data Access (FIDA) regulation, which extends data sharing to investments, pensions, insurance, and loans. The Commission is taking a staggered approach, transferring AISPs only when FIDA is fully operational. If you are building open banking architecture now, design it to accommodate the broader FIDA data categories from day one.

Your payment processing core (routing, settlement, reconciliation, ledger systems) is unaffected by PSD3/PSR directly. The changes concentrate on the compliance, authentication, and data-sharing layers that sit around your core.

Your Migration Roadmap: Where to Start Now

The provisional agreement is reached. Final texts come in early 2026, with EBA Regulatory Technical Standards developing throughout 2026-2027. Here is how to sequence your preparation.

Now through Q2 2026: Gap analysis. Map your PSD2 implementation against the eight changes above. Prioritize Verification of Payee and the consent dashboard, as these require the most engineering effort and deepest integration with your core systems. 

Colta warns that the most common mistake at this stage is treating the exercise as a simple “PSD2 compliance refresh” rather than a forward-looking platform shift because such an approach typically leads to short-term fixes and a second round of rework. 

His recommendation: assess your architecture and providers with both frameworks in mind from the start, prioritizing partners who already bridge PSD2 and PSD3, support API-first distribution, and bring an active TPP ecosystem so clients benefit from real use cases from day one. 

Q3-Q4 2026: Architecture and design. Define your target architecture for consent management, fraud data sharing, and expanded SCA. Align with emerging EBA technical standards as they publish.

2027: Build, test, and certify. Execute the technical migration. Run parallel systems where possible. Plan for certification with your national competent authority under the new regime.

H2 2027 / early 2028: Go live. Full PSD3/PSR compliance operational.

The 18-to-21-month transition window sounds generous. It is not. We have seen PSD2 migration projects take 12-14 months for a mid-size PSP, and PSD3 touches more systems. The consent dashboard alone requires deep integration across your entire data access layer. Fraud data sharing needs cross-institutional coordination that depends on EBA technical standards not yet published. Start your gap analysis now, before the final texts lock in the details.

PSD3 Compliance Checklist for PSPs, EMIs, and Neobanks

Use this PSD3 compliance checklist for payment platforms to track your readiness across all eight technical change areas:

Area	What to verify
Consent dashboard	– real-time two-way consent sync between ASPSP and TPPs – revocation UI – permission transparency display
Verification of Payee	– IBAN-name matching before all credit transfers – discrepancy notification UX – opt-out flow
SCA update	– dynamic linking enforcement – accessibility alternatives – wallet enrollment SCA – AISP lifecycle ownership
Fraud data sharing	– ingestion pipeline for shared fraud signals – reporting pipeline outward – integrated real-time risk scoring
Open banking APIs	– uptime and performance SLA compliance – obstacle-free TPP access – incident response process
Fraud liability system	– spoofing detection – behavioral analytics – device fingerprinting – 10-day refund workflow
Licensing compliance	– mapped EMI/PI obligations to new PSD3 unified regime – updated capital adequacy reporting
Payment system access	– assessed eligibility for direct payment system participation – integration layer updated if applicable
FIDA readiness	– architecture designed for future FIDA data scope expansion beyond payment accounts

How Kindgeek and Salt Edge Help With PSD3 Migration

What company can help with PSD3 migration? Kindgeek is a fintech engineering partner for PSD3 compliance, specializing in payment platform modernization for PSPs, EMIs, and neobanks. Our engineers understand consent management, SCA architecture, and open banking API integration at the code level.

Our partnership with Salt Edge means we cover both layers of PSD3 migration from a single engagement:

• Salt Edge provides compliant open banking rails: consent state synchronization, API aggregation across 5,000+ financial institutions, and Open Banking Compliance infrastructure that already meets PSR requirements.
• Kindgeek builds the product engineering layer: consent dashboards, SCA flows, Verification of Payee logic, fraud data-sharing infrastructure, liability architecture, and EMI/PI compliance reporting.

On future-proofing, Colta describes Salt Edge’s PSD3 architecture as deliberately modular where consent, data access, and orchestration are kept as separate layers. The consent management API is being built in a data-agnostic way so that expanding into broader FIDA data scopes is “a natural progression, not a rebuild” as regulation and market demand evolve. Rather than treating FIDA as a separate product, the PSD3 design is open-finance ready from day one.