The revised Payment Services Directive (PSD2) aims to contribute to the development of the EU market for electronic payments, where consumers, retail operators and payment service providers will be able to enjoy advantages offered by the internal market of the European Union.

 

In particular, the new Community rules aim to:

• stimulate competition by promoting innovative payment methods,
  • imposing a supervisory obligation also for suppliers of non-traditional payment systems (e-commerce payments)
  • reducing entry barriers for some types of payment service providers
  • forcing banks to allow access to their Third Party Provider (TPP) infrastructures through standardized APIs (Application Programming Interfaces)
• protect the consumer and improve security in the use of payment services,
  • providing for more transparent transaction costs and a ban on the applicability of “surcharging” to the customer in the case of electronic payments
  • improving authentication procedures and data protection measures
  • Increasing customer protection in case of unauthorized payments.

Below is a non-exhaustive list of some of the new rules of law.

• The PSD2 introduces two types of TPP: the Payment Initiation Service Providers (PISP) ​​and the Account Information Service Providers (AISP). Banks will be required to allow access of their back-end systems to TPPs in the first case following requests for initialization of payment transactions₂,₃, in the second case to requests for information on accounts held by their clients (with their authorization).
• The PSD2 requires that “strong customer authentication” (SCA) measures be applied whenever, in carrying out payment transactions through traditional financial institutions or third-party suppliers, the service user:
  • accesses your online account
  • has an electronic payment transaction
  • performs any operation, through remote channels that involves a risk of fraud or abuse.

These measures involve the use of at least two independent factors: “knowledge” (security question, password), “possession” (token, personal device or “digi-pass”), “inherence” (fingerprint, retina data) ₄,₅,₆.

The publication of the RTS and the questions still open

The process of implementation of the PSD2 Directive has developed in a complex path. One of the main steps of this path is certainly the publication of the Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common Secure Communication (CSC), which took place on March 13^th, 2018. On June 13^th 2018 EBA published his Opinion on the “implementation of the RTS on SCA and CSC” ₇.

The definition of RTS and the related opinions are fundamental elements of the PSD2 framework, but the documents leaves some important issues open.

The text of the RTS will apply from September 14^th 2019, but as of March 14^th 2019, the “Account Servicing Payment Service Providers” (ASPSPs) will have to make the technical specifications of their access interfaces available to TPPs and provide them with a test environment to carry out tests of the applications that TPP will use to offer services.

The RTS only specifies that the ASPSPs must ensure that their interfaces follow the communication standards issued by international or European standardization organizations.

The Commission, recognizing that the lack of detailed requirements may lead to application problems, proposed the creation of the Application Programming Interface Evaluation Group (API EG) to evaluate the API specifications to ensure that they comply with the PSD2 and other applicable regulations (i.e. General Data Protection Regulation – GDPR).

The recommendations issued by the EG API will aim to create harmonized market practices among EU Member States in order to reduce implementation time and costs for the actors involved.

Further, open points with respect to the General Data Protection Regulation
The European General Data Protection Regulation (GDPR), which became enforceable in May this year, poses some additional questions regarding the PSD2, such as:

• Determine who is responsible for obtaining consent from customers to enable banks to share their payment information with TPPs.

This is because if PSD2 foresees that TPPs can directly access the customer’s payment account information, provided that they have their explicit consent, using banks’ infrastructure to facilitate provision of payment initiation or account information services.

Under the GDPR, banks are responsible for the processing of their customers’ data and are responsible for the purposes and the manner in which personal data are processed and shared.

PSD2 adds data protection requirements by stating that TPPs are permitted to access the information only for specific purposes “explicitly requested by the customer” related to the provision of account information or payment initiation services.

Therefore, considering these interacting requirements, it seems that while TPPs will likely initiate the process of securing customers’ consent, including consent for their own activities and use of the data once obtained, banks will ultimately remain responsible for confirming, or otherwise separately obtaining, the consent directly with their customers.

Furthermore, EBA in his recent Opinion required above expressed his conviction regarding the fact that, if an AISP or a PISP provides services to a Payment Service User (PSU) on the basis of a contract signed by both parties, then the ASPSPs do not have to check consent. It suffices that the AISP and PISP can rely on the authentication procedures provided by the ASPSP to the PSU, when it comes to the expression of explicit consent. From our point of view, it’s not clear how the banks can verify the will of their customers and how the contractual obligations are going to involve the bank. In this sense, a joint pronouncement by EBA and EDPB is desirable.

