Dynamic linking - in a PSD2 context - requires an “authentication code”, unique to each transaction, to be transferred together with the amount and recipient of the payment through every step of the payment and authentication process. Additionally, both the amount and recipient have to be made clear to the payer when authenticating the payment. If the authentication code or any payment details are changed, the transaction should fail.

This sounds quite simple, but there are some interesting details when it comes to the practical implementation of dynamic linking. The most detailed requirements for dynamic linking is found in the Regulatory Technical Standard for PSD2 (RTS), in Article 5: 

1. Where payment service providers apply strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/2366, in addition to the requirements of Article 4 of this Regulation, they shall also adopt security measures that meet each of the following requirements: (a) the payer is made aware of the amount of the payment transaction and of the payee;
(b) the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction;
(c) the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer;
(d) any change to the amount or the payee results in the invalidation of the authentication code generated.

2. For the purpose of paragraph 1, payment service providers shall adopt security measures which ensure the confidentiality, authenticity and integrity of each of the following:
(a) the amount of the transaction and the payee throughout all of the phases of the authentication;
(b) the information displayed to the payer throughout all of the phases of the authentication including the generation, transmission and use of the authentication code.

Based on this, two questions come to mind:

The authentication code is discussed in Article 4, where it is stated that “the authentication shall be based on two or more elements which are categorised as knowledge, possession and inherence and shall result in the generation of an authentication code.” Furthermore, the authentication code is required to be specific to the unique payment, it cannot be forged or used more than once, and it needs to have a limited lifespan. 

A typical way for this to work in practice is that the authentication code is part of an encryption system, where the transaction details are securely received from the account service provider (e.g. bank), then authenticated on a smartphone using two factors out of knowledge, possession and inherence. The result is then signed with a private key local to the device and specific to the user, creating an authentication code, and the result returned to the bank. All of this has to take place in a secure environment, a “separated secure environment” as defined in Article 9 of the RTS. 

To the end-user, this means that the authentication most likely takes place on their smartphone, no matter where the transaction has been initiated. For transactions that take place entirely on the smartphone, the requirement of a secure environment means that there must be special care taken with how the authentication takes place. One of the many security mechanisms Okay has implemented is an invisible watermark on the screen displayed to the end-user, which can then be verified either on the device itself or on the server receiving the result, further strengthening the link between the payment details and the authentication process. 

In banking language, this type of authentication is an “out-of-band” authentication. Even when the authentication takes place all “inside” the banking app, it should be out of band, as the execution environment is required to be separate.

Yes! Here are two still common situations where dynamic linking fails:

• When you use an offline “dongle” that provides a time-based one-time code based on a secret encoded inside the dongle; as the dongle can’t receive the payment details it can’t generate a code that is specific to the amount and recipient, and thus can’t be part of the “link”. But, in some scenarios, it can be used to prove possession.  
• A more contested issue is with “transaction authorisation numbers” (TAN) sent by SMS. As the TAN can be sent together with the transaction details, it does sound like this could meet the requirements above. But in an EBA opinion from June 2019, it was made clear that the security of SMS messages is by itself too low, as they can’t be secured. An SMS might be enough to prove possession, but there must still be more factors such as biometrics or a PIN used, as well as a secure environment.

Authentication and dynamic linking can be quite complicated concepts. Hopefully, this article helped make it a bit clearer for you. If it was useful - please let us know!