PSD2 vs PSD3: A System-Level Guide for PSPs, EMIs and Banks

Your PSD3 readiness plan is probably already behind. The law isn’t published in the Official Journal yet, but the systems it requires are complex, and 21 months isn’t much runway when SCA refactoring, VoP integration, and permission dashboard builds are all on the critical path.

This article is written for product, compliance, and engineering leads at EU-licensed PSPs, EMIs, and banks who need to understand what PSD2 vs PSD3 means for the systems they run. It covers the legislative timeline as of October 2026, a side-by-side comparison table across nine system areas, and a segment-by-segment action map for the five business types most affected.

DashDevs has 15+ years in regulated fintech. The consent architecture we built for Tarabut Gateway and the multi-rail routing we built for MuchBetter are both directly relevant to the engineering problems PSD3 creates. What follows reflects what we see in production

PSD3 and PSR Timeline: Status as of October 2026

Status as of October 2026.

Proposed by the European Commission in June 2023, the directive moved through a multi-year legislative process before reaching a provisional political agreement on 27 November 2025. The final compromise texts for the legislative proposals on the Third Payment Services Directive (PSD3) and the Payment Services Regulation (PSR) by the Council of the EU. The Council expects formal adoption and publication in the Official Journal at the turn of 2026/2027, after which the transposition clock starts.

The PSR is different. Once published in the Official Journal, it applies directly across all 27 EU member states with no transposition step. That is the structural point competitors miss: PSD3 and the PSR are two instruments, and they work in tandem.

Key milestones:

• June 2023: European Commission publishes PSD3 and PSR proposals
• 27 November 2025: Provisional political agreement between Parliament and Council.
• 23 April 2026: Final compromise texts published.
• Turn of 2026/2027 (expected): Formal adoption and publication in the Official Journal
• 21 months after entry into force (~H2 2028): Most PSR obligations apply.
• 27 months after entry into force (~H1 2029): Verification of payee for all credit transfers applies; end of PI/EMI transition window.

For most PSPs and EMIs, the practical compliance window is tighter than those timelines suggest. The technical standards (RTS and ITS) under the PSD3 regulation will be drafted by the EBA and the European Commission during the transposition period, and those are what engineering teams will actually implement. When looking at PSD3 vs. PSD2 from a delivery standpoint, the key difference is that the PSR gives teams less room to wait for member-state guidance before starting build work.

The 21-month transposition clock starts when the text enters into force. Any product or platform change that requires API redesign, SCA flow refactoring, or ledger-level data changes takes at minimum six to twelve months end-to-end. That leaves almost no margin for teams that wait.

PSD3 and How Does It Differ from PSD2?

PSD3 is the EU’s third PSD, a legislative update to PSD2 that tightens fraud liability, expands open banking obligations, extends strong customer authentication, and introduces a directly applicable companion regulation that applies uniformly across all EU member states.

The PSD3 to PSD2 in plain terms: PSD2 created the framework. PSD3 fixes what didn’t work in that framework and makes enforcement consistent. Framed as PSD3 vs PSD2, the question becomes: what did the original EU Payment Services Directive leave unresolved, and how does the new directive address it?

The PSD2 regulation produced measurable results: open banking APIs across Europe, mandatory SCA for online payments, and third-party access to account data. It also produced persistent problems. Among the core PSD2 requirements that created the most friction in production:

• Banks implemented the directive inconsistently, with some building fallback interfaces that performed poorly by design
• SCA exemptions were applied selectively, with no uniform enforcement across member states
• Fraud liability rules were unclear when impersonation was involved, leaving liability disputes unresolved
• The verification of payee requirement covered only SEPA Instant, leaving regular credit transfers unprotected

PSD3 addresses each of these failures directly. The practical consequences for payment businesses are substantial.

Legal form changes

Under the PSD2 regulations, the RTS on SCA and common and secure open standards of communication sat as a separate delegated regulation. Under PSD3, the PSR consolidates consumer-facing rules into a directly applicable regulation. That means a PSP operating in Germany and France faces identical PSR obligations in both countries, with no transposition-driven variation. Compliance programs that relied on member-state flexibility will need to be rebuilt on a single standard.

Fraud liability and impersonation

