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

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. With PSD3/PSR politically agreed in November 2025 and formal adoption expected Q1-Q2 2026, firms must now prepare for enhanced fraud liability, mandatory Verification of Payee (VoP), dual-inherence SCA, and stricter API performance benchmarks during the 21-month transition period. [src1, src3]

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 agreement (27 November 2025) introduces mandatory Verification of Payee for all credit transfers, allows two inherence-factor SCA combinations (e.g., fingerprint + behavioral biometrics), makes PSPs liable for unauthorized transactions initiated by fraudsters impersonating bank employees, and mandates a 4-hour cooling-off period for spending limit changes. [src3, 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; formal adoption Q1-Q2 2026; 21-month transition; compliance ~H2 2027 to early 2028 [src3]

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 final text not yet formally adopted — specific requirements may shift during legal-linguistic review; EBA opinions on newer authentication methods (passkeys/FIDO2) remain pending; national transposition details differ across member states. [src3, src5]

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). During the ~21-month transition (from formal adoption Q1-Q2 2026), both frameworks coexist. Key changes: mandatory VoP for all credit transfers, dual-inherence SCA, fraud liability shifts to PSPs for impersonation fraud, platform liability for social media-originated fraud, 4-hour cooling-off for spending limit changes. [src3, src4]
• 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 → Agreement Nov 2025, adoption Q1-Q2 2026, 21-month transition
    └── 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: PSD3/PSR formal adoption expected Q1-Q2 2026, 21-month transition to ~H2 2027. PSR will be directly applicable without national transposition. Seek legal counsel for impersonation fraud liability and platform accountability provisions. [src3, src4]

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

PSD3/PSR introduces VoP, dual-inherence SCA, impersonation fraud liability, platform liability transfer, API performance benchmarks, and 4-hour cooling-off — none of which exist in PSD2. Existing compliance does not automatically carry over. [src3, src4]

Correct: Begin PSD3/PSR gap analysis now

Map capabilities against PSD3/PSR: implement VoP, enhance transaction monitoring (device intelligence, behavioral analytics, malware detection), update fraud liability processes, and ensure SCA accessibility for disabled and elderly users. [src3, src4]

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: While a provisional agreement was reached 27 November 2025, formal adoption, Official Journal publication, and a 21-month transition must still occur. PSD2 remains fully enforceable — realistic PSD3/PSR application date is late 2027 or early 2028. [src3]

Misconception: PSD3/PSR only makes minor PSD2 adjustments.
Reality: PSD3/PSR is a structural overhaul: replaces a Directive with a directly applicable Regulation (PSR), introduces mandatory VoP, allows dual-inherence SCA, shifts fraud liability to PSPs for impersonation, enables liability transfer to platforms, mandates API performance benchmarks, adds 4-hour cooling-off for spending limits, and extends provisions to certain crypto-asset transactions. [src3, src4]

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.