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: "breach of one element does not compromise the reliability of the other elements." [src2, src5] More than 75% of European banks have implemented the Berlin Group NextGenPSD2 XS2A framework as their dedicated API interface. [src7] Transaction Risk Analysis (TRA) exemptions permit frictionless authentication when the acquirer or issuer maintains fraud rates below reference thresholds: 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 or 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), 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 — exempt from SCA); MOTO transactions; merchant-initiated transactions (MIT) after initial SCA setup; anonymous prepaid instruments under EUR 150; entities under 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 permitted, 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 on whether to apply an exemption. 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 (customer due diligence), MiCA (crypto-asset services), and the 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 or national interpretation. [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 management
│   ├── PISP → Focus: Full authorization (EUR 50K capital), SCA delegation, eIDAS certificates
│   ├── AISP → Focus: Registration, PI insurance (EUR 5M/claim), data access scope, consent
│   ├── CISP → Focus: Fund confirmation requests, limited data access
│   ├── Merchant → Focus: SCA exemption optimization, 3D Secure 2 integration
│   └── Technology provider → Focus: PSD3 liability extension to digital 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 (amount + payee linked)
│   └── 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 (payment initiation, account information, card issuance, payment acceptance)
• Output: Determination of whether PSD2 applies and which obligations are triggered (ASPSP obligations, TPP authorization, SCA implementation, or merchant SCA compliance)
• Constraint: If the entity operates exclusively outside the EEA with no EEA customer transactions, PSD2 does not apply. If UK-based post-Brexit, UK PSRs 2017 apply instead. Entities under 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 member state NCA requirements, capital adequacy position (PISPs: EUR 50,000 initial capital; payment institutions: EUR 125,000; AISPs: no capital but EUR 5M professional indemnity insurance per claim)
• Output: Authorization/registration from home NCA, EEA passporting notifications filed, eIDAS certificates procured (QWAC + QSealC)
• Constraint: Operating without authorization is a criminal offence in most member states. AISPs may register (lighter regime) but must hold professional indemnity insurance. eIDAS certificates must be obtained from a qualified trust service provider. [src1, src2]

Step 3: Implement SCA and secure communication

• Inputs needed: Transaction types processed, authentication infrastructure, API development resources (for ASPSPs), eIDAS certificates (for TPPs)
• Output: SCA-compliant authentication flows using 2+ factors; dedicated API interface (ASPSPs) or eIDAS-authenticated API integration (TPPs); dynamic linking for remote transactions (unique authentication code linked to amount and payee)
• Constraint: SCA must be applied to all in-scope transactions unless a specific exemption applies. ASPSPs cannot block or degrade TPP access relative to their own channels. RTS Article 9 mandates factor independence — breach of one factor must not compromise others. [src2, src5]

Step 4: Configure SCA exemptions

• Inputs needed: Transaction volume data, fraud rates by value band, TRA infrastructure, trusted beneficiary management
• Output: Optimized SCA exemption strategy: low-value (<EUR 30, cumulative EUR 100 or 5 txns), TRA (<0.13% for ≤EUR 100, <0.06% for EUR 100-250, <0.01% for EUR 250-500), trusted beneficiaries, recurring fixed-amount, secure corporate, contactless (EUR 50/txn, EUR 150 cumulative)
• Constraint: Issuer makes the final exemption decision — acquirer/merchant requests can be declined. TRA requires quarterly fraud rate monitoring and reporting. 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: major incident reporting to NCA within 4 hours, fraud data reporting to EBA, complaint handling procedures, PSD3/PSR transition plan (VoP, dual-inherence SCA, fraud liability, API performance benchmarks)
• Constraint: With PSD3/PSR final texts published (23 Apr 2026) and adoption underway, reassess all obligations — 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 novel requirements (platform/telecom accountability, fraud-data sharing). [src8, src9]

Anti-Patterns

Wrong: Treating PSD2 API access as optional or implementing screen-scraping fallbacks

Some ASPSPs implemented minimal-functionality APIs or deliberately degraded API performance to discourage TPP access, while some TPPs continued using screen scraping as a primary method. The EBA intervened, requiring ASPSPs to provide dedicated interfaces with performance parity. [src2, src7]

Correct: Implement a dedicated API meeting NextGenPSD2 or STET standards with full functional parity

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

Wrong: Applying SCA to every transaction without exemption optimization

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

Correct: Implement a risk-based SCA exemption strategy using TRA and other available exemptions

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

Wrong: Assuming PSD2 explicit consent equals GDPR consent

Some TPPs conflated PSD2's explicit consent for account access with GDPR's consent as a legal basis for processing. These are legally distinct — PSD2 consent authorizes API access, while GDPR requires a separate legal basis (often legitimate interest or contract) for processing the retrieved data. [src1, src2]

Correct: Maintain separate PSD2 and GDPR consent/legal basis documentation

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

Wrong: Assuming current PSD2 compliance is sufficient 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 current capabilities against PSD3/PSR requirements. Prioritize Verification of Payee (now mandatory for all currencies, not just euro instant), enhanced transaction monitoring (device intelligence, behavioral analytics, malware detection), updated APP/impersonation fraud-liability processes, the e-money-to-payment-institution license migration, and 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 has created an uneven playing field — the PSR (directly applicable regulation) under PSD3 addresses this, but cross-border TPPs still face inconsistent NCA interpretation during the transition. [src3]
• The SCA requirement has been criticized for excessive friction in low-risk payment scenarios, potentially pushing transactions to less regulated channels. The UK FCA has signaled more flexible SCA approaches post-Brexit, creating competitive pressure on EU regulators. [src6]
• Open Banking adoption remains uneven across the EU — Nordic countries and the Netherlands have high TPP penetration while southern and eastern European markets lag, suggesting PSD2 alone is insufficient to drive financial innovation without complementary national initiatives. [src7]

Common Misconceptions

Misconception: PSD2 requires all banks to use the same API standard across the EU.
Reality: PSD2 mandates a dedicated interface but does not prescribe a specific standard. Multiple frameworks coexist: Berlin Group NextGenPSD2 (~75% adoption), STET (France), and the UK's 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 single online payment.
Reality: PSD2 provides multiple SCA exemption categories: 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 (out of scope entirely). The issuer decides whether to grant exemptions. [src2]

Misconception: AISPs and PISPs need the same level of authorization.
Reality: AISPs have a lighter burden — they register (rather than seek full authorization) with no capital requirement, but must hold professional indemnity insurance (EUR 5M per claim). PISPs require full authorization with EUR 50,000 initial capital and ongoing capital adequacy. [src1]

Misconception: PSD3 will completely replace PSD2 soon.
Reality: The final compromise texts were published 23 November 2025 (political agreement) and 23 April 2026 (texts), with the ECON committee voting 5 May 2026 and the plenary 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 obligations remain fully enforceable throughout — realistic PSD3/PSR application date is Q2-Q3 2028. [src8, src9]

Misconception: PSD3/PSR only makes minor adjustments to PSD2.
Reality: PSD3/PSR is a structural overhaul: it replaces the Directive (national transposition) with a directly applicable Regulation (PSR), extends mandatory Verification of Payee 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.