PSD2 and EU Open Banking: SCA, API Obligations, and TPP Licensing

Summary

PSD2 (Directive 2015/2366) governs payment services across the EEA: payment service providers must apply Strong Customer Authentication (two independent factors from knowledge, possession, inherence), banks (ASPSPs) must expose dedicated XS2A open banking APIs to licensed Third-Party Providers, and TPPs must hold NCA authorization (AISP registration or PISP/ASPSP license) plus eIDAS certificates (QWAC + QSealC). SCA carries defined exemptions — low-value (<EUR 30), Transaction Risk Analysis (up to EUR 500 by fraud-rate band: 0.13%/0.06%/0.01%), trusted beneficiary, recurring/MIT, secure corporate, contactless, and MOTO — with the issuer making the final exemption call. Non-compliance risks fines up to 4% of turnover and license revocation. The successor PSD3/PSR package reached its final stage in spring 2026 (final compromise texts published 23 April 2026; ECON committee vote 5 May 2026), extending Verification of Payee to all intra-EEA credit transfers in every EU currency, merging e-money institutions into the payment-institution regime (repealing EMD2), treating impersonation fraud as fully reimbursable, and extending liability to scheme operators, technical providers, and platforms. The PSR applies 18 months after entry into force (VoP liability at 24 months, PSD3 transposition at 18 months), so realistic compliance lands in Q2-Q3 2028. [src1, src2, src8, src9]

Rule

Any entity providing payment services within the European Economic Area must comply with PSD2 (Directive 2015/2366): implement Strong Customer Authentication (SCA) using two independent factors from three categories (knowledge, possession, inherence), expose dedicated open banking APIs for licensed Third-Party Providers (TPPs), and ensure TPPs hold appropriate NCA authorization (AISP registration or PISP/ASPSP license) with valid eIDAS certificates. Non-compliant entities face penalties of up to 4% of annual revenue and risk license revocation. The PSD3/PSR successor package advanced to its final stage in spring 2026 — the Council published final compromise texts on 23 April 2026 and the Parliament's ECON committee voted on 5 May 2026 — so firms must now prepare for full APP-fraud reimbursement, Verification of Payee (VoP) extended to all intra-EEA credit transfers, the merger of e-money into payment institutions, dual-inherence SCA, and stricter API performance benchmarks. The PSR will apply 18 months after entry into force (VoP liability at 24 months), so realistic compliance lands in Q2-Q3 2028. [src1, src9]

Evidence

PSD2 has been transposed into national law across all 30 EEA countries since January 2018, with SCA requirements entering full enforcement on 14 September 2019 via the EBA Regulatory Technical Standards (Commission Delegated Regulation 2018/389). The RTS defines three authentication categories — knowledge (passwords, PINs), possession (devices, SIM cards, hardware tokens), and inherence (fingerprints, facial recognition, behavioral biometrics) — requiring elements from at least two distinct categories with independence mandated by RTS Article 9. [src2, src5] More than 75% of European banks have implemented the Berlin Group NextGenPSD2 XS2A framework. [src7] Transaction Risk Analysis (TRA) exemptions permit frictionless authentication when fraud rates remain below: 0.13% for transactions up to EUR 100, 0.06% for up to EUR 250, and 0.01% for up to EUR 500. [src2, src6] The PSD3/PSR package (provisional agreement 27 November 2025; final compromise texts published 23 April 2026; ECON committee vote 5 May 2026) extends Verification of Payee — the IBAN/payee-name check first mandated by the Instant Payments Regulation for euro instant transfers — to all intra-EEA credit transfers in every EU currency, treats impersonation ("spoofing") fraud as unauthorized and so fully reimbursable, extends liability to scheme operators, technical service providers, and online platforms/telecoms that fail to remove fraudulent content after notification, merges e-money institutions into the payment-institution regime (repealing EMD2), enables time-bounded fraud-data sharing between PSPs (retention up to 5 years), lets banks delay or block suspicious instant payments, allows two inherence-factor SCA combinations, and adds a 4-hour cooling-off period for spending-limit changes. [src8, src9] The VoP obligation builds directly on the Instant Payments Regulation's IBAN-name check (mandatory for euro-area PSPs from 9 October 2025) and the PSR widens it to non-instant and non-euro credit transfers; failure to flag a name/IBAN mismatch shifts liability to the payer's PSP. [src10] OneSpan and other vendors note the parallel uplift in transaction-monitoring and device-intelligence expectations that accompanies the new fraud-liability regime. [src4]

