PSD2 / Strong Customer Authentication:
Cryptography for Open Banking and Payments
| Region | EU/EEA, transposed into national law by each member state |
| Applicability | Account Servicing Payment Service Providers (ASPSPs): banks and institutions holding payment accounts, required to expose secure APIs and enforce SCA Payment Initiation and Account Information Service Providers (PISPs/AISPs): third-party providers accessing accounts under open banking Card Issuers and Acquirers: apply SCA to remote, card-not-present transactions, commonly through EMV 3-D Secure |
| Relevant sections | Directive (EU) 2015/2366, Article 97: Strong Customer Authentication requirement Delegated Regulation (EU) 2018/389: RTS on SCA and Common and Secure Communication RTS Articles 5–9: Dynamic linking, independence of authentication elements, and exemptions |
Overview
PSD2’s Strong Customer Authentication requirement has applied since September 14, 2019, under the European Banking Authority’s Regulatory Technical Standards. It mandates authentication using at least two independent elements from three categories, knowledge, possession, and inherence, for most remote electronic payments and account access, with the resulting authentication code dynamically linked to the specific payment amount and payee.
PSD3 and a companion Payment Services Regulation are progressing through the EU legislative process, with realistic application expected between 2026 and 2028. They are expected to refine the exemption framework and strengthen open banking authentication requirements, but the underlying SCA obligation is not going away.
Why it matters
SCA violations, particularly dynamic-linking failures and misuse of the transaction-risk-analysis exemption, remain among the most common findings in National Competent Authority supervision. Non-compliant authentication flows can shift liability for unauthorized transactions onto the payment service provider and expose it to direct enforcement action.
Open banking has widened the scope of what needs cryptographic protection: the APIs that ASPSPs expose to AISPs and PISPs must independently meet the same secure-communication bar as customer-facing channels, commonly through qualified certificates under eIDAS.
How this maps to cryptography
PSD2 / Strong Customer Authentication addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:
| Section | Function | What it says | Supporting Products |
| RTS, Article 5 | Dynamic Linking of Authentication Codes | A cryptographically bound authentication code tied to the specific payment amount and payee, preventing replay or tampering with the transaction details. | EJBCA |
| RTS, Article 9 | Independence of Authentication Elements | A certificate- or key-based possession factor kept cryptographically isolated from the knowledge and inherence factors used alongside it. | EJBCA |
| RTS, Articles 30, 35 | Secure Communication for Open Banking APIs | Qualified certificates for website authentication and electronic seals (QWACs/QSealCs) and mutual TLS authenticating ASPSP-to-TPP API sessions. | EJBCA |
| RTS, Articles 22–23 | Confidentiality and Integrity of Personalized Credentials | Lifecycle management of the certificates and keys protecting personalized security credentials from disclosure or compromise. | Keyfactor Command |
| RTS, Article 18 | Transaction Risk Analysis Evidence | Supporting cryptographic and authentication evidence underpinning the documented fraud-rate calculations required to claim a TRA exemption. | AgileSec |
| Supporting secure-element and app-integrity guidance | Payment Application Integrity | Signed releases of mobile banking and payment applications, supporting the integrity of the possession factor they implement. | SignServer |
Audit readiness
Assessments and examinations, whether self-conducted, performed by a regulator, or reviewed by an independent assessor, focus on demonstrated evidence rather than policy statements alone. Key areas that examiners and assessors commonly probe:
- Dynamic Linking Implementation: Is the authentication code cryptographically bound to the specific transaction amount and payee for every applicable payment?
- Independence of Authentication Factors: Are the possession, knowledge, and inherence elements used for SCA kept genuinely independent of one another?
- Qualified Certificate Use for Open Banking APIs: Are QWACs and QSealCs used and kept current for ASPSP-to-TPP API communication?
- TRA Exemption Documentation: Is the fraud-rate calculation and supporting evidence for any transaction-risk-analysis exemption documented and current?
- Personalized Credential Lifecycle Management: Are the certificates and keys protecting personalized security credentials formally managed through issuance, renewal, and revocation?
- PSD3 / PSR1 Readiness: Is the organization monitoring the PSD3/PSR1 legislative process for changes to the SCA and exemption framework?
TAKE THIS TO MANAGEMENT
Dynamic-linking failures and transaction-risk-analysis exemption misuse remain top findings in national supervisory reviews, seven years after SCA became mandatory. Getting this wrong is not a theoretical risk: it shifts liability for unauthorized transactions onto us.
PSD3 is coming, but it keeps the core SCA obligation rather than replacing it, so there is no reason to wait for it before closing the gaps we already know about, particularly in how our authentication codes are bound to transaction details and how our TRA exemption evidence is documented.
Related Compliances
General Data Protection Regulation (GDPR)
Digital Operational Resilience Act (DORA)
