Open Banking, Open Liability: accountability issues for open banking APIs

This year heralds two new regulatory reforms which impact significantly how financial institutions must think about, exploit and share that data: the revised Payment Services Directive ("PSD2") and the General Data Protection Regulation ("GDPR").  PSD2 came into effect on 13 January; the GDPR follows closely, becoming law across the EU on 25 May.  

While at first blush these two regulatory regimes appear very different, they have a shared core objective: giving consumers more control over their data and keeping that data secure. Despite this commonality, uncertainty exists around how some of the finer detail between the two texts should be implemented. This presents a number of challenges to financial institutions who must reconcile this uncertainty to ensure they remain compliant on both sides of the legislation. This article explores some of these challenges and, importantly, where the accountability rests across the two regimes.  

Introduction to PSD2 and the rise of Open Banking

The idea behind Open Banking is not new.  For a while now, firms such as First Direct (through its Internet Banking Plus), Money Dashboard and OnTrees from Moneysupermarket.com have enabled customers to get a better view of their finances by aggregating various of their online bank accounts into a single app.  Many traditional payment service providers (which we call "banks" in this article for simplicity) warned customers that giving their login credentials to these third party account aggregators was a breach of their online banking terms, and that customers could be responsible for unlawful activity on their account as a result. 

PSD2 sought to address this by making it a legal requirement for banks to give authorised third parties (known as "TPPs") access to customer's account data.  This led to two new payment services being introduced under PSD2: 

• Account Information Services - under which TPPs (known as AISPs) provide an overview of available accounts and balances to their customers; and 
• Payment Initiation Services - under which TPPs (known as PISPs) can initiate payments on behalf of customers, using the bank's own infrastructure to effect the payment. 

Concurrently, the UK Competition and Markets Authority ("CMA") introduced an order on the nine largest retail banks in the UK aimed at addressing a perceived lack of customer engagement in the UK retail banking market.  One of the CMA's remedies, known as the Open Banking remedy, was to mandate these banks to grant TPPs both read and read/write access to customer account data. Although there are some notable differences, the CMA's Open Banking remedy effectively front runs aspects of PSD2.    

The aspiration for PSD2, in parallel with the CMA's Open Banking remedy, is to transform retail banking, with TPPs expected to use their new found access to customer data to design innovative and more informed comparison services, money management products and, ultimately, personal finance assistants. 

Relationship between PSD2 and GDPR

The GDPR and PSD2 do not talk about how they are intended to interact.  It will be up to each Member State's national regulatory authorities to interpret potential differences existing between both texts. This means the relevant data protection supervisory authorities will enforce the GDPR, while the appointed national financial regulators will be responsible for enforcing PSD2.  It will require collaboration between the respective regulators to ensure that interpretation of PSD2 does not introduce requirements that conflict with data protection obligations under the GDPR. And visa versa.   

In the UK, the Financial Conduct Authority ("FCA") has confirmed that it continues to work closely with the UK data protection regulator to implement specific details of the two texts in a consistent manner, and that neither regulator considers the texts to be incompatible.   This is encouraging news indeed. But there remains some areas of potential inconsistency which the regulators will need to watch out for.  The role of consent is one.  

Getting consent right for everyone

Article 94 of PSD2 entitles banks and TPPs to process personal data necessary for the provision of their respective payment services only with the "explicit consent" of the customer.  Similarly, PSD2 requires a TPP to obtain the customer's explicit consent before providing its account information services or payment initiation services. 

