What is Payment Services Directive (PSD2)? Here’s what ecommerce needs to know

Introduction to PSD2

What is PSD2

PSD2, short for the revised Payment Services Directive, is the European Union’s core piece of legislation governing payment services and the payment service providers that deliver them. Formally known as Directive (EU) 2015/2366, it sets the rules that banks, payment institutions, e-money institutions and a newer category of third-party providers must follow when they move money or handle account information on behalf of customers across the European Union.

For ecommerce merchants trading into Europe, PSD2 matters because it reshapes two things that sit at the heart of online commerce: how a customer’s bank account and card data can be accessed by other providers, and how that customer is authenticated before a payment goes through. Unlike the original directive, PSD2 introduced open banking, requiring banks to give secure, consent-based access to customer account data, and it strengthened payment security through Strong Customer Authentication (SCA). It also widened the scope of regulated payment services and brought many more providers under supervision.

Background and evolution from PSD1

The first Payment Services Directive, Directive 2007/64/EC, was adopted in 2007 to create a single set of rules for payments across the EU. It succeeded in harmonising licensing and conduct rules for payment institutions, but it predated smartphone banking, app-based payment initiation and the rise of fintech account aggregators, and it left security requirements largely to individual member states.
The European Commission proposed a revision in 2013, and the co-legislators adopted the revised Payment Services Directive in November 2015. Member states were required to transpose it into national law by 13 January 2018, while the technical rules underpinning Strong Customer Authentication did not apply until 14 September 2019, with several national regulators granting short extensions for card-not-present e-commerce transactions to give merchants and card schemes time to adapt.

Scope and objectives of the directive

PSD2 was designed around four stated objectives: opening the payments market to greater competition, encouraging innovation from non-bank providers, improving the security of electronic payments, and strengthening consumer protection. It aims to make cross-border payment services within the EU as safe and efficient as domestic ones, while bringing previously unregulated activities, such as payment initiation and account information services, into a common supervisory framework.

Regulatory context and legal framework

PSD2 within the broader EU financial regulation landscape

PSD2 does not sit in isolation. It works alongside the Single Euro Payments Area (SEPA) framework, the second E-Money Directive, and the General Data Protection Regulation (GDPR), and it is enforced by national competent authorities working through the European Banking Authority. The European Commission’s payment services portal provides the current legislative status and related guidance for this wider framework

Key timelines, implementation, and transposition into national law

The directive’s key dates are worth keeping in view: political agreement in 2015, national transposition by January 2018, and application of the regulatory technical standards on SCA and secure communication from September 2019. The EBA’s final report on those technical standards set out the trade-offs it had to balance between security, convenience, technology neutrality and market integration.

Below was the PSD2 compliance timetable regarding the next fifteen month period up until the completion date of 31 December 2020.

Territorial scope and entities covered by PSD2

PSD2 applies to payment service providers established in the European Union and, through its incorporation into the EEA Agreement, across the wider European Economic Area, which extends the same rules to Iceland, Liechtenstein and Norway. It covers credit institutions, payment institutions, e-money institutions, post office giro institutions and, for the first time, account information service providers and payment initiation service providers. It also applies, with some modifications, to “one-leg” transactions where only one of the payment service providers involved is located in the EEA.

Core innovations and concepts introduced by PSD2

Open banking and access to account data

The best-known innovation of PSD2 is open banking. Account-servicing payment service providers, typically banks, must give authorised third-party providers secure access to a customer’s account data and payment functionality when the customer has given explicit consent. The European Central Bank’s explainer on the revised directive describes this as a deliberate move to end banks’ exclusive control over customer account data and to open the payments market to new competitors.

New categories of third-party providers

PSD2 created two principal categories of regulated third-party providers, defined in Article 4 of the directive: account information service providers, which aggregate data from a customer’s accounts to build a consolidated financial picture, and payment initiation service providers, which trigger a payment directly from a customer’s bank account rather than routing it through a card scheme. A related category, card-based payment instrument issuers, can confirm fund availability for card-based payments under Article 65 without directly holding the customer’s funds.

Strong customer authentication (SCA)

Strong Customer Authentication is the security requirement at the centre of PSD2. It requires that most electronic payments be authenticated using at least two independent elements drawn from three categories: something the customer knows, such as a password; something the customer has, such as a phone or card; and something the customer is, such as a fingerprint or facial scan. The intention, as set out by the EBA, is to make it substantially harder for fraudsters to authorise a payment even if one authentication factor has been compromised.

