Biometrics & Payer Awareness in Dynamic Linking

Corbado’s approach pairs phishing‑resistant passkeys (SCA) with a bank‑controlled display and server‑side dynamic linking to meet PSD2 RTS Art. 5 (“what‑you‑see‑is‑what‑you‑sign”).

• Core implementation (today): We display the transaction amount and payee in a Bison‑Bank‑controlled UI immediately before and during passkey authentication. Our backend generates a one‑time challenge that is bound to a canonicalized transaction snapshot (amount, payee, txnId). The response is accepted only if it matches that snapshot; any change invalidates it.

• Regulatory position: Dynamic linking remains required for remote payments even with passkeys (PSD2 Art. 97(2); RTS Art. 5). The RTS does not require the dynamic‑linking “authentication code” to be computed on‑device; server‑side generation/validation is acceptable when display integrity, specificity and invalidation on change are enforced (see also EBA Q&A 2020_5366 on where the code can be computed).

• Security & auditability: Binding a hardware‑anchored, phishing‑resistant passkey signature to specific transaction data prevents tampering and relay, and yields strong, non‑repudiable evidence of payer consent. Where supported, we can optionally adopt Secure Payment Confirmation (SPC) to add cryptographic proof of the displayed details without changing the backend model.

• SCA: Two independent elements from distinct categories (knowledge/possession/inherence), protected against disclosure/replication with appropriate mitigations (RTS Arts. 6–8). Independence is required (Art. 9), including separation when executed on multi‑purpose devices (e.g., OS‑level protections, secure hardware).
• Dynamic linking (RTS Art. 5):
  • (i) the payer is made aware of amount and payee during authentication
  • (ii) the authentication code is unique to that amount/payee
  • (iii) any change invalidates the code
  • (iv) confidentiality/integrity of amount, payee and code are protected end‑to‑end. This delivers the regulatory “what‑you‑see‑is‑what‑you‑sign” intent.
• Implication: Strong user authentication alone is insufficient for payments. The approval must be bound to specific transaction data with auditable evidence of the binding and the display to the payer (RTS Art. 5(1)(a–d)).

Clarification — phishing vs. authorization: Passkeys are origin‑bound, so fake domains cannot elicit valid signatures. However, PSD2 still requires dynamic linking for remote payments to bind authorization to the exact amount and payee to invalidate any change and to protect the integrity of what is displayed to the payer (RTS Art. 5(1)(a–d)). Dynamic linking addresses authorization integrity (including MITM/MITB/TPP substitution), not only phishing.

EBA 2019 Opinion (EBA‑Op‑2019‑06) reinforces that dynamic linking binds authentication to the amount and payee, requires independence of factors and accepts device‑bound cryptographic keys as possession where unique device binding exists. It also emphasises integrity of what is displayed to the payer during authentication. EBA Opinion 2019

Before PSD2, many banks relied on SMS OTPs or printed TAN lists that often did not show the amount or the payee alongside the approval step. That gap made it easier to trick customers into authorising unintended transfers once credentials were stolen. Dynamic linking was introduced to close that gap by ensuring the payer is made aware of the exact amount and payee at the time of authentication and by making the authentication code specific to those details so any change invalidates it (RTS Art. 5(1)(a–d)). Where SMS is part of the flow, issuers must also ensure the confidentiality, authenticity and integrity of the amount/payee and the code throughout all phases of authentication (Q&A 2018_4414; RTS Art. 5(2)). Today’s in‑app approvals (for example, “Do you want to authorise 100 USD to John Smith via Face ID?”) implement this “what you see is what you sign” principle in a customer‑friendly way.

Today, on mobile, two patterns dominate. First, a push notification can deep‑link the customer into the app to review the transaction details and approve. Supervisors have clarified that push can serve as evidence of the possession element if Article 7 controls are in place to mitigate unauthorised use and prevent replication, and the overall journey complies with the RTS; nonetheless, social‑engineering risks remain and should be addressed in UX (Q&A 2019_4984; RTS Art. 7).