Under Article 6 of the GDPR, "consent" is one of the lawful bases for processing personal data. "Explicit consent" has a very different meaning under GDPR, and is one of the lawful bases for processing special categories of personal data (being personal data which, because of its sensitive nature, requires a higher standard of protection, like an individual's race, health or religious beliefs).  An individual's payment account history is not a special category of personal data under the GDPR.

For the UK, the FCA's guidance on implementation of PSD2 helpfully clarifies that the interpretation of explicit consent under GDPR should not be read across into Article 94 of PSD2, and that a bank cannot use the requirement to obtain explicit consent under Article 94 as a means to avoid its obligation to disclose payment account data to a TPP.  

That is all well and good under PSD2.  However, the bank also remains the controller of its customer's account data under GDPR.  This means that it will be responsible for protecting their customer's data from unauthorised access or loss.  GDPR guidance on data portability, for instance, explains that controllers will be expected to implement safeguards to ensure that third parties from whom they receive data porting requests are genuinely acting on the data subject's behalf.

It follows that:

• A TPP will be expected under PSD2 to obtain a customer's explicit consent before requesting the account data from the customer's bank.  This consent will need to cover use of that data to provide the account information or payment initiation service. 
• A TPP will also be expected under GDPR to demonstrate a lawful basis (which could include obtaining the customer's consent) to process the account data, as it will also be a controller of the customer's data it obtains from the bank.
• The bank will, under its duty under GDPR, want in turn to validate that the customer has consented to the requested data access/transfer directly with its customer, before making that account data available to the TPP.

That's a lot of consent that needs to be interpreted, obtained and managed. 

Liability model under PSD2

In addition to obtaining consent from customers, TPPs will also be required to have security measures in place to protect customer's account data and payments accounts.  In addition, all participants in PSD2/Open Banking will have to comply with new rules on strong customer authentication and secure methods of communication.  Despite this, there is still some uncertainty over who foots the bill when things go wrong. 

It has long been the case that the banks have to refund customers in the event of unauthorised and incorrectly executed transactions.  This occurs where there is theft of customer ID, card details are wrongfully obtained or online accounts are unlawfully accessed, for example. 

The introduction of account information and payment initiation services under PSD2 has made the process more complicated.  

In the case of unauthorised transactions, the bank must refund the amount of the unauthorised payment transaction to the customer and restore the customer's account to the state it would have been in had the unauthorised payment not taken place. If the TPP is liable for the unauthorised payment transaction, the TPP must indemnify the bank immediately.  It all sounds simple.  But then you start scratching the surface.  What if the TPP claims it is not liable and the bank also thinks it is not at fault?  One thing is certain: the customer does not get caught up in the middle – it is refunded by the bank, no matter who's ultimately at fault behind the scenes.

The FCA comments in its Approach Document that in relation to payments initiated via a TPP, the burden of proof lies with the TPP to demonstrate it was not responsible for the error.  The TPP will be required to prove, among other things, that the payment order was received by the customer's bank and that while within the TPP's "sphere of influence" it was authenticated and dealt with correctly. The FCA clarifies that it will consider any part of a transaction over which the "TPP has control" to be within the TPP's sphere of influence.  Clear?  Most consider not, and that there is still room for the prospect of some lengthy legal and technical disputes. 

Unsurprisingly, the issue of allocating of liability under PSD2 have been among the most controversial. The original European Commission proposal for the directive drew criticism from a number of stakeholders around these provisions.  The European Payments Council commented that under PSD2, the risk and the burden of financial recovery appeared to lie with the bank and cautioned against the banks being made liable for TPP's mistakes or other risks (such as cyber-vulnerabilities) arising from the TPP's activities. It stated that this would only be acceptable where an agreement between the TPP and the bank was in place. It argued that such an agreement should relate to the terms of the payment initiations and account information services offered by the TPP in question.

At the time of UK implementation of PSD2, both HM Treasury and the FCA received responses in relation to the practicalities of a liability model between the banks and TPPs.  In a joint response with other industry figures, Payments UK questioned how the banks would be able to obtain immediate refunds in the absence of a contract with the TPP, and whether a refund from "thinly capitalised" TPPs would be feasible. As TPPs could be authorised in any Member State, the management of cross-border disputes was also raised as a thorny issue.  Clarification was sought on the burden of proof (which falls on the TPP), as was TPP related liability (e.g. in the case of third party data loss or hacking).

Consumer protection watchdogs, such as the Financial Services Consumer Panel (FSCP), questioned the appropriateness of the bank being the first point of call for refunds, particularly where there is direct interaction between TPP and the customer.  Equally the FSCP pointed out the absence of a similar liability framework for TPPs and the banks in the event of data breaches.

Although Government has acknowledged industry feedback, it has yet to introduce a mechanism for resolving stakeholder concerns around liability.  It noted the bank's unease in relation to the practical difficulties of obtaining compensation from a TPP, but says the banks should rely on their traditional rights of action against a TPP who breaches its regulatory obligation to refund them for an unauthorised transaction.  

UK Government has suggested that the payments industry could find additional methods for closer collaboration between the bank and TPPs to alleviate concerns around liability.  

Open Banking – a move towards a solution? 

As noted above, the CMA's Open Banking remedy requires nine of the largest UK banks to make available significant amounts of customer data to TPPs.  This access is to be effect via standardised public APIs.  Those involved in the CMA's Open Banking remedy proposed a method of resolving disputes between the banks and TPPs in January 2018. 

The Open Banking Implementation Entity has designed a Dispute Management System for the banks and TPPs in the case of managing complaints, disputes or enquiries. The scheme is voluntary and is not just open to members of Open Banking.  It has been developed with UK Government, regulators, the payments industry and consumer groups. 

Under the scheme, participants sign up to a Code which sets out common best practice standards and principles for the bank and TPPs.  This includes best practice for where a complaint, dispute or enquiry is taken to mediation, adjudication or arbitration.  

The Code is not designed to replace the legislative process or existing policies or agreements between parties to a complaint, dispute or query.  It is also clear that the Code "does not offer a liability model".  As such, it is not yet the vaunted panacea to participant's liability concerns, but it is step on the road at least.  How bumpy that road is remains to be seen.