PSD2 – Update and new developments

| 17-8-2017 | François de Witte |

Early 2017, I published a post about PSD2, a lot of opportunities, but also big challenges. Now half a year later, I would like to update you on some developments in this area. PSD2 still needs to be transposed in the national legal system of all the member countries, and according to my knowledge several countries, including Belgium, have not yet released the draft laws. This creates quite some uncertainty in the market, as there will be several country-specific specifications. Hence one can expect that Fintech’s and other TPPs might already have started their certification application in countries that already enacted PSD2 in their local legislation.

LIST OF ABBREVIATIONS USED IN THIS ARTICLE

2FA: Two-factor authentication
API:  Application Programming Interface.
EBA: European Banking Authority
PSP: Payment Service Provider
PSU: Payment Service User
RTS: Regulatory Technical Standards (final draft issued by the EBA on 23/2/2017)
SCA: Strong Customer Authentication
TPP: Third Party Provider

Main updates on the regulatory framework

On 23 February 2017, the EBA published the final draft on the SCA (Strong Customer Authentication) and Secure Communication.
In this final draft, the EBA clarifies the new rules to be followed for customer authentication, applicable both for operations performed in traditional channels and over the new API (Application Programming Interfaces) services. The key clarifications concern the following:

The 2 factor authentication

Following systems would comply:

1. The 2-device-authentication, where the user has two independent devices:

• one device to access the banking website or app
• another device to authenticate himself or a payment: the authentication device, usually a hardware authentication token, a combination of a smart card and smart card reader, or a dedicated app on a mobile device.
  The authentication device generates one-time passwords (OTPs) over transaction data

2. The 2 app authentication:

This approach does rely on two different apps running on the same mobile device.

• Banking app : when a user wants to make a payment, he opens the banking app and enters the transaction data.
• Authentication app: When the user has submitted the transaction, the banking app opens the authentication app. After verification and confirmation of the transaction data by the user, the authentication app generates an OTP (One Time Password) linked to the transaction data and sends it back to the banking app, which submits it to the banking server for verification

The dynamic linking

In order to dynamically link the transaction, the draft RTS states the following requirements must be met:

• the payer must be made aware at all times of the amount of the transaction and of the payee;
• the authentication code must be specific to the amount of the transaction and the payee;
• the underlying technology must ensure the confidentiality, authenticity and integrity of: (a) the amount of the transaction and of the payee; and (b) information displayed to the payer through all phases of the authentication procedure (the EBA hasn’t specified the nature of this “information”);
• the authentication code must change with any change to the amount or payee;
• the channel, device, or mobile application through which the information linking the transaction to a specific amount and payee is displayed must be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.

The exemptions from the SCA

The exemptions from the SCA including also:

• Transactions between two accounts of the same customer held at the same PSP
• Low risk transactions: Transfers within the same PSP justified by a transaction risk analysis (taking into account detailed criteria to be defined in the RTS),
• Low value payments or contactless payments < 50 euro, provided that that the cumulative amount of previous consecutive electronic payment transactions without SCA, since the last application, of the SCA < 150 euro
• Unattended transport and parking terminals

The draft RTS (not finalized, not approved yet) also states that Screen scraping is no longer allowed. Screen scraping is a method to take over remotely the data on the screen of the user. This creates a lot of opposition in the financial community, in particular the Fintech’s, as this complicates the interaction between the bank, the TPP, and the PSU. On the other hand, the both the EBA and the EBF (European Banking Federation) are against it. There is a power game ongoing.

Main developments

Banks will have to implement interfaces, so they can interact with the AISPs and PISPs. This compliance with PSD2 is mandatory and all banks will have to make changes to their infrastructure deployments.

Although PSD2 does not specifically mention the API (Application Programming Interfaces), most technology and finance professionals assume that APIs will be the technological standard used to allow banks to comply with the regulation.

