---
url: 'https://www.corbado.com/blog/biometrics-payer-awareness'
title: 'Biometrics & Payer Awareness in Dynamic Linking'
description: 'Biometrics payer awareness under PSD2 dynamic linking: how local biometrics + PKI and passkeys meet compliance, with EBA/RTS guidance and best practices.'
lang: 'en'
author: 'Vincent Delitz'
date: '2025-09-04T19:53:07.297Z'
lastModified: '2026-03-27T07:01:46.852Z'
keywords: 'biometrics payer awareness'
category: 'Passkeys Strategy'
---

# Biometrics & Payer Awareness in Dynamic Linking

## Executive Summary: Biometrics & Payer Awareness in Dynamic Linking

Corbado’s approach pairs [phishing](https://www.corbado.com/glossary/phishing)‑resistant passkeys (SCA) with a
bank‑controlled display and server‑side
[dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) to meet
[PSD2 RTS](https://www.corbado.com/faq/sca-rts-technical-standards) Art. 5 (“what‑you‑see‑is‑what‑you‑sign”).

- **Core implementation (today):** We display the transaction **amount and payee** in a
  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](https://www.corbado.com/passkeys-for-payment) 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.

> **Clarifier:** Passkeys eliminate cross‑origin [phishing](https://www.corbado.com/glossary/phishing) (they only
> work on the site/app they were created for). **Dynamic linking** ensures that **exactly
> what the payer approved** (amount + payee) is what the bank executes.

## 1. PSD2 SCA & dynamic linking

- **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](https://www.corbado.com/passkeys-for-payment). 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](https://www.corbado.com/blog/psd2-passkeys) still requires
**dynamic linking** for remote [payments](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) addresses authorization integrity
(including MITM/MITB/TPP substitution), not only [phishing](https://www.corbado.com/glossary/phishing).

### 1.1 Theory background — legal text and guidance

> [PSD2](https://www.corbado.com/blog/psd2-passkeys) Article 97(2): “With regard to the initiation of electronic
> [payment](https://www.corbado.com/passkeys-for-payment) transactions, Member States shall ensure that the payer
> has access to the [strong customer authentication](https://www.corbado.com/faq/sca-psd2-importance) procedures
> which include elements dynamically linking the transaction to a specific amount and a
> specific payee.”
> [PSD2 Art. 97(2)](https://eur-lex.europa.eu/eli/dir/2015/2366/2015-12-23)

> RTS Article 5: “[Payment](https://www.corbado.com/passkeys-for-payment) service providers shall ensure that the
> authentication code generated is specific to the amount of the
> [payment](https://www.corbado.com/passkeys-for-payment) transaction and the payee agreed to by the payer when
> initiating the transaction; the payer is made aware of the amount of the payment
> transaction and of the payee to which the authentication is given; the authentication
> code accepted by the
> [payment service provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) corresponds
> to the original amount of the payment transaction and the identity of the payee agreed
> to by the payer when initiating the transaction; any change to the amount or the payee
> shall result in the invalidation of the authentication code; the confidentiality,
> authenticity and integrity of the amount and of the payee are protected.”
> [RTS Art. 5](https://eur-lex.europa.eu/eli/reg_del/2018/389/2023-09-12)

EBA 2019 Opinion (EBA‑Op‑2019‑06) reinforces that
[dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) 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](https://www.eba.europa.eu)

### 1.2 History of dynamic linking

![history dynamic linking](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/history_dynamic_linking_3c121b5d88.png)

Before [PSD2](https://www.corbado.com/blog/psd2-passkeys), 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](https://www.corbado.com/glossary/issuer) 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](https://www.corbado.com/faq/is-face-id-passkey)?”) implement this “what you see is what you sign”
principle in a customer‑friendly way.

### 1.3 Dynamic linking today: app push and local biometrics

![dynamic linking push notification](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_push_notification_f11e26ca47.png)

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).

![dynamic linking local biometrics](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/dynamic_linking_local_biometrics_36dbc6eff7.png)

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](https://www.corbado.com/blog/webauthn-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)).

### 1.4 How local biometrics with PKI implement dynamic linking

Under the hood, [local biometrics](https://www.corbado.com/blog/passkeys-local-biometrics) do not “authenticate
to the bank” directly. Instead, the biometric (or PIN fallback) performs
[user verification](https://www.corbado.com/blog/webauthn-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.

![biometrics dynamic linking](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/biometrics_dynamic_linking_4ee6cf3e76.png)

## 2. Why passkeys are SCA‑compliant (device‑bound and synced)

- **Possession (device-bound & synced keys)**: Passkey private keys are stored in secure
  hardware (TEE/[Secure Enclave](https://www.corbado.com/glossary/secure-enclave)/TPM).
  [Device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) 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](https://www.corbado.com/blog/webauthn-user-verification) via biometric (inherence) or
  device PIN (knowledge) activates the key locally. Combined with possession, this is true
  [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security) with factor independence. Breach of one does not
  compromise the other.

## 3. Do Passkeys satisfy dynamic linking requirements?

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](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) 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.

### 3.1 Payer Awareness Consideration

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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/iframe-passkeys-webauthn)
- **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.

### 3.2 Regulatory equivalence: local biometrics with PKI and passkeys

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](https://www.corbado.com/blog/passkeys-local-biometrics) with PKI — therefore, passkeys,
implemented with the same payer‑awareness and binding controls, should be accepted on an
equivalent basis.

### 3.3 Passkeys and the intent of dynamic linking

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](https://www.corbado.com/glossary/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.

## 4. How Corbado implements dynamic linking with passkeys

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

### 4.1 End‑to‑end solution: flow, tech, UX and compliance

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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/clientdatajson), signature, challenge, and canonicalized
  amount/payee), optionally hash‑chained for tamper evidence.
- **Device integrity gate:** Evaluate device integrity and
  [attestation](https://www.corbado.com/glossary/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 = bank domain) only when visible; require user verification;
  authenticator signs challenge + origin per
  [WebAuthn](https://www.w3.org/TR/webauthn-3/).
- **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.corbado.com/blog/dynamic-linking-passkeys-spc)]\([https://www.w3.org/TR/](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.

## 5. Residual risks & compensating controls

**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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/attestation) and blocking high‑risk devices, and trusted
confirmations such as [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-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.

## 6. Compliance FAQ

**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](https://www.corbado.com/glossary/assertion)
(authenticatorData, [clientDataJSON](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/malware)
manipulate the transaction or the passkey process? **Response:** Device compromise is a
critical threat in any digital [banking](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/glossary/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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/paypal-passkeys)) which indicates a level of confidence that this is
[PSD2-compliant](https://www.corbado.com/blog/psd2-passkeys). 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).

## 7. Conclusion: dynamic linking compliance and improved outcomes

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](https://www.corbado.com/blog/dynamic-linking-passkeys-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.

## Frequently Asked Questions

### How does the payer awareness requirement in RTS Art. 5 apply when biometrics are used to approve a payment?

RTS Art. 5(1)(a) requires the payer to see the amount and payee during authentication.
When biometrics unlock a passkey, the bank must display those details in a bank-controlled
view before invoking user verification. WebAuthn does not attest what was shown, so
display integrity must be enforced at the application layer through overlay detection and
tamper controls.

### What compensating controls does a bank need when WebAuthn cannot cryptographically prove what transaction details were shown to the payer?

Banks must enforce display integrity through a bank-controlled UI that blocks the passkey
prompt if the transaction view is obscured, overlay and tamper detection to prevent hidden
[iframes](https://www.corbado.com/blog/iframe-passkeys-webauthn), device integrity checks to deny rooted or
jailbroken devices and an immutable audit record linking the passkey
[assertion](https://www.corbado.com/glossary/assertion) to the canonicalized amount and payee snapshot.

### What is the difference between server-side dynamic linking and Secure Payment Confirmation for passkey-based payments?

Server-side dynamic linking binds a one-time WebAuthn challenge to a canonicalized
transaction snapshot on the backend, accepting the response only if it matches.
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) adds cryptographic proof
that the browser displayed the specific amount and payee, but lacks broad platform support
today, particularly from Apple.

### Why does PSD2 dynamic linking still apply to passkey payments even though passkeys prevent phishing?

Passkeys are origin-bound and block cross-site phishing, but PSD2 Art. 97(2) and RTS Art.
5 mandate dynamic linking for all remote payment initiation with no carve-out for
phishing-resistant methods. Dynamic linking addresses authorization integrity beyond
phishing, including man-in-the-browser attacks and third-party payment processor
substitution, ensuring the approved amount and payee cannot be silently changed.

### What additional compliance requirements apply when both SCA factors execute on the same mobile device under RTS Art. 9?

RTS Art. 9(2)-(3) requires separate secure execution environments and integrity checks so
a compromise of one factor does not compromise the other. On mobile, this means relying on
OS-level protections such as the [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) or TEE for key
storage, combined with device integrity gating to deny or step up authentication when
rooted or jailbroken signals are detected.