Back in August, the FCA introduced an extension to the enforcement of Strong Customer Authentication (SCA) under the EU's Payment Services Directive 2 (PSD2).
Bowing to industry concerns over lack of readiness, the FCA approved a phased roll-out of SCA, with active supervision for online banking beginning on 14 March 2020. By then, banks must have a working interface for third-party providers and both parties must have appropriate security certificates in place.
While SCA will undoubtedly create a safer environment for transactions, its introduction has not been plain sailing. First off, it’s one of many new measures introduced under PSD2 and the cumulative effect has posed significant issues for the sector as a whole, which simply has not been prepared for changes on this scale. Then, there’s the fact that the regulatory technical standards (RTS) underpinning SCA are inherently complex in their own right and rely on the use of application programming interfaces (APIs) or an appropriate alternative. Developing an API in the given timescale has been particularly tough and many banks have also had to produce a fallback option (a modified customer interface) in the event of an outage. Lastly, there are concerns over the customer experience and the potential impact on ecommerce.
Electronic identification authentication and trust services (eIDAS) certificates are a key security feature to authenticate a transaction under SCA. A third-party provider (TPP) will present them to an account service payment service provider (ASPSP) – generally a bank – to prove its identity. But there are multiple directories for ASPSPs to check the data against across the EU, in a range of languages and formats – making it challenging to confirm full TPP identity and scope of permissions. This has been particularly challenging for ASPSPs to manage the transport and verification of the certificates.
The phased rollout aims to address these issues and properly embed the necessary infrastructure, prior to full supervisory enforcement.
What needs to happen by 14 March 2020?
The March deadline is specifically for SCA in relation to online banking and applies to both ASPSPs and TPPs:
ASPSPs must have a working interface in place to allow third-party providers to use their service
TPPs must have appropriate eIDAS certificates in place
ASPSPs also need a fallback mechanism, unless the FCA has granted them an exemption. Alternatively, ASPSPs must have a modified customer interface (MCI), which is essentially a secure form of screen scraping. Whichever interface is used, it must comply with RTS and allow TPPs to identify themselves with an eIDAS certificate.
If a TPP has enrolled with the Open Banking Implementation Entity certificate scheme, they can use a certificate from the provider on each transaction, as long as they enrolled on the programme with a valid eIDAS certificate. This essentially gets around the problem of a de-centralised directory, and it becomes the responsibility of the API programme provider to check with the Qualified Trust Service Provider (QTSP) that the eIDAS certificate remains valid. Entering into this arrangement is voluntary for both the ASPSP and the TPP, but both parties must be in agreement.
What to do now
ASPSPs and TPPs must continue to work towards compliance by 14 March, making sure documentation is in place to evidence the steps taken. ASPSPs should continue to test their interfaces and fallback options, factoring them into their operational and business-resilience programmes. TPPs should have eIDAS certificates in place, as well as agreements with ASPSPs if also using certificates issued by an API programme provider.
Please contact Paul Olukoya for more information about PSD2 and SCA requirements.