PSD2 left impersonation fraud in a grey area. If a criminal posed as a bank employee and convinced a customer to authenticate a fraudulent payment, liability allocation was often disputed. PSD3 resolves this: issuers and PSPs become liable for losses where fraud exploits their employees or their authentication infrastructure. Payment schemes and technical third-party providers (including digital wallet operators) also carry liability if they failed to apply SCA correctly.

This matters operationally. It means your fraud monitoring must now cover social-engineering vectors.

Electronic money institution and payment institution licensing

PSD2 maintained separate licensing tracks for PIs and EMIs. PSD3 introduces a unified pathway. Existing licence holders have 24 months from transposition to re-authorise under the new framework. For businesses currently holding an EMI licence, the practical question is whether your AML, capital, and safeguarding arrangements meet the updated consolidated requirements. If you need context on the distinction between the two licence types, see our breakdown of electronic money institution vs payment institution differences.

PSD2 vs PSD3: Side-by-Side Comparison

The table below covers the nine areas most relevant to PSPs, EMIs, and banks building or updating payment systems.

Note: Exact applicability dates depend on Official Journal publication, expected at the turn of 2026/2027. Most PSR obligations are expected to apply H2 2028; VoP on all credit transfers at H1 2029 (PwC RegCORE, April 2026).

For context on how multi-rail payments in Europe are architected under these frameworks, including where SEPA Instant, SEPA Credit Transfer, and domestic rails intersect with PSD obligations, see our dedicated guide.

What PSD3 and PSR Change in Your Payment Stack

Most competitors explain what the law says. This section explains what the law requires your systems to do differently.

Verification of payee service

Under PSD3, every PSP processing a credit transfer must check that the beneficiary’s name matches the IBAN before the payment is authorized. This isn’t optional for SEPA Instant only: it applies to all credit transfers once the VoP timeline hits.

What this means in production:

• Integrate directly with a VoP scheme (EBA Clearing’s VoP service or a national equivalent) or connect via a third-party VoP provider
• Run the check pre-transaction, before authorization is issued
• Store the result with the transaction record for audit purposes
• Surface a clear warning in your UI when there is a name/IBAN mismatch

Teams building this for the first time typically underestimate the edge cases: partial name matches, legal entity names that differ from trading names, and joint accounts. We have a detailed breakdown of how verification of payee in SEPA transfers works at the protocol level.

Fraud signal sharing

PSD3 permits PSPs to share fraud-related data without violating GDPR, provided the sharing operates within a defined framework. The data set is broader than what most teams currently collect. In scope under the PSR:

• Transaction timing and amount
• Device fingerprint and session data
• User location and IP address
• Transaction history

This has two engineering consequences. First, your transaction monitoring system must capture and store the full extended data set. Second, you need a secure, auditable mechanism for outbound and inbound fraud signal exchange. Most teams will integrate with a shared fraud data consortium (there are several operating in the EU) rather than building bilateral connections.

Fraud signal sharing isn’t a feature you add to a transaction monitoring system. It is a separate data pipeline with its own consent, retention, and access-control requirements. Build it separately.

SCA flow refactoring

Three SCA changes require active engineering work under PSD3:

• Wallet tokenization SCA: Adding a card to Apple Pay, Google Pay, or any digital wallet now requires SCA at enrolment. If your card issuing infrastructure delegates wallet provisioning to a third-party processor, verify that the processor’s enrolment flow captures SCA and returns a compliant audit record. Liability for a failed enrolment SCA falls on the issuer.
• Non-smartphone authentication paths: Your SCA implementation must offer at least one method that doesn’t require a smartphone. Hardware OTP tokens, dedicated card readers, or call-center-assisted flows are the most common solutions. This isn’t optional for any PSP offering accounts to retail consumers.
• Flexible factor categories: PSD2 required two of three factor types (knowledge, possession, and inherence). PSD3 allows two factors from the same category. Your SCA configuration should be updated to allow, for example, two knowledge factors for users who can’t use biometrics. This sounds like a minor change; it often requires updates to both the authentication server and the fraud scoring logic that interprets the authentication outcome.

For the biometric authentication for SCA implementation patterns we use with licensed payment clients, including fallback flow design, see our dedicated article.

Permission dashboard and open banking API parity

