Dynamic linking is a security requirement in European payments law under which the code generated when a customer authenticates a remote electronic payment must be linked to that payment's exact amount and payee. If either detail changes, the code becomes invalid. The aim is to stop criminals from intercepting an authentication and using it to approve a different payment, for instance by changing the destination account or increasing the amount in a manipulated session.
Dynamic linking is part of strong customer authentication (SCA) under the EU's PSD2 and the equivalent UK rules. SCA requires two independent factors from knowledge, possession and inherence; for remote payments, dynamic linking adds a binding between the authentication and the transaction. It applies to card payments online, to bank transfers initiated through online banking or a payment initiation service provider, and to other remote electronic payments.
Legal basis
Article 97(2) of PSD2 requires payment service providers to apply SCA that includes elements dynamically linking the transaction to a specific amount and a specific payee when the payer initiates an electronic remote payment transaction. The detailed rules are in Article 5 of the regulatory technical standards on SCA and common and secure communication, Commission Delegated Regulation (EU) 2018/389, which applied from September 2019. National regulators, the European Banking Authority and the UK's Financial Conduct Authority have issued further opinions and guidance.
Key requirements
The technical standards set four main conditions:
- Awareness. The payer must be made aware of the amount and the payee during authentication, for example on the confirmation screen of a banking app or in the text of a one-time passcode message.
- Specific code. The authentication code generated must be specific to the amount and the payee agreed by the payer.
- Invalidation on change. Any change to the amount or payee must make the authentication code invalid.
- Integrity. The confidentiality, authenticity and integrity of the amount, the payee and all information displayed to the payer must be protected throughout authentication.
Where a payer authenticates a batch of payments to several payees, the code must be linked to the total amount and to all the payees. Where the final amount is not known in advance, such as for some card payments with an authorization hold, the payer must agree to the maximum amount to be blocked, and the code is linked to that amount.
How it works in practice
In card payments, dynamic linking is achieved through 3-D Secure 2. When a challenge is required, the issuer's app or authentication page shows the merchant name and amount, and the cryptographic value produced is tied to the transaction details sent through the 3DS process. In bank transfers, the bank's app displays the payee's name or account and the amount before the customer approves with a fingerprint, face or PIN, and the bank generates a signature over those details. One-time passcodes sent by text message can meet the requirement if the message shows the amount and payee and the code is generated for that specific transaction, although many regulators regard SMS as weaker than app-based methods.
Exemptions and edge cases
SCA, and therefore dynamic linking, does not apply where an exemption is used. The technical standards provide exemptions for low-value remote payments, trusted beneficiaries, recurring payments of the same amount to the same payee after the first, transactions judged low risk through transaction risk analysis, and certain corporate payment processes. Merchant-initiated card payments, such as subscriptions after an initial authenticated payment, fall outside SCA because the payer does not initiate them. See strong customer authentication exemption. Payments where the amount changes after authentication, such as hotel or car rental charges, raise practical questions, and scheme rules and regulators' opinions address how to handle them.
Role in fraud prevention
Dynamic linking protects against attacks such as man-in-the-browser malware, which alters payment details on the customer's screen while the customer approves what appears to be a genuine payment. Because the code is calculated over the real details and the customer sees them in a separate trusted channel, tampering can be detected. It does not, however, protect against authorised push payment fraud, where the customer is deceived into knowingly approving a payment to a criminal, because the amount and payee shown are exactly those the customer agreed. Controls such as Confirmation of Payee and transaction monitoring address that risk.
Future developments
The European Commission's proposed Payment Services Regulation keeps the dynamic linking requirement and seeks to clarify SCA in areas such as wallets, merchant-initiated transactions and accessibility for customers who cannot use smartphones. Industry work continues on making dynamic linking compatible with delegated authentication, where authentication is carried out by a wallet provider or merchant on the issuer's behalf, and with emerging payment methods such as variable recurring payments.