More information about PSD2

The PSD2 Directive, a strategic turning point for the banking sector

PSD2 goes further by extending the scope of PSD1 to payments in all currencies, and to payments where only one provider is located in the EU/European Economic Area.
PSD2 defines a new group of actors, the Third Party Providers (TPPs) that are permitted to provide certain types of services connected to payments. Customers will be allowed to initiate payments at their financial institution via authorized TPPs, to whom financial institutions will be obliged to open up their application interfaces and data. The Regulatory Technical Standards (RTS) which define how FinTechs will connect to Banks, will become applicable only in September 2019.

PSD2 - Choose your strategy

Why PSD2 ?

The retail payments market has experienced significant technical innovation since the introduction of PSD1 with a rapid growth in the number of electronic and mobile payment solutions as well as new types of providers and services.
Many innovative payment products and services have been introduced in particular in cards, e-commerce and mobile payments.
The objective of PSD2 mainly consists in protecting citizens and controlling the development of these new services by:

  • Increasing the safety of payment transactions and payment services,
  • Promoting payment innovation and adjusting legal requirements to all stakeholders.

New players in the payments sector

PSD2 introduces two new types of TPPs: the Payment Initiation Service Providers (PISPs) and the Account Information Service Providers (AISPs).
A payment initiation service is defined as a service to initiate a payment order at the request of a PSU with respect to a payment account held at any bank in the European Union. Payment initiation services enable the PISP to give the payee the comfort that the payment has been initiated, confirming to the payee to release goods or deliver a service without undue delay.
An account information service is an online service to provide consolidated information on one or more payment accounts held by a PSU with another PSP or multiple PSPs. These aggregators have been widely developed in Europe (Linxo and Bank’in in France, Tink in Sweden, Spiir in Denmark and Fintonic and Eurobits in Spain, Figo in Germany). In order to stand out, these platforms develop other valuable services such as the management of personal finances (budgeting and spending analysis), or document management (invoices, expense reports, etc.). The client is at the center of the strategy of these new players, with a goal to facilitate the user experience through innovative and intuitive new apps.

More about the "web-scraping"

Currently the AISPs and PISPs use the technique known as "web-scraping" to aggregate information from multiple banks.
This technique of "web-scraping" is a technique of extraction of the website content via a script or a program that will read the html code, in order to transform it to allow its use in another context. This method is used, for example, by the price comparison sites (trivago.co.uk, liligo.com).
In this case, a TPP will ask the client (PSU) their credentials to connect to the bank online banking application). It will then integrate them into a program that will act as a robot, simulating the connection action to the customer.
The web-scraping leads to several problems:

  • For ASPSP, the robot can trigger many connections, saturate the servers of the bank or consume expensive resources (e.g. mainframe MIPS)
  • For TPPs, one program per bank should be developed. When a web page changes, the robot must be adapted
  • The technique does not work when the Bank has set up a secured connection with OTP (One-Time Password)
  • For the user, by giving their code and password, the TPP has access to all their accounts and banking information, not just their payment accounts
  • Finally, the major problem of the webscraping" technique lies in the sharing of responsibility and the principle of proof.

Watch our video "screen-scraping versus APIs"»»

API, the EBA and banks’choice

Through APIs, banks will make available certain features of their information systems accessible to external developers.
These APIs define constraints and an interface that will determine how, when and what other platforms will have access to.
Building an API does not mean that everyone will have uncontrolled access to your data; It just means that you provide them with a well-designed method to access particular items and services. You have control!
These APIs constitute a new channel for banks in the same way as websites and mobile. They will enable banks to generate new revenues based on the data provided.

Security, a major issue

PSD2 introduces two major requirements about security: secure connection with the TPP and strong customer authentication (SCA).

Secure communication

The bank must clearly authenticate the sender of the request, in other words check that the sender is the one he claims to be. This will be achieved through EBA register of TPPS and certificate authorities called QTSP (Qualified Trust Service Provider). The exchanged messages must be encrypted between the different entities. The bank must also check that the sender is authorized to access customer data.

Strong customer authentication

PSD2 requires a strong or 2-factor customer authentication (2FA) using two or more elements out of the following three:

  • Knowledge: something only the user knows (e.g. a password or PIN),
  • Possession: something only the user holds (e.g. a card or a token), and
  • Inherence: something only the issuer is (e.g. a finger print or voice).

The elements must be independent of each other, so that a breach of one does not compromise the reliability of the others, and they must be designed in a way to protect the confidentiality of the authentication data.
The SCA will be systematically implemented for any request that doesn’t fall into the list of SCA exemptions.