Okay started its compliance journey back in 2015 with our first security evaluation. As this was before the PSD2 was finalised, the target of the evaluation was to meet the European Central Bank’s “Recommendations for the Security of Internet Payment. “ More specifically, it was defined in the “Assessment Guide for the Security of Internet Payments.” These recommendations were perhaps the first official documents where the term “Strong Customer Authentication” (SCA) was used. 

Recently, we did a similar evaluation against the RTS, also known as the “Regulatory Technical Standards on Strong Customer Authentication and Secure Communication Under PSD2” (2017), which was also a success. But why did we do so? Because by using such evaluations to help uncover issues and design challenges, it proves that the security your solution provides meets compliance standards, is well tested, and strong. 

 For both evaluations, we followed the same four-step methodology: 

• Build a formal model of the Okay solution
• Go through the requirements paragraph for paragraph
• Evaluate whether the requirement was relevant for SCA
• Verify if the requirement was fulfilled by the model
  

For example, if an asset is required to be confidential, we would do a mathematical verification of who could access the property. We also performed simulated attacks and asked model questions such as “if an attacker had access to this property during enrolment, could it be used to decrypt information later”? 

This type of analysis - where you follow a systematic process and link the regulation to systems (digital or people-based) - is key to proving that you follow the given requirements in any regulation. Just keep in mind that while this is usually straightforward for structured regulations using familiar security terms (such as the RTS), it can be much harder when you have to interpret legal language. 

Besides the obvious security benefits gained from doing this kind of analysis, there is one other important benefit: helping find the best solutions for any given client.

Essentially, it lets us look at the requirements that a client has to follow and, based off of that, decide where we can help or where one of our partners can help. We can also link the requirements up to regulation if so required. 

Note that both governmental regulation and market requirements are becoming more and more demanding. So while there might be some companies that claim to be able to deliver everything you need, the truth of the matter is that really no one company can deliver everything in one package.

As a technical provider, Okay’s primary goal is to help with securing authentication and transaction authorisations, including all the technical requirements that follow once that has been done. 

We also help you meet your compliance requirements by sharing documentation produced by internationally recognised independent third parties. This allows you to create both declarations of conformity and security reports, demonstrating your regulatory requirement compliance to auditors and supervisory authorities.

However, if you’re a regulated entity like a bank or a fintech, there are limits to where we can help. While the SCA process is important, it is just one piece of the regulatory puzzle. Regulated entities still must follow other regulations related to everything from anti-money laundering to risk-management, often accompanied by strict reporting requirements. 

Of course, we do have several partners who can help you with such compliance requirements. We’ve also been building relationships with other companies to help out in areas outside our core business of strong customer authentication.

Ultimately, we hope this series of posts on compliance has been of some use to you. If you’re interested in topics such as security and compliance, you can follow us on LinkedIn.

Happy authenticating!

————————————

This is part 3 of 3 of a series on PSD2 RTS SCA Compliance. Part 1 of the series focuses on compliance, while Part 2 focuses on the April 30th deadline.