Key Properties

• Legal basis: Directive (EU) 2015/2366, transposed into national law; EBA RTS on SCA (Commission Delegated Regulation 2018/389) [src1, src2]
• SCA definition: Authentication using 2+ independent elements from knowledge (PIN, password), possession (device, token, SIM), inherence (fingerprint, face, behavioral biometrics) [src2, src5]
• SCA exemptions: Low-value (<EUR 30, cumulative EUR 100/5 txns), TRA (0.13% for ≤EUR 100, 0.06% for ≤EUR 250, 0.01% for ≤EUR 500), trusted beneficiary, recurring/MIT, secure corporate, contactless (EUR 50/txn, EUR 150 cumulative), MOTO (out of scope) [src2]
• API obligation (XS2A): ASPSPs must provide dedicated interfaces with same availability and performance as customer-facing channels [src1, src7]
• TPP categories: AISP (read-only account info — registration + PI insurance EUR 5M/claim), PISP (payment initiation — full authorization + EUR 50K capital), CISP (fund confirmation) [src1]
• eIDAS certificates: QWAC (transport identification) + QSealC (data integrity) required for TPP-ASPSP communication [src2]
• Penalty framework: Up to 4% of annual turnover; specific amounts set by member state NCAs; license revocation possible [src1, src6]
• PSD3/PSR timeline: Political agreement 27 Nov 2025; final compromise texts published 23 Apr 2026; ECON committee vote 5 May 2026, plenary expected late May 2026; OJ publication ~June/July 2026 (may slip to September); PSR applies 18 months after entry into force, VoP liability at 24 months, PSD3 transposition at 18 months; realistic applicability Q2-Q3 2028 [src8, src9]

Conditions

• Applies when: The entity is a PSP (bank, e-money institution, payment institution, TPP) operating within the EEA, or a merchant processing electronic payments from EEA-based customers. SCA applies when both issuer and acquirer are in the EEA. [src1]
• Does NOT apply when: One-leg-out transactions (one PSP outside EEA — SCA exempt); MOTO transactions; merchant-initiated transactions (MIT) after initial SCA setup; anonymous prepaid instruments under EUR 150; Article 3 limited network exclusions. [src2, src6]
• Confidence degrades when: PSD3/PSR not yet published in the Official Journal — although the final compromise texts (23 Apr 2026) are now stable, the precise entry-into-force date and therefore every 18/24-month deadline remain pending OJ publication and may slip; EBA Level-2 RTS (including on newer authentication methods such as passkeys/FIDO2) are still to be drafted; national transposition details differ across member states. [src8, src9]

Constraints

