The contingent reimbursement model – obligations under the code

My previous article looked at the development of the Contingent Reimbursement Model (CRM) code, its purpose in dealing with Authorised Push Payment Fraud (APP) and the principles underpinning the scheme.

In this second piece I want to explore the standards it sets for those payment service providers (PSPs) who have committed to the code and how those standards may affect the landscape for all PSPs when they respond to APP fraud.

The CRM code breaks down participants' obligations into two parts – general expectations and the standards for firms.

General expectations

The general expectations provide a baseline of expected behaviours on the part of the participant PSPs. For instance, the code emphasises the importance of education and awareness as a responsible activity for PSPs to undertake. Further, it requires that the PSPs will collect statistics and measure impacts on the incidents of APP fraud.

Many PSPs highlight to their customers the developing threats and ways they can protect themselves. For those PSPs that have undertaken such a practice, it has enabled them to justify refusing to reimburse customers who have not taken due care when making payments.

However, PSPs have been doing so in the absence of any accepted “industry standard”. For the first time, the standards offer a baseline which will inevitably be considered by any competent authority (e.g. the FOS or a court) when faced with questions of whether the PSP has acted properly.

CRM code standards for firms (the standards)

The standards are more instructive than the general expectations and could soon be regarded as a minimum best practice. Where a PSP fails to meet the standards it risks bearing the cost of reimbursing customers even if the customer could be regarded as to blame:

"If Firms fail to meet these standards, they may be responsible for meeting the cost of reimbursing, in accordance with R1, a Customer who has fallen victim to an APP scam."

For each payment journey (i.e. the process of bringing about an authorised payment, ending with the initial reception of the transaction funds in a payee account and the steps in between), the standards are split between those applicable to the sending PSP and the receiving PSP.

Standards for sending PSPs

The code expects that sending PSPs will:

  • Undertake "appropriate action" to identify customers and particular authorisations that are a higher risk –by analysing transactional data or behaviour analytics and training employees to identify such risky transactions (DETECTION: SF1(1))
  • Provide effective warnings to customers based on minimum criteria. In due course, it is anticipated that PSPs will implement Confirmation of Payee protocols (PREVENTION:SF1(2))
  • In certain circumstances where there is "sufficient concern", intervene and delay the transaction whilst taking reasonable steps to contact the customer and notifying the receiving PSP. (RESPONSE:SF1(5)).

Standards for receiving PSPs

The code's standards also expect receiving PSPs to:

  • Take reasonable steps to prevent accounts being opened for criminal purposes (in accordance with legal and regulatory requirements) and use shared intelligence sources to screen customers or identify accounts at higher risk of being used by criminals (PREVENTION: SF2(1))
  • Take reasonable steps to detect accounts which may be used to receive APP scam funds (DETECTION: SF2(3))
  • When notified of concerns, act in accordance with the best practice standards developed by UK Finance (RESPONSE:SF2(4))
  • On identifying the proceeds of a scam, take reasonable steps to freeze and repatriate the funds to the sending PSP (RESPONSE:SF2(5)).

What are the implications for PSPs?

Overall, the standards codify processes that have differed between PSPs whilst giving some flexibility as to application – for instance depending on the risk profile of the PSPs' customers, transactions and business.

That flexibility offers opportunity and risk:

  • It offers a wider variety of PSPs (particularly new entrants to the market) an opportunity to meet the same standards in the response to APP fraud as more established PSPs, in a manner which meets their customer profile (without too much additional investment).
  • In terms of risk, there is a lack of “black and white” when determining compliance and, therefore, an opportunity for criticism. Therefore, as with all risk areas, record keeping of decision making at each step of the journey (and continued assessment as threats change) is essential – to respond to any subsequent audit, investigation or criticism.

Most notably, for the first time, the code provides that a receiving PSP’s breach of their overarching regulatory duty (e.g. to adhere to money laundering regulations) can give rise to a direct remedy for victims of fraud.

Therefore, it can be expected that all victims will make use of this right. For example, as a matter of default, why would a victim not exercise their rights under the expanded jurisdiction of the FOS – in the hope of capturing failures by the receiving PSP who banks a fraudster’s mule accounts?

What do PSPs need to do?

PSPs signed up to the code should consider the level of risk they are willing to tolerate and calibrate their policy and practice accordingly. These should reflect the differing obligations on sending and receiving PSPs.

In particular, where a receiving PSP has been targeted as useful channel to divert the stolen funds, it cannot expect to simply redirect complaints to the paying PSP.

PSPs who do not commit to the code should nevertheless familiarise themselves with the obligations and assess the impact to their business – particularly if the code were to become universally recognised by the FOS as industry standard.

As we'll see in my next article on how reimbursement functions under the code, getting this right will be important both for ensuring customers are reimbursed appropriately and also – perhaps more importantly – deciding who will need to foot the bill for compensating victims of APP fraud.

For more information or help with the Contingent Reimbursement Model code or debt finance more generally, please get in touch by email on [email protected], or via our contact page.