DORA Register of Information: What Payment Institutions Need to Know

If you're a compliance officer at a Payment Institution (PI), DORA has likely created more questions than answers. You're already navigating PSD2 requirements, incident reporting, and third-party oversight—and now DORA adds another layer of obligations.

The good news: DORA doesn't replace everything you've built. The challenging news: it introduces new requirements that demand specific attention, particularly around the Register of Information (RoI).

This guide cuts through the complexity and explains exactly what Payment Institutions need to know about DORA compliance.

DORA and Payment Institutions: The Basics

The Digital Operational Resilience Act (DORA) entered into force on January 17, 2025. It applies to 20 different types of financial entities—and Payment Institutions are explicitly included in scope (Article 2(1)(d)).

This means your PI must comply with DORA's requirements for:

• ICT risk management — maintaining a robust framework
• Incident reporting — reporting major ICT-related incidents to your competent authority
• Digital operational resilience testing — testing your ICT systems
• Third-party risk management — overseeing your ICT service providers
• Register of Information — maintaining a detailed register of all ICT third-party arrangements

How DORA Interacts with PSD2

One of the biggest sources of confusion for Payment Institutions is understanding where DORA fits alongside existing PSD2 obligations. The short answer: DORA doesn't replace PSD2, but it does supersede certain requirements.

What Changed with DORA

The European Banking Authority (EBA) has taken steps to clarify the relationship:

Incident Reporting: The EBA has repealed its Guidelines on major incident reporting under PSD2 for entities covered by DORA. If you're a licensed Payment Institution, you now report major ICT-related incidents under DORA's framework—not PSD2's.

ICT Risk Management: The EBA has amended its ICT and security risk management Guidelines. For Payment Institutions covered by DORA, the Guidelines now focus specifically on relationship management with payment service users, while DORA handles the broader ICT risk framework.

What Remains Under PSD2

PSD2 requirements still apply for:

• Strong customer authentication (SCA)
• Secure communication standards
• Operational and security risk management for PSPs not covered by DORA (e.g., post-office giro institutions, credit unions)

The Register of Information: PI-Specific Considerations

The DORA Register of Information (RoI) requires financial entities to maintain a comprehensive register of all contractual arrangements with ICT third-party service providers. This isn't just about your cloud hosting—it covers every ICT service supporting your operations.

What Payment Institutions Must Report

For each ICT third-party arrangement, your register must include:

Entity Information (Template B_01)

• Your PI's Legal Entity Identifier (LEI)
• Entity type and regulatory status
• Group structure (if applicable)

Contractual Arrangements (Template B_02)

• Contract start and end dates
• Service descriptions
• SLA terms and termination provisions
• Contract values and governing law

ICT Service Providers (Template B_03)

• Provider LEI or EUID
• Provider country and type
• Criticality assessment
• Subcontractor chains

ICT Services (Template B_04)

• Service classifications
• Data processing and storage locations
• Functions supported
• Substitutability assessment

Functions (Template B_05)

• Mapping of functions to services
• Critical/important function flags

Common ICT Services for Payment Institutions

Payment Institutions typically have more ICT dependencies than they initially realize. When building your register, don't forget:

• Core banking/payment processing platforms — The systems that execute transactions
• Card scheme connections — Visa, Mastercard, SEPA connectivity
• Fraud detection and AML screening — Often provided by third parties
• Cloud infrastructure — AWS, Azure, Google Cloud, or dedicated hosting
• Communication services — SMS gateways, email providers for OTP delivery
• Identity verification — KYC providers, document verification services
• Data analytics — Reporting and monitoring platforms
• Security services — DDoS protection, WAF, SIEM providers

Each of these may need to be documented in your register with full contract details, criticality assessments, and data location information.

The EPIF Perspective: Industry Concerns

The European Payment Institutions Federation (EPIF) has been actively engaging with regulators on DORA implementation. Their key concerns are worth understanding:

Definition of ICT Services

EPIF has raised concerns about confusion in how some Member States interpret what constitutes an "ICT service" under DORA—particularly in modern payment chains where regulated financial services and technology services can overlap.

For Payment Institutions, this matters because:

• Some services provided by other regulated entities (banks, card schemes) might be incorrectly classified as ICT services
• The distinction affects what goes in your register and how you assess third-party risk

EPIF has called on the European Supervisory Authorities (ESAs) to provide clarity and promote supervisory convergence across EU Member States.

Proportionality

Payment Institutions—especially smaller ones—face the same DORA requirements as large banks but with fewer resources. EPIF has advocated for proportionate application, recognizing that a 20-person PI shouldn't need the same compliance infrastructure as a global bank.

The good news: DORA does include proportionality principles. Your implementation should be scaled to your size, complexity, and risk profile.

Why 93.5% Failed (And PI-Specific Lessons)

The ESA dry run in 2024 revealed that 93.5% of financial entities had at least one data quality error in their Register of Information submissions. Payment Institutions weren't immune.

The Biggest Failure Points

Incomplete Subcontractor Chains: Your primary ICT provider likely uses subcontractors. DORA requires visibility into these chains, particularly for critical services. Many PIs discovered their providers couldn't or wouldn't provide this information.

Building Your PI Register: Practical Steps

Step 1: Inventory Your ICT Landscape

Start with a complete inventory before touching any templates:

1. List every system that supports your payment services
2. Identify the provider for each system
3. Flag which support critical functions (payment processing, fraud detection, regulatory reporting)
4. Gather existing contract documentation

Step 2: Assess Criticality

For each ICT service, determine:

• Does it support a critical or important function?
• What's the impact if it fails?
• How quickly would you need a replacement?

This assessment drives your substitutability ratings and determines reporting priority.

Step 3: Collect Provider Data

You'll need from each ICT provider:

• Legal entity identifier (LEI or EUID)
• Registered name and country
• Data processing locations
• Subcontractor information (for critical services)
• Exit provisions in contracts

Step 4: Validate Before Submission

Use the ESA's 116 validation rules as your checklist:

• All mandatory fields populated
• LEIs valid and current
• Cross-references between templates consistent
• Date formats correct (ISO 8601)
• Country codes valid (ISO 3166-1)

Proportionality: What It Means for Small PIs

DORA's proportionality principle means your compliance approach should reflect your:

• Size and scale of operations
• Nature and complexity of services
• Risk profile
• Resources available

For a small Payment Institution, this might mean:

• Simpler ICT risk management documentation
• Less frequent testing cycles
• Streamlined governance structures

Timeline and Next Steps

DORA has been applicable since January 17, 2025. If you haven't started your Register of Information, you're already behind—but not too late.

Immediate Actions

1. Confirm your entity scope — Verify your PI is indeed subject to DORA (most licensed PIs are)
2. Assign ownership — Someone needs to own the register process
3. Begin inventory — Start documenting your ICT landscape now
4. Contact providers — Request LEIs, data locations, and contract terms

Ongoing Requirements

The register isn't a one-time submission. You must:

• Keep it current as arrangements change
• Submit updates to your competent authority as required
• Maintain audit trails of changes

Conclusion: DORA Compliance Is Achievable

Payment Institutions face unique challenges with DORA—the PSD2 overlap, the breadth of ICT services in payment chains, and resource constraints. But compliance is achievable with the right approach.

Focus on:

• Understanding what goes in your register (and what doesn't)
• Starting with your ICT inventory before templates
• Validating data quality before submission
• Using tools that handle the 116 validation rules for you

The 93.5% failure rate in the dry run shows what happens without proper preparation. You can be in the 6.5% that passes on the first attempt.