An API is a set of commands, routines, protocols and tools which can be used to develop interfacing programs. APIs define how different applications communicate with each other, making available certain data from a particular program in a way that enables other applications to use that data. Through an API, a TPP application can make a request with standardized input towards another application and get that second application to perform an operation and deliver a standardized output back to the first application. For example, approved third parties can access your payment account information if mandated by the user and initiate payment transfer directly.

In this framework, the challenge is to create standards for the APIs specifying the nomenclature, access protocols, authentication, etc.”. Banks will have to think about how their new API layers interact with their core banking systems and the data models that are implemented alongside this.

At this stage, following working groups were constituted to further elaborate on these standards:

• UK’s Open Banking Working Group (OBWG). This initiative of UK Treasury aims to deliver a framework for open banking and data sharing via APIs for the UK’s banking industry. The joint industry/government initiative recently released its report on establishing the framework for an Open Banking Standard for the UK alongside a timetable for implementation.
• The Berlin Group, a-European payments interoperability coalition of banks and payment processors, is pushing for a single standard for API access to bank accounts to comply with new regulations on freeing up customer data under PSD2. The aim is to offer operational rules and implementation guidelines with detailed data definitions, message modelling and information flows based on RESTful API methodology. It will be published for consultation in Q4 2017
• STET has also released of a RESTFUL API standard which will allow TPPs to access payment accounts. This API has been built with the latest technology standards using REST, OAuth2, JSON and HTTP-signature. It relies on ISO 20022 elements for structuring the data to be exchanged between TPPs and ASPSPs

In the meantime, several providers are developing their services, including in the Benelux Equens Worldine, Capco, Sopra Banking and Isabel.

Along with the arrival of open API banking, there is also clear momentum for providing real-time services such as “instant payments”. This requires banks to shift their entire product and service mindset towards immediate delivery and to make fundamental changes to their legacy systems. While this is a challenge, it also presents opportunities (see also my article in TreasuryXL on this topic: SEPA Instant Payments – a catalyst for new developments in the payments market (https://www.treasuryxl.com/news-articles/francois-de-witte/sepa-instant-payments-catalyst-new-developments-payments-market and https://www.treasuryxl.com/news-articles/francois-de-witte/sepa-instant-payments-a-catalyst-for-new-developments-in-the-payments-market-part-ii/).

The large banks have already started working on being PSD2 compliant and on building for the opening of their banking architecture to the TPPs. However, several small or medium sized banks only started recently on this project. Hence a lot has to be done, and I do expect some shortages in resources in the next coming months.

With regard to the access to TPPs, article 113.4 of PSD2 explicitly states that the member states shall ensure the application of the security measures with the 18 months following the entry in force of the Hence, we might expect that this part of PSD2 needs only to be implemented by mid-2019. Given the strategic importance and the IT act, I recommend starting this exercise much earlier.

Conclusion

The PSD2 creates challenges. Several topics need to be clarified such as the RTS and the market players need also to agree on common standards for the interfaces.
However, there are initiatives, such as the Berlin Group, the UK’s Open Banking Framework and the STET group, which help give further clarity and direction in the absence of specific technical detail.
Consequently, there is no justifiable reason for any bank to delay starting these projects.
The clock is ticking in the PSD race.

If you want  further update on this topic, you can join the 1 day training session on this topic, which I will give on 22/11/2017 at Febelfin Academy.

 

François de Witte – Founder & Senior Consultant at FDW Consult

[button url=”https://www.treasuryxl.com/community/experts/francois-de-witte/” text=”View expert profile” size=”small” type=”primary” icon=”” external=”1″]

[separator type=”” size=”” icon=””]

Please read my earlier articles on PSD2:

PSD 2: A lot of opportunities but also big challenges (Part I)

PSD 2: A lot of opportunities but also big challenges (Part II)

Sepa instant payments – A catalyst for new developments in the payments market (Part I)

Sepa instant payments – A catalyst for new developments in the payments market (Part II)

[separator type=”” size=”” icon=””]