PSD3 and PSR: What's Changing for EU Payments and What Engineering Teams Must Update

PSD2 opened EU payment accounts to third-party providers (TPPs), mandated strong customer authentication (SCA), and created the XS2A API economy. It also produced uneven implementation across member states, persistent fraud losses, and open-banking interfaces that many corporates still cannot rely on for production volumes.

In April 2026, the Council of the EU published final compromise texts for the next package: the Third Payment Services Directive (PSD3) and the Payment Services Regulation (PSR). Together they aim to harmonise conduct rules, tighten fraud prevention, upgrade open banking access, and consolidate licensing for payment institutions (PIs) and electronic money institutions (EMIs).

This article is for CTOs, engineering leads, and architects at banks, EMIs, TPPs, and fintech vendors who already run PSD2-shaped systems. It is not legal advice. It translates the direction of travel into what you will likely need to change in products and platforms, and how to phase work before the expected application window (indicatively H1 2028, subject to Official Journal publication and EBA technical standards).

If you are still scoping baseline controls, start with our fintech regulatory and security checklist before you treat this as a delta list.

PSD3 vs PSR: two instruments, one programme

Instrument	Form	What it mainly governs	Who feels it first
PSR	EU Regulation (direct effect)	Conduct, transparency, SCA, open banking access, fraud, payment execution, liability	Product, API, payments, fraud, IAM teams
PSD3	EU Directive (national transposition)	Authorisation, prudential requirements, supervision; EMI as sub-category of PI	Compliance, finance, ops; engineering for safeguarding and reporting

Practical rule: API, consent, SCA, VoP, and transaction monitoring changes sit in the PSR track. Re-authorisation, safeguarding timing, and winding-up planning sit in PSD3.

Do not confuse this package with FiDA (Financial Data Access), which extends secure data sharing beyond payments, or with the UK regime, which follows its own open-banking path after Brexit.

Timeline: what is settled vs still coming

Based on published compromise texts and legislative process as of June 2026:

1. Political agreement was reached in late 2025; final texts were published in April 2026.
2. Formal adoption and Official Journal publication are expected in summer 2026 (confirm before you commit dates externally).
3. Entry into force typically follows 20 days after OJ publication.
4. Application for most PSR and PSD3 provisions is expected about 21 months after entry into force (indicative H1 2028).
5. Verification of payee (VoP) and related liability provisions may apply on a longer horizon (often cited around 27 months).
6. EBA regulatory technical standards (RTS) and guidelines will define detail for SCA, monitoring, dashboards, and reporting. Plan a second implementation wave after RTS publication.

Existing PIs and EMIs face a re-authorisation process under PSD3, with grandfathering only if they apply in time and meet the new requirements. Engineering should align with legal on evidence that systems already satisfy upgraded rules (or on a remediation roadmap).

Ten changes that matter for engineering

The ten PSD3/PSR changes that touch engineering, from dedicated TPP interfaces to MiCA overlap.

1. Dedicated TPP interfaces only

Under PSR, account-servicing payment service providers (ASPSPs) must offer TPPs a dedicated access interface with availability and performance at least at the level of the customer-facing channel. The PSD2 pattern of serving TPPs through a modified customer interface (popular with corporate banking) is not a long-term path.

Engineering impact: gap analysis on your XS2A layer; SLO monitoring that compares TPP vs retail traffic; capacity planning; deprecation of corporate opt-outs where they existed in national law.

2. Business continuity when the dedicated API is down

The formal contingency fallback interface requirement is removed, but ASPSPs must still offer an effective alternative so TPPs can continue when the primary interface fails.

Engineering impact: runbooks, failover design, and contractual SLAs with TPPs; test scenarios beyond happy-path sandbox.

3. Consent dashboard in the customer channel

