On 13 March 2018, the regulatory technical standard (RTS) on strong customer authentication (SCA) was finally published in the Official Journal of the European Union – some twenty months after the European Banking Authority (EBA) issued the first draft.
Smart Payments Association position on the RTS on SCA
Representing a fundamental regulatory pillar in the battle to combat the expected growth in payment fraud resulting from the boom in e- and m-commerce transactions, the entrance of non-bank competitors into the payments arena, the growth in cyberattacks and the diversity of security solutions implemented by payment service providers (PSPs), these landmark regulations herald a significant step forward in enabling enhanced consumer protection and security in payments services.
In this paper the SPA provides analysis of the chapters contained in the RTS on SCA text, together with observations and commentary on where greater clarity or rigor will be required in future iterations of the new regulatory standard.
General provisions
The SPA believes that Article 1.1 (b) sets an unfortunate precedent early in the document by outlining potential exemption scenarios in relation to the strong customer authentication requirements. In the opinion of the SPA this risks potentially focusing the attention of payment service providers (PSPs) on how to avoid the strong customer authentication regime from the outset, although Article 3 clarifies that PSPs making use of exemptions will be subject to audits and signposts readers to Article 18 where the requirements that will apply to transaction risk analysis and monitoring are also detailed.
While Article 2 exclusively focuses on authentication requirements, the transaction monitoring requirements applied by PSPs excludes unusual consumer patterns of behaviour (these now appear at Recital 14). Furthermore, the monitoring process has been simplified and the risk of infringing data protection lowered.
Security measures for the application of strong customer authentication
Article 2.1 implies, rather than explicitly states, that strong customer authentication requires multifactor authentication rather than two or more independent elements and the security requirements for different categories of authentication have been relaxed. The SPA believes this opens the door to technical solutions that may claim compliance with such high-level requirements, but which will risk potentially facilitating fraud.
The SPA also considers that the breaking of one authentication element enables the breaking of another authentication element of the same category; in other words, authentication elements from the same category should not be considered as independent from a security point of view.
Exemption regime
The SPA contends that exemption regime could potentially incentivize PSPs to utilize biased payment fraud accounting practices in a bid to avoid strict strong customer authentication constraints. That said, the SPA recognise the appropriateness of two countermeasures designed by European regulators to counter this risk:
- The European Banking Authority’s initiative to harmonize practices for fraud reporting, and
- The specification of extremely low fraud figures in the RTS on SCA Annex.
The SPA also advises while alternative authentication methods (such as the identification of suspicious payments) can complement more robust authentication processes based on certified hardware under end-user control and are useful for PSP risk management, their intrinsic limitations mean granting exemptions in such cases should be considered with care.
Confidentiality and personalised security credentials
While Articles 23 to 27 comprehensively cover the overall lifecycle management of Personalised Security Credentials (PSCs) issued by PSPs for customer authentication, a lack of definition around the format of such credentials allows for a wide interpretation around the manner in which PSCs are implemented.
The SPA would have preferred that the security credentials and properties of PSCs were clearly set out so that all solutions claiming compliance with the RTS on SCA conform in terms of the actual levels of security offered. It was for this reason the SPA submitted a proposal to the European Card Stakeholders Group (ECSG) to include a security assessment of known authentication solutions in the market so that PSPs could make informed choices.
Common and secure open standards for communication
Section 1 of Chapter 5 focuses on two aspects: identification (Article 28) and traceability of regulated electronic payments (Article 29) and sets out the requirements, applicable to any electronic payment transaction, that will enable PSPs to gather information about an individual payment ‘as a whole’.
However, while Article 28 includes a requirement for the secure identification of the payer’s device and the payee’s acceptance device, the text is ambiguous on the precise meaning of mutual and ‘secure identification’ – a point which the SPA believes should be clarified.
Dedicated solely to Third Party Payment Providers intermediated financial services, Section 2 (Articles 30 to 36) is a fundamental new piece of controversial regulation that bans existing TPP authentication practices such as screen scraping, as these are considered a risk for the end user. However, to assure continuity of TPP services, the European Banking Authority has stated it will tolerate screen scraping for the duration of the migration period to the new regulation which will apply from September 2019.
Similarly, while Article 30 mandates that account service providers (ASPSPs) must offer an interface for online access to payment accounts that complies with a set of functional and security requirements, there is no requirement that this is a dedicated interface for TPP access and an exemption regime means a bank may refuse the TPP use of the customer online interface, even if the dedicated interface they elected to provide fails.
Section 2 contains high-level requirements for the encryption of data, the protection of established communication channels between entities, prescribes the use of e-IDAS role certificates for Open Banking APIs and re-iterates the right that PSD2 provides to regulated TPPs in relation to payment account information equivalent to that provided to the end-user. Article 36 also insists on limitations on the data that can be obtained; no sensitive data is to be disclosed by the bank, although the nature of this ‘sensitive data’ is not set out; only designated accounts are accessible and under control by the end user; information retrieved must be purposeful and managed as confidential data by the TPP.
While Chapter 5 mandates the use of international standards for the secure authentication and data exchange for TPP services, interoperability between Banks (ASPSPs) and TPPs is at present limited to local implementations.
Final Takeaways
- The SPA considers the RTS on SCA to be a fundamental step forward in promoting safe innovation for retail payments that will contribute to a better perception of security by users (customers and retailers) and will help harmonise technical implementations towards a higher level of security.
- While the RTS on SCA is a good text it is underspecified. The eagerness of players keen to win market share in this huge potential market may result in innovative payment solutions that prioritise end-user comfort and convenience over security considerations.
- SPA members are committed to the development of international standards for the security of TPP services that will ensure open banking API interfaces, at the very least, comply with a common architecture layer that makes it possible to achieve the security and data protection requirements of PSD2.
The post Smart Payments Association position on the RTS on SCA appeared first on Payments Cards & Mobile.
