Social Engineering and Push Payment Fraud – Who Should Pay?
Blog: Enterprise Decision Management Blog
In a previous blog I wrote about authorized push payment fraud and how social engineering leads to victims making inadvertent payments to fraudsters. I highlighted the case for banks to use behavioral analytics to identify suspicious payments before they are made. This is particularly important when an irrevocable, real-time payments scheme such as UK Faster Payments or SEPA CT Inst is used.
While the focus has often been on recovering losses from the bank of the victim, there are also instances where victims and authorities look to the receiving bank for recompense. Their case is that the receiving bank has been negligent in their account-opening procedures and opened an account for a fraudster using a stolen or synthetic identity. This account has then been used to accept the proceeds of the authorized push payment fraud.
In a recent case a victim paid what they believed to be an invoice from their builder, only to find it wasn’t their builder they’d paid but a fraudster who had intercepted the invoicing process. In another case a victim transferred £4K from his bank account to buy a shepherd’s hut on Ebay. The hut never materialised and the payment made by bank transfer had gone to a fraudster. In both cases it appears that the fraudster had opened a bank account using either a stolen or synthetic identity; this bought the account-opening processes at the receiving banks into question.
On the surface it seems like an obvious answer – the receiving bank takes responsibility for the behavior of fraudsters they should not have opened accounts for, particularly when the account was opened using a stolen or synthetic identity. But this does not solve the problem of authorized push payment fraud for a number of reasons:
- The link to the fraudster frequently isn’t as clear. In the two cases above the payment seems to have been sent directly to an account that had been opened using a stolen or synthetic identity. This isn’t always the case — fraudsters can take over the accounts of legitimate account holders or even persuade people to let them use their accounts to transfer the proceeds of fraud. It is difficult for a receiving bank to spot this behavior in time to prevent it, particularly when the money can be hopped quickly through several such mule accounts, before arriving in an account the fraudster can extract it from.
- Even when the receiving bank has opened an account for a fraudster using a stolen or synthetic identity, the fraud is not spotted until after it has been executed. The original vector of attack, the social engineering and the payment have already happened. It may be good that victims can get some restitution from the receiving bank but the bank is then out of pocket and the fraudster has been successful.
The Which Super Complaint shows that consumers are increasingly looking to banks to solve the issue of authorised push payment fraud. Even in cases where banks may not consider themselves to be liable, negative publicity and loss of reputation is significant. Consumers have been given the welcome ability to make irrevocable, real-time payments, but individuals are not equipped to deal with all of the consequences. For example they cannot spot patterns across thousands of payments that indicate fraud — but their bank could.
At present many banks look at application fraud, payment fraud and account takeover fraud in silos. This story illustrates the same fraud can take advantage of weaknesses at any point. By looking at fraud in a more holistic manner across the entire enterprise, banks can be better prepared to stop fraud at all stages of the customer and payment lifecycles.
FICO has been leading the way in taking an enterprise-wide approach to fraud detection and management using the industry-leading FICO Falcon fraud Platform.
For more on application fraud, see the posts from my colleague Liz Lasher.
The post Social Engineering and Push Payment Fraud – Who Should Pay? appeared first on FICO.
Leave a Comment
You must be logged in to post a comment.
