PSD2 allocation of liabilities: Customers Vs ASPSPs Vs PISPs

Under the Payment Services Directive (EU) 2015/2366 (“PSD2”), an Account Servicing Payment Service Provider (“ASPSP”) must grant a Third Party Providers (“TPP”) direct access to certain payment accounts of the ASPSP’s customer so that the TPP can, as requested by that customer, provide its own services to that customer.

ASPSPs are typically banks that offer accounts (e.g. current accounts) to customers (albeit a non-bank payment institution can also offer payment accounts to customers, subject to the scope of its authorisation) – writes Kai Zhang, Associate Director, Bryan Cave Leighton Paisner.

TPPs are those payment service providers that provide the payment initiation service and/or account information service which are typically not authorised as banks (but banks may provide such services as well). The PSD2 requirements relating to such access are commonly referred to as the open banking regime.

There are on-going heightened debates around the open banking regime which so far have focused on areas such as the access interface between the ASPSP and TPP, security of communication channels and the type of payment accounts that should be covered.

However, one aspect of the open banking regime seems to have attracted less attention than it probably should: namely, once the access has been granted, how liabilities should be allocated between the ASPSP and the TPP if a transaction goes wrong?

This article explores the issues in this regard under PSD2 as implemented in the UK via the Payment Services Regulations 2017 (“PSR2017”), particularly in the context of transactions initiated through a Payment Initiation Service Provider (“PISP”).

For clarity, references to “transactions” here are to “payment transactions”. This should be distinguished from a situation where a consumer makes a purchase online (e.g. buying a shirt) and the payment for that purchase went through correctly (i.e. the consumer authorised the payment which was also executed correctly by the payment service providers in the processing chain) but the consumer has a dispute with the merchant (e.g. regarding the quality of the shirt).

Such a dispute (and the consequent refund or refusal by the merchant) would largely be a matter between the consumer and the merchant (the relevant card scheme rules may also be relevant). In other words, it is outside the scope of PSD2 as there is no issue with the underlying payment itself.

Overall framework

Regulation 95 PSR2017 provides that where the liability of one payment service provider for unauthorised or incorrectly executed transactions is attributable to another payment service provider, the latter must pay compensation to the former.

While the provisions are short and simple, their application in practice is unfortunately anything but. There is nothing in PSR2017 on how the ASPSPs and PISPs should communicate with each other and there is not even any express “requirement” for the ASPSPs and PISPs to cooperate with each other in this regard.

There are also no procedural or other requirements as regards who should be doing what with respect to potential disputes that may arise as between the ASPSPs and PISPs themselves and as between the customers on one hand and the ASPSPs/PISPs on the other. As further discussed below, there are significant questions to be answered.

Customer Vs PSP

Regulation 76 PSR2017 provides that, where there is an unauthorised transaction (e.g. a fraudster faked the customer’s authorisation) and the payment was initiated through a PISP, it is the ASPSP where the customer holds his account that is responsible for refunding the customer.

Regulation 93 PSR 2017 provides that, where there is deficiency in the execution of a payment transaction (e.g. non-execution, late execution, incorrect execution or other deficiencies) and the payment was initiated through a PISP, again it is the ASPSP where the customer account is held that is responsible for refunding the customer.

If the PISP is found to be actually liable for the unauthorised or deficiently executed transaction, then the PISP must compensate the ASPSP upon the latter’s request.

These provisions seem to suggest that, from the customers’ perspective, their first port of call is always their ASPSP with respect to any unauthorised or deficiently executed transactions.

However, Regulation 75 provides that where a customer denies a transaction having been authorised or claims a transaction having been executed incorrectly, if the transaction was initiated through a PISP, it is for the PISP to prove, within its “sphere of influence” (see below), that the transaction was properly authorised or correctly executed.

This seems to suggest that the customer should instead first contact the PISP upon becoming aware of the unauthorised or incorrectly executed transaction.

So the question is what the customer should do. Should the customer contact his ASPSP first or should he contact his PISP first? Bear in mind that the customer is statutorily entitled to the relevant refund only if he has notified the payment service provider “without undue delay” and in any event no later than 13 months after the debit date, on becoming aware of an unauthorised or incorrectly executed transaction.

If e.g. the customer notifies the ASPSP only, must the ASPSP then forward the notification to the PISP given it is for the PISP to prove the transaction was indeed authorised or correctly executed? Can the ASPSP refuse refund until the PISP has completed its investigation (the FCA guidance seems to suggest that the ASPSP cannot but it is not entirely clear within the open banking context)? Is there anything the ASPSP can do or should the ASPSP simply wait for the PISP’s investigation?

What if the customer is not satisfied with the PISP’s response (e.g. the PISP claims it was properly authorised), can the ASPSP reverse the refund on the basis of the PISP’s investigation? How would the ASPSP know that the PISP has completed its investigation (since the PISP has no duty under PSR2017 to inform the ASPSP)?

These are important questions that require clarity, as between the customer on one hand and the ASPSP and the PISP on the other. Even more complex issues may arise as between the ASPSP and the PISP themselves.

ASPSPs Vs PISPs

While it seems clear, in theory at least, that the ASPSP must refund the customer and then sort out the allocation of liabilities with the PISP as between themselves, there is nothing in the PSR2017 as regards what the ASPSP should do to achieve this in practice.

