Scope
This guide outlines the operational and technical compliance requirements introduced by the Third Payment Services Directive (PSD3) and the Payment Services Regulation (PSR). It's designed for compliance officers, fraud analysts, and engineering leads at banks, fintechs, and third-party payment service providers operating in or with the EU market.
You'll find requirement breakdowns, implementation timelines, and a quick reference table. This guide assumes you're already familiar with PSD2's Strong Customer Authentication (SCA) requirements and open banking fundamentals.
Key Concepts and Definitions
PSD3 vs. PSR: PSD3 establishes licensing and supervisory arrangements. The PSR sets directly applicable conduct and operational requirements across all EU member states. You'll need to comply with both, but they govern different operational layers.
Third-Party Provider (TPP): Any fintech or service provider accessing customer account data or initiating payments through bank APIs. Under the new framework, TPP authorization requirements become stricter.
Payment Initiation Service Provider (PISP): A TPP that initiates payments on behalf of customers. You'll face enhanced transaction monitoring obligations if you operate as a PISP.
Account Information Service Provider (AISP): A TPP that aggregates account data. Your API security requirements increase under PSR.
Instant Payment: A payment executed and settled in real-time. The PSR introduces mandatory real-time fraud checks for these transactions.
Requirements Breakdown
API Security and Authorization
The PSR tightens the rules around API access between banks and TPPs. Here's what changes:
Mutual Authorization Verification: Before any API connection, both the bank and TPP must verify that the counterparty holds appropriate licensing. You can't rely on passive certificate checks anymore.
API Security Standards: Your APIs must implement security controls that go beyond basic authentication. This means rate limiting, anomaly detection at the API layer, and session management that can detect and terminate suspicious access patterns.
Monitoring Obligations: Banks must monitor TPP API usage for abnormal patterns. TPPs must log all API interactions with sufficient detail to support fraud investigations.
Transaction Monitoring and Fraud Controls
The PSR introduces real-time monitoring requirements that affect your fraud detection architecture:
Real-Time Checks for Instant Payments: You must screen instant payments against fraud indicators before authorization. Batch processing won't meet the standard. Your detection rules need to execute within the payment flow, not after settlement.
Payee Name Verification: Before initiating a transfer, you must verify that the recipient's name matches the account identifier. This is a technical requirement, not just a user interface feature. Your payment initiation system needs to query the receiving institution's directory and halt the transaction if there's a mismatch.
Enhanced Customer Authentication Triggers: The PSR clarifies when you must apply step-up authentication. You'll need to reassess your risk-based authentication logic to ensure it aligns with the new thresholds.
Timeline and Compliance Window
The regulations go into effect 20 days after formal approval by the EU Council and Parliament. From that date, you have 27 months to achieve full compliance.
That's not as generous as it sounds. If you're building real-time fraud detection infrastructure from scratch, 27 months is tight. Start scoping now.
Implementation Guidance
Phase 1: Gap Analysis (Months 1-3)
Map your current controls against the new requirements. Focus on these areas first:
- API authentication and authorization flows
- Transaction monitoring latency (can you screen instant payments in real-time?)
- Payee verification capabilities
- TPP onboarding and licensing verification processes
Document every gap with a remediation estimate. Be specific about technical debt that'll slow you down.
Phase 2: Architecture Planning (Months 4-9)
Real-Time Monitoring: If you're running batch fraud detection, you'll need to rebuild. Consider a streaming architecture with in-memory rule engines. Your detection logic must execute within milliseconds, not minutes.
Payee Verification Integration: You'll need to integrate with account verification services or build bilateral connections with receiving institutions. This isn't a lift-and-shift project; it requires new API contracts and data exchange agreements.
API Security Hardening: Implement rate limiting per TPP, anomaly detection at the API gateway, and session monitoring that can detect credential stuffing or token replay attacks.
Phase 3: Build and Test (Months 10-21)
Prioritize instant payment fraud controls first. These have the tightest performance requirements and the highest operational risk if you get them wrong.
Test your payee verification logic against edge cases: name variations, special characters, corporate vs. individual accounts. A false positive rate above 2% will generate support volume you can't handle.
Phase 4: Parallel Run and Cutover (Months 22-27)
Run new controls in shadow mode before you enforce them. Compare detection rates, measure latency, and tune thresholds.
Don't wait until month 26 to discover your real-time fraud engine can't handle peak transaction volume.
Common Pitfalls
Underestimating Payee Verification Complexity: Name matching isn't a simple string comparison. You'll encounter Unicode issues, cultural naming conventions, and corporate entity name variations. Budget time for fuzzy matching logic and exception handling.
Treating API Security as a Perimeter Problem: TPP authorization isn't just about validating certificates at connection time. You need continuous monitoring of TPP behavior after they're authenticated. A compromised TPP credential is an insider threat.
Ignoring Cross-Border Implications: If you operate across multiple EU jurisdictions, you'll need to handle different implementation timelines and local supervisory interpretations. The PSR is directly applicable, but supervisory enforcement will vary.
Assuming Your Current SCA Logic Meets PSR Standards: The PSR clarifies when step-up authentication is mandatory. Review your risk-based authentication exemptions against the new requirements. What worked under PSD2 might not pass PSR scrutiny.
Quick Reference Table
| Requirement | Applies To | Technical Control | Compliance Deadline |
|---|---|---|---|
| Real-time fraud checks for instant payments | PISPs, banks processing instant payments | Streaming fraud detection with sub-second latency | 27 months after entry into force |
| Payee name verification | PISPs initiating transfers | API integration with account verification service | 27 months after entry into force |
| API security standards | Banks, TPPs using APIs | Rate limiting, anomaly detection, session monitoring | 27 months after entry into force |
| Mutual authorization verification | Banks, TPPs | Licensing database checks before API access | 27 months after entry into force |
| Enhanced customer authentication triggers | All payment service providers | Risk-based authentication logic aligned with PSR thresholds | 27 months after entry into force |
Entry into force: 20 days after formal approval by EU Council and Parliament.
You've got 27 months from entry into force, not from today. Track the approval timeline and adjust your project schedule accordingly.
