PSD2 and GDPR

In the first half of 2018, two major new pieces of regulation will “go live” as the revised Payment Services Directive (PSD2) and the General Data Protection Regulation (GDPR) come into effect from January and May respectively. Seemingly unconnected, these two regulatory initiatives do in fact share two common aims – putting customers in control of their own data and keeping that data safe.

Both GDPR and PSD2 are built on the principle that individuals own their personal data and should therefore be able to choose how it is used and with whom it is shared. However, once one moves from the high-level principles to implementation, the challenges of reconciling the details of each regulation quickly become apparent. In our view, if left unattended, these challenges have the potential to jeopardise the successful implementation of PSD2.

This article focuses on two key issues: i) determining who is responsible for obtaining consent1 from customers to allow banks to share their payment data with Third Party Providers (TPPs) under PSD2; and ii) determining what constitutes “sensitive payment data”.

Customer Consent

As explained previously, under PSD2 TPPs will be able to access the customer’s payment account information directly, provided they have the customer’s explicit consent, and use banks’ infrastructure to facilitate provision of payment initiation or account information services. In principle, this marries perfectly with the right to data portability introduced by GDPR, but in practice the key question about which party should obtain the customer’s consent is currently unanswered.

Under data protection regulations, banks are the data controllers of their customers’ information and are responsible for the purposes and the manner in which personal data is processed and shared. Under GDPR’s guidance on portability, data controllers are responsible for implementing safeguards “to ensure that they genuinely act on the data subject’s behalf”. PSD2 adds additional data protection requirements by stating that TPPs are only permitted to access information for the specific purpose(s) “explicitly requested by the customer” relating to the provision of the account information or payment initiation services, and not for any other reason.

Considering these interacting requirements, we believe 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. This will probably include confirming details such as the identity of the TPP customers wish to share data with, what data they wish to share, how frequently, and when such consent will expire. Such a two-part process, first to obtain and then to confirm consent, has the potential to provide greater protection to TPPs, banks and customers, than banks relying solely on the consent provided by the TPPs.

Our view is in line with the draft APIs specifications recently published by the UK’s Open Banking Implementation Entity. While the Open Banking API standards, which will become effective from January 2018, will only be mandatory for the nine largest UK banks2 and apply to a more limited number of products than PSD2, the Financial Conduct Authority (FCA) and HM Treasury (HMT) are encouraging all banks and TPPs to adopt these standards as the basis for the safe and effective sharing of banking data. We believe banks and other players across Europe will be watching these standards with interest and we may see others outside of the UK aligning themselves voluntarily to these standards.

Sensitive Payment Data