Second, approvals using the device’s native biometrics (with a PIN fallback) perform user verification locally to unlock a private key operation. The private key lives in a secure hardware environment (Secure Enclave/TEE/TPM) and signs a challenge. This maps cleanly to SCA: inherence (biometric) plus possession evidenced by device binding and a device‑bound cryptographic key (EBA‑Op‑2019‑06, paras. 25, 35–37). For remote payments, the code must be dynamically linked to the amount and payee and those details must be displayed to the payer before user verification (RTS Art. 5). If both factors are on one device, implement separate secure execution environments and integrity checks so a compromise of one does not compromise the other (RTS Art. 9(2)–(3)).

Under the hood, local biometrics do not “authenticate to the bank” directly. Instead, the biometric (or PIN fallback) performs user verification on the device and gates access to a non‑exportable private key stored in a hardware‑backed security module. When the payer approves, the device uses that private key to produce a digital signature over a bank‑provided challenge. If the bank derives or associates that challenge with a canonical snapshot of the transaction (amount, payee, identifiers), then the resulting signature functions as an authentication code that is specific to those details. Any change will invalidate the code because the stored snapshot no longer matches, or, in enhanced designs, because the challenge derivation changes. The payer‑awareness part remains a UX requirement: show the amount and payee in a bank‑controlled view immediately before user verification. Together, this satisfies RTS Art. 5’s requirements on awareness, specificity/uniqueness and invalidation on change, while Article 7 controls and device binding evidence the possession element.

• Possession (device-bound & synced keys): Passkey private keys are stored in secure hardware (TEE/Secure Enclave/TPM). Device-bound passkeys are non-exportable, aligning with EBA expectations for unique device binding (EBA‑Op‑2019‑06, paras. 25, 35–37). Synced passkeys can also evidence possession on each authentication, provided device binding and anti‑replication controls are effective; regulators have emphasised the need for a reliable link between the element and the device (EBA‑Op‑2019‑06; RTS Art. 7).
• Inherence/knowledge (User Verification): User Verification via biometric (inherence) or device PIN (knowledge) activates the key locally. Combined with possession, this is true 2FA with factor independence. Breach of one does not compromise the other.

Dynamic linking is about binding the authentication to the transaction. The question for a bank is: if we let a user approve a payment via a passkey (rather than, say, an OTP or a signing device), can we guarantee that this approval is specific to the intended amount and payee, and can’t be reused or manipulated?

There are 2 options to implement dynamic linking with passkeys:

• Server-side linking (standard): Generate a one-time WebAuthn challenge that the backend associates with the exact amount and payee. The user sees “€X to Y” in a bank-controlled view and approves with a passkey. The response is accepted only for that transaction. Any change invalidates it.
• Cryptographic inclusion (enhanced): Embed a hash of the amount/payee into the challenge so the signature commits to the transaction data. This is not required by RTS but adds assurance that even backend swaps would fail verification.

Explicit compliance note: The RTS does not require the dynamic‑linking “authentication code” to be computed on the payer’s device. A PSP may generate and validate it on the server as long as the amount/payee are protected and any change invalidates the code (see EBA Q&A 2020_5366 on location/timing of the code). That is our server‑side dynamic linking (standard) approach.

Both yield a unique, non-reusable “authentication code” specific to the transaction. The primary caveat is payer awareness: WebAuthn itself doesn’t prove what was displayed. Integrity of the display must come from bank-controlled UI.

RTS Article 5 requires the payer to see the amount and payee during authentication. WebAuthn does not attest what was shown. In theory, if the app or OS is compromised, a user could be misled while the authenticator still signs. We'll analyze below in detail how this risk plays out in reality and why it's not a real security risk and more an interpretation of regulation issue.

Display‑integrity controls we enforce:

• Bank‑controlled view renders amount + payee: we block passkey invocation if the view is obscured or out of focus
• Overlay/tamper detection in app/web: no passkey prompts from hidden iframes
• Device integrity/attestation gating: deny or step‑up on rooted/jailbroken/compromised signals
• Atomic approval against a server‑held snapshot of amount/payee: a fresh challenge is required on any parameter change

