PSD2 Strong Customer Authentication is one of the most operationally demanding regulatory requirements in European financial services. It demands multi-factor verification combining something the user knows, something they possess and something they are, with each factor drawn from a separate category. FIDO2, the passwordless authentication standard backed by the FIDO Alliance and formalized through the W3C WebAuthn specification, appears at first glance to satisfy this cleanly. The engineering reality is more complicated. This article examines where PSD2 SCA and FIDO2 align, where they create compliance gaps and how banking engineers can build session management and dynamic linking flows that satisfy both frameworks simultaneously.
What PSD2 SCA Actually Requires
The European Banking Authority published its Regulatory Technical Standards on SCA under PSD2 in Commission Delegated Regulation (EU) 2018/389. The core requirement is authentication using at least two independent elements from three defined categories: knowledge (PIN, password, passphrase), possession (registered device, smart card, token) and inherence (fingerprint, face, iris, voice). Independence means compromise of one element cannot undermine the other.
SCA applies to electronic payment initiation, remote access to payment accounts and any action through a remote channel that risks payment fraud. Exemptions exist for low-value transactions below 30 euros, low-risk transactions scored by real-time transaction risk analysis, recurring merchant payments and trusted beneficiary lists. The EBA has issued multiple opinions clarifying how these exemptions apply, particularly around transaction risk analysis thresholds based on fraud reference rates.
Two additional requirements define SCA beyond simple multi-factor authentication. Authentication codes must be specific to the transaction amount and payee, a concept the EBA calls dynamic linking. And authentication elements must be independent from the payment channel where possible, meaning that on-device confirmation of a payment initiated on a desktop browser represents the expected architecture, not an edge case.
FIDO2 and WebAuthn Architecture for Banking
FIDO2 is an umbrella term for two complementary standards: the W3C Web Authentication specification (WebAuthn) and the FIDO Alliance's Client-to-Authenticator Protocol (CTAP2). Together they enable a relying party, in this context a bank or payment service provider, to register a cryptographic key pair on a user's authenticator device and subsequently challenge that authenticator to prove possession using a private key that never leaves the device.
The cryptographic exchange works as follows. During registration, the authenticator generates an asymmetric key pair tied to the relying party origin and optionally to a user handle. The public key is sent to the server and stored. The private key is stored in a secure enclave, a hardware-backed key store such as the Android Keystore, Apple Secure Enclave or a FIDO hardware security key. During authentication, the server sends a challenge. The authenticator signs the challenge along with the authenticator data structure using the private key. The server verifies the signature against the stored public key.
For banking applications this means the possession factor is satisfied by the registered authenticator device. When the authenticator also requires a biometric gesture or a device PIN before releasing the private key, inherence or knowledge is layered in. This combination maps naturally to SCA's two-factor requirement. The FIDO Alliance's own analysis positions platform authenticators (built into modern smartphones and laptops) as providing possession through the bound device key and inherence through on-device biometric verification.
The critical technical detail is that WebAuthn assertions include a flags byte in the authenticator data. The UP flag (user presence) indicates the user physically interacted with the device. The UV flag (user verification) indicates the authenticator locally verified the user via PIN or biometric. A compliant SCA implementation must require UV=true in the assertion, not just UP=true. Accepting UP-only assertions satisfies presence but does not satisfy the knowledge or inherence factor, which creates a direct PSD2 compliance gap.
Dynamic Linking: The Hardest SCA Requirement
Dynamic linking is where most FIDO2-for-payments implementations run into friction. Article 5 of Commission Delegated Regulation (EU) 2018/389 specifies that where a payer initiates a payment order electronically, the authentication code must be specific to the amount and payee the payer consented to. If the payee or amount changes, the code must be invalidated.
Standard WebAuthn challenge-response does not carry transaction data natively. The authenticator signs the server's challenge bytes and the authenticator data structure. It does not sign a transaction amount or beneficiary account number. A bank that simply uses WebAuthn for payment confirmation without embedding transaction data into the signed challenge is not satisfying dynamic linking, even if the user is shown the transaction details on screen before tapping the authenticator.
The correct engineering pattern binds the transaction data to the challenge. The server generates the challenge as a cryptographic commitment to the transaction parameters, typically a hash of the canonical transaction representation including amount, currency, beneficiary IBAN and a server-generated nonce. The client displays this data before invoking the WebAuthn navigator.credentials.get() call. The authenticator signs a challenge that is deterministically derived from the transaction. The server verifies not just the signature but also that the challenge matches its own recomputed hash of the pending transaction record.
This pattern satisfies dynamic linking because the authentication code, the WebAuthn assertion, is cryptographically bound to a specific amount and payee. If an attacker attempts to replay the assertion against a different transaction, the challenge mismatch fails server-side verification. Banks implementing this pattern should document the binding mechanism explicitly in their SCA compliance documentation submitted to their national competent authority.
A secondary consideration is what the EBA calls the display binding problem. If transaction details are shown in the same app or browser that initiates the payment, a malware compromise of that environment can alter what the user sees without altering the underlying transaction. Some European banks address this by routing the confirmation step through a separate app instance with its own signing context, or by using a hardware authenticator with a trusted display. The EBA has acknowledged this as an acceptable risk management approach when paired with behavioral anomaly detection.
Session Management Patterns Under SCA
SCA applies at specific trigger points, not as a continuous authentication requirement for every API call. Understanding this distinction matters enormously for session architecture. Under the EBA's RTS, SCA is required at login to a payment account (with a 90-day re-authentication ceiling for account information services), at payment initiation and when accessing sensitive payment data for the first time.
The 90-day exemption for account information services means that after a compliant SCA event, a bank or authorized third-party provider can issue a long-lived session token that grants read access to account data without re-authenticating the user for up to 90 days. The token itself must be protected at rest and in transit. In practice this maps cleanly to a refresh token architecture where the SCA event issues both a short-lived access token and a long-lived refresh token, with the refresh token bound to the authenticated device via a FIDO2 assertion at issuance time.
Payment initiation resets this clock entirely. Each new payment instruction requires a fresh SCA event with dynamic linking. Banks must architect their token scopes so that a 90-day account information token cannot be escalated to a payment initiation token without a new authentication flow. This is a common mistake in open banking API gateway designs, where a single OAuth 2.0 token scope bundle conflates read access and write access into the same token lifetime.
For session invalidation, SCA-compliant implementations must revoke sessions on detected anomalies, on user-reported device loss and on any backend signal that the possession factor may be compromised. Because FIDO2 credentials are device-bound, credential revocation requires removing the stored public key from the server's authenticator registry, which immediately breaks the authentication loop for that device without affecting credentials on other registered devices.
European Bank Adoption in 2026
Adoption of FIDO2 across European payment service providers has accelerated since the EBA issued clarifying guidance on acceptable SCA methods. Several tier-one banks in Germany, France and the Netherlands have shipped full WebAuthn flows for both retail login and payment confirmation, replacing legacy SMS OTP entirely for customers using modern devices. The shift away from SMS OTP has been driven partly by SCA compliance pressure and partly by the documented vulnerabilities in SS7-based OTP delivery that have been the subject of ENISA advisories.
Smaller regional banks and credit unions face a different challenge. Legacy core banking systems often cannot generate challenge nonces in the format required for dynamic linking, and the middleware layer that would bridge the authenticator registration system to the transaction ledger represents significant engineering investment. For these institutions, hybrid approaches remain common: a FIDO2 platform authenticator handles login SCA while a separate hardware token or push notification OTP handles payment confirmation SCA with dynamic linking embedded in the notification payload.
Third-party providers operating under the PSD2 open banking access-to-account framework face a distinct compliance surface. They rely on the account-servicing payment service provider's SCA event for initial consent and must handle the re-authentication redirect gracefully when the 90-day window expires. The Berlin Group's NextGenPSD2 framework and the UK's Open Banking Implementation Entity specifications both provide reference patterns for this redirect flow, though implementation consistency across European banks remains uneven.
Implementation Gaps and Compliance Risks
The most common compliance gaps seen in SCA implementations involving FIDO2 fall into three categories.
The first is UV flag misconfiguration. As noted above, accepting WebAuthn assertions where UV=false passes user presence but not user verification. This satisfies the possession factor but provides no second independent factor from knowledge or inherence, making the entire authentication single-factor by PSD2 definition. Banks must set userVerification: "required" in the WebAuthn PublicKeyCredentialRequestOptions and must validate the UV flag server-side, not just rely on the client assertion.
The second is scope conflation in OAuth token issuance. Issuing tokens that bundle account information and payment initiation scopes under a single SCA event creates a compliance exposure if the token is later used for payment initiation beyond its intended scope. The correct pattern separates these into distinct authorization grants each backed by their own SCA event with appropriate dynamic linking for the payment case.
The third is inadequate documentation. National competent authorities under PSD2 require payment service providers to maintain documentation of their SCA implementation approach, including the methods used and how independence of factors is maintained. FIDO2 is not explicitly named in the EBA's RTS because the standard postdates the original regulation. Banks must therefore produce a reasoned mapping from their FIDO2 implementation to the EBA's factor categories and demonstrate that their dynamic linking mechanism satisfies the binding requirement. Absence of this documentation creates audit risk independent of whether the technical implementation is sound.
Engineering Checklist for SCA-Compliant FIDO2
The following checklist represents the minimum engineering verification points for a FIDO2 implementation targeting PSD2 SCA compliance. This reflects the clinical and technical review patterns applied by the BrightCloud.ai editorial team when evaluating open banking implementations.
- Registration flow enforces
authenticatorSelection.userVerification = "required"and rejects authenticators that cannot perform user verification. - Authentication flow enforces
userVerification: "required"in credential request options. - Server-side assertion validation explicitly checks the UV flag in authenticator data flags byte and rejects assertions where UV=false.
- Payment confirmation challenges are generated as a hash of canonical transaction data including amount, currency, beneficiary identifier and a server-issued nonce.
- The server recomputes the expected challenge from the pending transaction record and verifies that the signed challenge matches before marking the transaction as SCA-confirmed.
- OAuth scopes for account information and payment initiation are separated into distinct authorization grants with separate SCA events.
- Account information session tokens carry a maximum 90-day lifetime and cannot be upgraded to payment initiation scope without a fresh authentication event.
- Session revocation removes the public key from the authenticator registry, not just invalidates the session token.
- Compliance documentation maps each FIDO2 component explicitly to EBA factor categories and describes the dynamic linking mechanism for submission to the national competent authority.
- Re-authentication prompts trigger correctly on session expiry, on anomaly detection signals and on scope escalation attempts.
Further guidance on data ownership principles applicable to biometric credentials stored in banking authenticator registries is available at ownmydata.ai. Implementation patterns for open banking consent flows are documented at mydatakey.org.
The EBA's RTS and supporting opinions are primary sources for any SCA compliance analysis. The Berlin Group's NextGenPSD2 XS2A Framework and the FIDO Alliance's technical guidance on authenticator certification levels provide the technical substrate. NIST SP 800-63B remains relevant for factor strength analysis even in a European regulatory context. Engineers building these systems should read the primary standards rather than secondary summaries, because the compliance surface lives in the normative text.