Understanding Dynamic Linking in PSD2

Understanding Dynamic Linking in PSD2

This is the first of a series of posts detailing the EU’s PSD2 Strong Customer Authentication (SCA).

Riding on the convenience of same-day delivery and 1-click payments, online purchases are conquering the consumer marketplace. But they face a serious new challenge starting in September 2019, when any card-not-present transaction over 30 Euros will see an increased amount of friction by requiring payer authentication.

The European Banking Authority has issued rules and regulations in the form of the Payment Services Directive 2 (PSD2), a policy that regulates all payment service providers completing a payment in EU member states and applies to businesses around the world. The main goal of PSD2 is to open the payment ecosystem, allowing for new technologies that aim to simplify online payments or transfers. However, another aspect of the policy is to address concerns about rising costs of fraud for online financial transactions by mandating strong customer authentication.  

This blog will help to remove some of the uncertainty about what "strong" entails and explain in simple terms what you need to know to comply with the new regulations, specifically the important topic of “dynamic linking,” one of PSD2’s core components.

Does PSD2 apply to my business?

If your business processes payments that are completed in the EU, then you need to abide by PSD2. This includes cases, commonly referred to as “one-leg-out” payments,  where only one party is in EU, and not the other.

For example, a UK resident purchases something from a U.S.-based online store. The store, which uses an EU-based payment services provider (PSP) to manage payments in the EU, would have to make sure the PSP complies with PSD2.

Stronger Authentication explained

Strong Customer Authentication (SCA) mandates the use of Two-Factor Authentication (2FA) for all transactions above 30 Euros. These transactions will need to be authenticated using at least two of the following three factors:

1. Something that only the customer knows. For example, a password, PIN, or response to a security question. Card data (e.g., card number, CVV, or expiry date) is not considered a valid knowledge factor.
2. Something that only the customer has. For example, a mobile phone.
3. Something that the customer is. For example, a biometric such as a fingerprint.

If this sounds like your typical implementation of 2FA, you’re correct. But the “dynamic linking” requirement introduces a new batch of caveats.

What is Dynamic Linking?

Dynamic linking requires that an authentication code for each transaction must be unique (i.e. it can only be used once), is specific to the transaction amount and recipient, and that both amount and recipient are made clear to the payer when authenticating.

The PSD2’s dynamic linking requirement specifically states that payment service providers applying SCA:

“shall 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.“

Let’s break down this language further, because it’s not always super clear as to what “specific” means in practical terms.

• (a) the payer is made aware of the amount of the payment transaction and of the payee.

Essentially this is saying that at the time of the transaction, the value of the transaction and the identity of the recipient must be displayed.  For example, if you are sending €45 to your friend Bob Smith, or you are buying shoes worth £79.99 from Amazon.co.uk, this information needs to be visible when the person initiating the transaction (the payer) is being authenticated. Note this statement doesn’t specify how to make the payer aware, so it can be displayed on the payment interface in the web browser or mobile application. The goal here is to ensure the user is confident they are authenticating the right transaction.

• (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;

This language is a little trickier. How is a code specific to the amount and payee previously displayed in (a)? It means that any code you intend to use to authenticate a transaction must be used for that specific transaction only. You don’t need to actually derive the code from transaction details, (although you could) you just need to maintain a reference. For example, you could have a universally unique identifier (UUID) per code, and then enforce that this UUID, and its authentication code, can only be used to authenticate the €45 payment from you to Bob.

• (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

This provision may seem identical to (b), and while it is related, there’s a crucial difference. While (b) refers to codes generated, (c) pertains to codes accepted. But aren’t they the same thing? Not quite.

For example, different codes may be generated via multiple channels, e.g. push authentication, SMS - OTP and TOTP, for the same transaction. One of the codes will be used to authenticate the transaction depending on what channel a user has access to at the time.

Each one of these codes, while unique, corresponds to the same transaction. Once a valid code is entered, the other concurrently generated codes for that transactions are invalidated.

Thus, each transaction can have multiple codes sent via different channels, that depending on user connectivity, can all be used to authenticate the transaction. However, only one can be accepted and used.

And the last in this series of requirements,

• (d) any change to the amount or the payee results in the invalidation of the authentication code generated

Make sure that if the transaction value or recipient changes, you invalidate all outstanding authentication codes. The goal here is ensuring that any alteration of the transaction requires that new authentication codes are generated (with new information about the transaction displayed to the user), therefore preventing a hacker intercepting and trying to mess with the payment.

Finally, there’s also the requirement that:

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

Translation: to further improve security posture, data exchanged between all parties must be encrypted.

Conclusion

By paving the way for new players to innovate in the payment industry, PSD2 could encourage a revolutionized payments industry, affecting everything from the way we pay online to what information we see when making a payment.

Proper compliance with PSD2 will be critical to ensure the continued growth of online and mobile commerce. The onus is now on PSPs to provide solutions that allow merchants and banks to balance security and compliance with user experience and scale.

In part 2 of this series, we’ll focus on different types of 2FA you can use with Twilio and how they can help you with Strong Customer Authentication.