PSD2: What It Requires and Who It Applies To

What is PSD2?

Payment Services Directive 2 (Directive 2015/2366/EU) is the EU's primary law governing electronic payments across member states. The European Parliament and Council adopted it in November 2015 as a replacement for PSD1 (Directive 2007/64/EC), and it became enforceable from January 13, 2018.

PSD2 has three defining aims. First, it reduces payment fraud by mandating Strong Customer Authentication (SCA) for virtually all electronic transactions. Second, it opens the payments market by requiring banks to give licensed third parties API access to customer accounts, a framework now called open banking. Third, it strengthens consumer protections by tightening liability rules for unauthorized payments and improving disclosure requirements.

The European Banking Authority (EBA) holds the primary technical standard-setting role under PSD2. Its Regulatory Technical Standards on SCA (EBA/RTS/2019/04) define the exact authentication requirements, exemption thresholds, and incident reporting obligations. These RTS became fully enforceable in December 2020, after member states were granted extended transition periods.

PSD2 created two new licensed entity categories: Account Information Service Providers (AISPs), which aggregate financial data from multiple accounts with user consent, and Payment Initiation Service Providers (PISPs), which initiate account-to-account payments on a user's behalf. Both require a license in at least one EU member state and must meet all PSD2 security obligations.

The regulation sits within the EU's broader payments and risk architecture. The EU TFR (EU) governs data requirements for wire transfers between PSPs. DORA (EU), effective from January 2025, extends ICT risk management requirements that partially overlap with PSD2's Article 95 security obligations.

Who does PSD2 apply to?

PSD2 applies to any payment service provider serving customers in the EU or EEA, regardless of where the PSP itself is incorporated. Size doesn't matter. A two-person startup EMI and a €2 trillion bank face the same SCA, liability, and incident reporting obligations.

Covered entity types:

• Credit institutions (banks) holding payment accounts for retail or corporate customers
• E-money institutions (EMIs) issuing e-money and processing payments. Examples: Revolut (EU EMI), N26, Wise in its EMI capacity
• Payment institutions (PIs) including money remittance firms, card acquirers, and merchant payment processors
• Account Information Service Providers (AISPs) aggregating account data across banks with user consent
• Payment Initiation Service Providers (PISPs) initiating account-to-account payments on users' behalf
• Merchants accepting online card payments. They don't need a PSD2 license, but they must support SCA-compliant checkout flows or face liability for disputed transactions
• Technology vendors (indirectly). API gateway providers, authentication vendors, and fraud scoring firms carry contractual PSD2 obligations through their PSP clients' compliance programs

There are no revenue or volume thresholds. The regulation covers payments in euros and EEA currencies. "One-leg" transactions, where only one of the two PSPs is in the EEA, fall under partial PSD2 scope as defined in Article 2(4).

The UK transposed PSD2 as the Payment Services Regulations 2017 (PSR 2017), enforced by the FCA. Post-Brexit divergence has accumulated, particularly around SCA timelines and exemption rules for card-not-present payments, but the core obligations remain substantially aligned with PSD2 as of May 2026.

What does PSD2 require?

PSD2's obligations span authentication, data access, incident management, and consumer protection. The most operationally demanding are:

1. Strong Customer Authentication (SCA): All electronic payments above €30 require at least two independent factors from three categories: knowledge (PIN, password), possession (phone, hardware token), and inherence (biometrics). A cumulative threshold also applies: SCA is required after five consecutive contactless transactions or once cumulative spend since the last SCA reaches €100, whichever comes first.

2. Open banking / XS2A access: Banks must give licensed AISPs and PISPs API access to customer payment accounts when the customer has consented. Banks cannot charge for this access and cannot create technical barriers. The API Security for Financial Services obligation here is real: the API must meet EBA security standards under the RTS.

3. Transaction Risk Analysis (TRA) exemption: PSPs may skip SCA for low-risk transactions if their fraud rate stays below defined thresholds. The EBA RTS sets these at 0.13% for card payments up to €100, 0.06% for payments up to €250, and 0.01% for payments up to €500. Exceed the threshold and the exemption is revoked automatically.

