How Dynamic Linking Works
Dynamic linking transforms a generic authentication event into a transaction-specific cryptographic proof. The process is defined in Article 5 of the EBA's Regulatory Technical Standards under PSD2, and every payment service provider in scope must implement it for remote customer-initiated payments. Understanding each step helps merchants and developers diagnose why an authentication fails when transaction data is modified at any point in the flow.
Transaction details assembled
The payment initiator captures two mandatory binding inputs: the payee identifier (merchant name, MID, or beneficiary IBAN) and the exact transaction amount in the payer's account currency. These fields are the required cryptographic inputs under EBA RTS Article 5(2) and must remain unchanged through the entire authentication lifecycle.
Details displayed to the payer
The payer's authentication interface—issuer app, browser challenge screen, or open banking consent page—presents the payee and amount clearly before the payer takes any authentication action. This display step is a legal requirement independent of the cryptographic one: the payer must consciously approve a specific transaction, not a generic login event.
Cryptographic code generated
The authentication mechanism derives the authentication code using a one-way function that takes the payee identifier and amount as mandatory inputs alongside the authentication factors. The resulting code is mathematically unique to those exact values—changing either input by a single character or cent produces a completely different code.
Code transmitted with the payment request
The authentication code travels to the card issuer or ASPSP alongside the payment authorisation message. Because the code encodes the transaction details, any man-in-the-middle who modifies the payee or amount in transit produces a detectable mismatch at the receiving end. The attacker cannot forge a valid code without access to the payer's authentication credentials and the original inputs.
Issuer validates the binding
The issuer recomputes the expected authentication code using its own record of the payee and amount from the authorisation request. If the code the payer generated matches, the transaction is authorised and liability shift applies. A mismatch triggers an immediate decline or a step-up challenge. For card payments, this validation result is returned as part of the 3D Secure authentication response.
Why Dynamic Linking Matters
Static authentication codes—one-time passwords that verify a user's identity but carry no transaction context—were the primary vector for real-time transaction manipulation fraud in Europe before PSD2 enforcement. An attacker could trick a payer into approving what appeared to be a legitimate login or small payment, then relay that code to authorise a completely different, high-value transaction. Dynamic linking was introduced specifically to eliminate this attack surface at a regulatory level.
The scale of the problem justifies the mandate. The European Central Bank's Seventh Report on Card Fraud found that card-not-present fraud in EU member states reached €1.8 billion in 2019, with social engineering and transaction manipulation attacks representing a disproportionate share of losses in markets with low SCA adoption. Following the completion of mandatory SCA enforcement in 2021, multiple national competent authorities reported year-over-year CNP fraud reductions exceeding 50% in markets with high issuer compliance rates. Research from Javelin Strategy & Research corroborated this pattern, finding that SCA-compliant authentication flows incorporating dynamic linking reduce account-takeover payment conversion rates by approximately 80% compared to static-OTP flows.
Regulatory scope
Dynamic linking applies to all customer-initiated remote electronic payments subject to SCA under PSD2. Transactions covered by approved exemptions—low-value (≤€30), trusted beneficiary, or low-risk transaction analysis—are excluded from the SCA requirement. However, if an issuer soft-declines an exempted transaction and requests SCA, the retry must include full dynamic linking.
Beyond fraud reduction, dynamic linking carries direct commercial weight through liability shift. An issuer that authorises a dynamically linked transaction bearing a valid authentication code shifts chargeback liability away from itself toward the payer's device or, in certain scenarios, the merchant. This makes issuer enforcement rigorous rather than optional.
Dynamic Linking vs. Static Authentication
Strong Customer Authentication can be technically satisfied with or without dynamic linking, but only the former is PSD2-compliant for remote payments. The table below contrasts the two approaches to show why meeting the two-factor bar is necessary but not sufficient.
| Dimension | Dynamic Linking | Static Authentication |
|---|---|---|
| Code bound to transaction | Yes — payee + amount encoded | No — user identity only |
| Replayable by attacker | No — code invalid for any other transaction | Yes — valid for any transaction |
| Man-in-the-middle protection | Strong | None |
| PSD2 compliant for remote payments | Yes | No (as sole method) |
| Liability shift on fraud | Yes, when correctly implemented | No |
| UX impact | Minimal with in-app push | Moderate — OTP entry required |
| Implementation complexity | High — issuer auth logic must change | Low |
| Primary technical standard | EMV 3DS 2.x, open banking FAPI | TOTP (RFC 6238), SMS OTP |
A bank can enforce two-factor authentication using biometric plus PIN and still be non-compliant if neither factor produces a code bound to the specific transaction. Regulators and auditors explicitly test for binding, not just factor count.
Types of Dynamic Linking
Dynamic linking is a required property of the authentication output, not a specific product or protocol. Several technical approaches achieve it, each with different trade-offs for issuers, merchants, and developers.
In-app push with transaction display is the most prevalent consumer-facing implementation. The issuer's mobile banking app receives a push notification showing the payee name and amount. When the payer approves using biometrics or PIN, the app signs the transaction details with a private key stored in the device's secure enclave. The resulting signature is the dynamically linked authentication code transmitted back to the issuer for verification.
EMV 3DS challenge flow is the dominant mechanism for e-commerce. During a 3DS2 challenge, the issuer's Access Control Server (ACS) generates a CAVV cryptographically tied to the authorisation request fields including amount and merchant ID. The CAVV travels in the auth message and is validated by the issuer host. Merchants receive an ECI code indicating the authentication method used.
Open banking strong authentication applies to Payment Initiation Services under PSD2. ASPSPs expose SCA challenges through their open banking APIs, and TPPs must relay the correct beneficiary IBAN and amount for binding. The EBA's FAPI profile for open banking mandates request object signing that achieves dynamic linking at the API layer rather than the browser layer.
Hardware token with transaction signing (CAP/DPA) predates PSD2 but satisfies dynamic linking when the token display shows the transaction amount and the OTP is derived from it using a challenge-response mechanism. This approach remains in active use in business banking contexts where mobile app deployment is impractical.
Best Practices
Dynamic linking failures are among the most common causes of payment declines and SCA compliance findings during regulatory audits. The following practices address the most frequent implementation gaps seen across merchant and developer integrations.
For Merchants
Present the exact final amount before initiating the 3DS2 authentication request. Any post-authentication price adjustment—a discount applied after authentication, a currency conversion at settlement that differs from the authenticated amount—will cause the authenticated amount to diverge from the settled amount and may void the liability shift protections you relied upon.
Use merchant name and MID values that match exactly what the issuer sees in the clearing authorisation message. Discrepancies between the displayed payee in the 3DS challenge screen and the clearing record are flagged by issuer fraud systems and can produce soft declines that appear unrelated to authentication.
Retain the CAVV and DS Transaction ID from every 3DS2 authentication response and pass them through to authorisation. These fields are your legal proof that dynamic linking occurred. Without them, you cannot assert liability shift in a chargeback dispute regardless of the underlying transaction legitimacy.
For Developers
Always populate purchaseAmount and purchaseCurrency in the 3DS2 authentication request from the same source-of-truth object as the authorisation request. Never derive one from the other at different points in the flow—pass a single canonical transaction object by reference to eliminate divergence between authentication and authorisation values.
Validate that your 3DS server and ACS integrations target EMV 3DS 2.2 or higher. Earlier 2.x minor versions treated dynamic linking support as optional in certain authentication flows, which creates compliance gaps specifically when handling frictionless exemption fallbacks.
Log the full authentication response object including authenticationValue, eci, and dsTransactionId against your internal order ID. When investigating fraud prevention disputes, these fields are the primary evidence of whether dynamic linking was correctly applied for a given transaction.
Common Mistakes
Routing SCA-covered transactions through 3DS1. 3DS1 does not implement dynamic linking. Merchants still routing PSD2-scoped transactions via 3DS1 integrations are non-compliant, lose liability shift protection, and are exposed to scheme fines. EMV 3DS1 was formally decommissioned by Visa and Mastercard in October 2022.
Authenticating a rounded or estimated amount. Some implementations authenticate a pre-authorisation estimate—a hotel hold, a fuel pump pre-auth—and then capture a materially different final amount. This breaks the cryptographic binding between authentication and settlement. Use separate, correctly-scoped authentication flows for pre-authorisation and final capture, or use incremental authorisation flows that re-authenticate the delta.
Displaying generic or internal merchant names. If the payee displayed during the challenge shows "Payment Service" or an internal system identifier instead of the trading name the cardholder recognises, regulators consider the display requirement unmet even when the cryptographic binding is technically correct. The payer must see a meaningful, recognisable payee identifier.
Failing to re-authenticate after an issuer soft-decline. Transactions granted low-risk exemptions do not require SCA upfront, but if the issuer soft-declines with an SCA-required response code, the retry must include a fully dynamically linked authentication. Merchants that re-send the original request without triggering a new 3DS2 flow accumulate avoidable decline cycles and introduce payment authentication gaps.
Reusing authentication values across retry attempts. A dynamically linked code is valid for exactly one transaction instance. Caching and replaying CAVVs or authentication values across retry or re-submission attempts corrupts the payment flow, triggers issuer fraud scoring, and will produce hard declines in issuers that implement replay-detection heuristics.
Dynamic Linking and Tagada
Tagada's payment orchestration layer normalises dynamic linking requirements across the card schemes and open banking rails it connects to, removing the need for bespoke integration work per acquirer or authentication provider. When routing a European card payment, Tagada automatically selects a 3DS2-capable authentication provider and passes the correct payee and amount fields into the authentication request, ensuring the binding requirement is satisfied consistently regardless of which downstream processor handles the authorisation.
If you are seeing elevated SCA declines on European traffic, Tagada's transaction diagnostics surface authenticationValue mismatches and eci code anomalies in real time—giving your engineering team the exact signal needed to identify dynamic linking gaps before they compound into chargeback exposure or scheme compliance findings.