GDPR & PSD2: Will they work together?
- Posted on February 21, 2018
- Estimated reading time 4 minutes
For banks, 2018 will be a busy year. EU’s revised Payment Service Directive (PSD2) (and Open Banking) went live in January and the General Data Protection Regulation (GDPR) comes into effect in May. They both share common aims – putting consumers 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 be able to choose how it is used and with whom it is shared.
However, PSD2 is about making a person’s data more accessible, while GDPR is about controlling access to that data. PSD2 technical standards are still being defined - there is no current minimum standard for open APIs with each bank left to create their own definition. And the industry is still waiting to see how European data protection authorities will interpret GDPR. There’s no mention of PSD2 within GDPR or vice-versa.
There are different dynamics at play here. Banks need to deliver GDPR compliance to avoid hefty fines (4% of revenues or €20m, whichever is greater). PSD2 has the potential to create new banking opportunities by allowing banks to offer complementary products to customers developed by non-bank third parties. The challenge is to deliver one system that combines both data safety and controlled open access.
Are there any conflicts between these two initiatives? Let’s look at two scenarios.
Follow the fine(s)
If a bank has concerns about the quality of a third-party provider (TPP) requesting customer data, it has two choices. Decline the request - and be PSD2 non-compliant - or accept it and, if there is a data breach, become liable for a large fine under GDPR. Most banks would probably risk non-compliance with PSD2 and reject the request. (As PSD2 is a Directive, penalties are up to member states to define, so there might not even be a fine.) But this could severely limit TPPs’ access to data and create strict interpretations of consent, making their services more difficult to use and less valuable to consumers. This would reduce Open Banking’s impact and dilute regulators’ attempts to increase competition in the payments market.
In case this sounds risk-averse, there are a number of ways in which a TPP could create a breach: by violating the terms of consent, using bank data to mis-sell, engaging in identity fraud or enabling hackers to bypass bank cyber-security.
Banks will have to provide TPPs with the same information available to the customer, unless it is ‘sensitive payment data’. But PSD2 leaves it at the banks’ discretion to determine which data they consider sensitive. GDPR defines ‘personal data’ as information relating to an identified person, such as a name or online identifier.
This lack of clarity increases the risk of non-compliance. Without further guidance banks may take a very risk-averse approach and amend all data that could possibly fall into the sensitive data category to avoid breaching rules, under both PSD2 and GDPR. However, even using appropriate data management techniques, this is often complicated, expensive and not always reliable. This has been acknowledged in the UK by the FCA, The Treasury and the Information Commissioner’s Office, who are working to provide guidance in this area.
What can banks do now?
• Adopt an integrated approach to implementing PSD2 and GDPR. Data privacy cannot be handled in silos but needs experts from different domains – Security, HR, Marketing, IT and Legal. There needs to be one point of contact for both initiatives. Initially, it was the CIO but there’s now a number of options, including the COO, Chief Privacy Officer (CPO) or a ‘Transformation Programme Director’. Anecdotally, I have heard that there is significant churn among CPOs and programme managers responsible for these areas – so be aware that this is a significant task.
• Do not underestimate the resource required. At a recent briefing, one major European advisory firm stated that for GDPR alone ‘20% of the FTSE 100 will have 80% compliance by May 2018’. They estimate that over 40% of banks have less than 10 people in their GDPR teams with only 20% having teams of over 40 people.
• Demonstrate what you will do rather than create well-written policies. For example, where the right to be forgotten cannot be implemented due to regulations that require data to be retained (e.g. financial crime rules), set up appropriate controls so that the reasons for retaining customer data can be demonstrated to regulators.
• Apply GDPR considerations to PSD2 wherever applicable, such as data breach preparation, building privacy by design, having clear privacy notices, etc. If a bank gets a TPP request, they can check the TPP’s privacy policies to see if they fit with their privacy requirements.
• Learn from other industries. Some companies have adopted simple and clear approaches to managing customer data and privacy rights. Tesco’s Privacy Centre is a good example.
Clearly, there are significant areas around PSD2 and GDPR that are still evolving and have major implications for risk management within banks. Aligning these two initiatives is critical and, in some cases, may have to be done without clear guidance. It is no longer feasible to regard privacy simply as a ‘data issue’ for the IT department to solve. Privacy is now a strategic boardroom topic and needs to be firmly on the CEO agenda.