DORA vs PSD2/PSD3: 2026 Guide for EU Payment Institutions and EMIs
DORA vs PSD2/PSD3 for EU payment institutions and EMIs in 2026: operational resilience, payment security, incident reporting, SCA, fraud and third-party ICT.
In this article ↓
- The short answer
- DORA vs PSD2 vs PSD3/PSR at a glance
- What DORA changes for payment institutions and EMIs
- Where PSD2 still matters
- What PSD3 and PSR change in the operating direction
- Which regime owns which question?
- Comparison table: what to build once
- Incident reporting: the overlap that causes the most confusion
- One incident workflow, two reporting logics
- Third-party ICT risk: DORA is the heavier framework
- Supplier map for payment firms
- Evidence checklist for EU payment institutions and EMIs
- Obligation matrix: who owns what in a payment institution
- Common implementation mistakes
- Mistake 1: Treating PSD2 controls as enough for DORA
- Mistake 2: Running separate incident processes
- Mistake 3: Mapping suppliers only by contract owner
- Mistake 4: Waiting for PSD3/PSR final application dates before fixing operations
- Mistake 5: Treating open banking as only a PSD2 topic
- Mistake 6: Forgetting instant payments dependencies
- Practical 30-day alignment plan
- FAQ
- Does DORA replace PSD2 for payment institutions and EMIs?
- Does PSD3 replace DORA?
- Are PSD3 and PSR already final law?
- Should payment firms maintain separate DORA and PSD2 incident workflows?
- Does open banking sit under DORA or PSD2?
- What is the best first step for an EMI?
- Bottom line
- Related reading
- Primary sources
Last reviewed: 30 April 2026
The short answer
DORA and PSD2/PSD3 sit next to each other.
They solve different problems.
- DORA is the EU digital operational resilience framework for financial entities. It applies to payment institutions, e-money institutions and other financial entities in scope. It focuses on ICT risk management, incident reporting, resilience testing and ICT third-party risk.
- PSD2 is the current EU payment services directive. It focuses on payment services, payment institutions, e-money institutions, open banking, Strong Customer Authentication (SCA), consumer rights and payment security.
- PSD3 and the Payment Services Regulation (PSR) are the next generation of EU payments law. Political agreement was announced in November 2025 and compromise texts were moving through the legislative process in April 2026. Firms should track final publication and application dates, but the operating direction is clear: stronger fraud controls, more harmonisation, updated authorisation and clearer open-banking rules.
For an EU payment institution or EMI, the practical answer is: do not run DORA and PSD2/PSD3 as separate programmes. Use one operating model for ICT risk, incidents, third-party providers, fraud/security controls and management reporting.
DORA vs PSD2 vs PSD3/PSR at a glance
| Topic | DORA | PSD2 | PSD3 / PSR |
|---|---|---|---|
| Legal form | Regulation, directly applicable | Directive, transposed into national law | PSD3 Directive plus PSR Regulation |
| Main focus | Digital operational resilience | Payment services and payment security | Modernised payment and e-money framework |
| Status in 2026 | Applies since 17 January 2025 | Current payment services framework until replaced | Political agreement reached in Nov 2025; compromise texts progressed in Apr 2026 |
| Core audience | Financial entities, including PIs and EMIs | Payment service providers | Payment institutions, e-money institutions, PSPs and related actors |
| ICT risk | Central requirement | Relevant through security and operational risk expectations | Expected to coexist with DORA, not replace it |
| Incident reporting | Major ICT-related incidents under DORA Article 19 | Operational/security incident reporting under PSD2 framework | Expected to refine payment-specific incident and fraud/security rules |
| Third-party ICT risk | Dedicated DORA lifecycle and contract obligations | Outsourcing and operational reliability expectations | DORA remains the main ICT third-party resilience framework |
| Customer authentication | Not the primary regime | SCA and secure communication | Fraud prevention and SCA remain central themes |
| Fraud controls | Relevant where fraud depends on ICT controls and incidents | Core payment security topic | Stronger fraud prevention direction |
| Open banking | Relevant where APIs and ICT resilience support services | AIS/PIS access and secure communication | Expected to clarify access, obstacles and user permissions |
| Best implementation model | Evidence-led ICT resilience operating model | Payment compliance and security controls | Integrated payments + resilience governance |
What DORA changes for payment institutions and EMIs
Payment institutions and e-money institutions are financial entities under DORA. That means DORA is not a side framework for payments firms; it becomes part of the operating baseline.
In practice, DORA adds a structured resilience layer around the payment business:
- ICT risk management framework;
- management-body oversight;
- incident classification and major ICT-related incident reporting;
- business continuity and disaster recovery;
- resilience testing;
- ICT third-party risk management;
- Register of Information for ICT third-party arrangements;
- evidence of remediation and control operation.
PSD2 already pushed payment firms toward secure payments, SCA, access interfaces and incident/security controls. DORA goes wider: it asks whether the entity can withstand, respond to and recover from ICT disruptions across critical or important functions.
Where PSD2 still matters
PSD2 remains important because it governs the payment services relationship itself.
For payment firms, PSD2 concerns include:
- authorisation and conduct of payment services;
- Strong Customer Authentication;
- secure communication;
- access to payment accounts for regulated third-party providers;
- consumer transparency and rights;
- liability and unauthorised payment transactions;
- payment-specific security and operational incident expectations.
DORA does not replace these payment-service obligations. It changes the resilience environment around them.
Example:
SCA failure, payment fraud controls and open-banking interface availability may sit under payment services rules. The ICT systems, incident handling, third-party dependencies and recovery evidence also matter under DORA.
What PSD3 and PSR change in the operating direction
The European Commission published proposals in June 2023 for:
- a new Payment Services and Electronic Money Services Directive, commonly referred to as PSD3;
- a directly applicable Payment Services Regulation (PSR).
The European Parliament and Council announced political agreement on 27 November 2025. Council compromise text documents were published in April 2026. Until the final texts are published in the Official Journal and application dates are confirmed, firms should avoid treating every draft detail as live law.
Still, the operating direction is visible:
| Theme | Direction under PSD3 / PSR | What payment firms can do now |
|---|---|---|
| Fraud prevention | Stronger preventive controls and liability consequences | Improve fraud governance, payee checks, monitoring and customer communication |
| Authorisation | Updated PI/EMI authorisation and supervisory framework | Keep licence perimeter, capital, governance and service descriptions current |
| E-money integration | Payment and e-money services move into a more unified framework | Reconcile PI/EMI governance and safeguarding evidence |
| Open banking | More harmonised access, obstacle rules and user permission controls | Review API availability, permission dashboards and TPP access evidence |
| SCA | Continued focus on authentication and risk assessment | Maintain SCA architecture, exemptions, risk analysis and change records |
| Consumer protection | Stronger transparency, dispute and fraud handling | Align complaints, incident and customer communication workflows |
| Platform / technical access | New access obligations may affect certain technical actors | Track dependencies on mobile, wallet and interface providers |
These areas overlap with DORA operationally even when the legal obligation comes from payment services law.
Which regime owns which question?
| Question | Primary regime | Practical answer |
|---|---|---|
| Can the firm provide payment or e-money services? | PSD2 / PSD3 | Maintain authorisation, service perimeter and supervisory evidence |
| Can the firm withstand ICT disruption? | DORA | Maintain ICT risk, BCDR, testing, supplier and incident evidence |
| Are customers authenticated securely? | PSD2 / PSR | Maintain SCA architecture, exemptions, fraud controls and secure communication evidence |
| How are major ICT incidents reported? | DORA | Use DORA classification, notification and authority route |
| How are payment-security or fraud incidents handled? | PSD2 / PSD3 / PSR | Use payment incident, fraud and customer communication logic |
| Are ICT suppliers controlled? | DORA | Maintain Register of Information, criticality, contract clauses and exit evidence |
| Are open-banking interfaces reliable? | PSD2 / PSR + DORA | Maintain availability, access, security and resilience evidence |
| What should the board see? | DORA + payments governance | One board pack with ICT risk, fraud, incidents, suppliers and remediation |
This table is the core implementation principle: one operating model, different legal views.
Comparison table: what to build once
| Operating capability | DORA need | PSD2 / PSD3-PSR need | Build once by doing this |
|---|---|---|---|
| ICT risk register | Shows material ICT risks and treatment | Supports payment security governance | Maintain one ICT/payment risk register with control owners |
| Incident classification | Determines DORA major ICT incident reporting | Supports payment/security incident handling | Use one triage workflow with DORA and payment-service criteria |
| Business continuity | Proves recovery of critical or important functions | Supports payment service availability | Test end-to-end payment service recovery, not only infrastructure |
| Supplier oversight | Controls ICT third-party risk and Register of Information | Supports outsourcing and payment-service reliability | Map suppliers to payment services, critical functions and contracts |
| Fraud governance | Relevant where fraud depends on ICT systems and incidents | Core payment-services requirement | Connect fraud rules, authentication, monitoring and incident records |
| Open-banking resilience | API outages may be ICT incidents or resilience evidence | Access interface availability and secure communication matter | Monitor API availability, changes, incidents and TPP impact |
| Board reporting | Shows management-body oversight of ICT risk | Shows governance over payment security and fraud risks | Produce one board pack with resilience, fraud, incidents and remediation |
| Evidence management | Supports supervisory review | Supports audits, licensing and partner-bank due diligence | Maintain evidence by control owner and review cadence |
Incident reporting: the overlap that causes the most confusion
Incident reporting is where DORA and PSD2/PSDx overlap most visibly.
The safe operating assumption is:
- use DORA to manage ICT-related incident classification and major ICT-related incident reporting;
- maintain payment-specific incident and fraud logic where required under payment services rules;
- avoid duplicate incident workflows where the same event affects both ICT resilience and payment services.
For example, a payment processing outage may require:
- technical incident response;
- customer and partner communication;
- assessment of affected payment services;
- DORA major ICT-related incident classification;
- payment-security or operational incident assessment;
- management-body awareness where material;
- after-action remediation.
The mistake is to let compliance, payment operations and security classify the same event separately. A unified incident workflow should contain both DORA and payment-services decision points.
For DORA timing, see DORA Incident Reporting 2026.
One incident workflow, two reporting logics
| Event | DORA question | PSD2 / PSD3-PSR question | Evidence to keep |
|---|---|---|---|
| Card or payment processing outage | Is this a major ICT-related incident? | Is payment service availability or customer communication affected? | Detection time, service impact, transactions affected, recovery |
| SCA service failure | Does ICT disruption affect critical services? | Are authentication obligations, exemptions or fraud controls affected? | SCA impact, failed flows, customer impact, remediation |
| Open-banking API outage | Is an ICT service disruption reportable? | Are access-interface obligations or TPP access affected? | API availability, TPP impact, incident timeline |
| Fraud spike linked to control failure | Is there an ICT/security incident? | Are fraud reporting, liability or customer-protection obligations triggered? | Fraud metrics, root cause, customer handling, control change |
| Cloud provider incident | Is an ICT third-party incident affecting critical functions? | Are payment services unavailable or degraded? | Supplier notice, impact analysis, contract and exit evidence |
| Data integrity issue in ledger | Is resilience, integrity or availability affected? | Are payment records, customer balances or disclosures affected? | Reconciliation, correction, customer and authority decisions |
This structure keeps one timeline while preserving separate regulatory decisions.
Third-party ICT risk: DORA is the heavier framework
Payment firms depend heavily on third parties: cloud platforms, card processors, banking-as-a-service partners, fraud tools, KYC vendors, open-banking providers, core ledger systems, customer support tooling and payment gateways.
DORA makes ICT third-party risk a lifecycle discipline:
- due diligence before contracting;
- contract clauses for access, audit, security, incident support and exit;
- ongoing monitoring;
- subcontractor visibility;
- concentration-risk awareness;
- exit planning;
- Register of Information maintenance.
PSD2/PSD3 and PSR remain relevant for payment-service obligations, but DORA is the stronger operating framework for ICT dependency management.
Supplier map for payment firms
| Supplier type | DORA relevance | PSD2 / PSD3-PSR relevance | Evidence note |
|---|---|---|---|
| Card processor / scheme processor | ICT dependency supporting critical payment functions | Payment service reliability and customer impact | Contract, incident support, resilience and exit evidence |
| Banking-as-a-service / sponsor bank | Critical dependency for accounts, safeguarding or settlement | Authorisation perimeter, safeguarding, service model | Dependency map and responsibility split |
| Fraud / transaction monitoring tool | ICT service supporting risk controls | Fraud prevention and payment security | Rule governance, uptime, change and incident evidence |
| KYC / AML vendor | ICT supplier and operational dependency | Onboarding and compliance process support | Data, availability, subcontractor and continuity evidence |
| Open-banking platform | ICT dependency for AIS/PIS or access services | Interface access, TPP reliability, user permissions | API availability and incident evidence |
| Cloud provider | Core ICT third-party | Indirectly supports payment services | Register of Information, concentration and exit evidence |
| Customer support SaaS | ICT supplier if used for payment incidents / complaints | Complaint handling and customer communication | Access, data retention and continuity evidence |
The supplier list should not be a procurement spreadsheet only. It should show which payment service, critical function and regulatory evidence each supplier supports.
Evidence checklist for EU payment institutions and EMIs
For a payment institution or EMI, the combined DORA + PSD2/PSD3 evidence pack should include:
| Evidence artefact | DORA view | PSD2 / PSD3-PSR view |
|---|---|---|
| ICT risk register mapped to payment services | Core ICT risk evidence | Supports payment security governance |
| Critical or important function map | Defines DORA priority | Shows payment-service dependencies |
| Incident classification and payment incident workflow | Major ICT incident decision path | Payment-security / fraud incident path |
| SCA and fraud-control governance records | ICT control and incident relevance | Core payment security evidence |
| Open-banking or access-interface availability evidence | Resilience and ICT service evidence | PSD2 / PSR access evidence |
| Resilience test results for payment service chains | DORA testing evidence | Payment service continuity evidence |
| BCP/DR recovery evidence with RTO/RPO measurements | DORA BCDR evidence | Service availability support |
| Supplier criticality assessment | ICT third-party risk | Outsourcing and service reliability |
| Register of Information extract | DORA structured register | Supplier evidence input |
| ICT third-party contract clause tracker | Article 30 contract evidence | Outsourcing / operational dependency support |
| Board ICT/payment risk report | Management-body ICT risk oversight | Payment security and fraud governance |
| Remediation tracker with owners and target dates | Control improvement evidence | Audit, licensing and supervisory evidence |
This is the level of structure that helps avoid duplicated compliance work. One control can support several obligations if the evidence is clear.
Obligation matrix: who owns what in a payment institution
Operationally, the DORA / PSD2 / PSD3 conversation collapses into who owns each artefact and when it gets refreshed.
| Evidence artefact | DORA owner | PSD2 owner | PSD3 / PSR direction | Refresh cadence |
|---|---|---|---|---|
| ICT risk register | ICT risk owner | Operational and security risk input | Expected to remain relevant | Quarterly + material change |
| Major ICT incident notification | Incident manager / compliance | Payment incident owner informed | Fraud and incident rules remain important | Per incident |
| Open-banking interface availability | Technology / operations | Open-banking owner | Access and obstacle rules remain central | Monthly / quarterly |
| SCA exemption decisions | Indirect ICT control relevance | Fraud / payments owner | SCA and risk assessment remain central | On rule or risk-engine change |
| Fraud-rate KPI and monitoring | Security / ICT if system-driven | Fraud owner | Stronger fraud prevention direction | Monthly / quarterly |
| Strong Customer Authentication architecture | ICT risk / security | Payments / fraud owner | Expected to remain a core control | Major authentication change |
| Register of Information | ICT third-party risk owner | Outsourcing input | Supplier evidence remains relevant | Supplier or contract change |
| ICT third-party contract clauses | Legal / procurement / risk | Outsourcing input | DORA remains the heavier ICT contract layer | Contract renewal |
| Resilience testing | Security / technology / operations | Payment operations input | DORA remains the core testing regime | Annual + material change |
| Recovery time / point objectives | Operations / technology | Payment service owner | Continuity remains a payment-service concern | Tested annually |
| Board reporting on ICT, fraud and resilience | CEO / COO / risk owner | Compliance / payments / fraud owner | Integrated governance remains useful | Quarterly board pack |
| Customer transparency disclosures | Usually out of DORA | Compliance / conduct owner | Consumer protection remains central | Product launch or change |
For a payment institution running modern operations, this is one matrix maintained by one team, with each row owned by a specific function. The legal-instrument column is documentation, not allocation.
Common implementation mistakes
Mistake 1: Treating PSD2 controls as enough for DORA
PSD2 security controls may help, but DORA is broader. It covers resilience governance, testing, third-party ICT risk, continuity, recovery and management-body oversight.
Mistake 2: Running separate incident processes
If security, compliance and payment operations each maintain their own incident workflow, timelines and decisions will diverge. The better model is one workflow with separate reporting triggers.
Mistake 3: Mapping suppliers only by contract owner
Under DORA, supplier oversight must connect to critical or important functions. A vendor list by procurement owner is not enough.
Mistake 4: Waiting for PSD3/PSR final application dates before fixing operations
Some details may change before final publication and application.
The core operating capabilities already matter under existing law and DORA:
- fraud governance;
- incident handling;
- resilience testing;
- supplier oversight;
- board reporting.
Mistake 5: Treating open banking as only a PSD2 topic
Open-banking API availability, access control, monitoring and incident response are also ICT resilience topics. A prolonged API outage can become both a payment-services issue and a DORA evidence issue.
Mistake 6: Forgetting instant payments dependencies
Instant payment obligations increase pressure on availability, fraud detection, beneficiary verification, sanctions screening and supplier resilience. Even when the legal basis is not DORA, the operating dependencies often sit in the DORA evidence base.
Practical 30-day alignment plan
| Week | Action | Output |
|---|---|---|
| Week 1 | Create a combined obligation map | DORA / PSD2 / PSD3-PSR themes by operating capability |
| Week 1 | Confirm current payment services and licence perimeter | PI / EMI service map |
| Week 2 | Merge incident intake | One triage workflow with DORA and payment incident criteria |
| Week 2 | Map suppliers to payment services | Supplier-to-function dependency map |
| Week 3 | Test one payment service chain | Recovery, communication and supplier evidence |
| Week 3 | Review SCA, fraud and open-banking evidence | Control owner and evidence gap list |
| Week 4 | Update board reporting | ICT resilience, payment security, fraud, suppliers and remediation |
| Week 4 | Build evidence index | Owner, location, review cadence and regulatory view |
FAQ
Does DORA replace PSD2 for payment institutions and EMIs?
No. DORA governs digital operational resilience. PSD2 governs payment services, payment security, consumer rights and related authorisation / conduct obligations.
Does PSD3 replace DORA?
No. PSD3 and PSR modernise payment services and e-money law. DORA remains the main EU framework for ICT risk, resilience testing, ICT incident reporting and ICT third-party risk for financial entities.
Are PSD3 and PSR already final law?
As of 30 April 2026, political agreement had been announced and Council compromise texts had progressed.
Firms should still track final Official Journal publication and application dates before treating specific new obligations as live.
Should payment firms maintain separate DORA and PSD2 incident workflows?
No. Use one incident workflow with separate decision points: DORA major ICT incident classification and payment-services / fraud / customer-impact assessment.
Does open banking sit under DORA or PSD2?
Both can matter. PSD2 / PSR governs access, secure communication and open-banking rules. DORA matters when the API, platform, supplier or incident affects ICT resilience and critical payment services.
What is the best first step for an EMI?
Map payment services, critical functions, ICT systems and suppliers in one dependency view. That map supports DORA risk, PSD2 operations, PSD3/PSR preparation, incident handling and board reporting.
Bottom line
DORA vs PSD2/PSD3 is the wrong framing if it leads to separate teams and duplicate controls.
The practical framing is:
- PSD2 and PSD3/PSR define payment-services obligations;
- DORA defines the digital operational resilience model around the financial entity;
- payment institutions and EMIs need one evidence-led operating model that supports both.
Related reading
- DORA Incident Reporting 2026: Initial Notification, Intermediate Report and Final Report Timeline
- DORA National Competent Authorities — selected jurisdiction guides
- DORA and the Bank of Lithuania: Practical Guide for Fintechs
- DORA and Latvijas Banka: Practical Guide for Latvian Financial Entities
- DORA Reporting in Ireland: Central Bank of Ireland Guide for Financial Entities
- DORA Reporting in Cyprus: Competent Authorities Guide for Financial Entities
- DORA Register of Information: A Complete Guide for Financial Institutions
- DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026
- DORA vs MiCA: 2026 Compliance Guide for EU Fintechs and CASPs
- EBA Guidelines on ICT and Security Risk Management After DORA
Primary sources
- Regulation (EU) 2022/2554 — Digital Operational Resilience Act, EUR-Lex
- Directive (EU) 2015/2366 — PSD2, EUR-Lex
- European Banking Authority — Digital Operational Resilience Act (DORA)
- European Commission — Payment services
- European Parliament — Payment services deal: more protection from online fraud and hidden fees
- Council of the EU — PSD3 / PSR final compromise text note, 8220/26
- EUR-Lex — Proposal for PSD3, COM(2023) 366 final