The contingent reimbursement model – how reimbursement works under the code

So far in this series of articles on the CRM code, we've looked at the code's key principles and the standards it sets for firms to help prevent Authorised Push Payment (APP) fraud.

Of course, the real focus of the CRM code is the reimbursement of defrauded customers.

As a fundamental principle, R1 of the code is worth setting out verbatim:

"Subject to R2, when a Customer has been the victim of an APP scam Firms should reimburse the Customer" (emphasis added)

However, despite some expectations, this principle should not be regarded as an entitlement for customers to be refunded come what may. As industry (see here) and the police (see here) have long recognised, that would be self-defeating in the efforts to reduce APP fraud, which is a shared responsibility with customers.

The key caveat is: “Subject to R2…”

Making decisions under this express caveat will be the critical challenge for PSPs when implementing the code. As R2 states:

"A Firm may choose not to reimburse a Customer if it can establish any of the following matters in (a) to (e)". (emphasis added)

The matters in (a) to (e) relate to the customer’s requisite level of care. These have been revised since the draft code was issued and responses to the consultation were submitted. This has helpfully clarified matters and the CRM Steering Group has committed to a number of follow up steps. These include a substantial education and awareness exercise and early review of the code by the Lending Standards Board to monitor implementation.

If a PSP chooses not to refund

In order for a PSP to choose not to refund, it must first assess whether any of the matters in R2(1)(a) to (e) can be established and that these would have had a material effect on preventing the APP scam.

Whilst indicative, the circumstances are not entirely prescriptive and require individual assessment by the PSP. Broadly, they can be described as where the PSP considers the customer “to blame". For instance, where the customer has ignored “effective warnings”.

Understandably, the grounds for refusal are wider than “gross negligence” – which is the requirement if a PSP seeks to refuse to refund an unauthorised transaction under the Payment Services Regulations.

Nevertheless, choosing not to refund poses an obvious area of risk for PSPs. For instance:

