While most of the Nordic countries were on holiday in the month of July and well into August, the European Banking Authority (EBA) was working hard to finalise its most recent proposal to increase clarity for stakeholders on the PSD2 regulation.
More specifically, the focus has been on Article 98 of PSD2, which requires the EBA to develop draft Regulatory Technical Standards (RTS) “ensuring an appropriate level of security for payment service users and payment service providers”. More specifically, the RTS should specify:
the requirements of strong customer authentication (SCA),
the exemptions from the application of strong customer authentication,
the requirements with which security measures have to comply in order to protect the confidentiality and the integrity of the payment service users’ (PSU) personalised security credentials, and
the requirements for common and secure open standards of communication between account servicing payment service providers (ASPSP), Payment Initiation Services (PIS) providers, Account Information Services (AIS) providers, payers, payees and other payment service providers.
The regulator released the result of its work on 12 August, in a consultation paper “On the draft Regulatory Technical Standards specifying the requirements on strong customer authentication and common and secure communication under PSD2”.
So what are the issues hiding behind this title? It sounds like a paper for “the techies” to make sure they take care of security issues, but it is much more than that. While the document contains more than enough technical details for the average business reader, it also sheds more light on the long awaited answer to a key, strategically important question for those wanting to create services to compete with the banks. That question is:
“What account information will the incumbent banks, known as “ASPSPs” in PSD2, have to make available to new third-party players: the PISPs and the AISPs?”
And the short answer is: “everything”.
Or in the EBA’s own words:
“ASPSPs shall ensure that their communication interface is offering the same functionalities and the same level of availability, including support, as the online platform made available to the payment service user when directly initiating the payment transaction or directly accessing the information online. […] If the access is offered via a dedicated interface, this dedicated interface would offer the same service level as the online banking platform of the ASPSP, addressing the concerns that AIS/PIS providers have raised […] in relation to the potential lack of availability or the lack of resources invested by ASPSPs to maintain and/or to provide technical support for accessing such dedicated interface;”
And if this is not clear enough, the EBA goes on to set out the requirements further, stating that:
The data elements made available […] shall consist of the same information as the information made available to the payment service user when directly accessing the information of a designated payment account online or when directly initiating a payment transaction. The EBA is proposing this requirement to ensure that, if the access is offered via a dedicated interface, this dedicated interface will offer the same level of data as the online banking platform of the ASPSP, addressing the concern that AIS/PIS providers have raised […].
In other words, the EBA has, quite understandably, not specified in the standards themselves each and every piece of information that should be made available to providers of account information services. Instead, it simply states that the information available through a bank’s online platform should also be made available to third-party providers.
For detailed specifications of the communications interface, the draft proposes that “players shall use ISO 20022 […] if available.” This gives further direction since the ISO 20022 standard already describes the information or “messages” to be exchanged in the payment business domain in an extensive and detailed way.
A hard deadline on 31 October 2016 for its adoption on Euro transactions is currently driving a wider adoption of the scheme for domestic and crossborder transactions in other currencies as well. __This greatly facilitates its use for PSD2 purposes. In addition to what information should be exchanged, an important, related question is how often the providers of account information services can access the account information from the bank. The consultation paper also brings greater clarity on this point:
AIS providers shall request information from designated payment accounts and associated payment transactions each time the payment service user is requesting such information or, where the payment service user is not actively requesting such information by connecting to the AIS, no more than two times a day. The EBA is proposing this requirement to address the concern raised by some ASPSPs that AIS providers may make continuous and possibly automated account information requests, which could impact negatively the availability of the ASPSP’s online platform.
In other words, account information service providers should be allowed not only to access full information upon the user’s direct request, but also to access account details independently of this, twice a day.
Further proposals on how to implement the interaction between the various players are also given, summarised in the following points:
Each ASPSP shall offer at least one communication interface enabling secure communication with AISPs, PISPs, and PSPs issuing card-based payment instruments which shall be documented and freely available on the ASPSP’s website.
ASPSPs shall ensure that their communication interface allow PISP or AISP to rely on the authentication procedures provided by the ASPSP to the payment service user
ASPSPs shall ensure that their communication interface uses common and open standards which are developed by international or European standardisation organisations. In particular, […] the draft RTS propose that players shall use ISO 20022 […] if available.
ASPSPs, PSPs issuing card-based payment instruments, AISPs and PISPs shall ensure that, when exchanging data via the internet, secure encryption is applied […] using strong and widely recognised encryption techniques
On the question of secure identification, the EBA notes there is “a broad consensus for the use of certificates for ensuring identification between providers”. Although acknowledging some concerns with the use of the EU e-IDAS scheme, following a workshop with industry participants, it proposes the use of “website certificates issued by a qualified trust service provider under an eIDAS policy […] under the assumption that there will be qualified trust service providers designated under eIDAS by October 2018”. However, it asks specifically for further views on this topic, including potential fall-back scenarios in case the previously mentioned assumption does not hold true.
So what are the next steps?
With bankers and other industry players coming back refreshed from holidays, they have until October 12 to respond to the consultation paper and through this, seek to influence EBA’s final proposal. There will also be a public hearing in London on 23 September.
The EBA will then assess the responses, make changes where appropriate, and publish the final draft RTS within 12 months of entry into force of the Directive, i.e. by 12 January 2017. After that, the process moves to Brussels and the EU Commission, which has the final say. The RTS will not be applicable until 18 months after its adoption by the EU Commission. This suggests an application date of the RTS of October 2018 at the very earliest. According to the EBA, “the intervening period provides the industry with sufficient time to develop industry standards and/or technological solutions that are compliant”.
Given the on-going consultation and the subsequent EU Commission processes, we have not yet had the final word on these regulatory technical standards and there still seems to be room for interpretation and clarification.
For example, even if the draft technical standards propose the use of the ISO 20022 standard and the content of the ISO messages is well defined, the draft standards do not specify which ISO messages should be used, nor do they state that the full content of the messages should be exchanged. On the contrary, the draft standards state that “the same information made available to the payment service user” should be made available to the thirdparties. Seasoned bankers know that what is “made available to the user” is often quite different from the full information set linked to a transaction and an account. Furthermore, there could be differences between banks and markets on what is “made available to the user”. Without a uniform view of exactly what should be exchanged, there will still be heterogeneity between players and markets, adding complexity. This is likely to cause some debate and controversy.
However, as the draft technical standards are based on previous industry and stakeholder feedback, it is to be expected that the key elements will remain unchanged after the consultation. Any wishful thinking incumbent banks may have had that new players will fail to get the information they need to enable them to develop meaningful services can be forgotten once and for all. That means the proposal represents a confirmation that incumbent banks are likely to face unprecedented challenges from players trying to take over their key customer touchpoints. It also brings increased clarity to other service providers on how to navigate and adapt to the new world.
For a quick refresher on the key competitive dynamics introduced by the second Payment Services Directive, read the follow article from our previous edition here.
‘payment initiation service’ means a service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider;
‘account information service’ means an online service to provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider;
‘payment initiation service provider’ (PISP) means a payment service provider pursuing business activities as referred to in point (7) of Annex I; Payment initiation services
‘account information service provider’ (AISP) means a payment service provider pursuing business activities as referred to in point (8) of Annex I; Account information services
‘account servicing payment service provider’ (ASPSP) means a payment service provider providing and maintaining a payment account for a payer;