Category: Regulations and Standards

Payment Services Directive 2

Also known as: PSD2, Revised Payment Services Directive, Payment Services Directive 2, Directive (EU) 2015/2366

Simply put

PSD2 is a European directive that regulates payment services and electronic money, building on the earlier Payment Services Directive (PSD1). It is intended to make online payments more secure while increasing competition in the payments industry, including by enabling regulated third parties to access payment accounts with customer consent. As a directive, it is transposed into national law by individual jurisdictions, so specific implementation details can vary by country.

Formal definition

PSD2 (the Revised Payment Services Directive) is a European Commission directive governing payment services and electronic money, succeeding the original Payment Services Directive (PSD1). It establishes the regulatory framework often associated with open banking, permitting authorized third-party providers to access payment accounts subject to customer consent, and underpins requirements for stronger authentication of electronic payments. Because it is a directive rather than a directly applicable regulation, it is implemented through national transposition, and its detailed technical and authentication obligations (for example, those set out in associated regulatory technical standards) should be confirmed against the applicable national implementation and the current published texts. Note that the strong customer authentication obligations frequently discussed in connection with PSD2 are distinct from, and should not be conflated with, PCI DSS or other PCI Security Standards Council standards.

Why it matters

PSD2 is a foundational piece of European payments regulation because it reshapes both the security and competitive landscape of payment services. By succeeding PSD1, it extends the regulatory framework to make online payments more secure while opening the market to greater competition, including by enabling regulated third-party providers to access payment accounts with customer consent. For anyone operating in or serving the European payments ecosystem, understanding PSD2 is essential to navigating obligations around authentication, third-party access, and customer consent.

Because PSD2 is a directive rather than a directly applicable regulation, it is transposed into national law by individual jurisdictions. This means that while the directive sets a common framework, the specific implementation details can vary from country to country. Security engineers, compliance officers, and merchant risk teams must therefore confirm obligations against the applicable national implementation rather than assuming a single uniform standard applies across all European markets.

It is important not to conflate PSD2 with PCI DSS or other PCI Security Standards Council standards. The strong customer authentication obligations frequently discussed in connection with PSD2 are distinct from PCI requirements and address different regulatory objectives. Treating them as interchangeable can lead to gaps in either compliance program, so teams should keep the two frameworks and their governing bodies clearly separated in their planning.

Who it's relevant to

Compliance officers

Compliance teams need to understand how PSD2 is transposed into national law in each jurisdiction where they operate, since implementation details can vary by country. They should confirm authentication and third-party access obligations against the applicable national implementation and the current published texts, and keep PSD2 obligations distinct from PCI DSS and other PCI Security Standards Council standards.

Payment processors and acquirers

Processors and acquirers operate within the framework PSD2 establishes, including provisions that permit authorized third-party providers to access payment accounts with customer consent. Understanding these open banking and authentication provisions is important to supporting compliant payment flows across European markets.

Security engineers

Engineers responsible for authentication of electronic payments should recognize that PSD2 underpins requirements for stronger authentication, and that the detailed technical obligations are set out in associated regulatory technical standards that should be confirmed against the current published texts and national implementations. These obligations are separate from PCI DSS controls.

Merchant risk teams

Merchant risk teams serving European customers must account for PSD2's security and competition objectives, including its impact on how online payments are authenticated and how third parties may access payment accounts with consent. Because implementation varies by jurisdiction, teams should verify the specific requirements applicable in each market.

Inside PSD2

Strong Customer Authentication (SCA)

A requirement introduced under PSD2 that certain electronic payments be authenticated using at least two independent elements from the categories of knowledge (something the user knows), possession (something the user has), and inherence (something the user is). SCA is intended to help reduce unauthorized transactions, but it is a distinct concept from EMV chip authentication, 3-D Secure, and multi-factor authentication as those terms are used elsewhere, even though 3-D Secure is commonly used as a channel to deliver SCA for card-not-present transactions.

Dynamic Linking

An SCA-related requirement that the authentication code be dynamically linked to the specific amount and payee of a transaction, so that a code authenticating one transaction cannot be reused for another. This is intended to help mitigate certain manipulation and replay risks, subject to correct implementation.

SCA Exemptions

Defined circumstances under which SCA may not need to be applied, such as certain low-value or low-risk transactions, subject to conditions. Whether an exemption applies and how liability is affected depends on the applicable regulatory and network rules, which vary by region and change over time; exact thresholds and conditions should be confirmed against current published sources.

Access to Accounts (XS2A) and Third-Party Providers

Provisions enabling regulated third-party providers, such as payment initiation and account information service providers, to access account data or initiate payments with the account holder's consent, typically through defined interfaces. This shapes the operating environment but is separate from PCI DSS, which governs the protection of cardholder data.

Relationship to Cardholder Data Handling

