DORA for Payment Institutions: The Proportionality Challenge
The Scope Question Is Settled — The Proportionality Question Is Not
When DORA became applicable on January 17, 2025, it brought approximately 22,000 financial entities into scope across 20 categories. Among them, payment institutions occupy a unique and often uncomfortable position. Article 2(1)(d) explicitly includes "payment institutions, including payment institutions exempted pursuant to Directive (EU) 2015/2366" — placing licensed payment service providers, electronic money institutions, and account information service providers squarely within DORA's regulatory perimeter.
The scope question is settled. Every licensed payment institution in the European Union is subject to DORA.
The proportionality question — how much of DORA applies to a 50-person fintech versus a systemically important payment processor — is where the operational challenge lies. Article 4 establishes proportionality as a governing principle: financial entities shall implement DORA requirements "taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations." But proportionality is a principle, not a formula. It provides latitude for interpretation — and that latitude creates uncertainty.
For payment institutions, uncertainty translates directly into cost. Deloitte's 2024 survey estimated DORA compliance costs at EUR 2-5 million for mid-size payment institutions — a figure that can represent 5-15% of annual revenue for smaller PSPs. Getting proportionality wrong in either direction is expensive: over-compliance wastes resources that could fund product development; under-compliance risks supervisory findings and, ultimately, license jeopardy.
The Proportionality Framework: What Article 4 Actually Says
Article 4 does not create exemptions. It modulates intensity. The four proportionality factors are:
| Factor | What It Measures | PSP-Specific Considerations |
|---|---|---|
| Size | Headcount, revenue, balance sheet, transaction volume | A 30-person AISP processing no customer funds differs fundamentally from a 500-person PSP processing EUR 50B annually |
| Nature | Type of services, business model, customer base | Card acquiring vs. account-to-account payments vs. AISP vs. PISP — each creates different risk profiles |
| Scale | Geographic reach, number of customers, transaction volumes | A single-market PSP serving 100,000 customers vs. a pan-European processor serving 50 million |
| Complexity | Technology stack, third-party dependencies, integration depth | Cloud-native API-first PSP vs. legacy processor with mainframe core and 200+ vendor integrations |
Proportionality applies across all five pillars but manifests differently in each. A small AISP may reasonably apply simplified ICT risk management (Pillar I) but cannot proportionally reduce its incident reporting obligations (Pillar II) — because the reporting timelines are fixed by regulation, not scaled by entity size.
The Simplified ICT Risk Management Framework: Article 16
Article 16 provides the most explicit proportionality mechanism in DORA: the simplified ICT risk management framework. This simplified framework applies to entities identified by their national competent authorities as qualifying based on their size and risk profile.
The critical distinction: Article 16 does not apply automatically. NCAs must identify which entities qualify. Until your NCA has published guidance on which payment institutions fall under the simplified framework — and your institution has been assessed against those criteria — you should assume the full framework applies.
Full vs. Simplified Framework: What Changes
| Requirement Area | Full Framework (Art. 5-15) | Simplified Framework (Art. 16) |
|---|---|---|
| ICT risk management framework | Comprehensive, documented, audited annually | Proportionate to size; simplified documentation |
| Management body responsibility | Active oversight, regular reporting, competence requirements | Oversight required but reporting frequency may be reduced |
| ICT systems documentation | Complete inventory, dependency mapping, topology | Inventory required; dependency mapping may be simplified |
| Business continuity | Full BIA, BC plans, recovery plans, testing | BC plans required; testing scope proportionate |
| Recovery testing | At least annually with full scenario coverage | At least annually but scope proportionate to risk profile |
| Communication plans | Comprehensive stakeholder communication protocols | Communication plans required but may be simplified |
| Incident management | No simplification — Art. 17-23 apply in full | No simplification — reporting timelines unchanged |
| Resilience testing | Partially simplified — basic testing required, TLPT only for significant entities | Basic testing required; TLPT unlikely to apply |
| Third-party risk | Full Art. 28-30 provisions for critical arrangements | Proportionate due diligence; register still required |
The simplified framework reduces documentation burden and testing scope but does not eliminate core obligations. Incident reporting timelines (4 hours initial, 72 hours intermediate, 1 month final) are fixed regardless of entity size. Third-party risk management obligations apply proportionately but the Information Register under Article 28(3) is mandatory for all in-scope entities.
Decision Framework: Where Does Your Payment Institution Fall?
The following framework helps payment institutions assess their proportionality position. This is indicative — final determination rests with your NCA and legal advisors.
Tier 1: Full Framework (No Simplification)
Characteristics: Annual transaction volume > EUR 10 billion, pan-European operations, > 250 employees, critical infrastructure designation, TLPT-eligible.
Examples: Major card processors, large-scale acquiring networks, systemically important payment schemes.
DORA implications: Full Pillar I-V requirements. TLPT program under Art. 26 (if designated). Lead Overseer regime may apply to critical ICT providers they depend on.
Tier 2: Full Framework with Proportionate Application
Characteristics: Annual transaction volume EUR 1-10 billion, multi-market operations, 50-250 employees, significant but not critical infrastructure.
Examples: Mid-size PSPs, regional payment processors, established e-money institutions.
DORA implications: Full framework applies, but proportionality permits streamlined documentation, risk-based testing prioritization, and focused third-party due diligence on critical providers. TLPT unlikely.
Tier 3: Simplified Framework Candidates
Characteristics: Annual transaction volume < EUR 1 billion, single-market or limited-market operations, < 50 employees, limited complexity.
Examples: Small PSPs, niche payment services, AISPs, smaller PISPs, early-stage fintechs.
DORA implications: Likely candidates for Art. 16 simplified framework (subject to NCA designation). Core obligations remain: incident reporting, basic ICT risk management, third-party register, basic resilience testing.
The Five Hardest Requirements for Payment Institutions
Regardless of proportionality tier, certain DORA requirements are disproportionately challenging for payment institutions compared to banks or insurers.
1. The ICT Third-Party Register (Art. 28(3))
Payment institutions typically have deep, complex, and numerous third-party ICT dependencies. A mid-size PSP may depend on 50-100 ICT service providers spanning cloud infrastructure, card scheme connections, fraud detection, KYC/AML, core processing, and mobile SDKs. Building and maintaining the Information Register — with the detail required by the RTS — is an operational burden that scales with architectural complexity, not entity size.
2. Incident Reporting Timelines (Art. 17-23)
The 4-hour initial notification deadline is challenging for any organization, but especially for payment institutions operating lean teams. A 50-person fintech may have a 5-person engineering team and no dedicated security operations center. Detecting, classifying, and reporting a major ICT incident within 4 hours requires automated monitoring, predefined classification criteria, and pre-drafted notification templates — capabilities that require investment regardless of size.
3. Resilience Testing (Art. 24-27)
Payment institutions process transactions in real time. Testing resilience — particularly recovery from failure scenarios — without disrupting live payment flows requires isolated test environments that mirror production, synthetic transaction generators, and rollback capabilities. For institutions running on shared infrastructure or SaaS platforms, testing options may be limited by what the provider allows.
4. Exit Strategies for Cloud-Native Architecture (Art. 28(8))
Many payment fintechs are cloud-native from day one. Their entire technology stack — compute, storage, databases, queues, monitoring — runs on a single cloud platform. Art. 28(8) requires exit strategies for critical ICT arrangements, but for a cloud-native PSP, "exiting" the cloud provider means rewriting the application. The exit strategy must be honest about this reality while still demonstrating a credible path to continuity.
5. Management Body Competence (Art. 5(4))
DORA requires the management body to have "sufficient knowledge and skills to understand and assess ICT risk." For payment fintech boards — often composed of investors, commercial leaders, and founders — this may require training, advisory appointments, or board composition changes. The requirement is proportionate to the entity's risk profile, but even small PSPs must demonstrate board-level ICT risk competence.
The Cost of Compliance: Sizing the Investment
Compliance costs vary significantly by proportionality tier. The following estimates are based on industry surveys and advisory firm assessments for payment institutions in 2025.
| Investment Area | Tier 1 (> EUR 10B) | Tier 2 (EUR 1-10B) | Tier 3 (< EUR 1B) |
|---|---|---|---|
| ICT risk management framework | EUR 500K-1M | EUR 200K-500K | EUR 50K-150K |
| Incident management & reporting | EUR 300K-600K | EUR 150K-300K | EUR 50K-100K |
| Resilience testing program | EUR 400K-800K | EUR 150K-400K | EUR 50K-150K |
| Third-party risk management & register | EUR 300K-500K | EUR 150K-300K | EUR 50K-100K |
| Information sharing arrangement | EUR 50K-150K | EUR 30K-100K | EUR 15K-50K |
| Governance & board training | EUR 100K-200K | EUR 50K-100K | EUR 20K-50K |
| Total estimated (Year 1) | EUR 1.7M-3.3M | EUR 730K-1.7M | EUR 235K-600K |
| Ongoing annual | EUR 800K-1.5M | EUR 350K-800K | EUR 120K-300K |
For Tier 3 institutions, the EUR 235K-600K first-year cost is significant but manageable. For institutions at the lower end of Tier 3 — a 15-person AISP generating EUR 2 million in annual revenue — even the lower estimate represents more than 10% of revenue. This is where proportionality must be applied judiciously, focusing investment on the requirements that address genuine operational risk rather than gold-plating every obligation.
The Proportionality Argument: How to Make It
When engaging with your NCA or preparing for supervisory review, the proportionality argument must be structured, documented, and honest.
Document your risk profile. Quantify transaction volumes, customer counts, geographic reach, and technology complexity. Map your services to criticality levels. Demonstrate that you understand your risk exposure.
Map requirements to risks. For each DORA requirement, explain how you are applying it proportionately — and why. "We conduct quarterly resilience tests rather than monthly because our transaction volume and technology stack complexity do not warrant higher frequency" is a proportionate argument. "We don't test because we're small" is not.
Show your investment. Proportionality does not mean minimal effort. Demonstrate that you have invested proportionately — appropriate tooling, trained staff, documented processes, tested capabilities. The NCA is looking for evidence of genuine risk management, not checkbox completion.
Identify what cannot be proportioned. Be explicit about which requirements you apply in full regardless of size — incident reporting timelines, management body responsibility, basic ICT security hygiene — and why.
The Strategic Opportunity
DORA compliance is not purely a cost center for payment institutions. Institutions that build genuine operational resilience — rather than paper compliance — gain competitive advantages in a market where trust is the primary currency.
Payment institution clients — merchants, platforms, banks — increasingly evaluate operational resilience when selecting providers. A PSP that can demonstrate tested recovery capabilities, documented third-party risk management, and proven incident response processes is a more trustworthy counterparty than one that cannot.
For payment fintechs seeking bank partnerships, institutional clients, or cross-border expansion, DORA compliance demonstrates the operational maturity that larger counterparties require. The proportionality principle allows payment institutions to right-size their compliance investment — but the underlying capabilities are business-grade, not regulatory theater.
The payment institutions that will thrive under DORA are those that view proportionality as a tool for efficient compliance, not a loophole for minimal effort.
This guide reflects DORA Regulation (EU) 2022/2554 and associated RTS/ITS as applicable. Proportionality assessments are indicative; final determination rests with national competent authorities.