What is SCA and why does it matter?

July 23, 2019 | Louise Basse

Short for Strong Customer Authentication, SCA is a regulatory requirement introduced as a part of the EU's revised payment service directive PSD2. Both PSD2 and SCA are set to increase security and reduce fraud in the payments space.

But what is SCA actually? And how is it related to PSD2?

SCA will demand customers to use at least two of the three authentication measures before he or she can make online payments:

• Something the customer knows (password or pin)
• Something the customer has (phone or laptop)
• Something the customer is (fingerprint or face recognition)

By September 2019, banks have to reject any payment if it doesn’t live up to PSD2's SCA standards. 

But as we’ve tested the banks’ open APIs, we’ve discovered that many banks aren’t compliant when it comes to PSD2's regulatory technical standards (RTS) on strong customer authentication (SCA).

PSD2 and SCA: Finding the right redirect model 

Even though there’s nothing wrong with redirecting the SCA flow to the banks’ web-based authentication mechanism, we’ve found that banks often create different standards for their own and the third party SCA flows.

In this way, banks offer more advanced solutions in their own PSD2 SCA flow that are not offered in the banks’ third party redirect SCA flow - such as fingerprint and device recognition.

All you need to know about open banking

As banks are required to offer the same solutions to the customers of the third party providers as the banks offer themselves, this is not compliant with the regulatory technical standards on SCA.

The overall user-experience is also highly affected when it comes to the design of the banks’ third party flows. We’ve experienced that some flows aren’t responsive and only works on desktop. In this way, the user has to scroll or zoom in to fill out the SCA.

PSD2: Who handles the consent?

Last but not least, we’ve seen that banks use SCA to collect consent from users, which is unfortunate as it's up to the third party provider to do this - not the bank itself.

And what’s the problem with that?

First of all, it increases friction as the third party provider has to get the consent anyway. Therefore, the end-user is being dragged on a long journey in which he or she has to accept multiple consents from different parts.

Secondly, we’ve seen that banks use the consent to ask users to narrow down the number of accounts available. As third party providers are required to present this as well, there is a big chance that the same information is presented multiple times.

3 things you need to know about PSD2

We’re not against the fact that end-users get the choice to decide the number of accounts. But when third party providers are required by legislation to perform this task, it will lead to poor user experience. 

Finally, consents in the Strong Customer Authentication is often undocumented and only discovered in the production phase.

As banks are moving into new technical challenges and spend huge amounts of resources to become PSD2 compliant, we hope that the bank industry can use our experience to tackle some of the big issues that are still outstanding.