DORA applies to payment institutions and electronic money institutions. If your firm holds a payment institution (PI) licence under PSD2 or an e-money institution (EMI) licence under EMD2, you are in scope for EU Regulation 2022/2554. That applies whether you are a large payments processor or a small fintech operating in a single member state.
Most of the public commentary on DORA focuses on banks, insurers, and the handful of critical cloud providers subject to direct ESA oversight. Payment institutions and EMIs tend to get far less attention, which means compliance teams at these firms often have less to work from when trying to understand their specific obligations. This guide addresses that gap.
Are Payment Institutions and EMIs Actually in Scope?
Yes. DORA Article 2(1) lists the financial entities to which the regulation applies. The list explicitly includes payment institutions as defined in Article 4(4) of Directive 2015/2366/EU (PSD2), and electronic money institutions as defined in Article 2(1) of Directive 2009/110/EC (EMD2).
There is no size exemption for payment institutions or EMIs the way there is for microenterprises in some other DORA categories. However, there is a proportionality principle under Article 4 that allows national competent authorities to tailor the intensity of application to your size and risk profile. More on that below.
Your national competent authority is the supervisor responsible for DORA enforcement. For payment institutions and EMIs this is typically the same authority that issued your licence — the central bank, financial regulator, or payments supervisor in the member state where you are authorised.
Which DORA Obligations Apply to Payment Institutions and EMIs
All five pillars of DORA apply, but the intensity and specific RTS requirements will vary based on your classification and the proportionality assessment your NCA applies.
Pillar 1: ICT Governance
Article 5 requires the management body to take formal responsibility for ICT risk management. For a payments firm, this means the board or equivalent governing body must approve your ICT risk strategy, not just receive a summary of it. That is a meaningful shift if ICT risk has historically been handled below board level.
You need a documented ICT risk framework, a named function or person responsible for ICT risk, and evidence of management body engagement — board minutes being the most straightforward form of evidence.
Pillar 2: ICT Risk Management
Payment institutions and EMIs typically run a relatively focused ICT stack centred on payment processing, customer-facing interfaces, and connections to payment schemes (Visa, Mastercard, SEPA, local instant payment rails). DORA requires you to map all of that as a starting point.
Article 8 requires a comprehensive register of ICT assets and the business processes they support. For a payments firm, this means mapping your payment processing pipeline, API infrastructure, core banking or ledger system (if operated internally or by a third party), fraud detection systems, and customer-facing applications — and identifying which of these support functions that would be Critical or Important Functions (CIFs) under DORA's definition.
Payment processing is almost always a CIF for a payments firm, because its failure would materially disrupt the services you are authorised to provide. That means all DORA requirements around business continuity planning, RTOs, RPOs, and backup systems will apply to it at the higher intensity reserved for CIF-supporting systems.
Pillar 3: ICT Incident Management and Reporting
This is the area where payment institutions and EMIs need to pay particular attention. Article 19 requires a three-stage notification to your NCA for major ICT incidents:
- Initial notification: within 4 hours of classifying the incident as major (and no later than 24 hours after first awareness)
- Interim report: within 72 hours of the initial notification
- Final report: within one month of the interim report
For a payments firm operating real-time payment services, an outage that prevents customers from making payments is precisely the kind of incident that will trigger the major incident classification thresholds. The criteria under Article 18 include impact on the number of clients affected, financial losses, and the duration of the disruption. A payment processing outage of several hours at a mid-sized EMI could easily cross multiple thresholds simultaneously.
The critical operational challenge is that you need to have your classification process, reporting templates, and escalation procedures in place before an incident occurs. You cannot build the process during a live incident when the 4-hour clock is already running.
Pillar 4: Digital Resilience Testing
DORA requires all financial entities to conduct digital resilience testing. For most payment institutions and EMIs, this means:
- Annual vulnerability assessments across all ICT systems supporting CIFs
- Penetration testing on critical systems at least annually
- Testing results fed back into the ICT risk framework with tracked remediation
Threat-led penetration testing (TLPT) under Article 24 applies to significant financial entities. Payment institutions and EMIs are not automatically classified as significant — that classification depends on your size, systemic importance, and the determination of your NCA. Most payment institutions and EMIs below the threshold for significant institution status will not be required to conduct TLPT, but you should confirm this with your NCA rather than assume.
Pillar 5: Third-Party ICT Risk Management
This pillar is particularly relevant for payment institutions and EMIs because the business model of most payments firms depends heavily on third-party ICT services. Core banking platforms, payment scheme connections, fraud screening services, KYC/AML providers, cloud infrastructure, and API gateway services are all commonly outsourced.
DORA requires you to:
- Maintain a Register of Information (RoI) listing all ICT third-party arrangements in the format specified by EBA ITS 2024/2956. The first submission deadline was 30 April 2025.
- Ensure contractual arrangements include the minimum clauses required by Article 30 — including audit rights, service level commitments, data location provisions, and termination rights.
- Maintain exit plans for providers supporting CIFs (Article 28(8)).
- Assess and document concentration risk across your provider portfolio (Article 29).
For a typical payments firm outsourcing its core ledger to a SaaS provider and running on a major cloud platform, both of those providers are likely to be in your Register of Information and require Article 30-compliant contracts.
How Proportionality Works for Payment Institutions and EMIs
Article 4 of DORA directs financial entities and their NCAs to apply the regulation in a manner proportionate to size, overall risk profile, and the nature and complexity of the services provided. This does not mean smaller payment institutions and EMIs are exempt from DORA — it means the RTS requirements that layer additional detail on top of the base regulation may be applied with reduced intensity.
In practice, proportionality is most visible in the ICT risk management framework requirements. The EBA's RTS under Article 15 distinguishes between the simplified ICT risk management framework available to smaller and less complex entities, and the fuller framework required for larger institutions. If your NCA determines you qualify for the simplified framework, some of the more prescriptive requirements around documentation, testing frequency, and reporting will apply with reduced intensity.
What proportionality does not reduce is the core incident reporting obligation. The 4-hour initial notification timeline applies regardless of size. The Register of Information submission obligation applied to all in-scope entities from 30 April 2025 regardless of proportionality classification. Governance requirements — management body responsibility, ICT risk strategy, training — apply across the board.
Practical Priorities for Payment Institution and EMI Compliance Teams
If you are building or reviewing your DORA compliance programme, prioritise in this order:
1. Incident classification and reporting. Your NCA will notice a missed or late notification. Build and test your incident classification policy, make sure thresholds are documented against the Article 18 criteria, assign clear escalation responsibility, and prepare your three-stage report templates before you need them. 2. Register of Information. If you have not yet submitted your RoI or submitted an incomplete version, this is your most visible compliance gap. The EBA ITS 2024/2956 format is specific about what fields are required. A platform that generates the RoI in the required format significantly reduces the operational burden. 3. CIF identification. Everything in DORA's risk and continuity framework flows from knowing what your Critical or Important Functions are. Identify them, get management body approval of the list, and map your ICT assets to them. This is the foundation for your risk assessments, your BCP, and your testing programme. 4. Third-party contract review. Review your key ICT provider contracts against the Article 30 checklist. Most contracts predating DORA will be missing at least some of the required clauses. Prioritise contracts with providers supporting CIFs. 5. Governance documentation. Ensure your board minutes reflect ICT risk discussions. Approve your ICT risk strategy at board level. Document your ICT risk appetite. These are the documents an NCA will ask for in a supervisory engagement.For a deeper look at the full compliance picture, the DORA compliance checklist covers all five pillars with specific items to verify. The free DORA gap analysis will score your readiness across all pillars in about three minutes and identify your weakest areas.