• PSD2 applies only within the EEA (EU 27 + Norway, Iceland, Liechtenstein). The UK retained PSD2 via Payment Services Regulations 2017 but has diverged post-Brexit — FCA sets independent SCA requirements and does not recognize EU eIDAS certificates. [src1]
• PSD3/PSR replaces PSD2 with a directly applicable Regulation (PSR) and lighter Directive (PSD3). With final compromise texts published 23 April 2026 and second-reading adoption underway, the PSR will apply 18 months after entry into force, the Verification-of-Payee liability 24 months after, and PSD3 transposition is due 18 months after (Settlement Finality Directive amendments enabling direct system participation apply after just 6 months). Both frameworks coexist until then; realistic applicability is Q2-Q3 2028. Key changes: VoP extended to all intra-EEA credit transfers in every EU currency, EMD2 repealed (e-money institutions become a sub-category of payment institutions), impersonation fraud treated as unauthorized/fully reimbursable, liability extends to scheme operators, technical providers, and platforms/telecoms, dual-inherence SCA, 5-year fraud-data sharing, banks may delay suspicious instant payments, 4-hour cooling-off for spending-limit changes. [src8, src9]
• SCA exemptions are issuer-granted, not merchant-granted — the card issuer or ASPSP makes the final decision. TRA exemptions require quarterly fraud rate reporting below EBA thresholds. [src2]
• TPPs must obtain authorization/registration from their home NCA and may passport to other EEA states. eIDAS certificates (QWAC + QSealC) are mandatory for API identification. [src1, src7]
• PSD2 interacts with GDPR (PSD2 consent is not GDPR consent — separate legal bases required), eIDAS Regulation (TPP identification), AML Directive (CDD), MiCA (crypto-asset services), and Instant Payments Regulation (VoP for euro transfers). [src1, src2]

Rationale

PSD2 was enacted to create a single EU payment market by breaking the monopoly banks held over customer account data. By mandating open APIs and standardizing TPP access, the directive enables competition from fintechs and non-bank payment providers while protecting consumers through SCA requirements. PSD3/PSR strengthens this framework by directly regulating (eliminating national transposition inconsistencies) and addressing gaps in fraud liability, API performance, and consumer protection that PSD2 left to market practice. [src1, src3]

Framework Selection Decision Tree

START — User needs EU payment services regulatory guidance
├── Which jurisdiction?
│   ├── EU/EEA → PSD2 and EU Open Banking ← YOU ARE HERE
│   ├── UK → UK Open Banking (FCA PSRs 2017 + OBIE standards)
│   ├── United States → CFPB Section 1033 / Dodd-Frank
│   └── Multiple jurisdictions → Cross-border payment regulation comparison
├── What is the entity's role?
│   ├── Bank / ASPSP → Focus: XS2A API obligations, SCA implementation, TPP access
│   ├── PISP → Focus: Full authorization (EUR 50K capital), eIDAS certificates
│   ├── AISP → Focus: Registration, PI insurance (EUR 5M/claim), consent management
│   ├── CISP → Focus: Fund confirmation requests, limited data access
│   ├── Merchant → Focus: SCA exemption optimization, 3D Secure 2 integration
│   └── Technology provider → Focus: PSD3 liability extension to wallets/platforms
├── Is the question about SCA specifically?
│   ├── YES → SCA: 2+ factors from knowledge/possession/inherence
│   │   ├── Exemptions? → TRA, low-value, trusted beneficiary, MIT, corporate, contactless
│   │   └── Dynamic linking? → Yes, for remote electronic payments
│   └── NO → Continue to API or licensing sections
└── Is PSD3/PSR timeline relevant?
    ├── YES → Final texts 23 Apr 2026, plenary vote late May 2026, PSR applies +18mo (VoP +24mo) → ~Q2-Q3 2028
    └── NO → Apply current PSD2 requirements as stated

Application Checklist

Step 1: Determine applicability and entity classification

• Inputs needed: Entity type (bank, fintech, merchant, TPP), jurisdiction of establishment, jurisdictions of operation, services offered
• Output: Determination of whether PSD2 applies and which obligations are triggered (ASPSP, TPP authorization, SCA, merchant compliance)
• Constraint: If the entity operates exclusively outside the EEA with no EEA customer transactions, PSD2 does not apply. UK-based post-Brexit entities fall under UK PSRs 2017. Article 3 exclusions (limited network, telecom, independent ATM) are out of scope. [src1]

Step 2: Obtain required authorization or registration

• Inputs needed: Entity classification from Step 1, home NCA requirements, capital position (PISPs: EUR 50,000; payment institutions: EUR 125,000; AISPs: no capital but EUR 5M PI insurance per claim)
• Output: Authorization/registration from home NCA, EEA passporting notifications, eIDAS certificates procured (QWAC + QSealC)
• Constraint: Operating without authorization is a criminal offence in most member states. eIDAS certificates must come from a qualified trust service provider. [src1, src2]