Dynamic linking and secure communication

SCA also requires dynamic linking: the authentication code generated for a transaction must be specific to the payment amount and the payee, so it cannot be reused for a different transaction. Alongside this, PSD2 mandates common and secure communication standards between banks and third-party providers, so that account data and payment instructions are exchanged through authenticated, encrypted channels rather than shared credentials.

Technical standards and implementation requirements

Regulatory Technical Standards (RTS) on Strong Customer Authentication

The detailed rules that make SCA workable in practice sit in the EBA’s Regulatory Technical Standards (RTS) on strong customer authentication and common and secure communication. These RTS define the authentication elements, the exemptions available for lower-risk transactions, and the standards banks must meet when opening their systems to third parties.

The EBA has since amended the RTS more than once, for example to make it mandatory for account providers to exempt account information service providers from repeated authentication when accessing account data under agreed conditions.

Learn more about exemptions and knowing what falls outside the scope of strong customer authentication

Secure API access and communication standards

Banks must expose an interface, generally a dedicated API, that lets authorised third-party providers request account information or initiate payments. That interface has to be tested, documented, and monitored for availability and performance, with obligations to treat requests from third-party providers no less favourably than the bank treats its own customer-facing channels.

Interface options: dedicated APIs versus modified customer interfaces

Banks can choose to build a dedicated API or, in principle, offer a modified version of their existing customer interface for third-party access. In practice, national competent authorities have pushed the market firmly toward dedicated APIs, since a bank can only avoid building a fallback option if its dedicated interface passes rigorous testing and performance thresholds and is granted an exemption.

Fallback mechanisms and contingency measures

Where a dedicated interface has not been exempted, or where it experiences unplanned downtime or performance problems, banks must maintain a fallback mechanism so that third-party providers can continue to serve customers. This contingency requirement exists to stop technical failures on the bank’s side from cutting off the services customers have consented to use.

Consumer protection and rights under PSD2

Transparency of fees, terms, and conditions

Payment service providers must give customers clear, upfront information about the charges, exchange rates and execution times that apply to a payment before it is authorised, and set out the terms of the underlying framework contract in plain, accessible language.

Liability rules for unauthorised transactions

PSD2 reduced the maximum a customer can be held liable for in the case of an unauthorised payment, and it puts the burden on the payment service provider to prove that a transaction was authenticated, properly recorded and unaffected by technical failure. Where a customer has acted without gross negligence or fraud, their liability for an unauthorised transaction is capped at a low fixed amount, with the rest refunded by the provider.

Refunds, chargebacks, and dispute resolution

Customers have an unconditional right to a refund for direct debit payments in most circumstances, and an extended window, generally 13 months from the transaction date, to flag an unauthorised or incorrectly executed payment. Payment service providers must also offer accessible complaints procedures, with unresolved disputes able to go to out-of-court resolution bodies such as those coordinated through the FIN-NET network.

Rights related to access to account and data sharing

Customers decide which third-party providers can access their account data, and that consent has to be explicit, specific and revocable at any time. Access to account information for this purpose must be free of charge to the customer, reinforcing that data sharing under PSD2 is something the customer controls rather than something imposed on them.

Impacts of banks and payment services providers

PSD2 required banks and other account-servicing payment service providers to invest heavily in new infrastructure: dedicated APIs, sandbox testing environments for third parties, stronger authentication systems and expanded fraud monitoring. It also changed their competitive position. Where banks once held a near-exclusive relationship with the customer’s account, they now compete, and in some cases partner, with fintechs building services on top of that same account data.

Liability rules under the directive shift more of the risk of unauthorised transactions onto providers, giving them a direct incentive to invest in stronger fraud controls.

Implications for fintechs and third-party providers

For fintechs, PSD2 created a licensing pathway rather than a grey area. Firms offering account information or payment initiation services must register or gain authorisation from a national competent authority, and once authorised, they can passport that authorisation across the European Economic Area rather than seeking separate approval in every market. This has underpinned the growth of account aggregation apps, alternative payment methods that initiate transfers directly from a bank account, and open banking infrastructure providers connecting merchants to multiple banks through a single integration.

Security, privacy, and data protection under PSD2

Balancing data sharing with GDPR requirements