4. Major incident reporting: PSPs must notify their national competent authority within 4 hours of detecting a major operational or security incident, and submit a full report within 3 business days. The EBA's incident classification guidelines define what qualifies as "major."

5. Fraud data reporting: PSPs must report aggregate transaction and fraud data to the EBA and their NCA at least annually. The EBA uses this data to review and adjust authentication exemption thresholds.

6. Liability shift: When a PSP doesn't apply SCA and fraud results, the PSP bears full liability under Article 73. No recourse to the customer.

7. Client funds safeguarding: Payment institutions and EMIs must hold client funds in segregated accounts or cover them with qualifying insurance or guarantees.

8. Transparency and disclosure: Before and after each transaction, PSPs must provide users with specified information: fees, exchange rates, transaction reference numbers, and complaint procedures.

9. Complaints handling: PSPs must respond to complaints within 15 business days, or 35 in complex cases, and must participate in an Alternative Dispute Resolution (ADR) scheme.

10. Passporting: PSPs operating across EEA member states must notify their home regulator before providing services in a host state.

What evidence do regulators expect?

On an examination day, NCAs and the EBA want documented proof across four areas.

Authentication controls:

• Transaction-level logs showing which authentication method was used for every electronic payment, including the factor type and timestamp
• Documentation of all exemptions applied: TRA, contactless limit, trusted beneficiary, or low-value. For TRA, examiners expect the PSP's fraud rate calculation for the period the exemption was applied
• Quarterly recertification records confirming TRA fraud rates stayed within the EBA thresholds
• SCA integration test results, including regression tests after any system change

Incident management:

• A written incident classification procedure calibrated to the EBA's criteria in its Major Incident Reporting Guidelines (EBA/GL/2017/10)
• A log of all incidents reported to the NCA, with timestamps proving the 4-hour initial notification was met
• Post-incident analysis reports addressing root cause and remediation

Open banking and API governance:

• A register of all AISPs and PISPs with active access to the bank's XS2A API
• Consent records for each third-party access event, timestamped and linked to the specific customer authorization
• API uptime logs, including records of any unavailability exceeding 30 seconds that triggered the fallback mechanism

Fraud reporting and governance:

• Annual fraud data submissions to the EBA and NCA, broken down by transaction type, authentication method, and exemption category
• Board or senior management approval for decisions to apply TRA exemptions
• Evidence that fraud rate monitoring runs at least quarterly

Customer Due Diligence (CDD) and Know Your Customer (KYC) documentation is also reviewed where PSPs conduct customer onboarding, particularly for AISPs and PISPs registering business clients.

Common failure modes

PSD2 failures in practice aren't usually about missing a rule entirely. They're about partial implementation.

• SCA applied to payments but not to credential changes: Adding a new payee or changing an email address is a high-risk action. Several UK banks faced FCA scrutiny because they authenticated the payment correctly but left account management flows unprotected. That's exactly how account takeover fraud gets through.

• TRA exemption applied without qualifying fraud data: Some PSPs applied TRA exemptions before they had sufficient transaction volume to calculate a statistically meaningful fraud rate. When examiners asked for the supporting calculation, there wasn't one.

• Fallback mechanism failures: PSD2 requires banks to maintain a contingency fallback interface if the XS2A API is unavailable for more than 30 seconds. The EBA and NCAs have cited banks for deploying APIs that met the letter of PSD2 but failed to implement or test the fallback.

• Incident notification timeline breaches: A security incident detected at 10pm on a Friday has a 4-hour clock, not a "next business day" clock. Firms that notified on Monday morning after a Friday evening breach have faced regulatory escalation. The clock runs from detection, not confirmation.

• Consent records for AISP access: When banks fail to retain proof of user consent before granting AISP access, they create dual exposure: a PSD2 breach and a GDPR (EU) breach on the same transaction.

• New payment channels not re-certified: Firms that launched app-based payment flows and assumed their existing SCA certification covered the new channel without re-testing.

In 2021, Italy's competition authority (AGCM) fined Unicredit, Intesa Sanpaolo, and Banco BPM approximately €2 million each for systematically blocking third-party PSD2 API access, per AGCM case A543. The FCA published PS21/19 in August 2021, identifying persistent SCA implementation gaps across the UK payments sector.

