PSD2 and GDPR – Harmony or Dissonance?

Both the GDPR and PSD2 are built on the general principle that personal data are owned by the individual, who should be able to decide how their data will be processed and used and who they will be shared with. However, when we look at specific implementation, we are confronted with considerable challenges concerning the harmonisation of the requirements of the two directives and actual practice.

Our article focuses on two key topics:

1. Definition of responsibility for obtaining the client’s consent allowing banks to share the client’s payment information data with third party providers (“TPPs”) in line with PSD2; and
2. Definition of “sensitive payment data”.¹

Client consent

Under PSD2, TPPs will be able to directly access information on the client’s payment account. This access will be subject to the client’s express consent, based on which TPPs will be able to use the bank’s infrastructure in order to provide two new payment services, namely the indirect payment initiation service (PIS) and the account information service (AIS).² TPPs will essentially use the principle of data portability introduced by the GDPR. In practice, however, a key question remains unanswered – which party should be the one to obtain the client’s consent.

From a GDPR perspective, banks will be the controllers of their clients’ data and they will be responsible for the way the clients’ personal data are processed and shared. The GDPR gives the data controller the responsibility for ensuring that “they demonstrably act on behalf of the data subject.” However, PSD2 additionally states that TPPs are authorised to access information for “a purpose specifically required by the client” with respect to the provision of the account information service or the indirect payment initiation services, therefore not for any other purpose.

Having carefully considered these concurrent requirements, we believe that TPPs will be the initiators of obtaining the client’s consent in order to use data related to the provision of a specific payment service, or the consent to additional use of these data beyond the payment services in line with PSD2. On the other hand, banks will, in our opinion, be responsible for providing account information solely via a TPP for which they will have a confirmation directly from their clients that the consent has been provided. This consent will probably include the confirmation of data such as the identity of the TPP with which the client wishes to share their data, the scope of data to be shared including the related frequency and duration of the consent. The two-degree process where the consent is first obtained from the client and subsequently confirmed has the potential to ensure better protection to the TPPs as well as the banks and clients.

Our opinion is in line with the proposed API standard recently published by the British government initiative UK Open Banking. While the British Open Banking API standard, which will come into force in January 2018, will be obligatory only for the nine largest British banks³ and will concern a narrower range of products than what is defined by PSD2, the British Financial Conduct Authority (FCA) and HM Treasury try to motivate (PDF) all banks and third parties – TPPs – to accept these standards as a common base for secure and effective sharing of banking data.

It can be expected that banks and third parties across the EU will follow these standards with interest and draw inspiration from them or voluntarily join them.

Sensitive payment data

The current proposal of regulatory technical standards (RTS) for strong customer authentication (SCA) and secure communication (SC) as part of PSD2 state that banks are obliged to give account information service providers (referred to as AISPs) the same information that is available to the client in direct online access to their account information, but it must not include “sensitive payment data”.

However, the above condition seems to be problematic, since the legal provision does not specifically state what the “sensitive payment data” is. According to PSD2 (or more precisely, the RTS), it is all information, including personalised security data, that could be misused for fraud, but the assessment of which data are considered sensitive is left to the banks’ discretion.⁴

The GDPR defines “personal data” as all information about an identified or identifiable natural person. An identifiable natural person is an individual who can be directly or indirectly distinguished, especially with reference to a certain identifier, for example name, personal identification number, location data, online identifier or one or more special elements including the economic identify of this natural person.

However, the GDPR also allows EU member states to define their own rules for “processing special categories of personal data (‘sensitive data’)”, defined as personal data on racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, and the processing of genetic or biometric data.

The absence of a clear definition of what “sensitive payment data” actually is represents a challenge within the interpretation and implementation and increases the risk of regulatory non-compliance. Without further specification, some banks could adopt a risk-averse approach and declare all data that can be included in this category to be sensitive in order to avoid possible non-compliance with regulatory requirements as per PSD2 and the GDPR. This can represent a challenge in itself, because consolidating the requirements of both regulations using “fuzzy logic” techniques is a complicated, expensive and by far not one hundred percent reliable exercise.⁵