Step 3: Implement SCA and secure communication

• Inputs needed: Transaction types, authentication infrastructure, API resources (ASPSPs), eIDAS certificates (TPPs)
• Output: SCA-compliant flows using 2+ factors; dedicated API (ASPSPs) or eIDAS-authenticated API integration (TPPs); dynamic linking for remote payments
• Constraint: SCA applies to all in-scope transactions unless exempted. ASPSPs cannot degrade TPP access. RTS Article 9: factor independence mandatory. [src2, src5]

Step 4: Configure SCA exemptions

• Inputs needed: Transaction volumes, fraud rates by value band, TRA infrastructure, trusted beneficiary management
• Output: Optimized exemption strategy: low-value (<EUR 30, cumulative EUR 100/5 txns), TRA (<0.13% for ≤EUR 100, <0.06% for ≤EUR 250, <0.01% for ≤EUR 500), trusted beneficiaries, recurring, corporate, contactless (EUR 50/txn, EUR 150 cumulative)
• Constraint: Issuer makes the final exemption decision. TRA requires quarterly fraud rate monitoring. Transactions over EUR 500 always require SCA. [src2]

Step 5: Establish ongoing compliance and prepare for PSD3/PSR

• Inputs needed: Output from Steps 1-4, incident reporting procedures, complaint handling, regulatory monitoring
• Output: Compliance program: incident reporting to NCA within 4 hours, fraud data reporting, complaint handling, PSD3/PSR transition plan (VoP, dual-inherence SCA, fraud liability, API performance)
• Constraint: With PSD3/PSR final texts published (23 Apr 2026) and adoption underway, the PSR will be directly applicable without national transposition and applies 18 months after entry into force (VoP liability 24 months, PSD3 transposition 18 months), so plan for Q2-Q3 2028. Prioritize VoP for all credit transfers, APP/impersonation-fraud reimbursement processes, and the PI/EMI license migration. Seek legal counsel for platform/telecom accountability and fraud-data sharing. [src8, src9]

Anti-Patterns

Wrong: Treating PSD2 API access as optional or using screen scraping

Some ASPSPs implemented minimal-functionality APIs or degraded performance to discourage TPP access, while some TPPs continued screen scraping. The EBA intervened, requiring dedicated interfaces with performance parity to customer-facing channels. [src2, src7]

Correct: Implement a dedicated API meeting NextGenPSD2 or STET standards

ASPSPs must provide interfaces with the same data, functionality, and availability as their online banking. Over 75% of European banks use Berlin Group NextGenPSD2. TPPs should use dedicated APIs as primary access, with screen scraping only as a regulated fallback. [src7, src1]

Wrong: Applying SCA to every transaction without exemption optimization

Merchants and PSPs that apply SCA universally cause unnecessary cart abandonment of 20-30% on e-commerce transactions without additional security benefit. [src6]

Correct: Implement a risk-based SCA exemption strategy

Request TRA exemptions for low-risk transactions (maintaining fraud rates below thresholds), apply low-value exemptions for under EUR 30, use trusted beneficiary lists, and flag MIT correctly. The issuer retains final authority. [src2]

Wrong: Conflating PSD2 consent with GDPR consent

Some TPPs treated PSD2 explicit consent for account access as equivalent to GDPR consent for data processing. These are legally distinct — PSD2 consent authorizes API access; GDPR requires a separate legal basis for processing retrieved data. [src1, src2]

Correct: Maintain separate PSD2 and GDPR documentation

PSD2 consent covers account access through XS2A. GDPR requires an independent legal basis, privacy notice, data minimization, and purpose limitation. TPPs need both, documented separately. [src1]

Wrong: Assuming PSD2 compliance suffices for PSD3/PSR

