Okay did its first compliance audit back in 2016, before the PSD2 was even out of its planning stage. At the time, the audit framework was provided by the European Central Bank (ECB), in the form of the “Assessment Guide for the Security of Internet Payments”. This was published in February of 2014 and built off the earlier “Recommendations for the Security of Internet Payments” from 2013. 

Re-reading this Assessment Guide from 2014 today is intriguing. This is because while many concepts are similar to what we now find in the PSD2, others are simply missing. For example, the term “Strong Customer Authentication” (SCA) was used by the ECB throughout the Assessment Guide, but other words like “Dynamic Linking” are not mentioned at all. 

When reading the 2014 Assessment Guide, one central idea sticks out: when a multi-purpose device, such as a mobile phone, is used for the ownership element, the payment and SCA should be done in a “separate or independent channel”. This makes a lot of sense if you consider how internet banking was done ten years ago when banking apps weren’t common, and people mostly used their web browser (together with a dongle or a phone) to receive text messages with a one-time PIN code.

In the “Recommendations for Internet Payments”, the ECB recognised that banks would start using the app itself as a possession factor. This is because out of the three factors (knowledge, possession and inherence), two already needed to be verified to use the app. This might mean that payments could be initiated with just a password. However, given that viruses and malware were quite common, this caused a lot of security problems. In this context, requiring a separate channel for SCA makes a lot of sense.

During our 2016 audit, the requirement for an independent channel made us have some lengthy discussions. How could we best ensure that our own SCA channel would be both separate and independent from the rest of the mobile device’s operating system? The solution we ended up implementing was to use a separate voice call that could run in tandem with our SDK. This would allow a one time PIN from the voice call to be entered into a secured screen displayed by the SDK. 

Ultimately, our external auditors judged this as fulfilling all the requirements. Why? Because the voice channel was independent of the mobile phone operating system channel where the SDK was running.

As expected, the regulations changed again with the publication of the PSD2 and with the updated Regulatory Technical Standard for Strong Customer Authentication and Secure Communication (2018).

The requirement to use an independent channel was no longer mentioned, and there were now new requirements not yet seen before. The most important was that SCA must happen in a totally separate Secure Execution Environment. The payment details and user authentication also have to be linked throughout the entire process by Dynamic Linking. This linking allows for both the initiating and authorising of the device’s transaction without having separate channels (as long as the security requirements have been met).

How Strong Customer Authentication requirements have changed over the last ten years is an interesting topic, whether viewed from a legal perspective or a technical security perspective. However, one thing is clear: the regulatory authorities have been taking note and adapting to how consumers make payments. And this we hope they’ll continue to do as we watch technology evolve at an ever-increasing rate.

Looking ahead, we might see future regulation on how to delegate payment authorisation to IoT devices, and how merchants instead of banks can perform SCA. These topics we are already discussing and working on today. 

To learn more about our services, check out some other blogs like how we can help you set up Two Factor Authentication, how our Admin Panel works, or how you can customise your brand to the Okay Solution.