Author’s note: The government and regulatory authorities of the United Kingdom have already become aware of these challenges (PDF). HM Treasury, the FCA and the Information Commissioner’s Office are currently collaborating on ensuring a pragmatic approach to the harmonisation of GDPR and PSD2 requirements.

Transitional period

Another complication in terms of data transfer is the fact that the RTS for strong customer authentication and secure communication (specifying the rules of access to clients’ payment accounts and the related data sharing) have not been definitively completed and they are therefore not expected to come into effect before the second quarter of 2019.⁶

One of the areas where no consensus has so far been reached in the RTS is the permission of “screen scraping“.⁷ Both EU authorities, the European Banking Authority and the European Commission, agree that during the transitional period (from January 2018 until the effective date of the RTS) third parties (TPPs) can continue to use this method to access information on a client’s payment account and for indirect payment initiation.⁸ However, in the case of the use of screen scraping it is very difficult and often impossible for banks to limit the access only to data in the scope of the consent given by the client, and thus to be compliant with other data protection requirements. If they apply this model, banks will have essentially no possibility of verifying whether and what nature of consent the client has provided.

For the sake of completion, we add that during the legislative process an amendment was proposed to the Payments Act (act implementing PSD2 in Czech law), which also anticipated the option where the rules for TPP access to the payment account would be subject to the conclusion of an agreement between the bank and the TPP. Such an agreement should objectively define the rules of service provision (AIS or PIS) and rules for strong authentication. The draft amendment also anticipated an alternative to the agreement, which would be a situation where the TPP would provide the bank with evidence of meeting the conditions of a “reputable standard” for the access to the payment account and strong identification (without specifying what would be considered a reputable standard). However, this proposed amendment was not accepted in the third reading in the Chamber of Deputies and this provision is therefore not included in the final text of the Payments Act.

Conclusion

We believe that the EU and national regulators need to provide additional unified “instructions” that will allow banks and third parties to adequately harmonise and interpret PSD2 and GDPR requirements now during the transitional period and afterwards.

Given the new sanctions for GDPR non-compliance (up to 4% of the global annual turnover of the company), there is a risk that if such a unifying regulation does not appear, some banks may prioritise compliance with the GDPR over PSD2. Such a solution would probably lead to a significant limitation of TPPs’ access to data and a very strict interpretation of the scope of the client’s consent. Ultimately, it would have a negative impact on the usability of third party services and the added value of the newly introduced services for the end users brought by PSD2.

In our opinion, banks and TPPs both should in any case avoid making the strategic mistake of implementing PSD2 and the GDPR separately. On the contrary, they should ensure their mutual coordination and account for the requirements of both regulations at the same time.

As for the matter of consents, we believe that the current approach to API in the British Open Banking initiative offers a functional model that can serve as a good basis and that it could be interesting for third parties in the United Kingdom and elsewhere in Europe to draw inspiration from this approach.

Important

This summary was formulated only on a general level and in this respect we strongly recommend obtaining expert support of a specialised advisor before making any further steps. We will naturally gladly be of assistance in this context.

¹ The GDPR introduces a new standard of consents required for personal data processing. Although PSD2 does not offer its own definition of (client) consent, companies implementing PSD2 should not automatically follow the assumption that a limiting interpretation of the GDPR will have to be applied in all cases, since not all payment data are necessarily also personal data.

² This name for these services is used by the newly adopted Payments Act that implements PSD2 provisions in Czech law.

³ The nine largest British banks according to CMA that are already subject to the Open Banking standard are: Bank of Ireland, Barclays, Danske, HSBC, Lloyds Banking Group, Nationwide, RBS Group and Santander – author’s note.

⁴ The RTS explicitly state that the name of the account holder and account number do not constitute sensitive personal data.

⁵ Fuzzy logic is a calculation method based on “degrees of probability”, unlike the usual “true or false” (1 or 0) in Boolean logic.

⁶ RTS for strong customer authentication and secure communication will come into force 18 months after their publication in the European Union Official Journal.

⁷ A method using a computer program for copying data from a website designed for showing information to regular users, unlike the use of standard communication via API. A screen scraping software usually identifies itself to the provider as a human user, not as a robot.

⁸ Screen scraping allows TPPs to access any information that is available to clients on the online banking platform, same as if the users logged in themselves.