← All guides
Payment Regulation12 min read12 July 2026

PSD2 Strong Customer Authentication: Complete Guide to SCA, PSD3, and Open Banking API Obligations

Everything payment service providers, fintechs, and open banking platforms need to know about PSD2 Strong Customer Authentication, EBA RTS Art. 5 dynamic linking, SCA exemptions, PSD3/PSR transition, and eIDAS API obligations.

What PSD2 SCA is — and why it still trips up fintechs in 2026

Strong Customer Authentication (SCA) has been mandatory for EU payment service providers since 14 September 2019 under PSD2 (Directive 2015/2366, Art. 97). Seven years in, it's still one of the most litigated and most botched compliance requirements in EU financial regulation. The EBA enforcement tracker for 2025 shows SCA violations — particularly around dynamic linking and TRA exemption documentation — remain in the top five findings for NCA supervision visits.

This guide covers what SCA actually requires, the five exemptions in full, open banking API obligations, and the PSD3/PSR transition that's reshaping the landscape from 2025 onwards.

The three-factor rule (PSD2 Art. 97(1) / EBA RTS Art. 4)

SCA requires at least two of three independent elements:

  • Knowledge: something only the user knows — PIN, password, passphrase, security question answer
  • Possession: something only the user has — phone (for OTP/push notification), hardware token, smart card, FIDO2 security key
  • Inherence: something the user is — fingerprint, face recognition, voice recognition, keystroke dynamics, behavioural biometrics

The key word is independent. Two factors from the same category don't satisfy SCA. And a breach of one cannot compromise the other — an SMS OTP that goes to the same device as the compromised password doesn't satisfy this independence requirement (EBA Opinion EBA/Op/2019/06).

Authentication methods in practice: TOTP (RFC 6238 — Google Authenticator, Authy), FIDO2/WebAuthn (passkeys with platform authenticator, security keys — now the gold standard), push notifications with secure enclave key binding (Apple SE, Android StrongBox), SMS OTP (acceptable but being phased out due to SIM-swap attacks — EBA has flagged it as weaker than alternatives).

Dynamic linking: the requirement that catches everyone (EBA RTS Art. 5)

For remote electronic payment transactions, SCA must include dynamic linking: the authentication code must be uniquely linked to the specific amount and payee of the transaction. This means:

  • An OTP that works for any transaction is non-compliant. The code must be computationally linked to "€250 to ACME GmbH".
  • The payer must be shown the amount and payee before authenticating.
  • The confidentiality and integrity of the transaction details used in the authentication must be protected throughout.

Common failures: using a static HMAC seed with no transaction data input; showing transaction details on a different channel without binding them to the auth code; using the same auth flow for payments and account access. If your authentication code doesn't change based on what the user is paying, you're non-compliant — regardless of how strong the authentication method otherwise is.

The five SCA exemptions

EBA RTS Chapter 3 (Art. 10-18) specifies the following exemptions. These are risk-based, not blanket permissions.

1. Low-value transactions (EBA RTS Art. 16)

Remote electronic payments up to €30 per transaction. Cumulative limits: the PSP must apply SCA once cumulative transactions since last SCA reach €100, or five consecutive transactions, whichever comes first. The PSP, not the user, is responsible for tracking the cumulative counter. Many PSPs fail here by resetting counters per session rather than per card.

2. Contactless point-of-sale (EBA RTS Art. 11)

Up to €50 per contactless POS transaction. Cumulative limit: SCA required once total contactless transactions since last SCA reach €150 or five consecutive contactless transactions. This is the Apple Pay / Google Pay tap-to-pay exemption.

3. Transaction Risk Analysis — TRA (EBA RTS Art. 18)

The most complex exemption and the most frequently misapplied. A PSP may exempt transactions from SCA if it performs real-time TRA AND its reference fraud rates are below EBA thresholds:

  • Transactions up to €100: fraud rate must be below 0.13%
  • Transactions up to €250: fraud rate must be below 0.06%
  • Transactions up to €500: fraud rate must be below 0.01%

The fraud rate is a rolling reference rate — the PSP calculates it over all remote electronic payment transactions of the relevant type in a rolling quarter. You must report fraud rates to your NCA. If your rates breach these thresholds, you must immediately stop applying TRA exemptions for that tier. Common failures: applying TRA exemptions without tracking fraud rates at all; failing to exclude fraudulent transactions from the denominator; not distinguishing by PSP type (acquirer vs issuer rates are separate).

