PSD2 Strong Customer Authentication has been live across the European Economic Area since 2021, yet authentication engineers still routinely build flows that fail a compliance audit. The reason is almost always the same: the team understood the two-factor requirement but ignored dynamic linking, or they adopted FIDO2 passwordless flows without mapping authenticator outputs to the specific transaction data the EBA demands. In 2026, with FIDO2 and WebAuthn reaching genuine mainstream adoption in European retail banking, the gap between "we use biometrics" and "we satisfy SCA" is narrowing but has not closed. This article maps exactly where those gaps remain and how engineering teams can close them.
What PSD2 SCA Actually Requires
PSD2 defines Strong Customer Authentication under Article 4(30) of the directive and elaborates the technical requirements in the EBA Regulatory Technical Standards on SCA and Common and Secure Communication, commonly called the SCA RTS. The standard requires authentication using two or more elements drawn from three categories: something the user knows (a PIN or password), something the user has (a registered device or hardware token) and something the user is (a biometric).
These elements must be independent. Compromise of one must not undermine the others. For engineers, independence is not just a policy claim. It has structural implications for how credentials are stored, how the authenticator communicates with the relying party and how the session token is derived.
SCA also carries a freshness requirement. Authentication must be performed when a user initiates a payment or accesses account data for the first time in a session. The EBA allows a 90-day re-authentication grace period for account information services under specific conditions, but for payment initiation the requirement fires on every transaction above exemption thresholds.
The three statutory exemptions most relevant to retail banking are the low-value transaction exemption (transactions under 30 EUR, capped at 100 EUR cumulative or five consecutive transactions), the low-fraud-rate TRA exemption and the trusted beneficiary exemption. Each exemption has a specific monitoring obligation that feeds back into the fraud detection infrastructure. Engineers who treat exemptions as pure UX shortcuts without building the required fraud telemetry create compliance exposure at the next supervisory review.
FIDO2 and WebAuthn Architecture in Banking Contexts
FIDO2 is the umbrella specification combining the W3C Web Authentication API (WebAuthn) with the FIDO Alliance Client to Authenticator Protocol (CTAP2). WebAuthn handles the browser-to-relying-party layer. CTAP2 handles the browser-to-authenticator layer, covering both platform authenticators (device biometrics like Face ID or Windows Hello) and roaming authenticators (hardware security keys such as YubiKey or FIDO-certified smart cards).
From an SCA perspective, a FIDO2 platform authenticator flow natively satisfies two of the three element categories. Device possession satisfies "something the user has." The biometric unlock of the authenticator satisfies "something the user is." The FIDO2 credential itself is a hardware-bound asymmetric key pair where the private key never leaves the authenticator's secure enclave. This architectural property directly addresses the EBA's independence requirement.
The WebAuthn assertion is a cryptographic signature over a challenge issued by the relying party. That challenge binding is the mechanism that connects authentication to a specific session, which becomes critical when addressing dynamic linking.
Platform authenticators backed by Trusted Execution Environments (TEEs) or Secure Elements provide the strongest independence guarantees. Engineers integrating FIDO2 in a banking context should confirm authenticator certification level. FIDO Alliance certification levels run from L1 (software-only) through L3 (hardware-secured with independent penetration testing). For payment initiation flows, L2 or L3 certification is the defensible position in a supervisory conversation. FIDO Alliance maintains a publicly searchable metadata service (MDS) at fidoalliance.org where relying parties can verify authenticator AAGUID metadata at registration time.
The Dynamic Linking Requirement: Where Most Implementations Fail
Dynamic linking is specified in Article 5 of the SCA RTS. It requires that for payment transactions, the authentication code be specifically linked to the amount and payee of that transaction. If either changes after authentication, the code must be invalidated and re-authentication required.
This is the requirement that breaks the most FIDO2 implementations. The default WebAuthn assertion signs over a relying party-issued challenge and the origin. It does not sign over application-layer transaction data unless the relying party explicitly encodes that data into the challenge or uses the clientDataJSON extension mechanism.
There are two patterns for achieving dynamic linking with FIDO2. The first is challenge injection. The relying party constructs the WebAuthn challenge by hashing or structuring it to include the transaction amount and payee identifier. The authenticator signs over this challenge as part of the normal assertion flow. The server verifies the signature and decodes the embedded transaction data from the challenge before committing the payment. This approach is transparent to the authenticator and works with any compliant FIDO2 device.
The second pattern uses the transaction confirmation extension defined in the FIDO2 specification. The txAuthSimple and txAuthGeneric extensions allow the relying party to request that the authenticator display a transaction description to the user before generating the assertion. When the user confirms, that confirmation is bound into the authenticator's signature. This provides a stronger assurance model because user intent is captured at the authenticator layer, not just the application layer. Not all platform authenticators support these extensions in 2026, so relying parties must check AAGUID capability metadata before relying on this path.
Engineers must also handle the mismatch attack surface. If a man-in-the-browser attack modifies transaction data in the page DOM after the challenge is generated but before signing, the server must detect the discrepancy. The canonical defense is generating the challenge server-side from the transaction record stored in the server's session state, then re-validating that the signed challenge matches the stored transaction at the point of payment dispatch. Never derive the transaction from what the client sends back after signing.
Mapping Passwordless Authentication Flows to SCA Compliance
Passwordless flows in banking usually fall into one of three models: platform biometric only, platform biometric plus device PIN as fallback and hardware key with biometric on-key. Each maps differently to SCA element categories and each has different fallback failure modes that engineers need to address explicitly.
A platform biometric-only flow uses one authenticator device but captures two elements simultaneously. The possession element is the device with the bound private key. The inherence element is the biometric match. The EBA accepted this combination in its 2019 Opinion on SCA elements, and it remains valid under current RTS guidance. The risk is that device theft paired with a coerced or spoofed biometric collapses both factors simultaneously. Supervisory reviewers increasingly ask about anti-spoofing certification for biometric components, particularly for high-value payment corridors.
A platform biometric with PIN fallback maintains the two-element requirement even when the biometric path fails, since the PIN becomes the knowledge element. Engineering teams should configure fallback handling carefully. Unlimited PIN retries with no account lockout convert the PIN into a single factor in practice, which the EBA's October 2022 Q&A clarified as non-compliant regardless of the initial authentication method.
Hardware keys with on-key biometrics (such as biometric-enabled FIDO2 keys from Feitian or Yubico's Bio Series) represent the strongest posture. The possession element is the physical key. The inherence element is the on-device biometric match. The private key never leaves the hardware. For corporate banking portals or high-value wealth management applications, this architecture provides a clean compliance story and a reduced attack surface against remote credential theft.
Session Management Patterns for SCA-Compliant Applications
Session management is where SCA compliance degrades in production systems. A compliant authentication event at login does not satisfy SCA for payment initiation unless the session architecture correctly threads the authentication binding through to the point of transaction dispatch.
The most common failure mode is session token reuse. A user authenticates with FIDO2 at login. The application issues a session token. An hour later, the user initiates a payment. The application dispatches the payment using the existing session token without triggering re-authentication. This fails SCA for payment initiation regardless of how strong the initial login was.
The correct pattern is step-up authentication. The session maintains a record of authentication events, each with a timestamp, the authentication method used and the transaction scope if applicable. When a payment initiation request arrives, the session middleware evaluates whether a valid SCA event exists for that specific transaction. If not, it triggers a FIDO2 assertion flow scoped to the transaction, verifies dynamic linking and only then dispatches.
For open banking TPP flows using OAuth 2.0 authorization codes with PKCE, the dynamic linking requirement maps to the payment consent object. The consent object must capture the transaction amount and payee before the authorization code is issued. The FIDO2 assertion must be bound to the consent object identifier. Banks operating UK Open Banking or Berlin Group NextGenPSD2 APIs can model this using the payment consent ID as part of the challenge construction in the assertion flow.
Refresh token handling needs explicit scoping. A refresh token issued after SCA-authenticated payment consent must be scoped to that consent object and must not be reusable for initiating new payments without a fresh SCA event. OAuth 2.0 Rich Authorization Requests (RAR), specified in RFC 9396, provide the authorization_details mechanism that lets the authorization server encode payment-specific constraints into the token grant. This is the current best-practice architecture for PSD2-compliant open banking API token management.
Regulatory Friction Points and EBA Guidance in 2026
The EBA's supervisory convergence work through 2025 and into 2026 has produced a clearer picture of where National Competent Authorities are focusing SCA enforcement. Three areas dominate the findings from supervisory review cycles across the EBA's Single Rulebook Q&A process.
First, exemption monitoring gaps. Banks applying the TRA exemption are required to monitor fraud rates against the reference fraud rates in the RTS and suspend the exemption when thresholds are breached. Supervisors have found that fraud telemetry pipelines feeding exemption eligibility decisions often have data latency that allows non-compliant exemption use for hours or days after the threshold breach. Real-time or near-real-time fraud rate monitoring with automatic exemption suspension is now an expectation, not a best practice.
Second, mobile banking app channel inconsistency. Several NCAs have cited banks for applying SCA correctly in web browser flows while their native mobile apps route payments through backend paths that bypass the session-level SCA check. The mobile SDK integration of FIDO2 via platform authenticators (Android Credential Manager API, Apple's ASAuthorizationController) must feed the same session validation middleware as the web channel.
Third, biometric fallback configuration. As noted above, unlimited PIN fallback retries remain a live finding. The technical control is straightforward: implement progressive lockout with account hold after a defined number of consecutive failures, consistent with the account security policy used for the primary authentication path.
Engineering Checklist for FIDO2-Based SCA
Based on the compliance architecture described across this article, the following items represent the minimum engineering verification points for a FIDO2-based SCA implementation targeting PSD2 compliance.
- Verify authenticator AAGUID against FIDO MDS at registration. Reject authenticators below the minimum certification level defined in your payment security policy.
- Construct WebAuthn challenges server-side using a hash of the stored transaction record (amount and payee). Never derive transaction data from client-supplied post-authentication payloads.
- Validate that the signed challenge decodes to the transaction record in the server's session state before dispatching payment.
- Implement step-up authentication triggers in session middleware. SCA events must be scoped to specific transactions for payment initiation flows.
- Scope OAuth 2.0 refresh tokens to payment consent objects using RAR authorization_details. Prevent cross-consent token reuse.
- Configure biometric fallback PIN lockout with progressive delay and account hold after defined failure counts.
- Align mobile SDK FIDO2 flows (Android Credential Manager, iOS ASAuthorizationController) with the server-side session validation pipeline used by web channels.
- Monitor TRA exemption fraud rates with latency below your exemption suspension SLA. Automate suspension when rates breach RTS reference thresholds.
- Log all authentication events with method, timestamp and transaction scope for supervisory audit readiness.
PSD2 SCA compliance in a FIDO2 architecture is achievable and produces a better user experience than legacy OTP-based flows. The engineering lift is concentrated in dynamic linking implementation and session middleware, not in the authenticator integration itself. Teams at Own Your Data Inc. working on open banking infrastructure can cross-reference consent-scoped token patterns at mydatakey.org for production implementation guidance. The EBA's Single Rulebook Q&A at eba.europa.eu remains the authoritative source for compliance interpretation questions.