Crummy CReM code Part IV, and ensuring validation of mandatory data at the beneficiary firm

This is the fourth blog out of eight in our series on the Contingent Reimbursement Model code (“CReM”) that purports to offer customers strong protection against certain types of Authorised Push Payment Fraud, or “APPF”.

We made the point in Part III that firms demanded Name + Sort Code + Account Number as mandatory information for instructing payments through the eBanking services that provide the seed bed for APPF, and that firms should be held to executing the payment on the basis of all this information, and not just the Sort Code + Account Number.

It would surely follow, even if it is not explicitly stated in the 2017 Payment Services Regulations (the “PSRs”), that the firms, having demanded the mandatory information before entering into the contract to make the payment, have the responsibility for ensuring that the payment is executed through a mechanism that guarantees the validation of that information by the beneficiary firm before the amount is credited, or else, if they cannot guarantee that, the firm bears the risk of incorrect application of the money.

The sending firm chooses the mechanism through which it sends the payment. If the mechanism does not support the validation, then the payer must have a blanket indemnity against incorrect application. The payer has this for cheque payments, thanks to the crossing “Account payee”: if a firm allows the cheque to be paid in to an account with different naming than the payer has stated in the payee line, the firm is liable to the payer for its mistake.

The range of possible outcomes for a “push payment” should be:

• The “information” correlates to an account at the beneficiary firm and the payment amount is credited to that account; or
• The “information” does not correlate to an account at the beneficiary firm and the payment amount is returned, and re-credited to the payer; or
• The “information” does not correlate to an account at the beneficiary firm, but the beneficiary firm wrongly credits it. When this comes to light the beneficiary firm first returns the payment and it is re-credited to the payer. Then the beneficiary firm, separately and at its discretion, will try to get the money back from their account-holder, but whether they can or not has no impact on their obligation to return the payment, and has no effect on the payer.

The 2017 PSRs are the law now, and these matters need to be tested in the light of them. There is a disconnect between the assumptions behind the PSRs as we read them (that firms will check the “information” and behave as set out above in the case of a mismatch) and how UK “push payments” are processed in practice.

The CReM code accepts the way in which UK “push payments” are processed in practice as a given, and this serves to undermine the protection that the PSRs were, in our view, intended to give the customer – and not just the customers in-scope of the CReM but all of them.

The real solution to “wrong name” APPF is for firms to re-gear their IT infrastructure and payment schemes to validate the name. Indeed, the proposed Confirmation of Payee service has been designed by Pay.uk to validate the name. So, if it can be done through this service, why cannot it be done on every payment and without the need to build a new service?