Will the Contingent Reimbursement Model (CRM) Code Stop Push Payment Scams?
If you do business in the UK market, you might have heard some mention of a new system known as the Contingent Reimbursement Model Code, or CRM.
This fund, the brainchild of the Authorised Push Payment Scams Steering Group, is meant to protect customers from fraud. What are the details of this new plan, though, and what does it mean for fraud prevention going forward? Let’s have a look and find out.
Push Vs. Pull Payments
Before we can understand either the Contingent Reimbursement Model or the authorized push payment (or “APP”) fraud it seeks to correct, we must first address this basic question: what is an authorized push payment?
The phrase “push payment” is used to differentiate a buyer-initiated payment from a supplier-initiated one.
- Merchant requests payment from buyer.
- Buyer authorizes payment, and merchant submits payment for clearing.
- Issuer releases funds to cover authorized amount.
- Merchant acquirer receives funds.
- The merchant provides a request for payment to buyer.
- Buyer initiates payment to merchant.
- Buyer authorizes payment, submitting directly for clearing.
- Merchant acquirer receives funds.
A key advantage to the authorized push payment method is that the buyer doesn’t reveal any sensitive information to the merchant. Instead, the merchant receives the funds from the transaction without ever handling the cardholder’s information. There are several other advantages to this as well:
Sounds great, right? Well of course, the authorized push payment concept isn’t without flaws. Authorized push payment fraud, or simply APP fraud, is a fast-growing new threat source designed to manipulate this payment method.
APP fraud allows criminals to take advantage of real-time payment schemes, such as the UK’s Faster Payments system. The fraudsters sometimes use social engineering techniques, or may hack into an email account to set up the plot. Then, when the buyer receives a seemingly-legitimate request for payment, the individual inadvertently submits a push payment to the fraudster.
Remember: these payments are generally irrevocable. Thus, if the consumer submits a payment to a fraudster…they have little legal recourse to recover their funds. The payment service provider (PSP) would only be required to compensate the victim if that user can prove that the PSP failed to protect them according to legal requirements.
Enter: The Contingent Reimbursement Model Code
Such a glaring shortcoming in consumer protections couldn’t go unaddressed for long. Thus, the Contingent Reimbursement Model Code was developed.
The CRM features three overarching objectives:
- Reduce occurrences of authorized push payment fraud.
- Protect customers from APP fraud by enabling reimbursement of fraud victims.
- Minimize disruption of legitimate payments.
In essence, the CRM is a reserve of cash which signatories to the Code agree to fund. The reserve can then be used to reimburse victims of APP fraud attacks. If a customer does everything expected under the provisions of the code in a push payment context, that individual will be protected by the code in case of APP fraud.
Consumer protections enshrined under the code took effect in the UK on May 28, 2019. Signatories to the code are expected to introduce some kind of long-term funding mechanism for the CRM fund by January 1, 2020.
It’s important to note that compliance with this code is voluntary among payment service providers. However, numerous PSPs agreed to sign-on to the code. This is partially a show of good will, as most agree that protecting consumers against fraud is important on its own. There’s also a personal interest angle, though; PSPs who don’t offer CRM protections for consumers will be at a significant competitive disadvantage.
The UK Payments Systems Regulator also insists that the CRM should establish better incentives for PSPs to use the measures developed. Such a move will, at least in theory, help prevent and respond to APP scams, and incentivize consumers to remain vigilant.
Based on a survey of over 400 merchants, the report presents a comprehensive, cross-vertical look at the current state of chargebacks and chargeback management.Access the FREE Report
Will the CRM Code Work?
While the Contingent Reimbursement Model Code is an intriguing idea, it’s hard to say at this point whether it will work. One of the main concerns is that the CRM Code is not yet fully conceptualized. For instance, some players worry that introducing the CRM could backfire and lead to more fraud than ever before.
A statement published by HSBC Bank asserts their belief that “there is a real risk that the introduction of a CRM could, at least initially, see an increase in APP scams.” The bank cites a lack of customer vigilance as a likely product of the CRM introduction. It’s essentially created a perverse incentive: if customers have nothing to fear from fraud, they have no reason to try and prevent it.
The version of the CRM Code ultimately adopted does address this concern to a degree. To be eligible for a refund, for instance, the customer may not be deemed to be at fault due to behavior considered “grossly negligent.”
Of course, the guidelines for determining whether a customer violated best practices for an authorized push payment are left up to the PSP to decide. This is like when a customer files a chargeback; the PSP has an incentive to keep customers happy, and thus, to side with a customer in a dispute.
Fraud Mitigation Should Come First
Furthermore, having this fund in place only ensures that consumers are insulated from fraud losses. The contingent reimbursement model doesn’t actually prevent any fraud. Thus, the CRM Code doesn’t fully live up to its first overarching objective: to reduce authorized push payment fraud attacks.
The CRM could be a good starting point. However, we need to continue pushing forward in developing methods to counter APP fraud as part of a broader fraud mitigation strategy.
APP fraud may be quite different from standard card fraud. That said, mitigating new and developing loss sources should be part of any multilayer fraud strategy. Otherwise, we risk allowing fraud to entirely overwhelm the payments sector. That’s why the Contingent Reimbursement Model Code should be a first step…not a final answer.