Why cryptography now sits at the center of PSD2
PSD2 and SCA compliance is a cryptographic obligation, not a checkbox. Strong Customer Authentication (SCA) has applied to most remote electronic payments since September 14, 2019, under Commission Delegated Regulation (EU) 2018/389, the Regulatory Technical Standards (RTS) developed by the European Banking Authority. Several national authorities ran a phased ramp for card-based e-commerce into 2020. Behind every compliant authentication flow sits a set of keys, certificates, and cryptographic bindings that have to work correctly and stay current.
Open banking has widened the scope of what needs that protection. PSD2 opened payment accounts to licensed third parties, so banks now expose APIs that must meet the same secure-communication bar as customer-facing channels. This guide walks through what the rules require and the cryptography that satisfies each control.
What PSD2 and strong customer authentication actually require
The core rule is straightforward. SCA requires authentication using at least two independent elements from three categories, for most remote electronic payments and account access. For remote payment transactions, the authentication code must be dynamically linked to the specific amount and payee.
The three authentication factor categories
The three categories are knowledge, possession, and inherence:
- Knowledge: something only the user knows, such as a password or PIN.
- Possession: something only the user has, such as a registered device or a key stored on a secure element.
- Inherence: something the user is, such as a fingerprint or face scan.
“Two independent elements” means the factors must come from at least two of these categories. They must also be independent, so compromising one does not compromise the others. That independence is a technical property, not just a policy statement.
The regulatory anchors
The obligation rests on named legal instruments. The base requirement is Article 97 of Directive (EU) 2015/2366. The technical detail lives in Commission Delegated Regulation (EU) 2018/389, the RTS on strong customer authentication and common and secure communication.
Within the RTS, a cluster of articles carries the cryptographic weight. Articles 4 to 9 cover the authentication of code and its dynamic linking, and the independence of authentication elements. Conditions for exemptions sit in Articles 10 to 21. Later articles govern secure communication and the protection of personalized security credentials.
Who is in scope
PSD2 touches several roles, and each has a cryptographic stake in the outcome.
Account servicing payment service providers (ASPSPs)
ASPSPs are the banks and institutions that hold payment accounts. They must expose secure APIs to licensed third parties and enforce SCA on account access and payments. They also decide how their interface authenticates the parties connecting to it.
Payment initiation and account information service providers (PISPs and AISPs)
PISPs initiate payments on a user’s behalf, and AISPs aggregate account information. Both are third-party providers that access accounts under open banking. To connect, they must identify themselves to the ASPSP using qualified certificates and communicate over a secured channel. Card-based payment instrument issuers (CBPIIs) also access accounts to confirm funds availability and fall under the same identification and secure communication rules.
Card issuers and acquirers
Issuers and acquirers apply SCA to remote, card-not-present transactions. In practice, this is commonly delivered through EMV 3-D Secure. That protocol carries the authentication and its dynamic linking between the merchant, acquirer, and issuer.
How PSD2 maps to cryptography, control by control
This is the analytical core. Each RTS control area maps to a specific cryptographic mechanism. Each subsection below stands on its own, answer first.
Dynamic linking of authentication codes (RTS Articles 4 and 5)
Dynamic linking binds the authentication code to a specific payment. The code is cryptographically tied to the exact amount and payee, so any change to either invalidates it. This prevents replay and stops an attacker from tampering with the transaction details after approval.
Independence of authentication elements (RTS Article 9)
Independence keeps the factors cryptographically separate. A certificate-based or key-based possession factor is isolated from the knowledge and inherence factors used alongside it. If one channel or element is breached, the isolation prevents the others from falling with it.
Secure communication for open banking APIs (RTS Articles 28, 30, 34, and 35)
Open banking APIs must authenticate both ends and protect data in transit. The RTS relies on qualified certificates issued under eIDAS. Two types apply: qualified certificates for website authentication (QWACs) and qualified certificates for electronic seals (QSealCs).
The two certificate types do different jobs. A QWAC identifies the endpoints and secures the channel, while a QSealC seals the application data to prove its origin and integrity. Mutual TLS then authenticates the ASPSP-to-TPP API session.
The APIs that ASPSPs expose to AISPs and PISPs must meet the same secure-communication bar as their customer-facing channels.
Confidentiality and integrity of personalized credentials (RTS Articles 22 to 27)
Personalized security credentials must be protected across their whole lifecycle. That means disciplined management of the certificates and keys that shield those credentials from disclosure or compromise. Weak issuance, storage, or renewal of those keys undermines every authentication built on top of them.
Transaction risk analysis exemption evidence (RTS Articles 18 to 20)
The transaction risk analysis (TRA) exemption lets a provider skip SCA on lower-risk payments, but only with evidence. The documented fraud-rate calculations behind a TRA claim rest on supporting cryptographic and authentication data. If monitored fraud rises above the RTS thresholds, the right to apply the exemption is lost.
Payment application integrity (RTS Article 9(3))
The possession factor is only as trustworthy as the app that implements it. Article 9(3) requires separated secure execution environments on multi-purpose devices and mechanisms confirming the software or device has not been altered. Signed releases of mobile banking and payment applications protect that integrity. Code signing lets a device confirm a release genuinely came from the provider and was not modified in transit.
What examiners look for: audit readiness
Supervisory assessments focus on demonstrated evidence, not policy statements alone. A useful way to prepare is to self-assess against the controls an examiner will probe. Treat each item as something you must be able to show, not just describe.
- Dynamic linking: show the authentication code is bound to amount and payee, and that changes invalidate it.
- Independence of factors: demonstrate the possession factor is cryptographically isolated from the other elements.
- Qualified certificates: prove QWACs and QSealCs for open banking APIs are valid, current, and correctly used.
- TRA exemption documentation: produce the fraud-rate evidence that supports every exemption claimed.
- Credential lifecycle: evidence that certificates and keys protecting personalized credentials are managed end to end.
- PSD3 and PSR readiness: show a plan for the coming refresh of the exemption and authentication framework.
The stakes: liability, enforcement, and open banking exposure
Getting SCA wrong carries real consequences. SCA violations, particularly dynamic-linking failures and misuse of the TRA exemption, remain among the most common findings in National Competent Authority supervision. Under Article 74(2) of PSD2, where the payer’s PSP does not require SCA, the payer bears no financial loss absent fraud on the payer’s part, and a payee or payee’s PSP that fails to accept SCA compensates the payer’s PSP.
Open banking raises the exposure further. Every API a bank exposes to third parties is another channel that must clear the same cryptographic bar. A lapsed qualified certificate on one of those APIs is both an outage and a compliance gap, and it can trigger direct enforcement.
Looking ahead: PSD3, PSR, and post-quantum readiness
PSD2 is not the last word. The European Parliament and the Council reached provisional political agreement on PSD3 and the Payment Services Regulation (PSR) on November 27, 2025, and the Council published final compromise texts on April 23, 2026. Formal adoption and Official Journal publication remain outstanding. The PSR’s core conduct rules apply roughly 18 to 21 months after entry into force, putting realistic application in late 2027 to 2028. PSD2 remains the applicable framework until then.
These measures are expected to refine the exemption framework and strengthen open banking authentication. The underlying SCA obligation is not going away.
A second deadline is arriving in parallel. NIST finalized FIPS 203, 204, and 205 in August 2024. The transition timeline sits in a separate document, NIST IR 8547, still an initial public draft, under which quantum-vulnerable public key algorithms including RSA, ECDSA, ECDH, and finite-field Diffie-Hellman are deprecated after 2030 and disallowed after 2035.
On January 13, 2026, the G7 Cyber Expert Group, chaired by the U.S. Department of the Treasury and the Bank of England, published a coordinated roadmap for post-quantum migration in the financial sector. It sets out six phases running from awareness and preparation through inventory, risk assessment, planning, execution, and validation, and states that it does not set guidance or regulatory expectations.
The timeline is tighter than it looks for payments infrastructure. Swift has indicated that SwiftNet 8.0 is targeted to be post-quantum enabled in 2027, with a 15-month migration window for participating institutions. Yet recent surveys reveal that only a small percentage of global financial institutions have begun substantive migration.
Harvested data can be decrypted later, so the data’s sensitivity horizon sets the real deadline. That makes crypto-agility a PSD2-era priority rather than a future one.
How Keyfactor supports PSD2 and SCA compliance
Keyfactor helps regulated payment providers manage the cryptographic trust that PSD2 and SCA compliance depends on. The map from RTS control to product is direct.
EJBCA issues and manages the certificates behind dynamic linking, factor independence, and mutual TLS, including QWAC and QSealC issuance. It is standards-compliant PKI, and it is ready for post-quantum and hybrid certificates.
SignServer signs payment application and mobile banking releases, supporting the integrity of the possession factor those apps implement. AgileSec discovers and inventories cryptographic assets, providing the evidence base for TRA documentation and post-quantum planning.
Keyfactor Command keeps a current register of every certificate and key protecting personalized credentials and open banking APIs. It automates renewal well ahead of expiry, so a qualified certificate never lapses into an outage or an audit finding.
The Keyfactor Trust Control Plane brings these together as one platform that observes, analyzes, provisions, orchestrates, and governs every cryptographic asset and machine identity across core banking, payments, and open banking infrastructure, so the evidence any framework asks for comes from a single system of record. That is the foundation both PSD2 today and PSD3 tomorrow will be assessed against.
Summary and next steps
SCA is a cryptographic capability, not a one-time control. The rules resolve into concrete artifacts: authentication codes bound to transaction data, isolated possession factors, qualified certificates on every open banking interface, and documented fraud-rate evidence.
Four practical starting points apply regardless of where an institution sits today:
- Inventory the certificates and keys behind authentication and open banking APIs.
- Confirm dynamic linking works and that authentication factors are genuinely independent.
- Keep qualified certificates for open banking APIs valid and current.
- Document the fraud-rate and cryptographic evidence behind every TRA exemption.
Treated as an ongoing program rather than a project, that foundation lets each new requirement, whether it arrives as PSD3, PSR, or a post-quantum deadline, land on infrastructure that already answers it. Request a Demo
Got PSD2 and SCA questions? We’ve got answers.
What is PSD2?
PSD2 is the EU’s Second Payment Services Directive, Directive (EU) 2015/2366, applicable since January 13, 2018. It replaced the first Payment Services Directive. It opened payment accounts to licensed third parties and set security rules for electronic payments, including Strong Customer Authentication.
What is Strong Customer Authentication (SCA)?
SCA requires at least two independent authentication elements from three categories: knowledge, possession, and inherence. It has applied to most remote electronic payments and account access since September 14, 2019, under the EBA’s RTS.
What is dynamic linking?
Dynamic linking cryptographically ties the authentication code to a specific payment amount and payee. Any change to either invalidates the code, which prevents replay and tampering with the transaction details.
What are QWACs and QSealCs?
Both are qualified certificates issued under eIDAS. A QWAC (qualified website authentication certificate) identifies endpoints and secures the TLS channel. A QSealC (qualified electronic seal certificate) seals API data to prove its origin and integrity.
Which RTS articles matter most for cryptography?
Articles 4 to 9 cover the authentication code, dynamic linking, the element categories, and independence. Articles 18 to 20 cover the TRA exemption and its fraud-rate evidence. Articles 22 to 27 cover personalized credential protection. Articles 28, 30, 34, and 35 cover identification and secure communication for open banking APIs.
What is the TRA exemption?
Transaction risk analysis lets a provider skip SCA on lower-risk payments. It is allowed only where documented fraud rates stay below RTS thresholds, backed by supporting cryptographic and authentication evidence.
How is PSD3 different from PSD2?
PSD3 pairs a directive with a directly applicable Payment Services Regulation. PSD3 also folds e-money institutions into a single licensing regime, replacing EMD2. On authentication, the PSR is expected to state in the text that SCA applies to adding a card to a digital wallet, and to support authentication methods that do not require a smartphone. Realistic application is late 2027 to 2028. The core SCA obligation remains.
Why does certificate management matter for PSD2 compliance?
PSD2 depends on qualified certificates and keys that expire and must be validated, renewed, and revoked correctly. Automated discovery, renewal, and governance prevent outages, support audits, and keep open banking APIs trusted.
Does the RTS require mutual TLS?
The RTS requires qualified certificates for identification and a protected communication session, and that mutual TLS is the common market implementation, for example in the Berlin Group specification.