The current draft Regulatory Technical Standard (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (SC) under PSD2 states that banks will have to provide Account Information Service Providers (AISPs) with the same information available to the customer when directly accessing their account information, provided that this information does not include “sensitive payment data”.

Unhelpfully, neither the RTS nor PSD2 primary legislation defines sensitive payment data. The RTS states only that it includes all data, including personalised security credentials, which can be used to carry out fraud, but leaves it at the banks’ discretion to determine which data they consider sensitive.3

GDPR defines “personal data”, and therefore protects, as any information relating to an identified or identifiable natural person, who can be identified, directly or indirectly, including by reference to an identifier such as a name, an identification number, location data, an online identifier or other factors including the economic identity of that 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 origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data.

This lack of clarity on what constitutes sensitive payment data creates challenges for interpretation and implementation and increases the risk of non-compliance. Without further guidance banks may need to take a very risk-averse approach and redact all data that could possibly fall into the sensitive data category in order to avoid breaching rules around data protection, both under PSD2 and GDPR. This in itself could pose challenges, as redacting such contextual data through “fuzzy logic” techniques tends to be complex, costly and less than 100% reliable.4

In the UK, the government and the regulators have recently acknowledged these challenges. HMT, the FCA and the Information Commissioner’s Office are currently working together to ensure a pragmatic approach to align the requirements under GDPR and PSD2.

The Interim Period

A further complication is that the RTS on SCA and SC has not yet been finalised and it is not expected to become applicable before the first quarter of 2019 at the earliest.5 An area of contention in the RTS is whether “screen scraping” should be allowed, but in the interim period (from January 2018 to when RTS takes effect), the EBA and the EU commission agree that TPPs can continue using this practice to access customers’ payment information and initiate payments transactions.6 Screen scraping poses challenges for banks, as it inherently allows TPPs to access any information available to customers on their online banking platforms, as if they had they logged in. As such, when screen scraping is used, it is very difficult, if not impossible, for banks to limit access only to data allowable in line with a customer’s consent, and comply with the other data protection requirements related to sensitive data. Indeed, under such a model, it is unlikely banks will be able to know if and what consent has been provided by the customers.

Conclusions

Further guidance is urgently needed from both EU and national regulators on how firms can reconcile the requirements under PSD2 and GDPR, both in the interim period and thereafter. With GDPR introducing a new maximum monetary penalty of 4% of annual global turnover for breaches, the continued lack of such guidance may lead some banks to give GDPR compliance greater priority over PSD2. In all likelihood, this would lead to severe limitations on TPPs’ access to data and very strict interpretations of consent. This in turn would make third party services more difficult to use, and less beneficial to consumers. It would also put a dampener on the “open banking” movement and reduce the effectiveness of regulators’ efforts to increase competition and innovation in the payments market.

In the meantime, firms should avoid considering GDPR and PSD2 implementation programmes in silos, but instead ensure they are co-ordinated and take into account each other’s requirements.

With regards to the issue of consent, we believe the emerging UK Open Banking APIs approach provides a useful model on which to proceed and we would suggest that firms, both in the UK and the rest of the EU, review these plans and consider whether this approach can be embedded into their own planning for PSD2 and GDPR.

Important

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.

1GDPR introduces a new, and very high, standard for the type of consent required for the processing of personal data. Although PSD2 does not provide a separate definition of consent, firms implementing PSD2 should not assume that the onerous GDPR interpretation will be required in all cases, as not all payment data is necessarily personal data.

2As per the Competition and Markets Authority’s “Retail banking market investigation – Final Report”, the nine largest UK banks are: Allied Irish Bank, Bank of Ireland, Barclays, Danske, HSBC, Lloyds Banking Group, Nationwide, RBS Group, and Santander.

3The RTS explicitly states that the name of the account owner and the account number do not constitute sensitive payment data.

4Fuzzy logic is an approach to computing based on "degrees of truth" rather than the usual "true or false" (1 or 0) Boolean logic.

5The RTS on SCA and SC will become applicable 18 months after its publication in the European Union Official Journal.

6The action of using a computer program to copy data from a website built for human users, rather than via a machine-to-machine API. Normally the screen scraping software would identify itself, but as a human user rather than as a robot.

 

David Strachan - EMEA Lead, Centre for Regulatory Strategy, Deloitte

David focuses on the impact of regulatory changes - both individual and in aggregate - on the strategies and business/operating models of financial services firms. David joined Deloitte after 12 years at the FSA, where in his last role, Director of Financial Stability, he worked on the division of the FSA into the PRA and the FCA.

Email | LinkedIn

Stephen


Stephen Bonner - Partner, Cyber Risk Services, Deloitte

Stephen is a Partner within Deloitte’s Cyber Risk Services practice with over 5 years of security consulting experience and over 20 years of financial services industry experience. In particular, Stephen ran global security teams and was accountable for Cyber Security, Records Management, Data Privacy and IAM for a global FS institution. He also led IT Security for a derivatives exchange for four years.

Email | LinkedIn

Steven J Bailey0089_uncropped

Steven Bailey - Director, Risk Advisory

Steven is a Director within the UK payment practice. He has more than 15 years’ experience in assurance and advisory services specialising in providing technology risk and control services to the banking and payments industry. He has led major process, technology and regulatory reviews across many parts of the payments ecosystem including banks, schemes, networks and other providers.

Email | LinkedIn

Adam X Scott6525 - Blog

Adam Scott - Senior Manager, Risk Advisory

Adam is a Senior Manager within Deloitte’s UK payment practice. He has more than 10 years’ experience in providing assurance and advisory services to the Financial Services industry, and focuses on Payments, IT & Operational Risk, and Change & Project Management. Adam has extensive experience of delivering and leading business and technology risk projects as well and regulatory assessments across many parts of the payment ecosystem.

Email | LinkedIn

Valeria Gallo_Professional_Picture

Valeria Gallo - Manager, EMEA Centre for Regulatory Strategy

Valeria focuses on regulatory initiatives related to payments and FinTech. She joined Deloitte in early 2012 from a global strategy consulting firm where she was the Business Operations Manager for the European financial services practice.

Email | LinkedIn

Comments

The comments to this entry are closed.