Part 2/8: SCA Industry Challenges - Taxonomy
First published: 20/01/2020
Authentication in the banking industry continues to be a headache for many. While everybody would like to have a “one-size-fits-all” solution to SCA, experience shows that the authentication use-cases are too complex for that to be feasible. Let’s take a look at the different scenarios.
Talking to a challenger or neo-bank, everything seems easy. All the potential customers have smartphones, and they are familiar with using them. However, this is not the reality if you’re an established bank. As many as 20% of your customers might not have a smartphone, don’t want to use their smartphone for their company accounts, or might work in an environment where mobile data isn’t available.
While talking to different actors within the banking industry, a few common security-related issues around SCA have crystallised. First, we see four common tasks related to SCA:
- The initial onboarding to the SCA solution
- SCA and transaction verification
- Two-factor authentication (2FA)
- Re-enrolment to the SCA solution (lost device or credentials)
These use-cases are common across user types, but the technical environment of the users vary for the different user groups. Based on our experience, we define five different technical environments that cover almost all users:
- Smartphone only
- Smartphone only, but no data coverage
- Smartphone with no data + PC with network
- PC with network + no smartphone but landline available
- PC with network + low-tech phone - “dumb-phone”
Let’s dive in!
The user has a smartphone and they have network access. These are the users that need single device authentication like the Okay solution for SCA. How onboarding is done is up to the bank or issuer, but we suggest using either an SMS message, which proves possession, or the traditional letter with OTP.
For re-enrolment to the service, we believe SMS by itself is not enough, because of “SIM swap fraud”: Someone might register a new address on you, then have a new SIM card sent to that address, which can be used to access your account. Using a single factor (such as knowing the PIN) is not enough. We suggest using one of our partners here, Boku, which can mitigate this problem.
Smartphone Only, but No Data Coverage:
How do you serve customers who have a smartphone but no data connection to said smartphone? This is more the market of traditional offline eWallet providers, which at least used to be tied to special hardware in the handset. For SCA and transaction verification it would, of course, be possible for the user to use a dongle, but the question here remains: what kind of transaction could the user initiate without data coverage?
Smartphone with No Data + PC with Network:
These users have a computer with network access, but no data connection for their phones. This is the case with some customers of banks that we’ve been talking to. Not having a data connection to the phone makes the onboarding and enrolment process challenging because it is not possible to create a link between the smartphone and the account in this scenario. Not having a data connection also makes re-enrolment even more of a challenge.
A dongle would be an alternative for authentication for these users, however, it is important to note that the only usable dongle under the PSD2 is a dongle which can communicate with the PC. Dynamic linking between the transaction data and any code provided is required to be PSD2 compliant. Yet this is not the case for a lot of dongles and card-readers today.
PC with Network + No Smartphone but Landline Available:
This is the “grandmother-with-PC” scenario, but is also the case for some enterprise customers. They have PCs and landlines, but no smartphones are allowed.
This is a use case that can be handled with dongles, but as we know, dongles are expensive and inconvenient. An alternative that Okay supports is to use a voice call to a landline. The user has to listen to the details of the transaction, and then either get a TAN from the call to be entered on the PC, or has to enter a TAN from the PC during the voice call.
Our assumption here is that the security of a voice call to a landline is strong enough, yet we recognise that might not always be the case. Nevertheless, a voice call on a landline would surely be more secure than a text message to a smartphone.
In our view, a voice call can be strong enough for a transaction verification, possibly depending on value, but we would not recommend it for onboarding or re-enrolment.
PC with Network + Low-tech Phone - “Dumb-phone”:
Here we have the same issue as above, but the user has a “dumb-phone” with the option of receiving SMS. Boku doesn’t fully work without a data connection to the device, but it is worth investigating if they can help you with SIM swap fraud in your country.
Of course, in addition to these issues, there are several potential problems with SCA linked to accessibility that are not included in the descriptions above. These are problems that are more general than the purely security related issues above. How Okay work’s with the accessibility interfaces available on modern smartphones, while not lowering security, is a topic for a different blog post.