ASPSPs must embed a dashboard in the customer interface where users see which TPPs have access, to which accounts, for what purpose, for how long, and which data categories are shared. Users must be able to withdraw consent from the dashboard. Records of withdrawn or expired consents must be kept (two years in the published texts). ASPSPs and TPPs must cooperate in real time on consent state.

Engineering impact: new UI surface, consent data model extensions, webhooks or event streams to TPPs, audit storage, and regression tests on revocation paths.

4. Stronger SCA and EUDI wallets

PSR expands SCA expectations, including accessibility (support for users without smartphones or with disabilities, free of charge where required). Dynamic linking applies more broadly to remote payment orders, including certain NFC / wallet contactless flows per recitals. PSPs must be ready to accept EU Digital Identity (EUDI) wallets for SCA as member states roll out eIDAS 2.0 wallets.

Engineering impact: payment flow review, IAM roadmap, alternative authentication channels, and test matrices for wallet and contactless edge cases.

5. Verification of payee (VoP) on credit transfers

VoP requirements extend to all credit transfers, not only the SEPA subsets already in scope. PSPs must match IBAN (or other identifier) to payee name before execution, with rules for payer choice when there is a mismatch. Non-consumer users get structured opt-out / opt-in options.

Engineering impact: new pre-execution step in payment engines, name-matching services, logging for liability, and API changes for corporate channels.

6. Fraud monitoring, sharing, and liability

PSP transaction monitoring must improve continuously, with explicit room for modern analytics and AI in detection (under human governance and policy). PSPs must participate in fraud information sharing arrangements, subject to GDPR (DPIA, purpose limitation: fraud monitoring only, no automatic customer off-boarding from shared data alone). Liability expands when monitoring or VoP obligations fail.

Engineering impact: data pipelines, consent and retention for shared fraud signals, model documentation, and incident evidence for regulators.

7. Technical service providers (TSPs) in scope

TSPs that are not licensed PSPs still face new rules when they provide or verify elements of SCA, including outsourcing agreements with PSPs and liability for direct financial damage if they fail to support SCA, capped in proportion to the failure.

Engineering impact: if you sell authentication or payment widgets as a vendor, review contracts, shared responsibility models, and observability on SCA flows.

8. PI/EMI re-authorisation and safeguarding (PSD3)

EMIs become a sub-category of payment institutions. Existing PIs and EMIs must re-apply for authorisation. Safeguarding rules tighten: EMIs move toward T+1 safeguarding (from T+5 under EMD2), with concentration risk mitigation across safeguarding accounts and regulator notification on material changes. Firms need winding-up plans that cover outsourced critical activities.

Engineering impact: treasury and ledger jobs, reconciliation timing, reporting hooks, and disaster-recovery documentation tied to ops runbooks.

9. Access to payment accounts and payment systems

Banks may refuse or close payment accounts for PIs only on limited serious grounds. Payment system operators must apply POND (proportionate, objective, non-discriminatory) access rules. PIs and EMIs may gain direct participation in certain settlement systems under amended settlement finality rules.

Engineering impact: mostly legal and treasury, but affects settlement integrations and liquidity architecture for non-bank PSPs.

10. MiCA overlap for e-money tokens

The package clarifies how e-money tokens interact with MiCA and PSD3 licensing, including deemed equivalence for certain crypto-asset services when a firm is PSD3-authorised (notification timelines apply).

Engineering impact: service catalogue matrix (what is offered under which licence); avoid shipping features that trigger a second authorisation path by accident.

Open banking upgrades in practice

Teams that built PSD2 compliance in 2018–2022 should assume a programme, not a patch release:

1. Inventory current TPP interfaces, consent stores, and SCA methods per channel.
2. Benchmark TPP API uptime and latency against retail digital banking (not against a legacy PSD2 minimum).
3. Design the consent dashboard as a first-class product surface, not an admin screen.
4. Harden revocation and propagation to TPPs (idempotent webhooks, reconciliation jobs).
5. Plan VoP and monitoring as platform capabilities, not per-product one-offs.

