It was a long gestation and difficult birth but Europe finally has new requirements for strong customer authentication. They will apply across the region from 14 September 2019, bringing much-needed clarity. Yet some uncertainties remain.
Strong Customer Authentication rules agreed for Europe
The regulatory technical standard (RTS) on strong customer authentication and secure standards of communication was published in the Official Journal of the European Union on 13 March 2018. It entered into force the following day and EU member states have 18 months’ transition before it becomes effective on 14 September 2019.
A DIFFICULT BIRTH
In short, the RTS includes strong customer authentication provisions for accessing payment accounts and making online payments. It also bans traditional ‘screen scraping’. Instead it sets out minimum requirements for the interface between banks and third party payment service providers for access to account information.
The European Banking Authority (EBA) had the delegated authority under the revised payment services directive (PSD2) to develop a number of RTS. It originally submitted a draft RTS to the European Commission on 23 February 2017 for adoption. The Commission disagreed with parts of the draft and amended it. After considering some of the the EBA’s comments on an intermediary draft, the Commission finally adopted this amended version of the RTS on 27 November 2017.
Strong customer authentication is defined within the RTS as two or more of the following: something a customer knows (knowledge), something they have (possession) and something they are (inherence). The interdependence of each element should be guaranteed, so that the compromise of one does not compromise the others.
The RTS sets out minimum standards of each of these elements. Plus the dynamic linking of each transaction amount and payee to an authentication code. If either changes, this invalidates the authentication code. There are exemptions but generally every electronic transaction is subject to strong customer authentication.
Although the adoption of the RTS has provided a degree of market certainty, some articles are still open to interpretation. There is also uncertainty about whether specific solutions will be considered compliant by the EBA and local competent authorities.
The permissible methods of strong customer authentication remain unclear. One-time passcodes sent via SMS are not explicitly allowed or disallowed within the RTS. There is also debate about the dual factor requirement for such an authentication method. This is particularly if the mobile device to which this is sent is already serving as an authentication factor. Would the consumer be required to have an additional device?
One-time passcodes via SMS are already used widely within many European markets, including the UK. National competent authorities will have to balance the convenience, familiarity and inclusiveness of the method against its known vulnerabilities to certain types of attack.
Requirements for strong customer authentication generally apply to payments initiated by the payer. Recurring payments are exempt from strong customer authentication as long as the first payments in the series for the same amount and payee was so authenticated (Article 14). Direct debits are considered out of scope of the regulation. But what about similar pull payments set up on cards? Beyond the first payment in the series, these are payee-initiated. The amount may also change depending on consumption during a given period in the case of a utility or mobile phone subscription.
Article 13 on trusted beneficiaries merely states that “payment service providers shall be allowed not to apply strong customer authentication […], where the payer initiates a payment transaction and the payee is included in a list of trusted beneficiaries.” It is not clear whose payment service provider — that of the payer, payee or both — can create, amend or invoke a white-listing exemption.
There are also uncertainties on how what the EBA calls ‘transaction risk analysis’ (TRA) will work in practice. This risk-based approach gives exemptions to strong customer authentication for low-risk transactions, if the PSP operates within certain thresholds as to fraud by value bands. As above, it is not clear which PSP can invoke such an exemption. If a transaction is later found to be fraud, whose fraud statistics is this attributed to? And how does this sit with the triggering of a TRA exemption?
SCREEN SCRAPING BANNED?
The matter of ‘screen scraping’ pitted banks against FinTech firms. This is when third party payment service providers (TPPs) access customer account information and initiate payments using the customer’s security credentials. Banks sought to ban the practice for security and cost reasons, whereas FinTech firms favoured the status quo.
The RTS bans traditional screen scraping. Banks who provide a dedicated interface to TPPs for account access (e.g. via API), may block certain types of screen scraping. However, banks must allow a contingency method of accessing customer data if their interface is unavailable. This may be a form of screen scraping.
Although the RTS comes into force in 18 months, banks must be ready with their dedicated interfaces to allow TPP account access within 12 months. This is to give TPPs six months to make their own preparations to implement and test the bank interfaces prior to September 2019.
After a long gestation, protracted labour and difficult birth the RTS on strong customer authentication and common and secure open standards of communication has arrived. The hard work of growing up has only just begun.