4. Trusted beneficiary whitelisting (EBA RTS Art. 13)

PSUs (payment service users) can whitelist specific payees. Once whitelisted, subsequent payments to that payee can bypass SCA. The PSP must allow PSUs to add, manage, and remove beneficiaries from their whitelist — this is mandatory. The initial whitelisting action itself requires SCA.

5. Corporate / dedicated payment processes (EBA RTS Art. 17)

Legal entities (not natural persons) using dedicated and controlled corporate payment processes may be exempt. This covers ERP-initiated payments, bulk payroll, treasury management systems — where the risk profile is materially different from retail payments. Requires formal risk assessment and documentation.

Open banking API obligations (PSD2 Art. 66-67 / EBA RTS Art. 30-36)

Account Servicing PSPs (ASPSPs) — banks and e-money institutions holding payment accounts — must provide TPPs (Third Party Providers) with access to payment accounts via a dedicated interface. The EBA Guidelines EBA/GL/2018/07 set the standards:

  • Dedicated interface required: typically an API meeting EBA performance standards — 98%+ availability per calendar month, ≤500ms response time for 95th percentile requests
  • Sandbox environment: ASPSP must provide a testing environment for TPP developers before go-live
  • Performance statistics: published quarterly, showing availability, response times, and error rates — must be at least as good as the customer-facing interface
  • No additional barriers: ASPSPs cannot require TPPs to register, pay fees, or complete any vetting beyond verifying the TPP's NCA authorisation/registration via the EBA register
  • Contingency mechanism: if the dedicated API is unavailable for ≥30 seconds in any 30-second window, TPPs must be able to fall back to a "modified customer interface" — the ASPSP cannot charge for this

eIDAS certificate validation is mandatory for TPP authentication (Regulation (EU) No 910/2014):

  • QWAC (Qualified Web Authentication Certificate): used for TLS mutual authentication — the TPP proves identity at the transport layer. ASPSPs must accept QWACs for TPP authentication without additional registration steps.
  • QSealC (Qualified Electronic Seal Certificate): used for request signing — each API request body is signed by the TPP. The ASPSP validates the signature and checks the certificate against the EBA register.
  • EBA Central Register: all licensed TPPs are listed at the EBA's public register — your validation logic must check the TPP's PSD2 role (AISP/PISP/CBPII) against this register before granting access.

PSD3/PSR: what's changing

The European Commission published PSD3 (COM(2023) 366, a new Directive) and the Payment Services Regulation (PSR, COM(2023) 367, directly applicable without national transposition) in June 2023. Key changes from the current PSD2 regime:

  • IBAN/name verification mandatory: PSD3/PSR introduces mandatory beneficiary name verification for credit transfers — modelled on the UK's Confirmation of Payee. This is specifically designed to reduce APP fraud. PSPs must warn users when name doesn't match IBAN.
  • Open finance scope: PSD3 paves the way for the Financial Data Access Regulation (FIDA, COM(2023) 360), which extends open banking beyond payment accounts to investment accounts, insurance, crypto-asset holdings, and pension products.
  • Improved API standardisation: PSD3/PSR addresses the current fragmentation where each EU country's ASPSPs have different API implementations. The regulation mandates more standardised API interfaces — reducing the burden on TPPs that currently maintain dozens of country-specific connectors.
  • Real-time fraud data sharing: PSPs will be required to share fraud data in real time with other PSPs and competent authorities to improve TRA accuracy across the sector.
  • Direct PSR applicability: unlike PSD2 (a Directive requiring transposition), the PSR is a Regulation — directly applicable across all Member States on the same date, eliminating national transposition variations that currently create compliance fragmentation.
  • Strengthened SCA requirements: PSD3 proposes mandatory transaction monitoring for all PSPs, not just those using TRA exemptions.

Timeline: PSD3 is in the ordinary legislative procedure (co-decision). Realistic transposition/application timeline is 2026-2028 depending on political pace. PSPs should monitor progress via the Council and Parliament positions.

Assess your SCA compliance now

PSD2 SCA enforcement has matured. NCAs are now running targeted supervision visits focused specifically on SCA gaps — dynamic linking failures, TRA exemption misuse, and API performance shortfalls are the top three findings. The EBA's annual fraud report publishes PSP-level fraud rates in some jurisdictions.

→ Use the free PSD2/PSD3 SCA Compliance Checklist to assess your posture — covers all 40 SCA requirements across SCA authentication, open banking APIs, PSD3 readiness, consumer rights, and fraud prevention. No account required.

More guides