Many firms are still yet to fully implement the strong customer authentication regulatory technical standards (SCA-RTS) and won't be ready in time for the 14 September deadline.
SCA-RTS is key to achieving the objective of the EU Payments Services Directive (PSD2), which aims to improve consumer protection and the security of payment services.
Payment service providers (PSPs), banks and account servicing payment service providers (ASPSP) should review their existing implementation plans and make sure they are compliant as soon as possible.
The sector just isn't ready
There's a lot of work to be done to successfully implement SCA-RTS and the scale of the challenge should not be underestimated. The European Banking Authority (EBA) recognises this and has allowed national regulators a degree of short-term flexibility for some firms. But, in reality, the obstacles go beyond the individual firm and reflect broader infrastructure issues across the sector.
UK Finance, the UK financial services and banking trade association, successfully lobbied the Financial Conduct Authority (FCA) to allow for a phased implementation of up to 18 months for SCA-RTS for e-commerce and online banking. Active supervision of SCA-RTS requirements for online banking will begin on 14 March 2020, and supervision for card issuers, payments firms and online retailers will begin in March 2021.
Achieving adequate transaction monitoring
Secure customer authentication aims to increase security and reduce the potential for fraud by establishing greater authentication processes for certain types of transactions - such as those to a new payee, or for a sum of money over €30. There are several transactions, such as repeated payments to the same beneficiary, which are exempt from SCA-RTS. Where the standard does apply, three categories of authentication can be used:
Knowledge - something the customer knows, such as a password
Possession - something the customer has, such as log in key
Inherence - something unique to the customer, such as a fingerprint
For example, a possession element may include the use of a one time passcode, sent via text message (SMS OTP codes). PSPs have upgraded their digital channels to accept SMS OTP codes, but many do not have appropriate transaction monitoring mechanisms in place to check if any exemption should be applied - for example, if the recipient is a regular and trusted payee. As a precaution, many PSPs are erring on the side of caution and applying SCA to roughly 90% of their transactions. Not only are these additional transactions unnecessary in many of these scenarios, but they can also be an inconvenience for customers.
Establishing effective transaction monitoring processes won't be easy and may require significant operational changes within an organisation. You should undertake a gap analysis of your existing processes to identify the necessary changes to support SCA compliance in the long term.
Access to card details is not a security feature
In June, the EBA published its official opinion on the use of security standard 3DS 2.0, stating that it would not make card transactions SCA compliant. In short, this means the card details cannot be used as a possession element in SCA. The cards industry is currently discussing requirements for 3DS V2.1 / V2.2 to remedy this. Until this happens, firms will be required to find alternative authentication methods to be SCA compliant, potentially embracing card transactions as a verification type in the future.
Finalising the fallback exemption
One of the most high profile, ongoing challenges around SCA-RTS compliance is the exemption from the screen scraping fallback method in the event of any issues with the application programming interface (API). The deadline for exemption requests was in June and some firms may still be waiting for their decisions from the FCA, leaving little time to develop the fallback method in the event of a minded to refuse decision. Firms should consider their options and make contingency plans accordingly in order to meet the September deadline.
The use of eIDAS certificates
For a firm to conduct transactions under PSD2, banks as third-party providers must enrol as an ASPSP to an Open Banking Directory Service (OBIE, PRETA or others). They must also use eIDAS certificates for the identification of a third party provider (TPP) (PISPs, AISPs and CBPIIs). That means that the bank must be able to manage the highly technical transport and signing test certificates including QWACs and QSeals (eIDAS certificates).
Firms must consider the most appropriate directories to register with and work out effective processes for using eIDAS certificates.
What to do now
Recognising the broader sector issues, firms should work towards SCA compliance - factoring in potential changes in the industry in order to future proof their implementation strategies. For further information on SCA-RTS and how we can help, please contact Paul Olukoya.
PSD2 - will your API (or fallback) be ready in time?Find out more