PSD2 addresses authentication and access to payment accounts; it does not replace PCI DSS controls over cardholder data. The distinction between cardholder data (such as PAN, cardholder name, expiration date, service code) and sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks) remains governed by PCI DSS, and sensitive authentication data must not be stored after authorization even when encrypted.

Common questions

Answers to the questions practitioners most commonly ask about PSD2.

Does PSD2 apply globally to all card payments?

No. PSD2 is European Union legislation, transposed into national law by EU and EEA member states. It governs payment services within its regional scope and does not automatically apply to transactions or entities outside that jurisdiction. Card brand and network rules, which vary by region and change over time, govern many aspects of transactions elsewhere. Organizations operating across regions should confirm which regulatory and network requirements apply to each transaction flow rather than assuming PSD2 coverage.

Is PSD2 the same thing as PCI DSS or a substitute for it?

No. PSD2 is a regulatory framework governing payment services and includes requirements such as strong customer authentication and access for third-party providers. PCI DSS is a separate industry security standard for protecting cardholder data and the environments that store, process, or transmit it. They address different objectives and are maintained by different bodies. Complying with one does not establish compliance with the other; an organization may need to satisfy both depending on its role and activities.

How does PSD2's strong customer authentication requirement relate to multi-factor authentication and 3-D Secure?

Strong customer authentication under PSD2 is a regulatory requirement that authentication rely on multiple independent elements from defined categories, which is a form of multi-factor authentication applied to payment contexts. 3-D Secure is a protocol commonly used as a mechanism to help implement strong customer authentication for card-not-present transactions, but it is one implementation option rather than the requirement itself. These concepts address authentication at different levels: the regulatory obligation, the general security control, and a specific technical protocol. None of them alone eliminates fraud.

What should teams consider when relying on exemptions from strong customer authentication?

PSD2 frameworks provide for certain exemptions where strong customer authentication may not be applied, subject to defined conditions. Relying on an exemption typically involves assessing eligibility conditions and associated risk, and the availability and treatment of exemptions can vary by regional transposition and by acquirer and network rules. Because rules change and vary by region, teams should confirm current requirements against the applicable regulation and network documentation rather than assuming a fixed set of exemptions.

Which parties are affected by PSD2's provisions for third-party providers?

PSD2 introduces roles for third-party providers that may access payment account information or initiate payments on behalf of a user, subject to consent and defined access conditions. This affects account-holding institutions that must support such access as well as the third-party providers themselves. Implementation details, including interfaces and access mechanisms, are governed by the applicable regulation and technical standards, and organizations should confirm the current requirements applicable to their role.

How should an organization determine whether PSD2 obligations apply to a specific transaction flow?

Applicability depends on factors such as the jurisdiction of the parties, the nature of the payment service, and the organization's role in the flow. Because PSD2 is transposed into national law with regional variation, and because network rules also vary by region, organizations should map each transaction flow to its jurisdiction and participants and confirm obligations against the current applicable regulation rather than assuming uniform treatment.

Common misconceptions

PSD2 SCA and PCI DSS are the same thing, so complying with one satisfies the other.

They are separate. PSD2 is a regulatory framework addressing authentication and account access, while PCI DSS is a security standard governing the protection of cardholder data. Meeting SCA requirements does not by itself establish PCI DSS compliance, and vice versa; controls, scope, and validation differ.

3-D Secure and SCA are identical, and enabling 3-D Secure automatically means SCA is satisfied.

3-D Secure is a protocol commonly used as a channel to deliver SCA for card-not-present transactions, but SCA is a set of authentication requirements, not a specific protocol. Whether an SCA obligation is met depends on how authentication factors and dynamic linking are implemented, not on the presence of a label.

Applying SCA prevents payment fraud.

SCA is intended to help reduce certain unauthorized transactions, but it does not eliminate fraud. It does not by itself address risks such as account takeover, friendly or first-party fraud, or synthetic identity fraud, and detection controls involve false-positive and false-negative trade-offs. No single control guarantees fraud prevention.

Best practices

Treat PSD2 SCA obligations and PCI DSS obligations as distinct programs, mapping which controls satisfy each rather than assuming overlap; confirm PCI DSS requirements against the current published standard rather than a fixed requirement number.

When using 3-D Secure to deliver SCA, verify that the implementation actually applies two independent authentication factors and dynamic linking to amount and payee, rather than relying on the protocol label alone.

Document and validate any reliance on SCA exemptions against current applicable regulatory and network rules, noting that thresholds, conditions, and liability effects vary by region and change over time.

Maintain PCI DSS controls over cardholder data independently of PSD2 work, and ensure sensitive authentication data is not stored after authorization, even when encrypted.

Combine SCA with layered fraud controls, since SCA alone does not address account takeover, first-party or friendly fraud, or synthetic identity fraud, and monitor detection controls for false-positive and false-negative trade-offs.

Govern third-party provider access under XS2A with explicit account-holder consent, defined interfaces, and access controls, keeping this separate from cardholder data protection scope.