PSD3 requires banks to give consumers a dashboard where they can see which AISPs and PISPs have active access to their accounts and revoke that access in real time. For banks and large PSPs, this is a product build. The dashboard must:

• Surface active consent records across all integrated TPPs
• Handle revocation with sub-second effect on API gateway authorization
• Log every access and revocation event for audit

For a reference on how banking APIs are structured to support these consent and revocation patterns, see our dedicated guide.

For AISPs and PISPs, the implication is different: your consent management layer must respond correctly to revocation events from the bank. A consent you believed was active can be revoked at any moment by the consumer. If your service continues calling the bank API after revocation, you are in breach. If you need context on how open banking infrastructure handles consent lifecycle management, we cover the full data flow in that article.

Licensing data for PI/EMI re-authorisation

The unified PI/EMI licensing pathway requires existing licence holders to reapply within 24 months of the directive’s transposition date. The re-authorisation package will require demonstrating compliance with PSD3’s updated safeguarding, AML, and capital requirements. KYC and KYB documentation is a central part of that package. If your current onboarding flows produce incomplete or inconsistent identity records, that gap surfaces at re-authorisation. Our KYC integration service covers the data quality and audit trail requirements that regulators inspect. Start assembling that data now. Regulators in most EU jurisdictions have indicated they won’t grant extensions.

Open Banking Under PSD3

PSD3 doesn’t reinvent open banking. It fixes the parts of PSD2 that banks exploited to slow down or block third-party access.

Under PSD2, banks were required to provide a dedicated API interface and a fallback interface as a backup. In practice, the fallback was used as a lever: banks that let their dedicated interface perform poorly knew TPPs could fall back to screen scraping, and regulators were slow to enforce interface quality standards. PSD3 removes the fallback requirement entirely and raises the performance bar on the dedicated interface instead.

What changes for banks

Two new mandatory builds for banks:

• Quarterly API performance reporting: availability, response times, and error rates submitted to the national competent authority. A bank whose API underperforms against published benchmarks faces enforcement action. Regulatory pressure now runs toward better performance.
• Consumer permission dashboard: must show all active AISP and PISP consents, display what data each TPP can access, and allow revocation in real time, with immediate propagation to the API gateway.

If you are building or modernizing with open banking API providers for a licensed institution, the permission dashboard and the performance reporting module are the two new builds that don’t exist in most current open banking stacks.

What changes for AISPs and PISPs

The removal of the fallback interface is a constraint for third-party providers. Screen scraping as a backup is no longer permitted once PSD3 takes effect. Your integration must rely entirely on the bank’s dedicated API. If that API goes down, your service goes down with it.

The practical response is better circuit-breaker logic, multi-bank redundancy where the product allows it, and clear user-facing communication when a bank API is unavailable. PSD3 requires banks to notify TPPs of planned downtime, but unplanned outages still happen.

For teams integrating with open banking providers across multiple EU jurisdictions, the removal of the fallback also means that your testing environments need to simulate API failure scenarios properly. That testing discipline is rarely in place when a product ships.

The dedicated interface is now the only interface. If your product resilience plan includes a fallback to screen scraping, that plan expires when PSD3 takes effect in your jurisdiction.

The interplay between PSD3, Wero, and DORA is covered in depth on Fintech Garden, the fintech podcast by DashDevs, in an episode dedicated to how these three regulatory programs interact at the system level.

SCA: What Changes in Your Authentication Flows

Strong customer authentication under PSD3 is more demanding than PSD2 in three specific ways: the scope is broader, the accessibility requirements are stricter, and the liability chain is longer.

Scope expansion

The most operationally significant addition is SCA for mobile wallet enrolment. Under PSD2, adding a card to a digital wallet sat in a grey area of the SCA framework. Under PSD3, it is in scope without exception. Every card-to-wallet provisioning event must be SCA-authenticated, and the authentication record must be retained.

For card issuers, this means your provisioning API needs to trigger an SCA challenge at the point of enrolment. For wallet operators running a stored-value account or a tokenized card program, this requires SCA delegation to be documented as outsourcing, with all the contractual and operational requirements that come with it.

Merchant-initiated transactions and MOTO payments remain exempt. The first transaction in a recurring series still requires SCA; subsequent transactions initiated by the merchant don’t. That rule is unchanged from PSD2.

