These are the types of questions that are often brought to the table by long-established banks and enterprise banks. The type of banks that most often have to deal with users not being able to use smartphones for authentication, and thus have to provide an alternative SCA method for their clients. 

Challenger banks and neo-banks on the other hand, do not have to deal with the same issues. The reason is quite clear: challenger banks are basing their entire business model on the fact that their users can do everything on a smartphone.

In terms of technology, these banks have an easier job of becoming SCA compliant. Since they do not have an “old” client base to service, they are free to build a client base that is comfortable and willing to use their smartphone for all banking purposes.  

There are some typical scenarios where there is a clear need for a fallback option to the smartphone SCA solution:

• Enterprise users that don’t want to use or can’t use a personal smartphone for their work
• Users who do not have a smartphone
• Situations where there is no wifi or mobile internet
• When there is doubt about the integrity of the user’s smartphone

There is no official number for how large the non-smartphone market is. In some cases, we have heard numbers as high as 20%. Regardless of the bank, that represents a significant number of clients, and the banks have to supply these users with a fallback alternative for SCA. 

When a client can’t or won’t use their smartphone for SCA, what are the technical alternatives, and do they keep the authentication process SCA compliant? Let’s take a look at the different alternatives and how they stand in terms of compliance:

• The conventional  way is to use a code generator or a dongle. Traditionally this was a time-based code generator, where you press a button and got a code that authenticates you. The obvious disadvantage is that dongles are expensive and inconvenient to users, particularly since they have to support dynamic linking with the transaction details to be SCA compliant. 
• Another common mechanism is to use SMS by OTP on the user’s dumb-phone. As we have talked about before; SMS is very vulnerable to malware, and using OTPs makes the user vulnerable to phishing. This is therefore not considered an SCA compliant option. 
• A less used option is to use a voice call to the user. In the call, the transaction details are repeated to the user, or the user is either asked to enter a TAN from the screen during the call or enter a TAN from the call on their computer. This is an SCA compliant option, and it is this mechanism that Okay has decided to support as the alternative to smartphone SCA. 
• An older alternative - no longer legal in Europe - is to use printed listings of TAN codes. Surprisingly, some banks have been using this method until the end of last year.
• A last and perhaps obvious alternative is to ask the users to go to a physical bank location, bringing their physical identification with them.

Each of these solutions has its disadvantages, but there are situations where an automated call to a landline would be a lifesaver, such as if there is an issue with your smartphone.

Do you have a business case for a challenger bank targeting non-smartphone users?

We think that there is a largely untapped market in the non-smartphone users, however, it would require quite a bit of creative thinking to offer these users a secure product.

How about using state-of-the-art voice and speech recognition, and require the user to make a call to the bank? It might not be an easy thing to do, but if you are interested in exploring this further, let’s talk!

— — —

This is the 3rd article in a series about the challenges in the SCA industry.
Read the next article in the series Challenge 4 - The mobile OS headache ,or go back to the previous article about Challenge 2 - The taxonomy of SCA mechanisms.