Interaction between PSD2 standards and e-ID rules clarified

In financial services, innovation can be put in jeopardy if customers cannot trust that new solutions being developed are secure or if mandated security standards cause the customer experience to be clunky.

It is not easy to balance robust security with a smooth customer journey, but there are standardisation groups working to do just that. Their work needs to be aligned internationally at a technical level to ensure the different security protocols they develop can work in tandem, while their voice must also be heard by law makers and regulators before security requirements are set.

The interaction between regulatory standards set under EU payment services laws and EU-endorsed solutions for electronic identification (e-ID) provides a good example of the tension between work carried out by standardisation bodies on security and parallel work on mandating new security requirements. It is a topic that has been addressed in a new opinion by the European Banking Authority (EBA), and in recent work by the API Evaluation Group, set up earlier this year by the European Commission and the Euro Retail Payments Board (ERPB) of the European Central Bank (ECB).

PSD2 and the e-ID framework

When the second Payment Services Directive (PSD2) began to apply across the EU earlier this year, a raft of new third party account information and payment initiation services became regulated for the first time. While the reforms, promise to deliver widespread innovation and shake up competition for payment services, much of the progress that is still to come is currently being held up as incumbents like banks and credit card providers, as well as fintechs, retailers and other newcomers to the market, grapple with complex regulation.

PSD2 provides new rights to account information service providers (AISPs) to access payment accounts, like current accounts, and statement details, as well as other account information, held by banks and other account servicing payment service providers (ASPSPs), and to payment initiation service providers (PISPs) to initiate payments, where customers consent. These rights of the third parties are governed by regulatory technical standards which expand on the provisions in the directive.

The 'strong customer authentication' standards, developed by the EBA, were written into EU law in March, but the majority of the provisions will not apply until 14 September 2019. Under those standards, ASPSPs must either enable third party access to the data through the customer's normal online banking websites, or alternatively develop a new 'dedicated interface' (API) for that purpose.

To ensure that data is accessed by third parties securely, third parties are required to identify themselves to ASPSPs. The 'strong customer authentication' standards require that, for the purpose of identification, payment service providers “shall rely on qualified certificates for electronic seals ... or for website authentication” as provided for under the EU’s regulation on electronic identification and trust services (eIDaS).

The standards also require data exchanged between ASPSPs and AISPs or PISPs to be subject to “secure encryption ... throughout the respective communication session”.

In its new opinion, the EBA has tried to clarify aspects of the use of qualified certificates for electronic seals (QSealCs) and qualified certificates for website authentication (QWACs) under the 'strong customer authentication' standards.

eIDAS certificates

As the EBA has explained, QSealCs and QWACs serve different purposes. It has recommended payment service providers use both "in parallel" to ensure they comply with the PSD2 standards, although it said there are alternative options available.

QSealCs are used to electronically seal data and ensure the “integrity and correctness of the origin” can be authenticated. In the case of their application under the PSD2 standards, this means these certificates can be relied upon for evidencing that the payment provider named under the certificate is who they say they are.

However, the EBA said QSealCs “do not provide confidentiality of the data” when the information is being exchanged and that therefore their use on their own, without an accompanying QWAC or "an additional element that ensures secure communication”, does not comply with the 'strong customer authentication' standards.

QWACs provide for “confidentiality, integrity and authenticity of all data transferred” during the transit stage. However, the EBA said they cannot be relied upon for authenticating the origin of the data and therefore “do not give legally assumed evidence of a transaction".

According to the EBA, ASPSPs should select which eIDAS certificate or certificates to use for identifying AISPs or PISPs, and not the third parties.

Many ASPSPs are preparing to act as AISPs or PISPs too, and the EBA's opinion provides further guidance on who is responsible for eIDAS certificates, and the number of different certificates that might be applied, in these circumstances.

Technical service providers

Often the business which holds the customer relationship will not be the party that directly accesses the data from the customer's account. Instead it will be a technical service provider acting on its behalf that will perform the task of accessing the data.

The EBA, in its opinion, clarifies that where an AISP or a PISP uses a technical service provider, it should consider using multiple certificates simultaneously – with each one tied to each technical service provider. The EBA views this as an appropriate business continuity and risk management step to take in relying on technical service providers. As regulated entities, all businesses using technical service providers should be aware that they remain fully responsible, liable and potentially subject to regulatory enforcement for any failures of their outsourcing providers.

The UK’s open banking regime

In the UK, it is not just the PSD2 rules and standards that need to be considered by industry.

The 'open banking' framework has been implemented in parallel and similarly provides for the use of open 'application programming interfaces' (APIs) to link the systems of third parties into those operated by banks in a secure way.

Work on the open banking standards pre-dated the finalisation of the PSD2 regime. It has meant that the Open Banking Implementation Entity (OBIE) has had to rethink the technical standards it first mandated to accord with the rules and standards from Europe.

At the end of November, the OBIE published version 3.1 of the open banking standard. It contains updates on, among other things, the use of eIDAS certificates.

A better approach to security standards

The concerns raised about the conflict between use of some eIDAS certificates in online banking, as highlighted in the API Evaluation Group’s paper, is a good example of why a great deal of thought is needed before technical security requirements are hard-wired into regulation.

In this case it is clear that businesses in the payment services market are just as concerned about the impact on customer experience of using eIDAS certificates as they are about security, as mandated in the ‘strong customer authentication’ standards under PSD2.

The establishment of bodies such as the API Evaluation Group with high levels of technical knowledge is a positive step forward and one that in future should be taken before technical security requirements are set in stone.

Not only will this help ensure that industry initiatives are aligned, it will help ensure security standards set in regulation are future-proof and not subject to becoming obsolete in an era where this risk is growing as technology changes.

Luke Scanlon is an expert in financial services and technology at Pinsent Masons, the law firm behind Out-Law.com.