About cryptographic inclusion: WebAuthn “transaction display” extensions (SPC) are not broadly supported today. Our portable baseline is server‑side binding, reinforced by deriving the challenge from the transaction snapshot (e.g., H(amount ‖ payee ‖ txnId ‖ nonce)) so the signature commits to those values.

Both patterns use public‑key cryptography with non‑exportable device keys, and both rely on local user verification to unlock the signing operation. In both, the bank ensures payer awareness by showing the amount and payee in a bank‑controlled view immediately before user verification, and ensures specificity by binding the authentication code to those details — invalidating it on any change (RTS Art. 5(1)(a–d)). The RTS is technology‑neutral and does not require the amount/payee to be rendered inside an OS biometric modal; it requires display to the payer and binding of the code (RTS Art. 5). When both SCA elements execute on one device, Article 9’s integrity and separation requirements apply equally (RTS Art. 9(2)–(3)). Finally, the location of the dynamic‑linking computation is flexible: it may be performed server‑side if integrity is preserved and any change invalidates the code (Q&A 2020_5366). These are the same conditions under which regulators already accept local biometrics with PKI — therefore, passkeys, implemented with the same payer‑awareness and binding controls, should be accepted on an equivalent basis.

So, do plain passkeys according to the WebAuthn standard fulfill the intent of dynamic linking? Partially:

• MITM/network attacks: Yes. Origin binding and per‑challenge signatures prevent tampering and replay.
• Transaction integrity: Yes. Server association or challenge‑hashing ensures only the original amount/payee will verify.
• Payer consent: Harder. Passkeys lack an authenticator‑level display. UI deception on compromised devices could be possible. There must be built something on top to guarantee payer consent

Why dynamic linking is still needed with passkeys

• Legal: PSD2 Art. 97(2) and RTS Art. 5 mandate dynamic linking for all remote payment initiation. There is no carve‑out for phishing‑resistant methods.
• Security: Passkeys remove cross‑origin phishing, but they do not by themselves evidence what was displayed to the payer. Dynamic linking + display‑integrity controls ensure that the specific amount/payee the user saw are what the bank executes, and that any change invalidates the approval.

In summary, passkeys can satisfy dynamic linking when strictly bound to transaction data and paired with trustworthy display mechanisms. The residual challenge is proving what the user actually saw.

Corbado offers a dynamic linking compliant solution that explicitly addresses the payer‑consent considerations above.

// TODO PROVIDE MOCKUPS FROM KARUNA AND DESCRIBE THEM

Process flow:

• Bank‑controlled display shows the payer the exact amount and payee. No passkey prompt is shown unless this view is visible.
• Authentication: the client invokes WebAuthn with a one‑time, bound challenge for the canonicalized transaction. The authenticator performs user verification (biometric or device PIN) and signs over the challenge and origin.
• Server verification: the backend verifies RP ID hash and origin, matches the challenge to the stored transaction, checks UV/flags, enforces one‑time use and expiry, and compares the stored amount/payee snapshot.
• Approval and audit: only then is the transaction atomically approved. Any mismatch/change is rejected and requires a fresh authentication. An immutable audit record is persisted (credential ID, authenticatorData, clientDataJSON, signature, challenge, and canonicalized amount/payee), optionally hash‑chained for tamper evidence.
• Device integrity gate: Evaluate device integrity and attestation signals: deny or step‑up if the device is rooted/jailbroken/compromised.
• Payee canonicalisation: Display a friendly label (e.g., “ACME GmbH”), but bind and verify against a canonical payee identifier (e.g., IBAN/BIC or other unique scheme).

Technical details:

• Backend: create a transaction object with canonicalized data (e.g., normalized currency/decimals; canonicalized IBAN/beneficiary). Generate a short‑lived challenge committing to these values (e.g., H(amount||payee||txnId||nonce)); store pending; expose only opaque IDs to the client.
• Client/authenticator: render the payer details in a bank‑controlled view; invoke WebAuthn (RP ID = Bison domain) only when visible; require user verification; authenticator signs challenge + origin per WebAuthn.
• Verification/finalization: validate signature, RP ID hash, origin/type, UV flags; anti‑replay/expiry; compare immutable amount/payee snapshot; approve atomically; persist the audit record.
• Derive the challenge from the snapshot:: challenge = H(amount ‖ canonicalPayee ‖ txnId ‖ nonce)