Penalties for non-compliance

PSD2 doesn't specify EU-wide fine amounts directly. Article 103 instructs each member state to establish "effective, proportionate and dissuasive" penalties. What that means in practice varies significantly by jurisdiction.

Germany: The Payment Services Supervision Act (ZAG) transposes PSD2. BaFin can impose fines up to €5 million or 10% of annual turnover for material breaches. The Wirecard case remains the most significant German payment sector collapse involving PSD2-related obligations: BaFin revoked Wirecard Bank AG's license in June 2020, partly due to client funds safeguarding failures. Current enforcement actions are published on BaFin's sanctions database.

France: The ACPR supervises payment institutions under PSD2. It has issued sanctions in the low millions of euros for client funds safeguarding failures and inadequate SCA implementation. Decisions are published on the ACPR's sanctions page.

Italy: As noted above, AGCM imposed approximately €2 million each on three major banks in 2021 for blocking XS2A access. This was a competition law penalty on top of the prudential one, showing that PSD2 non-compliance carries more than one regulatory angle.

United Kingdom: Under PSR 2017, the FCA can issue unlimited fines. It has generally pursued PSD2-related enforcement through supervisory action rather than public fines. The bigger financial exposure is often Article 73 liability: a PSP that skips SCA on a fraudulent €50,000 payment absorbs that loss directly, with no recourse to the customer.

Beyond direct fines, firms that repeatedly fail incident reporting timelines risk license conditions or, in extreme cases, license revocation. The FATF Rec 15 (FATF) framework adds a further angle for PSPs deploying new authentication technologies: inadequate controls on new methods can constitute a money laundering risk failure on top of the PSD2 breach.

Related regulations and frameworks

PSD2 sits within a dense cluster of EU financial regulation, and most PSPs are subject to several of these simultaneously.

PSD3: The European Commission published its PSD3 proposal in June 2023 (COM/2023/366). PSD3 would convert many PSD2 provisions into a directly applicable regulation, removing the need for national transposition. New additions include Authorized Push Payment (APP) fraud liability rules, open finance obligations extending beyond payment accounts, and tighter SCA scope. The PSD3 (EU) dossier covers the current proposal status.

DORA: From January 17, 2025, DORA (EU) is the primary ICT risk management framework for payment institutions in the EU. Where DORA and PSD2 Article 95 overlap, DORA takes precedence for ICT risk. PSD2's 4-hour incident reporting obligation remains in force separately.

GDPR: The consent framework for AISP account access is simultaneously a PSD2 consent and a GDPR consent. A defective consent creates parallel liability under both regimes. GDPR (EU) Article 7 requirements for freely given, specific, and informed consent apply to every XS2A access event.

EU AMLR and 6AMLD: PSPs licensed under PSD2 are obliged entities under EU AML law. Transaction data collected for SCA purposes feeds directly into Customer Due Diligence (CDD) and transaction monitoring obligations under EU AMLR (EU) and 6AMLD (EU).

EU Transfer of Funds Regulation: Payment messages between PSPs must carry payer and payee data under the EU TFR (EU). PSD2 creates the licensed PSP framework within which the TFR operates.

UK PSR 2017: Post-Brexit UK PSPs operate under the Payment Services Regulations 2017, enforced by the FCA. The core PSD2 framework is preserved, but divergence on SCA specifics is growing. UK PSPs marketing into the EU must comply with EU PSD2 separately through their local EU entity or passporting arrangement.

How FluxForce supports PSD2 compliance

PSD2 demands real-time fraud monitoring, SCA exemption management, and structured incident detection. FluxForce agents monitor payment flows continuously, identify authentication anomalies, and generate the audit trails NCAs require on examination day. Nova Sentinel tracks fraud rates against EBA exemption thresholds in real time, alerting compliance teams before a breach occurs. Aiden Flux produces a full decision record for every exemption applied. For firms managing open banking third-party risk or preparing for PSD3, Regulatory Compliance Automation and Payment Gateway Security capabilities are worth exploring. Request a demo to see them in action.