PSD2: EU Payment Services Directive Guide

The Second Payment Services Directive (PSD2) transformed the European payments landscape by introducing open banking requirements and strong customer authentication (SCA). By requiring banks to share account data with authorized third parties and mandating two-factor authentication for electronic payments, PSD2 opened the door to a new generation of financial services while raising security standards across the payments ecosystem. PSD3, proposed by the European Commission in June 2023, will further evolve these requirements — organizations should factor upcoming changes into their compliance planning.

What PSD2 Is and Who Issues It

PSD2 (Directive 2015/2366/EU) was adopted by the European Parliament and Council in November 2015 and became applicable from January 13, 2018. It replaced the original Payment Services Directive (PSD1) with significantly expanded requirements, introducing the open banking framework, new payment service provider categories, and strong customer authentication obligations.

PSD2 is implemented by EU member states through national legislation, with each member state's national competent authority (NCA) — typically the central bank or financial regulator — responsible for authorizing and supervising payment service providers. The European Banking Authority (EBA) publishes regulatory technical standards (RTS) and guidelines that harmonize implementation across the EU, including the critical RTS on Strong Customer Authentication and Common and Secure Open Standards of Communication (RTS on SCA and CSC).

The European Commission's June 2023 proposal for a third Payment Services Directive (PSD3) and a companion Payment Services Regulation (PSR) aims to address remaining fragmentation, strengthen fraud protections, and extend open banking to open finance. PSD3 is expected to apply from 2026–2027 and organizations should track the legislative progress.

Post-Brexit, the UK retained PSD2 through the Payment Services Regulations 2017 (PSRs). The UK FCA and Payment Systems Regulator are developing a UK-specific open banking and open finance framework through the National Payments Vision, diverging incrementally from the EU approach.

Who Must Comply

PSD2 applies to all payment service providers operating in the EU/EEA:

Banks and credit institutions providing payment services to their customers must implement SCA for electronic payments, build PSD2-compliant open banking APIs, and maintain appropriate security programs.

Payment institutions — including payment processors, e-money institutions, and payment gateways — must be licensed under PSD2 and comply with its conduct, security, and capital requirements.

Account Information Service Providers (AISPs) are a new PSD2 category. AISPs access customer bank account data (with customer consent) to provide services such as account aggregation, personal financial management, and credit assessment. AISPs must be registered or licensed with a national competent authority.

Payment Initiation Service Providers (PISPs) initiate payment transactions directly from customers' bank accounts. PISPs must be licensed and must access banks' APIs using the PSD2 framework, without storing customer credentials.

E-commerce merchants are not directly licensed under PSD2 but are significantly affected by SCA requirements on customer-initiated card payments and alternative payment methods. Merchants must integrate with SCA-compliant payment flows or face payment declines.

Third-country firms serving EU customers with payment services may need EU authorization or may face restrictions if no equivalence framework applies.

Key Requirements Explained in Depth

Strong Customer Authentication (SCA)

SCA is PSD2's most impactful operational requirement for the payments industry. It requires that electronic payment transactions use at least two of three authentication factors:

• Knowledge: Something the user knows (password, PIN)
• Possession: Something the user has (phone, hardware token, card)
• Inherence: Something the user is (fingerprint, face recognition)

The factors must be independent, meaning that a compromise of one factor does not compromise the others. For online card payments, SCA is typically implemented through 3D Secure 2 (3DS2) protocols, which also carry dynamic linking requirements — the authentication must be linked to the specific amount and payee of the transaction.

SCA exemptions allow frictionless payment experiences where risk is lower:

• Low-value transactions under EUR 30 (with cumulative limits)
• Trusted beneficiaries (merchants whitelisted by the customer)
• Recurring transactions of the same amount to the same payee
• Corporate payments using dedicated payment processes
• Merchant-initiated transactions (including subscriptions)
• Low-risk transactions passing transaction risk analysis (TRA) with fraud rates below defined thresholds

Effective SCA implementation balances security with conversion rate optimization. Friction in the payment flow directly reduces checkout completion rates, making SCA exemption strategies a significant commercial consideration for merchants and payment providers.

Open Banking APIs

Banks (account servicing payment service providers, or ASPSPs) must provide dedicated interfaces (typically APIs) through which licensed AISPs and PISPs can access customer account data and initiate payments. These APIs must meet the performance, availability, and security standards defined in the EBA RTS on SCA and CSC.

The API must be able to handle the same volume of requests as the bank's own customer-facing channels, must provide fallback access mechanisms if the dedicated interface fails, and must support a standardized authentication flow that does not require AISPs/PISPs to access customer credentials. The UK Open Banking Standard (OBIE) and the Berlin Group NextGenPSD2 framework are the most widely implemented API standards across their respective markets.

Banks must provide open banking APIs free of charge to licensed TPPs, though they may charge for additional services not required by PSD2.

Operational and Security Risk Management

PSD2 Article 95 requires payment service providers to maintain operational and security risk management frameworks. Key requirements include:

• Annual submission of an assessment of operational and security risks and adequacy of mitigation measures to competent authorities
• Regular testing of security measures
• Incident reporting to competent authorities for major operational or security incidents (within 4 hours of incident classification)
• Customer communication for major incidents that affect customers' financial interests

The EBA Guidelines on major incident reporting and the ICT and Security Risk Management Guidelines provide detailed implementation expectations, including reporting templates and classification criteria.

Customer Protection and Liability

