Performing dynamic linking in a compliant, convenient way

One of the most discussed requirements of the final Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) under PSD2 is the requirement to perform “dynamic linking” to authenticate a financial transaction, such as electronic payments.

The dynamic linking requirement has three parts:

• It requires a payer to authenticate a financial transaction by calculating an authentication code over certain transaction data (at least the amount and some information identifying the beneficiary). This ensures that the authentication code is linked to the data. 
• The confidentiality and integrity of the transaction data should be protected throughout the authentication process. 
• The online banking user should be aware of the transaction data they authenticate. This latter requirement is often referred to as “What You See Is What You Sign” (WYSIWYS). This implies that merely showing a hash of the transaction data or a session identifier does not suffice.

The European legislators who drafted PSD2 introduced the dynamic linking requirement to counter man-in-the-middle attacks. This attack occurs when an adversary alters the details of a transaction after the payer authenticated the transaction. Such an attack could change a genuine transfer of 100 euro to a friend into a rogue transfer of 1000 euro to an imposter. 

The WYSIWYS requirement intends to avoid social engineering attacks. Throughout these attacks, a payer is convinced to authenticate data they do not understand. This could later turn out to represent a fraudulent transaction. 

As such, PSD2 compliance goes a step further than the EBA’s Final Guidelines on the Security of Internet Payments applied in most EU member states and do not require dynamic linking.

Complying with PSD2 requirements raises several questions for banks. How can a bank conveniently implement dynamic linking into its online or mobile banking application? Can SMS be used to implement dynamic linking? And what about batch transactions?

Let’s explore these topics.

Convenient dynamic linking

Consider the scenario where a user initiates a financial transaction via an online banking application. When running within the browser of their PC, they authenticate the online payment. They do this with either a dedicated hardware token or a mobile banking app.

One convenient way to implement dynamic linking relies on the use of colored QR codes or Cronto codes. When the user wants to initiate a transaction, they:

• Enter the transaction data into the online banking application in the browser. Based on this transaction data, the banking server generates a color code, representing the encrypted transaction data. The color code displays in the browser.
   
• Scan the color code using the camera of their hardware token or mobile device. The device then decodes the color code and decrypts the transaction data. The cleartext transaction data is shown to the customer on-screen.
   
• Authenticate to their device (e.g. key in the device’s PIN). It calculates the authentication code over the transaction data using a cryptographic key stored on the device.

This approach meets all dynamic linking requirements described above. Additionally, it does not require the user to manually enter transaction data onto the device.

An alternative mobile approach consists of transferring the transaction data from the banking server to the mobile banking app. This approach uses an encrypted push notification message. Here’s how it works:

• The user receives a push notification message on their phone.
• When they accept it, the now open mobile banking app shows the transaction data to the user.
• The user authenticates using a fingerprint or face scan, for example.
• The device calculates the authentication code over the transaction data.
• The mobile banking app sends the authentication code back to the customer via the Internet.

This approach also complies with the dynamic linking requirements. It does not require the user to manually enter any data onto the mobile device.

Batch transactions

The dynamic linking requirement also applies to batch transactions or bulk payments. This occurs when combining multiple transactions with different beneficiaries. The final RTS states that the authentication code must be specific for batch transactions. These factors include the total amount of money from all transactions combined and the various beneficiaries.

It is impractical to show a large number of beneficiaries to the user for validation. The following can then be used to balance security measures and user convenience:

• Show the user the beneficiaries corresponding to transactions with the largest risk.
   
• Show the user randomly selected beneficiaries.
   
• Do not show the user any whitelisted beneficiaries.

It is good practice to include a hash of all transactions in the calculation of the authentication code. This protects the integrity of all transactions.

Dynamic linking using SMS?

Can a financial organization implement dynamic linking using SMS? Yes. In this case, the user would receive an SMS message with the transaction data and its authentication code.

Given the requirement to protect the confidentiality and integrity of the transaction data, this would imply the transaction data inside an SMS message must be encrypted. It is not clear how the message could then be decrypted on the mobile device without using a dedicated app. The need for a mobile app to process SMS messages undermines one of the primary benefits of SMS.

Dynamic linking, a key PSD2 requirement

In summary, banks should approach the PSD2 regulation not merely from a compliance point of view. They should also consider optimizing the user experience through convenient, strong authentication and dynamic linking procedures. For more information, see this case study from the Bank of Cyprus.

PSD2 refers to the Revised Payment Services Directive. It is a European directive that aims to improve the security of online payments and consumer protection while increasing competition in the payment market. The framework establishes new services for consumer payment accounts, such as Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs).