The Regulatory Technical Standards (RTS) is a supplementary directive designed to complement the Revised Payment Service Directives (PSD2), eIDAS and any other such cases where Strong Customer Authentication is required.

In Part 1 and Part 2 of our series on the Regulatory Technical Standards, we looked at how it complements eIDAS and PSD2 respectively. RTS not only stipulates the specifics of achieving Strong Customer Authentication, but it also lays the groundwork for establishing secure communication between various parties to an online transaction.

While on the surface it may seem like the Regulatory Technical Standards on Strong Customer Authentication have been designed to target a very specific problem (that of customer authentication), they in fact comprehensively target broader transactional security in the following ways:

RTS allows for technologically neutral resolutions. Solution providers can choose from a variety of methods including one-time passwords, digital signatures or other cryptographically underpinned validity assertions. This allows for customization based on cost considerations and technological compatibility with other systems, as long as the minimum security criteria are met.
Dynamic linking of transactions with authentication codes is another RTS requirement which provides another layer of security and protection against fraud and misuse.
Consumers often cite security as a primary deterrent to engaging in online payment transactions. This is obviously a hindrance to the goal of achieving a Digital Single Market and RTS provides for mechanisms to safeguard against such activities. With rapidly evolving cyber threats, transaction monitoring mechanisms are necessary to ensure that security credentials have not been lost or compromised.
In terms of transaction volume, retail customers obviously account for the lion’s share. But in terms of transaction value, corporate and institutional clients dominate. RTS requirements for Strong Customer Authentication are applicable to both groups and apply to natural persons as well as corporate entities.
All the security in the world would be for nothing if the customer experience is not good enough for him or her to engage in the transactions in the first place. Requiring frequent intervention for recurring transactions or for very small value micro-transactions might not be desired or necessary. RTS provides exemptions for such cases.

RTS encourages the dynamic setting of risk levels on a transactional basis based on real-time transaction risk analysis. What this essentially means is that even low value exempted transactions might require SCA if the transaction is deemed unusual based on real time analysis. While at the same time, additional exemptions from SCA may be allowed for transactions that are deemed to be low risk. This entire mechanism is obviously dependent on the effectiveness of the real time risk analysis algorithms used.

In order to gauge the effectiveness of the real-time transaction risk analysis mentioned above, service providers would also be required to calculate fraud rates and report the data to the European Banking Authority (EBA) and other competent authorities.
This means that service providers which are better at protecting their customers from fraud would be allowed more exemptions and will therefore have more leeway in designing hassle-free mechanisms.

Conclusion

Although some service providers have offered reservations about RTS, there is definitely enough flexibility built-in to allow for a multitude of approaches to achieving the goal of transactional and account security. By making exemption thresholds dynamic based on actual performance, service providers with better systems and procedures will have even more options available to them. For the end users, this means better security and the assurance of certain minimum standards.