Aligning PSD2 and GDPR - Finance Dublin Magazine

With two potentially conflicting compliance requirements coming into force in 2018 many FS organisations are opting to stay on the sidelines. But Mazars partner Liam McKenna says there are still a lot of questions to be resolved.

The Revised Payments Services Directive (PSD2) and the General Data Protection Regulation (GDPR) will both affect financial services organisations in 2018. Most organisations have distinct programmes underway for these two compliance requirements.  Based on the PSD2 and GDPR work we are completing with organisations at present we see a number of areas of overlap that need addressing:

  1. PSD2 references the need for explicit consent (Article 94.2) when processing personal data. While explicit consent may be required, does this mean it has to be the basis for PSD2 processing? The data subject has increased rights under GDPR where processing is based on consent. But clients are grappling with the question of whether the various elements of processing, while requiring consent, have an alternative legal basis such as legitimate interest, legal obligation or the performance of a contract?
  2. For organisations providing services to children, GDPR requires the consent of the child’s parent or guardian. What are the implications for organisations that provide online accessible accounts to children? If the organisations do not allow open access to these accounts (XS2A) this would appear to be noncompliant with PSD2. The alternative, of obtaining parental consent, would be very challenging. The approach followed will be affected by local legislation, which may define a child as under 16 or under 13. In jurisdictions where a child is defined as under 13 it may make sense to restrict the services that are provided to under 13s.
  3. What consent is required to support the Account Information Service Provider (AISP) model for a joint account? Will both parties to the account need to consent? Extending this question, what happens to the payment data of counterparties to payments? The counterparties will not have provided consent, so can their personal data be shared with an AISP? The large AISPs (e.g. large incumbent banks that act as AISPs) could have the data that would allow them to build profiles of individuals who are not their customers using customer AISP related data.
  4. Explicit consent is required to process sensitive personal data under the GDPR (Article 9). Where a payment service user includes sensitive personal data in a payment narrative will a different consent process be needed? Or alternatively, do organisations need to assume sensitive data will be included in narratives and plan accordingly? Of course, the introduction of the term 'sensitive payment data' into PSD2 adds to complexity given that this term is not adequately defined.
  5. The GDPR (Article 17) provides a right to erasure, also known as 'the right to be forgotten'. In the event that a data controller has made the data public, the controller will need to inform other controllers. Can organisations confirm that sharing data with an AISP is not considered making it public?
  6. PSD2 deliverables will be introduced both before and after the May 2018 deadline for GDPR. Deliverables implemented post May 2018, GDPR (Article 25) require data protection by design and default. Is implementing the RTS on Strong Customer Authentication and Secure Communications enough to satisfy this requirement? Will a data protection impact assessment (GDPR Article 34) be required prior to implementing the third parties payment (TPP) models? It will be interesting to see if data protection commissioners, as the GDPR allows for, have a view on this, especially if the TPP model is delayed until 2019.
  7. Both GDPR (Article 33 & 34) and PSD2 (Article 96 and related guidelines) require incident reporting. It would make sense to define one process that takes account of all of the possible notification requirements, data subject, data protection supervisory authorities and payments services national competent authorities.

The above focuses on the challenges, there may also be synergies, e.g. using the Open API gateways to facilitate data portability under GDPR. One thing is certain, we are in for an interesting year. These are just some of the points to consider. Individuals within FS organisations invariably have strong opinions on the questions raised and have formed views on the logical solutions. However, having spoken to many of these people, it is clear to us that the opinions differ. As a result, organisations are delaying for as long as possible to enable industry and regulatory positions to be formed. If clarity on the date when XS2A is required can be secured, and the date is aligned to the RTS on SCA, we can breathe easier and have the luxury of developing a left to right plan. If we need to continue to plan for XS2A on January 13th 2018 we are in for a torrid six months. Hopefully the answer is known by the time you are reading this article!

This article first appeared in Finance Dublin magazine May 2017.