With PSD3/PSR final texts published (23 Apr 2026) and adoption underway, some organizations assume existing compliance carries over. PSD3/PSR adds VoP for all intra-EEA credit transfers, full impersonation-fraud reimbursement, liability for scheme operators/technical providers/platforms, the PI/EMI merger (EMD2 repeal), dual-inherence SCA, and mandatory API performance benchmarks — none of which exist in PSD2. [src8, src9]

Correct: Begin PSD3/PSR gap analysis now

Map capabilities against PSD3/PSR: implement VoP (now mandatory for all currencies, not just euro instant), enhance transaction monitoring (device intelligence, behavioral analytics, malware detection), update APP/impersonation fraud-liability processes, plan the e-money-to-payment-institution license migration, and ensure SCA accessibility beyond smartphones for disabled and elderly users. Treat 2026 as the preparation year — firms that wait for OJ publication will be behind. [src8, src9]

Counter-Arguments

• PSD2's fragmented implementation across 30 EEA countries created an uneven playing field — the PSR (directly applicable) addresses this, but cross-border TPPs still face inconsistent NCA interpretation during transition. [src3]
• SCA has been criticized for excessive friction in low-risk scenarios, potentially pushing transactions to less regulated channels. The UK FCA signals more flexible approaches post-Brexit, creating competitive pressure. [src6]
• Open Banking adoption remains uneven — Nordic countries and the Netherlands have high TPP penetration while southern/eastern European markets lag, suggesting PSD2 alone is insufficient without complementary national initiatives. [src7]

Common Misconceptions

Misconception: PSD2 requires all banks to use the same API standard.
Reality: PSD2 mandates a dedicated interface but does not prescribe a specific standard. Multiple frameworks coexist: Berlin Group NextGenPSD2 (~75%), STET (France), and UK OBIE (UK only). PSD3/PSR may mandate stricter API performance benchmarks but a single standard remains uncertain. [src7, src3]

Misconception: SCA is required for every online payment.
Reality: PSD2 provides multiple exemptions: low-value (under EUR 30), TRA (up to EUR 500 depending on fraud rates), trusted beneficiaries, recurring/fixed-amount, secure corporate, contactless (under EUR 50), and MOTO (entirely out of scope). The issuer decides. [src2]

Misconception: AISPs and PISPs need the same authorization level.
Reality: AISPs register (lighter regime) with no capital requirement but must hold EUR 5M professional indemnity insurance per claim. PISPs require full authorization with EUR 50,000 minimum capital and ongoing capital adequacy. [src1]

Misconception: PSD3 will replace PSD2 soon.
Reality: The provisional agreement (27 Nov 2025) and final compromise texts (23 Apr 2026) are done, the ECON committee voted 5 May 2026 and the plenary is expected late May 2026, but Official Journal publication (~June/July 2026, possibly September) and the subsequent 18-month PSR application / 18-month PSD3 transposition windows still must run. PSD2 remains fully enforceable — realistic PSD3/PSR application date is Q2-Q3 2028. [src8, src9]

Misconception: PSD3/PSR only makes minor PSD2 adjustments.
Reality: PSD3/PSR is a structural overhaul: replaces a Directive with a directly applicable Regulation (PSR), extends mandatory VoP to all intra-EEA credit transfers in every EU currency, merges e-money institutions into the payment-institution regime (repealing EMD2), treats impersonation fraud as unauthorized and fully reimbursable, extends liability to scheme operators, technical providers, and online platforms/telecoms, allows dual-inherence SCA, enables 5-year fraud-data sharing between PSPs, mandates API performance benchmarks, and adds a 4-hour cooling-off for spending-limit changes. [src8, src9]

Comparison with Similar Rules

When This Matters

Fetch this rule when a user asks about EU payment services regulation, Strong Customer Authentication requirements or exemptions, Open Banking API obligations for European banks, TPP (AISP/PISP) licensing in the EU, eIDAS certificate requirements for open banking, or how to prepare for the PSD2-to-PSD3/PSR transition.