PSD2 establishes clear liability rules for unauthorized payment transactions. Where a payer has not committed fraud or gross negligence, the payer's payment service provider must refund unauthorized payments immediately, and in any case by the end of the following business day. Strong Customer Authentication implementation is central to liability allocation — PSPs that fail to implement required SCA cannot shift liability to the payer.

IBAN Verification and Authorization Confirmation

PSD2 improvements (through national implementations and EBA guidance) require PSPs to offer or support IBAN verification services to help payers confirm that the intended recipient matches the IBAN before authorizing a payment — an anti-fraud measure targeting authorized push payment (APP) fraud.

Licensing and Authorization Process

New PISPs and AISPs must obtain authorization from a national competent authority. The licensing process typically involves:

• Application submission including business plan, governance structure, security policy, and anti-money laundering program
• Regulatory review (typically 3–6 months for a complete application)
• Capital requirements: EUR 50,000 for PISPs, no minimum for AISPs (though appropriate resources must be maintained)
• Professional indemnity insurance or comparable guarantee
• Regular ongoing reporting to the NCA

Once authorized in one EU member state, a PISP or AISP can passport its authorization to other EU/EEA member states by notifying its home regulator, significantly simplifying pan-European expansion.

Costs and Timeline

Comparison with Related Frameworks

• PCI DSS: About 30% overlap, primarily in payment security controls. PCI DSS provides detailed payment card security requirements that complement PSD2's SCA and fraud management obligations. See /learn/pci-dss for details.
• GDPR: Approximately 35% overlap. PSD2's account data access by AISPs involves processing of financial personal data and requires GDPR-compliant consent and data handling. The interaction between PSD2 consent and GDPR consent has been an area of regulatory guidance. See /learn/hipaa for data protection parallels in healthcare.
• MiFID II: For investment firms offering payment services, PSD2 and MiFID II licensing obligations may overlap. See the MiFID II guide.

How Automation Helps

PSD2 compliance encompasses licensing, API management, SCA configuration, incident reporting, and ongoing risk management documentation. Compliance automation supports:

• Policy and procedure management aligned to PSD2 operational and security risk requirements
• Incident tracking with EBA notification timeline management (4-hour initial notification)
• Annual risk assessment documentation for competent authority submissions
• Third-party API vendor management for banks managing TPP ecosystem relationships

LowerPlane provides AI-powered compliance automation covering PSD2 alongside PCI DSS, GDPR, and 50-plus additional frameworks. At $4,000 per year entry pricing with a free tier, and rated 9.4/10 on AuditXYZ, LowerPlane helps fintech companies and payment service providers maintain compliance-ready documentation across their full regulatory stack. For fintech-specific guidance, see /for/fintech. Compare platforms at /compare/best-compliance-automation-platforms.

Frequently Asked Questions

What is open banking and how does PSD2 mandate it?

Open banking is the practice of giving authorized third parties secure access to customer bank account data and payment initiation capabilities, with the customer's consent. PSD2 mandates open banking by requiring all banks (account servicing payment service providers) to build and maintain dedicated APIs through which licensed AISPs and PISPs can access account data and initiate payments. Before PSD2, banks were not required to share data with third parties and most did not. PSD2 forced incumbents to open their infrastructure, enabling a generation of account aggregation apps, personal finance management tools, and direct payment solutions.

What is the difference between an AISP and a PISP?

An AISP (Account Information Service Provider) is licensed to access read-only account information — transaction history, account balances, and account details — across one or more of a customer's bank accounts. AISPs use this data to provide services like account aggregation, financial planning tools, and credit assessment. A PISP (Payment Initiation Service Provider) is licensed to initiate payment transactions from a customer's bank account directly, without the customer needing to use the bank's own interface. PISPs enable direct bank payment options at checkout, bypassing card networks. The two licenses can be held simultaneously by a single entity.

Is SCA required for all online payments in the EU?

SCA is required for customer-initiated electronic payment transactions in the EU/EEA, including online card payments and credit transfers. However, the SCA exemption framework allows many common transaction types to proceed without full SCA friction: low-value payments under EUR 30 (subject to cumulative limits), recurring fixed-amount subscriptions, whitelisted merchants, and low-risk transactions passing transaction risk analysis. In practice, a significant portion of online transactions qualify for exemptions. The challenge for merchants and PSPs is implementing exemption logic correctly to maximize frictionless customer experiences without exceeding regulatory fraud rate thresholds.

When will PSD3 apply and what will it change?

The European Commission proposed PSD3 (and a companion Payment Services Regulation, PSR) in June 2023. As of 2026, legislative negotiations are ongoing, with application not expected before 2026–2027. Key changes proposed in PSD3 and PSR include: extending SCA obligations and fraud liability rules to cases of APP fraud, strengthening IBAN verification requirements, extending open banking to open finance (covering savings, investments, and insurance), improving the TPP access framework, and harmonizing licensing requirements. Organizations should monitor the legislative process and begin assessing the likely impact of PSD3 on existing compliance programs and API infrastructure.

How does PSD2 interact with GDPR for open banking?

The interaction between PSD2 and GDPR is complex. PSD2 requires banks to provide account data to AISPs with customer consent, but GDPR also requires a valid legal basis for processing personal data — including the financial transaction data shared under PSD2. The Article 29 Working Party (now the EDPB) has clarified that PSD2 access is based on contract performance (GDPR Article 6(1)(b)) rather than consent, meaning GDPR consent is not required for the basic data sharing. However, when AISPs use the data for additional purposes beyond the core service, GDPR's consent requirements apply. Privacy notices must clearly describe the data sharing under PSD2 and the purposes for which data will be used, in plain language.