Accessibility

PSD3 requires every PSP to offer at least one SCA method that doesn’t depend solely on a smartphone. That is a harder requirement than it sounds. Most modern SCA implementations are entirely smartphone-based: push notification, authenticator app, or SMS OTP to a mobile number. None of these work for a customer without a smartphone or without mobile signal.

The compliant solutions are:

• Hardware OTP token
• Dedicated card reader (common in business banking)
• Call-center-assisted authentication with alternative verification
• Branch-based fallback

At least one of these must be live on your platform before PSD3 obligations apply.

Liability

Third-party providers and digital wallet operators that are delegated SCA responsibility by an issuer are now classified as outsourcers of that function. They carry liability for fraud that results from a failure to apply SCA correctly. Payment gateways are specifically named: if a gateway fails to enforce SCA where it was required, the gateway bears liability.

For any business in the payment chain that currently handles authentication on behalf of an issuer, review your contracts now. The liability allocation in your current MSA almost certainly predates PSD3 and doesn’t reflect the updated framework.

If you need a technical reference on how DORA compliance intersects with authentication outsourcing requirements, that article covers the operational resilience obligations that run alongside PSD3’s SCA rules.

From Open Banking Concept to Regulated Infrastructure: Lessons from Tarabut

In 2021, we built MENA’s first regulated open banking platform for Tarabut Gateway on a $500K budget, delivered in 9 months, integrating 8 banks across Bahrain in the first 6 months of operation.

The core engineering challenge wasn’t the API integrations themselves. It was consent management. Every bank had a different interpretation of what a valid consent looked like, how long it remained active, and under what conditions it could be revoked. We built a consent orchestration layer that normalized those differences into a single model the platform could reason about, audit, and revoke reliably.

That problem doesn’t go away under PSD3. It gets more demanding. The permission dashboard requirement means the consent lifecycle is now visible to consumers in real time, and revocation must propagate instantly. The consent model we built for Tarabut, which treated consent as a first-class data entity with its own audit trail and lifecycle state machine, is exactly the architecture PSD3’s permission dashboard requires.

Tarabut went from £0 to a £25M valuation, and the platform now has 200K+ users. None of that would have been possible without a consent layer that regulators could inspect and that banks could trust.

If you are building a compliant open banking product under PSD3, the permission dashboard is a consent infrastructure problem.

For teams working on the payments side, the multi-rail routing architecture we built for MuchBetter, which handles SEPA Instant payments, standard credit transfer, and card rails within a single payment flow, is directly relevant to the cross-rail SCA and VoP requirements PSD3 introduces. See the MuchBetter case study for details on how those routing decisions were made.

Who Needs to Do What: Segment-by-Segment Action Map

PSD3 doesn’t affect every business the same way. The table below maps the five most common segments to their priority actions.

For infrastructure design and compliance architecture support across any of these segments, our infrastructure for licensed PSPs and EMIs and fintech consulting services covers the full stack from licensing data to production system design.

You may also find it useful to read how the trade-off between compliance and speed in cross-border payments plays out in practice, particularly where VoP and SCA interact with payment latency requirements.

The Bottom Line

PSD2 built the framework for open banking and SCA in Europe. PSD3 closes the gaps that banks and PSPs spent a decade exploiting.

The paired PSR is the most significant structural change: one directly applicable regulation across all 27 EU member states means there is no longer a compliant version of PSD3 implementation that varies by jurisdiction. Your SCA flows, VoP integration, fraud data infrastructure, and consent management layer all need to meet a single standard.

The timeline is tighter than it looks. Official Journal publication is expected at the turn of 2026/2027, with most PSR obligations applying around H2 2028. By the time RTS and ITS are finalised and ready for implementation, the practical engineering window for most teams will be 12 to 18 months. That isn’t enough time to treat PSD3 as a future problem.

The businesses that will be in the best position at the transposition deadline are the ones that assess their stack now, prioritize the five areas identified above, and build to the standard. PSD2 taught that lesson at considerable cost. PSD3 offers an opportunity to apply it.

If your team needs support assessing PSD3 readiness, mapping obligations to your current architecture, or building specific compliance components, DashDevs’ fintech consulting team works with licensed PSPs, EMIs, and banks across Europe.