The industry is readying itself for significant change related to Strong Customer Authentication, consent, and liability as it looks towards the deadlines of EU Payment Services Directive 2 (PSD2). For PSD2, which came into force on January 13, 2018, the true compliance deadline will be when the adoption of the European Banking Authority’s Regulatory Technical Standards (RTS) becomes mandatory from 14 September 2019.
With these new regulations forcing action, banks need to adopt solutions that are simple, secure, and compliant.
Banks need to ensure their own environment is safe and that cyber-risks are mitigated as part of a more holistic cybersecurity strategy. Additionally, there are specific compliance requirements for each regulation that must be addressed, and how these are implemented will go a long way to determine the success or failure both for individual banks and PSD2 as a whole.
PSD2 is adopting the approach of definining its requirements through the European Banking Authority by publishing a set of general guidelines on how to implement PSD2 through the RTS, specifically the aspects of Security, Strong Customer Authentication (SCA), and Consent.
There are several articles within PSD2 that directly or indirectly address security and implementation. They are as follows:
1. Separate and Secure Execution Environments
This means the Payment Service Provider (initiating party) must have a separate payment and security solution. As an example, a consumer may make a purchase on a merchant’s website from a laptop and then be asked to confirm the payment by using a separate mobile device.
2. Dynamic Linking
Simply put, there must be a way to trace the payment transaction end-to-end from the PSP, to the Payment Service User (PSU) to the Account Holding Institution.
3. Possession
As part of multifactor security—Something I Am, Something I Know, and Something I Have—possession is all about ensuring the Something I Have, such as registered mobile device.
4. Malware Detection
This is the ability to detect whether malicious software has been introduced onto a device for the purpose of illicitly capturing information that can ultimately be used to steal money.
5. General Authentication
As the name suggests, this refers to making sure customers are who they say they are for the purposes of initiating a payment or accessing account information.
6. Software Authenticity
This applies to both the third-party initiator and the bank who holds the customer accounts. Are they both using suitable secure techniques, including software, to identify and authenticate the customer?
7. Secure Communication Session
This is about ensuring that the information exchanged between the various parties is confidential, cannot be altered, and cannot be intercepted or stolen.
The laws and guidelines are open to interpretation regarding implementation, security and compliance. Banks may mistakenly think that SMS is the solution to PSD2 Secure Customer Authentication. Although it is simple and cost effective, it is neither compliant nor secure.
On first examination, SMS fulfils a number of the PSD2 compliance requirements:
It provides a Separate Execution Environment in that a payment or request may be initiated through a browser but authorised via SMS on a hand-held device
It fulfils the multifactor authentication requirement of “Something I Have,” such as a one-time password delivered to the handheld device via SMS
But it does not address the issues of:
Dynamic Linking
Malware Detection
General Authentication
Software Authenticity
Secure Communication Session
The good news for banks is that it is possible to create an easy-to-use experience that is both secure and compliant. Such solutions are inevitably slightly more costly, but are part of the necessary investment to ensure security and compliance, while maintaining a simple interface for the customer.
For PSD2, banks have a duty to deliver compliant and secure solutions, and, in this case, they can do so by providing a simple capability for both the aspects of consent and Strong Customer Authentication (SCA). The complexity of providing a compliant and secure solution can be hidden by providing a rich, easy-to-use interface on a mobile device, capable of receiving and sending encrypted contextual messages. This solution is substantially more secure than SMS while meeting PSD2 SCA requirements, which SMS clearly does not.
By going back to focus first on the principles of simply being compliant, the irony is of course that in this case, the solution will be both secure and easy to use – a win for the bank, the regulators, and the customer.
Download the InAuth whitepaper to learn more about the successful adoption of Open Banking here.
About Michael Lynch
Michael Lynch is InAuth’s Chief Strategy Officer and is responsible for developing and leading the company’s new products strategy, as well as developing key US and international partnerships. He brings two decades of experience in key roles within financial services, consulting, and Fortune 500 companies, specialising in security and technology leadership.
About InAuth
InAuth is a leading digital device intelligence company for a mobile-first world. InAuth delivers the most advanced device identification, risk detection, and analysis capabilities possible to help organisations limit risk, remove friction, and reduce fraud within their digital channels. With safer digital transactions, banks, payment networks, merchants, healthcare providers, governments, and other organizations are better positioned to capture new revenue opportunities and compete more effectively in an “always-on” world. For more information, visit www.InAuth.com.
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now