It should be noted that the ASPSP is prohibited under PSR2017 from requiring or suggesting to the PISP that a contractual arrangement is required before granting access to the relevant payment account(s). In other words, there is no contract between the ASPSP and the PISP governing their interaction with each other.

The FCA in its Payment Services and E-Money Approach Document (“Approach Document”) notes that payment service providers may put in place “voluntary arrangements” for the settlement of such liabilities between themselves.

Such arrangements would purely relate to allocation of liabilities and would thus not be subject to the prohibition as long as they do not function as a pre-condition on granting access itself.

The FCA goes on to say that such voluntary arrangements can only be put in place if “both” the ASPSP and the PISP wish to do so. That seems to make much sense, given the “voluntary” nature of such arrangements. However, it is difficult to see what possible incentives there are for the PISP ever to wish to enter into such arrangements voluntarily.

There are incentives for the ASPSP to wish so because the ASPSP is primarily responsible for refunding the customer in the first instance and the arrangements would be in its interest.

There seems little or no benefit for the PISP to wish so since the arrangements are primarily intended to make it easier for the ASPSP to attribute potential liabilities to the PISP and the PISP may also likely incur not insignificant costs (including legal costs) in e.g. negotiating such arrangements.

In the absence of such voluntary arrangements, it is not clear how the ASPSP may communicate with and request compensation (where applicable) from the PISP. While the PISP must identify itself to the ASPSP when accessing the customer’s account, that relates to the identity of the PISP rather than the provision to the ASPSP with detailed contact information for purposes of dispute handling.

Further, what if the PISP simply ignores the communication or request from the ASPSP (there being no express timing requirement on the PISP to respond)? What if the PISP disputes the compensation request from the ASPSP? Or is it the case that the PISP must compensate “upon” request by the ASPSP (i.e. it cannot raise a dispute)?

Must the ASPSP provide the relevant evidence to support its request for compensation (bearing in mind that it is for the PISP to prove a transaction was properly authorised or correctly executed)?

Incorrectly executed transactions

With respect to incorrectly executed transactions, it seems that the ASPSP can actively request the PISP to prove that the transaction was indeed correctly executed (the wording of Regulation 93 is not entirely clear though). However, the PISP is only required to so prove within its “sphere of influence”.

The FCA explains that any parts of the transaction over which the PISP has control are considered to be within its sphere of influence. This seems circular because the very question is to identify which party controls which parts and where the deficiency in processing the transaction occurred.

Therefore the guidance does not seem particularly helpful. Additional difficulty may also arise as regards which party has “control” over which parts of the transaction, given the different account access models under the (various) open banking standards (e.g. an embedded model, a de-coupled model or a re-direction model).

Even where the “sphere of influence” can be clearly identified and agreed between the two sides, there are other practical issues. For example, would the ASPSP have to make a written request?

If so, what constitutes a written request? What if the ASPSP is not satisfied with the PISP’s evidence? If so, who should make the final decision as regards whether a transaction was authorised or correctly executed? How could the parties appeal and to whom?

Unauthorised transactions

In addition, unlike with respect to incorrectly executed transactions, Regulation 76 on liabilities for unauthorised transactions is silent on whether the ASPSP can actively request the PISP to prove that the transaction was indeed properly authorised.

It seems to be implied (read together with Regulation 75) that the ASPSP may actively make such requests. In that case, similar issues as noted above may arise. If the ASPSP cannot actively make such requests, then the question is what it should do. Should the ASPSP ask the customer to ask the PISP to prove?

Customer at fault

Finally, under Regulation 77 PSR2017, if a customer is found to have acted fraudulently or with gross negligence in keeping his security credentials confidential, the customer is fully liable for all the loss of the relevant transaction (assuming the payment service providers have complied with their applicable obligations).

However, it is not clear which of the ASPSP or the PISP should be responsible for conducting the relevant investigations into the customer’s behaviour. Given it is for the PISP to prove the transaction was properly authorised or correctly executed, presumably it should be the PISP that looks into the customer’s behaviour.

However, the ASPSP is responsible in the first instance for refunding the customer and thus it would be in the ASPSP’s interest to scrutinise the customer’s behaviour as well. If both the ASPSP and the PISP conduct their own respective investigation, what if the investigations by them lead to different outcomes (e.g. one says there was fraud and the other says no)? What if the ASPSP wants to investigate but the PISP does not?

What if the PISP requires cooperation from the ASPSP for its investigation or vice versa? Must the PISP or the ASPSP cooperate with the other? If so, which should bear the costs of such cooperation?

Concluding remark

There are important practical questions that need to be clarified with respect to the operation of the account access regime. Unfortunately there are at the present no clear answers. One thing seems clear.

That is, it cannot be the case that each time there is a dispute in this regard between the customer and the ASPSP/PISP or between the ASPSP and the PISP, the FCA or the court must be involved to solve the issue. That would be a time-consuming and expensive process for all concerned.

Whatever solutions there may be (e.g. certain industry voluntary code or other framework imposed by the regulators), action need be taken sooner rather than later as the Open Banking regime will come into force September 2019.

The post PSD2 allocation of liabilities: Customers Vs ASPSPs Vs PISPs appeared first on Payments Cards & Mobile.