UX policies:

• Clear emphasis on amount/payee; accessible confirm/cancel controls; short timeouts; graceful retries always using a fresh challenge; immediate receipts (e.g., “You approved €X to Y”). Block the passkey prompt if the display is obscured and warn if parameters change prior to signing.
• Detect overlays/obscured content: never show a passkey prompt if the transaction view is not visible. Reject if parameters change mid‑flow and restart with a fresh challenge.

Compliance note: This end‑to‑end design meets RTS Art. 5: payer awareness (bank‑controlled display), specificity and uniqueness (one‑time code bound to amount/payee), invalidation on change (strict server checks), and confidentiality/integrity of amount/payee and the code throughout all phases (RTS Art. 5(1)(a–d), 5(2); see also Q&A 2018_4414 for SMS integrity). Factor independence (Arts. 7–9) is preserved via device‑bound possession and local user verification on multi‑purpose devices with appropriate protections (RTS Art. 9(2)–(3)).

Note:* for web flows, Corbado will optionally adopt [Secure Payment Confirmation](https://www.w3.org/TR/ payment-request-secure-payment-confirmation/) if/when Apple provides broad support, adding a trusted browser‑mediated display that cryptographically attests amount and payee.

Concern: Phishing attacks
Response: Passkeys are phishing‑resistant by design: they are bound to the legitimate origin and involve no shared secrets, so credentials cannot be harvested on a fake site, unlike OTPs. An attacker who proxies traffic to a look‑alike domain cannot obtain a valid signature for the bank’s origin. Dynamic linking contributes less in this vector, but remains mandatory to ensure any approval is unique to the intended amount and payee. Complementary measures (phishing education, clear separation of login vs payment approvals, anomaly/risk scoring for unusual payment contexts) further reduce exposure.

Concern: Social engineering / Authorized Push Payment (APP) fraud
Response: No authenticator can fully prevent a user from authorizing a payment under false pretenses (e.g., “safe account” scams). Dynamic linking ensures the user explicitly sees the payee and amount and provides strong evidence of consent, but it cannot override a convinced payer. Compensations include contextual warnings (new payee, first large transfer), cooling‑off periods or delayed execution for high‑risk payees, stronger payee verification, and step‑up checks (extra confirmation) on risk signals. Post‑payment notifications and rapid dispute channels help detect and contain harm. We add real‑time contextual warnings (e.g., new payee, first large transfer), cooling‑off periods for high‑risk payees, stronger payee verification and post‑payment notifications (“You approved €X to Y”) to speed detection and response.

Concern: Malware or device compromise
Response: Private keys are non‑exportable and require local user verification for each signature, so malware cannot simply exfiltrate credentials. The realistic risk is UI deception on a fully compromised OS. Mitigate with secure/verified UI (e.g., protected confirmations), device integrity checks/attestation and blocking high‑risk devices, and trusted confirmations such as SPC or a confirmation extension when available. If compromise indicators appear (overlay detection, root/jailbreak), use out‑of‑band re‑verification or deny execution. No consumer method is perfect on a fully owned device, but these controls narrow the window dramatically.

Concern: Man‑in‑the‑browser / session hijacking
Response: Malicious extensions or injected scripts can initiate actions on the legitimate origin. Origin‑bound passkeys stop cross‑site phishing. Dynamic linking ensures behind‑the‑scenes edits to amount/payee fail. We harden the channel via CSP/anti‑tamper controls and by requiring a fresh, one‑time challenge for each confirmation.

Concern: Insider threat or server‑side tampering
Response: The authentication response is uniquely tied to the original amount/payee, so any server‑side substitution fails validation. Maintain tamper‑evident, immutable linkage records (challenge, credential, signature, and canonicalized amount/payee) for audit/non‑repudiation. Apply separation of duties and four‑eyes controls on critical payment processing paths to reduce insider risk.

Concern: Stolen devices / credential theft
Response: Mere device possession is insufficient: user verification (biometric/PIN) is required for each signature, with OS‑level rate limits and lockouts. Each payment requires a fresh, transaction‑specific challenge; generic session tokens cannot authorize arbitrary payments. Additions like remote device revocation, step‑up on new device use, geovelocity checks, and notifications (“You authorized €X to Y”) further constrain abuse.

Overall: passkeys materially reduce phishing and replay risks; dynamic linking remains essential to guarantee transaction integrity, bind approvals to amount/payee, and provide strong evidence of informed consent across the remaining threat scenarios.

Question 1: How can we prove that the user actually saw and agreed to the amount and payee when using a passkey?
Response: We enforce payer display in a bank‑controlled view and tie approval to a server‑side snapshot of amount/payee. The passkey assertion (authenticatorData, clientDataJSON, signature) is accepted only for the challenge derived from that snapshot; any change requires a new challenge. Our tamper‑evident audit links the assertion to “€X to Payee‑ID Y” and records that our system would not proceed if details differed. Where supported, SPC adds cryptographic evidence that the user confirmed the displayed details.

Question 1: How can we prove that the user actually saw and agreed to the amount and payee when using a passkey? Response: This is essentially the non-repudiation question. Under PSD2, dynamic linking was intended to ensure the user is aware of what they’re approving. With a passkey, the evidence we retain is the cryptographic signature (authentication code) and associated data (which amount/payee it was tied to on our server). By policy, we display the transaction details to the user in the app or web page before they authenticate. We log that screen/view and the subsequent successful passkey authentication for that specific transaction. In case of dispute, we can show that the user’s device produced a valid signature for a challenge that was associated with (e.g.) “€100 to ACME Corp.” and that our system would not have proceeded if any detail was different. Our compliance relies on secure logging: we ensure our systems are tamper-proof in linking the passkey response to the transaction data.

Question 2: What if the device or OS is compromised? Can malware manipulate the transaction or the passkey process? Response: Device compromise is a critical threat in any digital banking scenario. If the operating system is malicious, it could attempt to mislead the user or hijack processes. However, even in this worst case, passkeys maintain some key protections. The private key cannot be extracted by malware. Malware also cannot impersonate the user to the bank, because it can’t produce the passkey signature without the user’s biometric/PIN. The most it could do is push the user to authenticate something under false pretenses. Dynamic linking helps here by requiring integrity checks: the malware cannot silently change the transaction details after the fact – if it does, the signature won’t verify. The weakest point is the display/UI: a sophisticated Trojan might alter what the user sees (e.g., display “ACME Corp” while the underlying transaction is actually going to another payee). This is not trivial, especially if the bank app uses secure UI frameworks, but it’s conceivable. All that said, if we detect signs of device compromise (unusual behavior, known malware signatures, etc.), we would fall back to out-of-band verification or deny the transaction. In summary: No solution is 100% if the user’s device is fully owned by an attacker. Passkeys + dynamic linking dramatically reduce attack surface (an attacker can’t just proxy credentials or alter network data; they would have to run a con on the user in real-time). Should the OS be compromised, dynamic linking at least ensures any mismatch between what should be and what is approved gets caught by our backend.

Question 3: If a biometric is used to unlock the passkey, is that considered one factor or two? Are we complying with the 2-factor rule? Response: A biometric alone is not sufficient for SCA – it’s just one inherence factor. However, in a passkey implementation the biometric is not alone: possession of the device is the other factor. The user’s biometric unlocks the private key stored on the device. Possession and inherence are two distinct categories. This is analogous to how many banking apps already satisfy SCA: you have the phone (possession) and you use your fingerprint or face to unlock the app (inherence). The EBA has explicitly recognized combinations of device-binding plus biometric as compliant SCA. The passkey scenario is exactly that combination. If the user opts to use a PIN instead of biometric to unlock the passkey, then it’s possession + knowledge, also compliant. We enforce user verification on all passkey operations (meaning the user must provide biometric/PIN each time), so there’s no situation where just having the device suffices. Thus, every payment authorization via passkey is a two-factor event under PSD2 definitions.

Question 4: Could an attacker reuse a passkey authentication or somehow bypass dynamic linking by manipulating data in transit? Response: No. This is where passkeys and dynamic linking work together strongly. Every WebAuthn authentication yields a unique signature that’s tied to the challenge (which we generate per transaction) and is scoped to our domain. An attacker cannot replay that signature for a different transaction. The signature itself incorporates the challenge nonce and is only valid for what it was originally issued for. If an attacker intercepted the network communication, they couldn’t alter the amount or payee without invalidating the signature (since the challenge or transaction context would no longer match). This is effectively the MITM protection we discussed. Also, passkey signatures include origin data – they won’t verify if not sent to our exact website/app origin, so phishing or redirecting won’t work. In short, any manipulation attempt invalidates the authentication code, per the dynamic linking rules. This is actually more secure than some current OTP-based flows, where users sometimes approve a generic code and there’s a risk the request was tampered. With passkeys, we cryptographically bind user authentication to the specific session/transaction.

Question 5: Are there any known regulatory opinions on WebAuthn/passkeys for SCA? Are we sure regulators will accept passkeys as compliant? Response: As of now, the EBA has not explicitly published opinions on WebAuthn or the term “passkeys” in their Q&A or guidance. However, based on the principles they’ve laid out, passkeys clearly fit within the acceptable methods. EBA’s 2019 opinion essentially anticipated FIDO2-like approaches: for possession, they explicitly mention “exchange of public/private keys” with proper device binding as evidence of possession. A WebAuthn passkey is exactly that – a public/private key pair, with the private half securely bound to the device. They also gave a nod to “signature generated by a device” as a valid possession proof. So while they didn’t use the term passkey, the method is covered by their examples. We have also observed that major payments players in Europe are moving ahead with passkey implementations (e.g. PayPal) which indicates a level of confidence that this is PSD2-compliant. This example demonstrates that passkeys are being accepted as part of compliant SCA flows, provided dynamic linking and overall requirements are met.

Question 6: Do we still need dynamic linking if passkeys are phishing‑resistant?
Response: Yes. Passkeys eliminate cross‑origin phishing, but PSD2 still mandates dynamic linking for remote payment initiation. Dynamic linking binds the specific amount and payee to the SCA result and invalidates any change, addressing authorisation integrity beyond phishing (e.g., MITM/MITB/TPP substitution).

Corbado’s solution is Dynamic Linking and PSD2‑compliant. The pre‑auth payer display, one‑time challenge bound to amount and payee, strict server verification, and immutable audit together satisfy RTS Art. 5 requirements on payer awareness, uniqueness/specificity, invalidation on change, and integrity/confidentiality. Factor independence is preserved through device‑bound possession and UV (biometric or PIN), aligning with EBA guidance.

Relative to today’s OTP/SMS methods, Corbado delivers materially better security and user outcomes: resistance to phishing and relay, prevention of silent parameter tampering, stronger non‑repudiable evidence, and reduced friction through on‑device UV. Residual risks (e.g., social engineering, compromised devices) are mitigated with concrete controls and are narrower than with legacy methods. For web, Corbado can adopt SPC when platform support (notably Apple) is broad, adding cryptographic proof of display without changing the core compliance posture.

In short, Corbado’s passkey‑based transaction authorization meets the letter and spirit of PSD2 dynamic linking and improves fraud resilience and auditability compared to legacy approaches, while maintaining a clear path to future enhancements (SPC) as the ecosystem matures.

In practice, passkeys satisfy dynamic linking when we do three things: we display the amount and payee to the payer before user verification; we generate an authentication code that is specific to those exact details; and we invalidate the code on any change (RTS Art. 5(1)(a–d)). This mirrors the principles that regulators already accept for local biometrics, with the added convenience that passkeys are OS‑native and work across web and app channels without an extra app. Combined with origin binding, they do not surface spoofed requests — only legitimate prompts from the original site or app appear to the user.