Skip to content

The EBA’s Regulatory Technical Standards Provide the “How” to PSD2’s “What”

Regulatory Technical Standards for PSD2

February 2017 saw the release of the long-awaited draft regulatory technical standards (RTS) for strong customer authentication (SCA) from the European Banking Authority (EBA). The RTS defines the technical framework for the implementation of PSD2 with primary focus on SCA, and common and secure connection (CSC). In short, we could say that PSD2 covers the “what” aspect of the regulation whereas the RTS defines the “how” this is to be done.

Function over form? European Commission amendments to RTS for SCA

In June, the commission suggested several amendments to the RTS that addressed concerns around the auditing of transaction risk analysis and the addition of a new exemption from SCA for certain corporate payment processes. The amendments also proposed direct access for the EBA to fraud reports from PSPs in addition to aggregated data provided by competent authorities (national financial regulators). Finally, as an additional safeguard for third-party payment service providers (TPPs), the revisions clarified that should the unavailability or inadequate performance of the dedicated communication interface occur, banks would be expected to offer secure communication through user-facing interfaces as a contingency measure.

The final text of the RTS was confirmed on November 27 and submitted to the European Parliament for deliberation before being published in the official journal of the European Union. Scrutiny will begin in earnest in February 2018 and could last between three to six months. With PSD2 on its way in January, the European Commission has confirmed the deadline for compliance to the RTS will actually start in September 2019.

The ratification process up to this point has consisted of a fine balancing act between functional and non-functional requirements, with all parties trying to find a compromise position on the RTS. Depending on which side of the aisle you sit, be it incumbent (banks), TPPs or merchants, there are inevitably good and not-so-good things in the RTS. However, this notion of non-functional requirements (NFRs) is well established in software development and forms the backbone of common standards around which the final RTS rests.

Finding common ground on non-functional requirements

Non-functional requirements of a payments system typically include system performance, availability and security. For a banking application, a major non-functional requirement is availability of the application 24/7 with zero down time. Hardening systems, adding in redundancy, resilience and, above all, added security are all NFRs on which the commission and EBA have been striving to seek common ground.

The security measures outlined in RTS stem from two key objectives of PSD2: “ensuring consumer protection and enhancing competition.” The RTS introduces requirements that payment service providers (PSPs) “must” observe when they process payments or provide payment-related services. In the context of competition and innovation, RTS includes two new types of services, the “so-called payment initiation services” and the account information services.

The commission says it made some “limited substantive amendments” to the draft RTS submitted by the EBA. This was done to “better reflect the mandate of PSD2 and to provide further clarity and certainty to all interested parties.”

PSD2: A quick recap

Looking back at the original brief of PSD2 which set out the framework for the RTS, it is important to remember the main tenets of the directive.

The implementation of PSD2 is intended to make it easier, faster and less expensive for consumers to pay for goods and services by promoting innovation (especially by third-party providers), enhancing payments security and standardizing payment systems across Europe. PSD2 uses three mechanisms to achieve this:

  • First, it expands the regulatory purview of the European Union to include new kinds of providers, such as payments initiation and account information services.
  • Second, it imposes limitations on transaction fees and stricter rules on refunds to lower transaction costs for consumers.
  • Third, and the most disruptive, it requires European banks to open their payments infrastructure and customer data to third-party providers of financial services.

This last mechanism has arguably been the most contentious and the amendments from the commission go some way to easing the burden on corporate players at the very least with regard to direct access. TPPs will be granted consented access to customer information through the banks’ infrastructure to deliver new value-added services.

Ensuring European payment mechanisms are fit for purpose

To enable bank account access (often referred to as payments initiation and account information services, or XS2A for short), banks are required to offer a communication interface for TPP requests. This TPP interface should have the same functionality and deliver the same level of support as for customers transacting directly with their bank. The EBA has suggested the use of ISO 20022 as a potential candidate for the interface format, but the RTS does not provide any prescriptive guidance on how exactly XS2A is to be implemented.

Thankfully, individual country regulators have been issuing implementation and compliant handling guidelines for a few weeks now, so the need to “interpret” the new regulations has been lessened somewhat. Regardless of the adoption challenges ahead, PSD2 and the RTS in particular, are sorely needed to ensure the European payment mechanisms are fit for purpose for the coming decade.