Okay LogoOkay Logo
Go back to Okay blog

Remote Dial as a Fallback for PSD2 SCA

First published: 03/03/2021

updated: 21/10/2022

artifact

What is a reliable solution for users who do not have a smartphone? In this post, we review our remote dial option, aimed at helping those with accessibility impairments.

Accepting Non-smartphone Users

About a year ago, as part of a series about challenges in the SCA industry, I wrote a post talking about fallback mechanisms. Since then, the situation has remained unchanged: there is still a market-need to support users who, for some reason or another, do not have or want to use smartphones (and subsequently their authentication methods). 

This should not be a surprise to any long-time players in the payment industry. The discussion has been going on for years regarding those against smartphones, whether it be a personal or professional choice. 

However, in 2020, it seemed like there was less focus on the frustration that comes with this inaccessible market segment. Instead, we saw a positive attitude shift towards accessibility, including those with visual disabilities or impairments. And since we know that 20-30% of the customer base for some of the larger incumbent banks are non-smartphone users, there are quite a few users falling under this category that need an alternative authentication method.

Remote Dial

The main way that we here at Okay have decided to support these types of users is to enable a “remote dial”. In other words, using voice calls to authenticate the user when required. It is quite simple for the user to receive the call: 

  1. We make a call to a pre-registered phone number belonging to the user initiating the transaction. 
  2. During the voice call, the user has to listen to the details of the transaction, followed by a “transaction authentication number” (TAN) that must be entered onto the PC. 
  3. Once the TAN has been entered in the web browser, the transaction can be confirmed or denied.

PSD2 Compatibility

The first question to ask is how can this be compatible with the PSD2 RTS?

To begin with, a voice call is a much stronger test of possession than a text message. Basing authentication on text messages in 2021 is not recommended, as even the most basic types of malware can steal text messages.

But, there are still possibilities for fraud. One example is a SIM-swap attack, which is when someone gets hold of a SIM card that answers for a user’s phone number. Avoiding this type of attack is out of scope for this post, but we do have a partnership with Boku for just this type of scenario. Boku is great because they have integrated with telecoms, allowing them to verify the ownership of the phone number more so than what is possible with just a voice call.

Secondly, when using voice calls, dynamic linking is handled by having the details be an actual part of the voice call. It is quite hard for an attacker to listen in to the call, particularly if it goes to a landline, which makes this a strong security mechanism. The TAN is also linked directly to the transaction details, which are repeated to the user.

Lastly, a voice call can also be considered to be a separate execution environment, which is the third major requirement of a PSD2 compliant SCA solution. This environment is particularly secure if the call is to a landline, but even if it goes to a non-smartphone, it is usually much harder for an attacker to interfere with the call.

Remembering 2-factor Authentication

Remember, remote dial provides a verification of possession. But there is still a requirement to implement one either out of inherence or knowledge. We’ve experimented with implementing biometric authentication through speaker recognition during phone calls, but found that the false-positive rate was just too high.

This leaves the knowledge factor, like a password or secret PIN. As the remote dial mechanism is a true second (physical) factor for the authentication, we leave the verification of knowledge to the second factor: e.g. a password verification through the web browser.

Is this type of authentication interesting for you? Please let us know, and we will be happy to show you how we’ve implemented it into our solution!

Follow us on LinkedIn