Payment Service Directive II -Technical specification and implications

• PSD II defined business requirements of account access by third parties

• Technical specifications of access and open communications protocols

• The authentication of users of the third party’s is the key issue

The amendment to the Payment Service Directive (PSD II) follows the European regulator’s intention to further strengthen competition in the field of payment services.  Initiatives taken by financial institutions such as the ZOB interface (Central on-line banking interface) or FinTS (Financial Transaction Services), led to a variety of reasons for insufficient market acceptance.

For this reason, the banks under PSD II should grant third payment service providers  access to the account information and features in on-line banking and provide a technical interface for this purpose.

The second version of the Payment Service Directive is currently in the regulatory and technical specification phase of the EBA. Key points of this specification process will have a massive impact on the IT infrastructure of banks and future business processes. Although PSD II does not have to be implemented before 2018 it compels already on the part of banks, the need to prepare for the reactions and the strategic orientation for dealing with the situation in the new payments market.

Payment Service Provider and roles of PSD II

For basic understanding, it is essential to grasp the scope and focus of PSD II. PSD II focuses on three main roles of payment service (so-called Payment Service Providers), which offer respective payment services (Payment Services). It defines three payment services: a Payment Initiation Service (PIS) to initiate payments, an Account Information Service (AIS) to query account information and a Payment Instrument Issuing Service (PIIS) for retrieval of funds in the account information when using a payment instrument.

Figure 1: The Payment Service Directive II (Access to Account) sets the framework for three specific services

The three payment services include functions which the purchaser (Payment Service User – PSU) can also access via his on-line banking or previously could only use. The provision of these services by a third party is subject to the ability of the on-line payment account. In its simplest form, thus the Payment Services can be called a long arm of a third party who acts on instructions from the PSU.

Processes of PSD II

The provision of an interface by the banks to allow account access via third party requires all participants to implement processes which govern access to the account clearly and thus for standardized communications. PSD II defines herein foremost bonds and demands of the payment participants, however, does not specify communication sequences of such an interface. Accordingly, several variations of such processes are imaginable, covering the required functional spectrum of PSD II.

The preparation on the part of account providers thus requires profound engagement with PSD II on a functional-technical level. Understanding the underlying payment and communication processes is an essential advantage in the effective preparation of the IT systems and enables future-proof planning adjustments.

Authentication and authorization

The central theme of the PSD II that does not remain entirely detectable at least until the publication of the Regulatory Technical Specifications (RTS) is  the question of the authentication of the payer. It is particularly unclear who in which case carries out an authentication of the PSU and has thus to verify the identity of the PSU. Especially in light of potential liability issues in the event of fraud or failure of the process of this aspect the PSD II is the subject of great discussion to clarify an important open point. PSD II calls for authentication and authorization of actions on account, so far quite general, the use of open standards by all payment process participants. Several variants of these open standards, such as a token-based authentication and authorization by the account holding bank, are under discussion.

Technical risks

PSD II offers because of the focus on requirements and responsibilities sufficient scope for design measures. These outstanding issues naturally go hand in hand with risks, which are to be defined in their dimensions and to identify who bears responsibility. Although PSD II already provides specific information on documentation requirements and compensation periods, other liabilities and charges remain unclear. The special behaviour in case of detected fraud cases – particularly by PSPs – for example, is still unclear. The increased load by partially automated requests for the banks, for example, and the associated potential attack scenarios through denial of service attacks represent major obstacles, to which the banks and payment service providers have to adjust at an early stage. Timely knowledge of the requirements and technical implications can help here: both in preparing for the implementation phase as well as for the benefit of strategic moments.

The obligations imposed on banks for strategic opportunities are therefore to be kept also in mind  and should accompany the reflection on the regulatory requirements. For this purpose, on the one hand involves using the Payment Services by the banks themselves and, consequently, also the use of the data; on the other hand the provision of higher quality services effectively. The monetization of premium content for third party service providers as a payment hub or infrastructure provider is also conceivable. The existing and usable synergies of the two current areas of development technology and market can be extended by a third dimension to the regulatory provisions, here prominently represented by PSD II. the foundations are already laid for their positive use and preparation for Payments in 2020.