Here’s what it takes to be RTS compliant on SCA in September
As we’re approaching the final PSD2 deadline in September, the financial industry must live up to higher security standards than ever.
Banks and third party providers are required to comply with the EBA’s regulatory technical standards (RTS) on strong customer authentication (SCA).
These standards are an important milestone to give banks and third party providers more clarity about the technical implementation of PSD2.
Yet, EBA’s final RTS still leave a range of important questions open.
In our recent edition to the series “PSD2 and beyond”, explained why no bank will get a fallback exemption by September.
In this edition, we’ll talk about what it takes to be RTS compliant by the final PSD2 deadline in September.
What do the new rules mean? And what do banks do to comply with them?
Creating a seamless and consistent user experience
Although banks across the EU are using tons of time and resources to become RTS compliant by September, there are still many insecurities about the technical implementation of PSD2.
This is especially evident when it comes to the flow of the Strong Customer Authentication which every customer has to go through before he or she can make online payments.
But what is SCA actually?
Short for Strong Customer Authentication, the SCA requirement will demand customers to use at least two of the three authentication measures:
- Something the customer knows (password or pin)
- Something the customer has (phone or laptop)
- Something the customer is (fingerprint or face recognition)
By September this year, banks have to reject any payment if it doesn’t live up to the SCA standards.
But as we’ve tested the banks’ open APIs during the last three months, we’ve discovered that many banks aren’t compliant when it comes to the regulatory technical standards (RTS) on strong customer authentication (SCA).
Finding the right redirect SCA 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 SCA flow that are not offered in the banks’ third party redirect SCA flow - such as fingerprint and device recognition.
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 SCA 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.
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.
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.