How PSD2 Works
PSD2 operates through a set of Regulatory Technical Standards (RTS) published by the European Banking Authority, which translate the high-level directive into specific technical and operational requirements. The directive splits obligations across payment service providers, merchants, acquirers, and issuers — each bearing distinct responsibilities. Understanding the flow from transaction initiation to authentication outcome is essential for anyone operating in the European payments ecosystem.
Transaction Initiated
A cardholder submits a card-not-present payment on a merchant's checkout. The merchant's payment service provider determines whether the transaction falls in scope of PSD2 based on the location of the acquirer and issuing bank within the EEA.
Exemption Assessment
The acquirer or merchant's payment service provider evaluates whether an SCA exemption applies — such as Transaction Risk Analysis (TRA) for low-fraud acquirers, a low-value transaction under €30, or a recognised recurring series. The exemption request is signalled in the authorisation message.
Issuer Decision
The issuing bank receives the authorisation request and decides whether to honour the exemption or step up to full authentication. Issuers may apply their own risk models. If they honour the exemption, liability for any subsequent fraud shifts to the issuer; if they step up, Strong Customer Authentication is triggered.
Authentication Challenge
When SCA is required, the issuer returns a challenge via 3D Secure 2.x. The cardholder completes authentication using two of three factors: something they know (PIN/password), something they have (device/OTP), or something they are (biometric). EMV 3DS 2.x passes rich browser and device data to the issuer to enable frictionless flows where possible.
Authorisation and Liability
The transaction completes with an authenticated or exempted status. Liability for fraud follows the authentication decision: fully SCA-compliant transactions shift fraud liability to the issuer; exempted transactions where the acquirer requested the exemption leave liability with the acquirer/merchant; declined exemptions that were then authenticated revert liability to the issuer.
Open Banking Flows (TPP)
Separately, licensed Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs) access customer bank accounts via PSD2-mandated APIs. Banks must provide dedicated interfaces for TPPs, enabling account data aggregation and direct bank-to-bank payment initiation — the foundation of open banking.
Why PSD2 Matters
PSD2 is not a compliance checkbox — it directly affects conversion rates, fraud economics, and the competitive landscape for payments in Europe. Getting SCA exemption strategy right can be worth several percentage points of checkout conversion for high-volume merchants.
According to the European Banking Authority's 2023 report on fraud in non-cash payments, card-not-present fraud in the EU declined measurably following the phased rollout of SCA mandates, with some member states reporting CNP fraud drops of over 50% compared to pre-SCA baselines. At the same time, Stripe's research on SCA rollout in the UK found that authentication challenge rates above 25% correlated with meaningful conversion losses, underscoring the need for smart exemption management.
The open banking provisions have had macroeconomic impact: by 2024, the number of licensed TPPs operating across the EEA exceeded 500, and open banking-powered payment initiation volumes were growing at over 40% year-on-year according to the Open Banking Excellence (OBE) tracker. For merchants, this opens an alternative to card rails with lower interchange costs and reduced chargeback exposure.
PSD3 on the Horizon
The European Commission published its PSD3 and Payment Services Regulation (PSR) proposals in June 2023. PSD3 will consolidate and strengthen PSD2 obligations, introduce enhanced open banking data rights, and address emerging fraud vectors such as authorised push payment (APP) fraud. Merchants and PSPs should monitor the legislative timeline — implementation is expected no earlier than 2026.
PSD2 vs. PCI DSS
PSD2 and PCI DSS are both mandatory frameworks for merchants processing card payments in Europe, but they serve fundamentally different purposes and are enforced by different bodies.
| Dimension | PSD2 | PCI DSS |
|---|---|---|
| Type | EU law (directive) | Industry standard (card schemes) |
| Enforced by | National Competent Authorities | Acquirers / card schemes |
| Scope | EEA payment transactions | Any entity storing, processing, or transmitting cardholder data |
| Primary focus | Authentication, open banking, liability | Cardholder data security |
| SCA mandate | Yes — two-factor authentication required | No direct SCA requirement |
| Penalties | Regulatory fines, processing suspension | Fines from acquirer, loss of card acceptance |
| Applies to merchants outside EU? | Only if EEA PSP involved | Globally, wherever card data is handled |
| Version cadence | Legislative (years) | Annual updates (PCI DSS v4.x) |
Both frameworks must be satisfied simultaneously. PCI DSS governs how cardholder data is stored and transmitted; PSD2 governs how transactions are authenticated. A merchant can be PCI-compliant while still failing PSD2 SCA requirements — and vice versa.
Types of PSD2 Obligations
PSD2 creates distinct obligation categories depending on the type of payment service provider involved.
Strong Customer Authentication (SCA) is the most operationally visible requirement, applying to electronic remote payment transactions where both the payer's and payee's PSPs are located in the EEA. It requires two independent authentication factors from the three recognised categories.
Open Banking Access (XS2A — Access to Account) requires banks and payment institutions to provide standardised API access to licensed AISPs and PISPs. The bank cannot charge for this access or apply discriminatory conditions. This underpins the entire European open banking ecosystem built on SEPA infrastructure.
Liability Shift Rules define which party bears fraud losses based on whether SCA was applied, exempted, or declined. The rules create strong financial incentives for issuers, acquirers, and merchants to implement SCA correctly.
Complaint and Reporting Obligations require PSPs to report major operational and security incidents to their National Competent Authority, maintain dispute resolution procedures, and provide transparent pricing information to consumers.
Best Practices
For Merchants
Apply SCA exemptions strategically rather than attempting full authentication on every transaction. Work with your acquirer to enable Transaction Risk Analysis exemptions, which can qualify transactions up to €500 depending on the acquirer's fraud rate. Flag recurring subscriptions correctly as merchant-initiated transactions after the initial authenticated payment — this removes subsequent charges from the SCA scope entirely.
Ensure your checkout integrates EMV 3DS 2.x rather than the legacy 3DS 1.0 protocol. Version 2.x passes over 150 data elements to the issuer, significantly increasing the frictionless authentication rate and reducing unnecessary challenges. Test your 3DS integration against all major issuer simulators before going live in the EEA.
Monitor your SCA challenge rate and authentication decline rate separately. A rising decline rate often signals issuer friction rather than genuine fraud, and can frequently be resolved by enriching the data passed in the authentication request.
For Developers
Implement the 3DS 2.x threeDSRequestorChallengeInd field correctly to signal your preferred challenge preference. Do not hardcode 04 (challenge requested) for all transactions — this wastes exemption opportunities and drives unnecessary friction.
Handle all possible 3DS outcomes: frictionless authentication, challenge completed, attempted authentication, failed authentication, and decoupled authentication. Many integrations only handle the happy path and silently drop challenged transactions.
Use your payment orchestration layer — such as Tagada — to manage exemption logic centrally rather than embedding it in individual payment integrations. Centralised exemption management allows consistent policy application across all PSPs and acquiring connections.
Ensure your liability shift tracking is accurate in your transaction records. For dispute resolution, you will need to demonstrate which party held liability at the time of a fraudulent transaction. Store the eci (Electronic Commerce Indicator) value and authenticationValue (CAVV/AAV) returned by the 3DS authentication.
Common Mistakes
Requesting exemptions without acquirer enablement. Many merchants assume exemptions are automatically available, but Transaction Risk Analysis and other acquirer-side exemptions must be explicitly enabled by the acquirer based on their portfolio fraud rates. Sending exemption flags to an acquirer that hasn't enabled them results in the flag being ignored or the transaction being declined.
Conflating SCA with 3D Secure. PSD2 mandates SCA as the authentication standard; 3D Secure is one technical protocol used to carry out SCA on card transactions. Other payment methods — such as open banking payment initiation — fulfil SCA through different mechanisms entirely. This distinction matters when building multi-method checkout flows.
Ignoring one-leg-out transactions. Some merchants incorrectly assume that transactions involving a non-EEA card are fully out of scope. If the acquiring bank is in the EEA, the transaction is still in scope as a "one-leg" transaction, though issuers outside the EEA cannot be compelled to perform SCA. Understanding this avoids misconfigured exemption logic.
Failing to re-authenticate on scope changes. A Merchant-Initiated Transaction series becomes invalid if the transaction amount or merchant changes materially. Re-authentication is required, and skipping it exposes the merchant to chargeback liability.
Treating SCA as a once-and-done implementation. PSD2 RTS requirements, card scheme mandates, and national authority enforcement guidance continue to evolve. The move from PSD2 to PSD3/PSR will require additional implementation work. Teams that treat the initial go-live as permanent will accumulate technical debt and compliance gaps.
PSD2 and Tagada
Tagada's payment orchestration platform is built with PSD2 compliance as a first-class concern, not an afterthought. Managing SCA exemption logic, authentication data routing, and liability shift tracking across multiple acquirers and PSPs simultaneously is one of the most operationally complex aspects of PSD2 compliance — and exactly the problem orchestration solves.
Exemption Routing at Scale
Tagada centralises SCA exemption policy across all your acquiring connections. Rather than configuring exemption logic separately in each PSP integration, you define a single exemption waterfall — TRA, low-value, recurring, trusted beneficiary — and Tagada applies it consistently, routes to the optimal acquirer for each exemption tier, and tracks liability shift status per transaction for dispute evidence.
When an acquirer declines an exemption and triggers a step-up challenge, Tagada handles the 3DS 2.x orchestration and re-routes the authenticated result back to the originating acquirer. For merchants with multi-acquirer setups, this prevents authentication loops and ensures the liability shift data is preserved end-to-end. The result is a measurably lower SCA challenge rate compared to single-acquirer integrations without centralised exemption management.