PSD2’s consent-based access to account data has to operate alongside the GDPR, which governs the broader processing of personal data. A customer’s consent to share data with a third-party provider under PSD2 does not, on its own, satisfy every GDPR obligation; providers still need a valid legal basis for processing, clear privacy information, and appropriate security safeguards for the personal data involved.

Customer consent management and data minimisation

In practice, this means third-party providers should request access only to the account data they genuinely need to deliver the service the customer signed up for, in line with the data minimisation principle in Article 5 of the GDPR, keep clear records of consent, and make it straightforward for a customer to withdraw that consent later. Data minimisation is not just good practice here; it is central to how the two regimes are meant to work together.

Fraud prevention and transaction monitoring

PSD2 allows payment service providers to apply certain exemptions from Strong Customer Authentication, including one based on transaction risk analysis, but only where the provider maintains fraud monitoring capable of keeping its own fraud rates below the thresholds set out in Articles 18 and 19 of the RTS on strong customer authentication. In effect, the directive ties a merchant’s or provider’s ability to reduce authentication friction directly to the strength of its underlying fraud detection.

Customer experience and SCA friction

The most persistent criticism of PSD2 in practice has been friction at checkout. Extra authentication steps, particularly for card-not-present online payments, have been linked to cart abandonment and false declines, and the impact has fallen unevenly across merchants depending on how well their payment service provider and issuing banks implement exemptions such as low-value payments, trusted beneficiaries and transaction risk analysis. Cross-border transactions, including “one-leg-out” payments where one party sits outside the EEA, have proven especially difficult, since not every issuer applies exemptions consistently.

PAyment optimisation

Increase approvals and recover lost revenue

Apply SCA exemptions and 3DS intelligently to every transaction, while sharing enriched data with issuers to reduce avoidable false declines and unlock more approved orders.

Learn more

Future of PSD2 and evolution toward PSD3 and open finance

Regulatory reviews and identified gaps in PSD2

The European Commission’s review of PSD2 identified uneven implementation across member states, inconsistent application of SCA exemptions, continued reliance on screen scraping in some markets, and rising losses from authorised push payment fraud that the original directive was not designed to address. These findings led the Commission to propose a new legislative package rather than another amending directive.

Key proposals under PSD3 and the Payment Services Regulation

The Commission’s proposal splits the current rulebook into two instruments: a new Payment Services Directive (PSD3) covering licensing and supervision, and a directly applicable Payment Services Regulation (PSR) covering conduct rules, including SCA, liability and open banking access, so the core rules apply uniformly without relying on national transposition. As of August 2026, the European Parliament’s legislative tracker shows Parliament and Council reached provisional agreement on both texts in November 2025, with the Council endorsing the compromise texts in April 2026 and a Parliament plenary vote following. Publication in the Official Journal is expected in 2026, after which the new regime will generally apply around 21 months later.

Among the changes merchants should watch for are mandatory IBAN and account-name verification checks for credit transfers, extended liability for payment service providers in cases of authorised push payment fraud, broader access to payment systems for non-bank providers, and refinements to SCA intended to reduce false declines while keeping the underlying security bar high.

From open banking to open finance and beyond

The direction of travel extends beyond payments. The EU’s Financial Data Access framework aims to extend the open banking model established by PSD2 into a wider “open finance” regime covering savings, investments, insurance and pensions data, building on the same principles of consent-based, API-driven data sharing that PSD2 first established for payment accounts.

Conclusion

Summary of the transformative impact of PSD2

PSD2 reshaped European payments by opening bank account data to licensed third-party providers, mandating Strong Customer Authentication for most electronic payments, and rebalancing liability and consumer protection rules in the customer’s favour. It turned payment initiation and account information services from a regulatory grey area into a licensed, passportable activity across the European Economic Area, and it set the template that PSD3 and the Payment Services Regulation now build on.

Strategic considerations for stakeholders going forward

For enterprise merchants selling into Europe, the practical challenge has shifted from “are we compliant” to “are we compliant without losing legitimate sales to unnecessary friction.” That means understanding which SCA exemptions apply to each transaction, working with payment service providers and banks that implement those exemptions consistently, and building fraud monitoring strong enough to qualify for risk-based exemptions in the first place, especially as PSD3 and the Payment Services Regulation approach and further changes to SCA and fraud liability come into force.