Our open banking API integration case illustrates production patterns (unified API, consent, multi-bank connectivity) that teams extend when regulation moves from PSD2 to PSR-shaped requirements. For Java-centric gateway and integration work, see enterprise Java and Oracle engineering.

Engineering readiness checklist

Use this as a gap-analysis worksheet against your current PSD2 baseline. Map each row to an owner (engineering, compliance, ops).

Area	PSD3/PSR driver	Typical system touchpoints	Action
XS2A / API gateway	Dedicated TPP API, performance parity	API gateway, rate limits, monitoring	Re-architect or upgrade; publish SLO evidence
Consent	Dashboard, withdrawal, 2-year records	Consent DB, customer app, TPP notifications	New UX + event model
SCA / IAM	Accessibility, EUDI, dynamic linking	Auth server, mobile apps, wallets	Flow redesign + RTS watch list
Payments core	VoP on credit transfers	Payment engine, SEPA/non-SEPA rails	Pre-validation step + mismatch policy
Fraud / risk	Monitoring, sharing, liability	Rules engine, ML, case management	Data model + legal basis for sharing
Reconciliation	New liability chains	Ledger, dispute workflows	Update playbooks
Safeguarding (EMI)	T+1, diversification	Treasury, core ledger	Batch timing + bank account strategy
Licensing	Re-authorisation, winding-up plan	GRC tooling, architecture docs	Evidence pack for competent authority
Vendors / TSP	Outsourcing, SCA support	Contracts, integration layer	DPIA + SLA + exit clauses
Reporting	Fraud stats, API performance	Data warehouse, regulatory exports	Align with upcoming EBA RTS

Phased roadmap (indicative)

Phase 1 (H2 2026): Executive sponsorship; PSD2 vs PSR/PSD3 gap analysis; join industry working groups; freeze a regulatory assumptions doc for architects.

Phase 2 (2027): Target architecture for dedicated API, consent dashboard, VoP, and monitoring; re-authorisation dossier inputs from engineering; pilot markets for highest-risk flows.

Phase 3 (H1 2028 target): Production rollout, penetration and conformance testing, RTS-driven adjustments.

Phase 4 (ongoing): FiDA and open-finance data products; UK/EU divergence if you operate in both; scheme evolution (e.g. industry payment schemes beyond bare XS2A).

UK, FiDA, and what stays outside this article

• United Kingdom: PSD3/PSR do not apply. UK firms follow FCA and Open Banking Implementation Entity (OBIE) evolution separately. If you serve both EU and UK, maintain two compliance tracks in architecture and roadmaps.
• FiDA: Still in negotiation as of mid-2026. It will extend data access to investments, insurance, and pensions. Design consent and API patterns that can reuse payment-era infrastructure without baking in payments-only assumptions.
• Vendor selection: PSD3 raises the bar on bank-side performance and TPP-side governance. Product teams still use aggregators and compliance platforms where licensing and coverage justify it; treat vendor RFPs as a separate procurement exercise from this engineering delta.

Conclusion

PSD3 and the PSR are not a rebranding exercise. They move core conduct rules into a directly applicable regulation, tighten open banking access and consent transparency, and pair VoP and fraud sharing with clearer liability. For engineering organisations, the work is visible: APIs, consent, payments, IAM, monitoring, and safeguarding pipelines all move together.

Teams that treated PSD2 as a one-off integration project will feel the cost of retrofitting. Teams that run a continuous compliance architecture (checklist in discovery, idempotent payments, observable APIs) can absorb much of the delta as incremental releases.

If you are planning PSD3-ready open banking integration, payment modernisation, or Java-based API gateways in a regulated environment, tell us about your scope. We help fintech and enterprise teams ship production systems where regulation, security, and delivery speed must align.

Disclaimer: This article summarises publicly available legislative materials and industry analysis as of June 2026. Confirm all obligations, dates, and national transposition with qualified legal counsel and your competent authority before implementation.