• Determine what constitutes “sensitive payment data”.
  The aforementioned RTS on SCA and CSC in PSD2 establish that banks must provide AISP with the same information made available to the customer₈,₉, when he accesses his own account information directly, if this information does not include “sensitive payment data”. Unfortunately, neither the RTS nor the PSD2 define the meaning of “sensitive payment data”, leaving to the discretion of the banks the task of determining which data they consider sensitive.

GDPR defines “personal data”, and therefore protects, such as any information relating to an identified or identifiable natural person. However, it also allows EU Member States to specify their own rules ” for the processing of special categories of personal data (‘sensitive data’)”, defined as personal data revealing racial or ethnic origins, political opinions, religious beliefs or philosophical beliefs, or union membership and processing of genetic data, biometric data.

The risk, in the absence of specifications on the point, is that the rule will be interpreted in a less restrictive way, facilitating access to additional and unnecessary information with respect to the purposes indicated in the standard increasing the risk of non-compliance.

It is necessary to change the pace
Further guidance by national and EU regulators is urgently needed on how companies can reconcile the requirements under PSD2 and the GDPR, both in the interim period and thereafter. It is desirable that companies manage the GDPR and PSD2 implementation programs in a coordinated way, taking into account reciprocal conditioning.

On the other hand, with the finalized RTS and the timing of implementation deadlines clarified, the companies should proceed quickly, clarifying their strategic positioning and then proceeding on the design and implementation of their communication interfaces, on SCA solutions, on the definition of operating models for the management of interaction with TPPs. All of these points will allow companies to face a rapidly-changing competitive environment such as the one enabled by PSD2₁₀.

David Mogini – Partner Deloitte Consulting

Michele Paolin – Partner Deloitte Consulting

 

Notes

1. This publication has been written in general terms and we recommend that you obtain professional advice before acting or refraining from action on any of the contents of this publication. Deloitte LLP accepts no liability for any loss occasioned to any person acting or refraining from action as a result of any material in this publication
2. The EBA also clarified in his Opinion issued on June 13^th 2018 that PISPs have the right to initiate the same transactions that the ASPSP offers to its own PSUs, such as instant payments, batch payments, international payments, recurring transactions, payments set by national schemes and future-dated payments.
3. The EBA also clarified in his Opinion issued on June 13^th 2018 that PISPs have the right to initiate the same transactions that the ASPSP offers to its own PSUs, such as instant payments, batch payments, international payments, recurring transactions, payments set by national schemes and future-dated payments.
4. The EBA also clarified in his Opinion issued on June 13^th 2018 that the two factors in SCA need to belong to two different categories (the categories being knowledge, possession, inherence).
5. The EBA also clarified in his Opinion issued on June 13^th 2018 that SCA has to be applied to access to payment account information and to every payment initiation, including within a session in which SCA was performed to access the account data, unless an exemption under the RTS applies.
6. The PSP applying SCA is the PSP that issues the personalised security credentials. Therefore, it is the same provider that decides whether or not to apply an exemption in the context of AIS and PIS. The ASPSP may, however, choose to contract with other providers such as wallet providers or PISPs and AISPs for them to conduct SCA on the ASPSP’s behalf and determine the liability between them.
7. On June 13^th 2018, EBA also published the document “Draft Guidelines on the conditions to be met to benefit from an exemption from contingency measures under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA &CSC)”.
8. The EBA also clarified in his Opinion issued on June 13th 2018 that, AISPs can access the maximum amount of data available to PSUs with regard to their payment account(s) help with a specific ASPSP regardless of the electronic channel used to access it. I.e. if there are more data available through a computer connection online than through a mobile app, the AISP is able to access, via the ASPSP’s interface, the data available on the computer online, regardless of the channel used by the PSU to access the AISP.
9. The scope of data to be shared with AISPs and PISPs by the ASPSP does not include the PSU’s identity (e.g. address, date of birth, social security number).

 

For further reading on this topic please visit

• PSD2 finalised standard on SCA and CSC: the wait is over, but questions remain
• PSD2 and GDPR – friends or foes
• PSD2 are firms ready
• The Open Banking era begins
• PSD2 standard on secure communication: a balancing act
• PSD2 RTS on authentication and communication | The devil is in the (lack of) details
• PSD2 – EBA dials up flexibility to achieve a more balanced approach
• PSD2 RTS on authentication and communication – EU Commission proposes amendments
• Le misure sulla sicurezza nei servizi di pagamenti definite da EBA RTS