PSD2’s dynamic linking in a mobile world

Last updated: 15 March 2019

As regular readers of the blog will know, the PSD2 regulation and its RTS document (Regulatory Technical Standards) set out the mandatory actions financial institutions need to take to make their online banking services, mobile app and payment services comply. RTS is technology neutral but it defines SCA (Strong Customer Authentication), Dynamic Linking and Risk Assessment requirements.

SCA requires the implementation of at least two of the following authentication factors: knowledge (PIN or password), inherence (biometrics) and possession (device). Dynamic Linking for payment services requires financial institutions to dynamically link the authentication code to both the transaction amount and the payee, to provide a true “what you see is what you sign” solution. Lastly, Risk Assessment provides a risk score to each transaction to enable exemptions for a more seamless user experience.

Of these three main requirements, Dynamic Linking is one of the most discussed. Let’s look a bit more closely at what it means.

The aim of dynamic linking is to prevent man-in-the-browser attacks, where malware placed on a user’s computer can modify transactions in real time as they are taking place. For example, a user wanting to transfer €200 to a friend could instead end up transferring €2000 to a different account entirely. The “what you see is what you sign” approach aims to avoid the situation where a payer is asked to authenticate data that they don’t understand, and therefore can’t identify any potential tampering. A unique, one time only authentication code is generated for each transaction that must be specific to the transaction amount and recipient, which both must be made clear to the payer when authenticating. Any change to the amount or the payee results in the immediate invalidation of the authentication code generated.

Meeting PSD2’s requirements has been on the agenda for financial institutions for some time now. One factor that can help is the prevalence and sophistication of modern smartphones. Across Europe, the number of consumers using banking apps on their phones continues to grow, driven by the convenience of being able to access them from anywhere, and in more recent times, the ability to use biometric factors like fingerprints or faces to access accounts or authorize transactions.

The fact that mobile banking has become such a natural habit, with built-in biometric security methods, means it’s something financial institutions can use to help compliance with PSD2. But it’s not as simple as just implementing something like Apple Face ID within their app – as they still need to properly comply with SCA, Dynamic Linking and Risk Assessment requirements.

Using a software development kit specifically designed to address the security challenges of PSD2 can help a financial institution to meet these needs. We created our Gemalto Mobile Protector SDK to do just that. It can strengthen the implementation of biometrics compared with native solutions from smartphone vendors, and integrates leading edge Risk Management software that can assess each transaction for risk in real-time, using a combination of factors such as geo-location, device profiling, IP address, device assessment and behavioral biometrics.

But the final advantage is the ability to sign every single transaction dynamically, protecting each unique transaction while maintaining a simple, seamless user experience. This means the “what you see is what you sign” requirement of dynamic linking is achieved clearly and easily.

With the nature of security threats ever changing, and the number of those targeting mobile devices growing, building mobile banking applications on the most secure possible foundation is crucial. For those still debating how best to meet PSD2’s requirements, developing new banking apps with security in mind should be a priority. You can read more about our Mobile Protector here, and see more of our posts on PSD2 here.

Leave a Reply

Your email address will not be published. Required fields are marked *