• Has the assessment been carried out properly, with due care and skill and is it consistent in treating customers fairly?
• Has the process been followed in the required timeframes (e.g. deciding and responding to the customer within 15 business days (or 35 in exceptional circumstances)?
• If the customer is not satisfied, it can challenge the PSPs decision by way of a DISP complaint, which, if resolved unsatisfactorily, can be pursued via the FOS. This gives rise to potentially precedent-setting assessments of the PSP’s process.

If a PSP makes a refund

If a PSP refunds customers it must communicate (and document) that decision to both the customer and the other PSP in the payment journey. The paying PSP should record the incident and factor it into its ongoing prevention and detection processes, especially if the PSP has breached one of the code's standards for firms.

Depending on the circumstances, the code may give rise to additional issues for the paying PSP (who refunds the customer).

The decision to refund requires proper management to ensure customers are being treated fairly and consistently. Improperly managed, a decision to refund could risk undermining a core purpose of the code (i.e. to reduce APP fraud), by relieving customers of their own responsibilities and, further, spark challenges from other customers (or PSPs).

For instance, if the customer was “to blame” but nevertheless other factors (such as vulnerability) led to the PSP to choose to refund, the PSP would be making (potentially substantial) payments when it did everything reasonably expected of it.

In that case, under the code, the paying PSP would then have the opportunity to recoup this sum via the "no blame” fund.

The “no blame” fund

The "no blame” fund is a central pot intended to refund PSPs the cost of reimbursing customers where they have not breached the standards set out in the code. Until 31 December 2019, a number of PSPs committed to find an initial contribution before a long term funding mechanism is determined. A long term mechanism has not yet been determined following a refusal by Pay.UK to adopt a transaction levy - due to inconsistent views across the industry.

However, if it is to be funded by all the code participants, one questions whether they should bear a shared cost where an individual PSP has chosen to refund its own customer despite the customer being “to blame”. What if a certain PSP happens to bank a greater proportion of vulnerable customers or one PSP's reimbursement decisions are more generous than others'?

Accordingly, a sending PSP may face challenges in respect of the decision to refund, when it requires the receiving PSP to contribute directly to the refund under the allocation mechanism or via the "no blame" fund.

Allocating the costs of reimbursement

Under the code, the PSPs involved in the payment journey are expected to unanimously agree (within 15 business days) the allocation of the cost of reimbursement.

The code suggests that it is best practice to either split the cost of reimbursement 50/50 (if both PSPs have breached the standards) or wholly allocate it to the culpable PSP (if only one PSP has breached the standards). Inevitably this requires PSPs to cooperate and share the details of their internal processes and procedures. Appropriate safeguards will be required in doing so, particularly around customer confidentiality and data protection.

Where the customer has not met the requisite level of care and one or more of the PSP has breached the standards, they customer will be entitled to a 66% reimbursement (if both PSPs have breached the standards) and 50% (if only one PSP has breached the standards). This more nuanced split of culpability was introduced to the code after the publication of the "final" code on 28 February 2019. Whilst it is logical, it again offers the risk of inconsistency in application.

Rather ambitiously, the code also expects the customer’s PSP to use best endeavours to contact PSPs who are not code participants but are involved in the payment journey to seek their cooperation to follow the same allocation procedure. It is not obvious why a non-code member would do so.

Vulnerability

PSPs should be familiar with obligations to identify vulnerability in their customers. However, this is can be a difficult assessment in a dynamic situation and with sophisticated fraudsters intent on exploitation.

The code provides that if the customer is vulnerable, they should be reimbursed come what may. The allocation between the PSPs will follow the ordinary split as if the customer had met the required standards. One can imagine that vulnerability would be pleaded in most circumstances and offer the risk of difficult judgment and an inclination to rely on the no blame fund for reimbursement.

Again, additional text was introduced to the code after the publication of the "final" code on 28 February 2019.

Points for all PSPs to consider

 As with the standards for firms (discussed in our previous article), all PSPs should familiarise themselves with the circumstances in which a customer may be considered “to blame” under the code – even if the PSP is not a code participant. We've appended these to the bottom of this article.

The allocation process also creates several areas of operational risk for PSPs. For instance, 15 business days will seem like a lifetime in the eyes of a defrauded customer, but for the PSPs it does not give much working time to gather information to conduct a fulsome assessment and agree who will bear the potentially onerous cost of reimbursement.

That timeframe applies whatever the amount lost to the scam (whether £100 or £1,000,000). That said, the code does allow for the decision timeframe to be extended to 35 days in exceptional circumstances, without specifying what qualifies as exceptional.

The code provides that a decision to reimburse should not be delayed pending allocation. So paying PSPs will likely be left carrying the liability until the allocation and, if necessary, dispute resolution processes are exhausted.

Dispute resolution under the code will be the subject of the next article – if you have any questions on this topic which you'd like me to address, let me know via [email protected]

Appendix: CRM Code R2 (1)

A Firm may choose not to reimburse a Customer if it can establish any of the following matters in (a) to (e). The assessment of whether these matters can be established should involve consideration of whether they would have had a material effect on preventing the APP scam that took place.

(a) The Customer ignored Effective Warnings, given by a Firm in compliance with SF1(2), by failing to take appropriate action in response to such an Effective Warning given in any of the following:

(i) when setting up a new payee

(ii) when amending an existing payee and/or

(iii) immediately before making the payment

(b) From [DATE TBC], the Customer did not take appropriate actions following a clear negative Confirmation of Payee result, where the Firm complied with SF1(3) or SF2(2), and those actions would, in the circumstances, have been effective in preventing the APP scam

(c) In all the circumstances at the time of the payment, in particular the characteristics of the Customer and the complexity and sophistication of the APP scam, the Customer made the payment without a reasonable basis for believing that:

(i) the payee was the person the Customer was expecting to pay

(ii) the payment was for genuine goods or services

(iii) the person or business with whom they transacted was legitimate.

 (d) Where the Customer is a Micro-enterprise or Charity, it did not follow its own internal procedures for approval of payments, and those procedures would have been effective in preventing the APP scam

 (e) The Customer has been grossly negligent. For the avoidance of doubt the provisions of R2(1)(a)-(d) should not be taken to define gross negligence in this context