EU Payment Regulations: A Developer-Friendly Overview

Why Developers Need to Understand Payment Regulations

Payment regulations are not just legal documents for compliance officers. They define what your software must do, how data must flow, and which authentication steps are mandatory. Building a payment system without understanding the regulatory landscape is like building a house without checking the building codes.

This overview covers the EU regulations that directly impact how payment software is designed and built.

The Regulatory Stack

European payment regulation is layered. Each layer addresses different concerns:

PSD2 / PSD3 (Payment Services Directive)

What it covers: Rules for payment service providers, including licensing, consumer protection, SCA requirements, and open banking obligations.

Developer impact:

• SCA implementation in checkout flows
• Support for 3D Secure 2
• Open banking API integration (if you are an AISP or PISP)
• Handling SCA exemptions correctly
• Webhook-based payment confirmation flows

PSD3 (expected to apply around 2026-2028) introduces IBAN-name verification and strengthens open banking requirements.

EMD2 (Electronic Money Directive)

What it covers: Rules for issuing electronic money (e-wallets, prepaid cards, digital currencies backed by fiat).

Developer impact:

• If your platform holds customer funds, you may be creating electronic money
• Safeguarding requirements: customer funds must be segregated from company funds
• Redemption rights: customers must be able to withdraw their funds at any time
• KYC requirements for e-money accounts

SEPA Regulation

What it covers: Technical standards and rules for euro payments across Europe. Covers credit transfers (SCT), direct debits (SDD), and instant credit transfers (SCT Inst).

Developer impact:

• IBAN format validation and routing
• SEPA XML message formats (pain.001, pain.008, camt.053)
• Direct debit mandate management
• Settlement timing expectations (D+1 for SCT, seconds for SCT Inst)

AML Directives (AMLD5, AMLD6)

What it covers: Anti-Money Laundering rules requiring identification of customers, monitoring of transactions, and reporting of suspicious activity.

Developer impact:

• KYC (Know Your Customer) flows at onboarding
• Customer due diligence data storage
• Transaction monitoring and alert systems
• Sanctions screening against EU/UN watchlists
• Suspicious Activity Report (SAR) filing workflows

GDPR (General Data Protection Regulation)

What it covers: Protection of personal data, including payment and financial data.

Developer impact:

• Lawful basis for processing payment data (contractual necessity, legal obligation)
• Data minimization in payment flows
• Right to erasure versus legal retention obligations (AML overrides GDPR for transaction records)
• Cross-border data transfer rules affecting where payment data can be processed

DORA (Digital Operational Resilience Act)

What it covers: ICT risk management requirements for financial entities, including payment service providers.

Developer impact:

• Incident reporting for major ICT disruptions
• Third-party risk management for cloud providers and SaaS dependencies
• Resilience testing requirements
• Business continuity planning for payment systems

Applies from January 2025 to all regulated financial entities in the EU.

Interchange Fee Regulation (IFR)

What it covers: Caps on interchange fees for consumer debit (0.2%) and credit (0.3%) card transactions within the EEA.

Developer impact:

• Affects pricing models if you process card payments
• Surcharging prohibition for consumer cards (cannot pass interchange costs to customers)
• Merchant fee transparency requirements

How These Regulations Interact

The real complexity comes from overlapping requirements:

Example: Online card payment by an EU consumer

1. PSD2 requires SCA (you implement 3D Secure 2)
2. IFR caps the interchange fee your acquirer charges
3. PSD2 prohibits surcharging the consumer
4. GDPR requires you to process only necessary personal data
5. AML may require enhanced due diligence for high-value transactions
6. DORA requires you to have incident response plans for payment system failures

Your checkout flow, backend processing, and data storage must satisfy all of these simultaneously.

Practical Compliance Strategy

Layer Your Compliance

Do not try to address all regulations in one monolithic effort. Build compliance in layers:

1. Foundation: GDPR compliance for all data handling
2. Payment core: PSD2/SCA compliance in your payment flows
3. Financial operations: AML/KYC for customer onboarding
4. Resilience: DORA for operational risk management
5. Specifics: SEPA, IFR, and EMD2 as applicable to your business model

Delegate Where Possible

You do not need to implement everything yourself:

• SCA: Delegate to your PSP through 3D Secure 2
• AML screening: Use specialized providers (ComplyAdvantage, Onfido, etc.)
• SEPA processing: Use your bank's or PSP's SEPA infrastructure
• VAT compliance: Use services like Vatly for tax calculation and validation

Build Audit Trails

Every regulation requires some form of record-keeping. Build comprehensive audit logging from day one:

• All payment transactions with timestamps, amounts, and participants
• Authentication events (SCA challenges, outcomes)
• Data access logs
• Configuration changes to payment rules
• Customer consent records

Stay Current

Payment regulation evolves. Subscribe to updates from:

• European Banking Authority (EBA) for PSD2/PSD3 technical standards
• European Commission for legislative proposals
• Your national financial authority for local implementation details
• Your PSP for integration requirement changes

European payment regulation is complex but logical. Each regulation addresses a specific concern: security, transparency, resilience, or consumer protection. Understand the purpose behind each requirement, and implementation decisions become clearer. Build in layers, delegate where you can, and invest in audit trails.