Following her appearance on BBC Radio 4’s Moneybox, Nikki Worden discusses the growing issue of authorised push payment scams, what the regulators are doing to tackle it, and what that means for payment service providers and others.
Once upon a time, banking was easy. If I wanted to make a payment, I went to my branch and obtained some cash or I wrote a cheque. My local bank saw me on a regular basis, they knew who I was and didn’t ask for any identification before making the payment.
The growth in credit and debit card usage, and in online banking, has changed the landscape for good. As technology has developed, authorisation via these payment mechanisms has become more sophisticated, so that we now talk generically about “payment instruments”, encompassing not only Chip and PIN card technology, but also fingerprint recognition and one-time pass codes. Banks don’t need to know our faces anymore, they can rely on their systems to recognise our unique identifiers and take them as our authorisation for a payment.
Regulating payment services
In 2009, across the EU, Member States responded to this new world by implementing payment services legislation setting out when a payment was to be treated as authorised. In the UK, to reflect EU-wide changes, the 2009 legislation will be repealed and replaced by the Payment Services Regulations 2017 (PSRs) from 13 January 2018. The PSRs and, for debit transfers, the Consumer Credit Act 1974, also set out who bears the losses where payments are not authorised.
However, there has always been one area that has not been legislated for, and that is who bears the losses where payments are authorised but made as a result of fraud. For example, what if I am tricked into authorising a credit transfer from my bank to a fraudster? What if I have paid a fake invoice, or paid money to a fake charity? I’ve been scammed, but I have also authorised the payment, so will my bank refund me? The answer is that payment service providers (PSPs) have no legal responsibility to refund their customers in these circumstances, although some may do so on a case-by-case basis.
These authorised push payment (APP) scams are a growing problem. According to statistics recently released by UK Finance, just over £100m was lost to transfer scams in first six months of 2017. There were 19,370 reported cases – with an average loss of £3,027 for consumers and £21,477 for businesses. There are likely to be many more cases that go unreported, due to the perceived embarrassment felt by some for having been scammed at all.
The problem has been exacerbated by the fact that, since 2008, online payments have generally been made through the UK’s Faster Payments Scheme, so they are received immediately by the scammer, giving customers no time to realise they’ve been scammed and cancel the payment. As increasing use of digital payments and technology creates more complexity in the market, there is every opportunity for fraudsters to extend their reach.
In September 2016, the consumer group Which? submitted a super-complaint to the Payment Systems Regulator (PSR) highlighting the scale of this problem. Which? suggested two remedies:
- PSPs could be made liable for reimbursing consumers when there has been APP fraud, other than where the consumer has acted fraudulently or with gross negligence.
- Standards for risk management could be established which PSPs are required to meet when executing APPs. PSPs would then be liable to reimburse a customer if an APP has been made and the PSP has not been in compliance with those risk management standards (and a customer has not acted fraudulently or with gross negligence).
When the PSR first responded to the super-complaint in December 2016, it took the view that focussing only on the conduct of PSPs and payment systems ignored the role that should be played by a wider eco-system of participants in preventing and responding to APP scams. For example, consumers need to understand the risk of being scammed; data leaks and breaches by other companies are often at the root cause of a scam; and law enforcement and government also have a role to play. As such, a year or so ago, the PSR said that it was satisfied simply to support the payments industry in pursuing existing work in this area, as the industry was already trying to develop a common approach and Best Practice Standards for responding to APP fraud.
What progress has been made?
In its recent report and consultation, the PSR sets out the progress that UK Finance (the trade association representing the UK financial services industry) has made throughout 2017, including:
- developing, collecting and publishing robust APP scam statistics to enable better monitoring of the problem;
- improving how PSPs work together in responding to reports of APP scams by developing industry Best Practice Standards, so that customers might have a better chance of recovering their money; and
- developing a common understanding of what information can be shared between PSPs under the law.
The Financial Conduct Authority (FCA) is actively monitoring the adoption, implementation and impact of the Best Practice Standards and looking at how banks will incorporate them into their policies, procedures and target operating model. It is also checking whether the Senior Manager with responsibility for each bank’s financial crime policies and procedures is ensuring that there are adequate measures to address APP fraud.
Interestingly, however, as all of this work has progressed, the PSR has been persuaded that a more radical step is needed. Notwithstanding industry Best Practice Standards, better data sharing and better preventative technology, it has acknowledged that it is still going to be the case that APP scam victims could bear all the loss in any circumstance if their PSP cannot recover the money or decides not to reimburse them.
The challenge is that there is no easy way to resolve the problem. The PSR has circled back to the second option suggested by Which? in September 2016, being an “industry-led contingent reimbursement model”. Under such a model, PSPs will agree to reimburse victims if those PSPs have not met certain required standards in terms of preventative steps (for example, confirming the payee name matches the payee unique identifiers). The idea is that this would incentivise PSPs to invest in and maintain practices that help prevent and respond to APP scams, which should help reduce APP fraud.
The whole question of contingent reimbursement is, however, fraught with difficulty. Consumer groups may not be very happy with the PSR’s expectation that consumers will have to take a requisite level of care in order to qualify for reimbursement. It follows that there will still be circumstances in which customers have to bear losses where they have been victims of fraud.
The PSR’s view is that a model that guarantees that victims are reimbursed in any circumstance could drive increased first party fraud and actually drive APP fraud up. It has suggested that the standard expected of the consumer should be “high enough that consumers have an incentive to be careful of scams, but should not be unreasonable for them to meet“. Any standard would have to be capable of consistent application, not least to mitigate the risk that this area becomes a focus for claims management companies.
The PSR has also discarded the idea of only holding either the paying PSP or the receiving PSP liable, as this would significantly weaken incentives to prevent and respond to APP scams. Yet the obvious way to ensure that PSPs work together to reimburse a customer – via a central fund – would generate a whole new set of challenges, not least in terms of administration and cost, and there would also be a dispute resolution mechanism that would have to be paid for. Not only would this risk driving up costs for customers, there would be the question of whether this would act as a barrier to new market entrants.
The proposed timeframes are ambitious. The PSR has requested responses to its consultation by 12 January 2018 and, if it decides to give the contingent reimbursement model the green light, it would want to see implementation as soon as possible, with its first iteration implemented by the end of September 2018.