Authorised Push Payment Fraud – More Than Just Confirmation of Payee

Authorised Push Payment (APP) Fraud scams currently rank near the top of the regulatory agenda in the UK, with the Confirmation of Payee (CoP) approach one of the regulators’ favoured solutions to the problem. Yet unfortunately, UK Finance just last week stated that Confirmation of Payee system may be delayed until 2020. Until this is implemented and settled, what can financial institutions do in the meantime to protect both customers and themselves from this type of fraud?

What is APP fraud?

Authorised Push Payment (APP) fraud scams differ from more traditional account takeover (ACTO) scenarios as it is the customer, not the fraudster, that initiates and authenticates the payment. Why would a customer be enticed to do this? There are lots of different tricks fraudsters use to get a customer to make a payment to an account they control – and what is worse, the financial institutions rarely reimburse the customer for their full loss. This problem has spread universally and is not just a UK problem. Among several examples, you can see this type of fraud growing in the Nordics and as Zelle P2P payments are now picking up pace, it is also a problem in the United States.

Fraud types under this scenario fall into two main categories: a malicious payee or a malicious redirection. With regards to a payee, this includes the ubiquitous romance scams, where the customer is duped into sending money to someone with whom they think they are in a relationship. These types of scams also include investments scams, where they are convinced to invest in carbon credits or another scheme. In both cases, the money is transferred to a fraudster quickly and before the unwitting consumer realises there is fraud behind the transaction.

With malicious redirection, the scams involve a call, purportedly from the police, saying the customer’s money is not safe in their current financial institution and should be moved. By scaring the customer and injecting a sense of urgency, rational thought is removed, and the customer voluntarily moves the money to a fraudster. Another example of malicious redirection is where an individual or a company receive an e-mail requesting a change of bank details for an upcoming payment. This might seem to be from the customer’s solicitor or a local authorities’ road maintaining supplier or other known vendor. In both instances, the e-mail is really coming from a fraudster who is quoting an account they control. This is often called Business E-mail Compromise (BEC) as the start of the fraud often starts in email form.

Why are regulators so interested?

This type of fraud has been increasing, with £145m of APP Frauds recorded in the first half of 2018, according to UK Finance, with just c.£30m returned to customers. Unlike the majority of Account Takeover frauds, where the bank which makes the payment (based on the fraudsters’ instruction, rather than the customers’ direction) is liable to refund the customer, with APP the bank has no liability. As such, customers are not refunded and losses can be large with life changing consequences due to the scenarios involved, such as sending a house deposit.

Because of this, the
Payment Service Regulator (PSR) and the Financial Conduct Authority (FCA) are starting to force banks to help protect customers more. The main method of doing this is via a Contingent Reimbursement Model (CRM), which means that if a bank cannot demonstrate compliance with the rules they will take on added liability for covering the losses.

Is Confirmation of Payee (CoP) the only solution?

CoP, is basically a name matching routine, so that the customer can more accurately determine if the name of the person that they are paying is in fact the true owner of the account they are providing funds to. This sounds simple, but has a number of operational issues, among which is the complexity of building this capability into a financial institutions current fraud system, especially at a time of multiple regulatory IT builds, such as PSD2. This routine also only targets the Malicious Redirection type of fraud, and is reliant both on data quality of the customer input and the institution’s own databases, among many other data-related concerns.

So, if CoP is clearly not a panacea, what else can financial institutions do to ward off this type of fraud liability? As is usually the case, a multi-layered approach to fighting fraud is key. First, give your customers more opportunities to spot the tell-tale signs of these sophisticated frauds themselves. An institution might consider adding friction in the form of questions or messages aligned to any high-risk payments, to make the customer stop and consider if this is a scam in the making and to potentially identify a fake account manoeuvre.

It is also important to provide your existing fraud systems more data to aid in making better decisions, for example bringing in all customer transactions as well as adding device profiling and behavioural biometrics to your fraud fighting toolbox. These approaches provide operations teams more insight by highlighting unusual behaviour and network links in a simple way.

Finally, financial institutions should take steps to introduce real-time inbound payment profiling, which alerts and blocks unusual transactions as they come in to prevent onward transmission of fraudulent funds.

By implementing these capabilities, along with CoP when it can be implemented, you’ll be able to better protect your customers from APP, whilst reducing fraud losses and liabilities. This armoured system will also help create a hostile environment for fraud and money laundering at your organisation, and further demonstrate to regulators that aggressive action is underway to protect customers.

WE USE COOKIES

We use cookies to ensure that we give you the best experience on this website. If you continue without changing your settings, we’ll assume that you are happy to receive all on the NICE website. However, if you would like, you can change your cookie settings at any time. To find out more about how we use this information, see ourPrivacy Policy.