WhatsApp fraud, where criminals try to embezzle money from credulous, vulnerable victims, is rampant. Part of the problem is that with internet banking and especially banking apps, transferring money is a breeze. Here I discuss some methods that could help to protect potential victims, by adding some purposeful friction.
There are several forms of fraud involving WhatsApp. One method involves the scammer sending a message to the victim, while claiming to be a family member (e.g. “Hi dad, It’s me. Had a little accident and broke my phone, so I am now contacting you with my new number.”). As soon as the victim responds (“Hi dear, hope you’re ok!”) and apparently believes the claim, the scammer concocts a story that he/she urgently needs some money. Could dad please wire a significant amount of money as soon as possible, pretty please? Believe it or not, many people fall for this. (According to this study, in the Netherlands this happens to 5% of the people contacted by scammers, sometimes paying thousands of euros!)
Now the way in which the victim is asked to transfer money varies: sometimes a link to a payment request is sent, allowing the victim to “seamlessly” rescue the sibling by opening it with their banking app. Sometimes, an account number is sent with the request to transfer the money to that account.
The latter form of fraud can be prevented by adding an account check to each transfer approved through the banking app. This check warns any user when the name of the account holder does not match with the account number entered. Dutch banks implement this. As most parents will have transferred money to their children in the past, you would think the scammer is exposed. (This check also helps detect errors when entering long bank account numbers by hand.) Unfortunately, the check only tells you that there is a mismatch between name and account number. For (obvious) privacy and fraud prevention reasons the full known account name corresponding to the entered account number is not shown. As a result, small misspellings in the account name are flagged as errors exactly like a complete name mismatch. (Perhaps banks could implement a less binary indicator, where a small misspelling is signalled different from a complete mismatch.) As many people make such small spelling mistakes, the warning happens often and, by the ‘boy-cries-wolf’ principle, therefore ignored.
There are two other fraud prevention methods that banks could consider to implement. Both are based on the fact that the scammer needs to act fast: the longer it takes, the more likely it becomes that the victim gets suspicious. Moreover, the real sibling may contact the victim in the meantime, collapsing the scammer’s ploy.
The first one uses the difference between a savings and a checking account. Payments are only made from the checking account: by keeping the balance low, any fraud has only limited impact. Possibly larger sums of money kept on the savings account can only be transferred to the checking account. Banks could impose a fixed delay, of several days, for all transfers between a savings account and checking accounts, offering the option to cancel the transfer at any time within the grace period.
The second one also uses a similar multi-day delay, but now for any transfers from the checking account to a hitherto unknown account. This works because most people rarely transfer money to a new account: most payments are regular ones (subscriptions, instalments), or payments to friends or relatives. And people rarely change banks, so their account numbers stay fixed. Banks can easily detect when a transfer to a new account is initiated. Also, banking apps often have an ‘address book’ storing the account numbers for known accounts to which transfers have been made in the past. Enforcing a delay on transfers to unknown accounts therefore does not affect normal transactions. And any automatically collected monthly payments are similarly unaffected. Again users should have the option to cancel the transfer at any time within the grace period (when they realise something is “phishy”). Note that this delay should not be enforced when paying with a banking card at point-of-sale terminal in a shop: this would prevent people from shopping in any new shops!
Perhaps an emergency escape should be implemented in the (unlikely, but possible) case that someone really, really needs to transfer a significant amount of money to an unknown account. One approach would be to require the user to contact the abuse desk of the bank by phone to approve the transfer. The abuse desk could ask some questions to make the user think twice before really approving the transaction, thus increasing the chance that the transfer is really legitimate. (You probably do not want the abuse desk to make that decision because in the end the user knows the context better than they do.)
Consideration should also be given to the fact that in specific circumstances, users actually do transfer money to complete strangers, for example when buying stuff on eBay or similar online marketplaces. Delaying the transaction, and especially the option to cancel it, are completely unacceptable in such settings. The online marketplaces could play a role here, and some do. Dutch marktplaats offers to handle payment requests on behalf of the seller, meaning that buyers only need to ‘whitelist’ the account number of the marketplace once in order to trade with anybody on that platform.
Note that limiting transfers to unknown accounts only for amounts exceeding a certain threshold will probably not work as, according to the study cited, scammers often ask for amounts less than 50 euro, so the threshold would be so low that almost all transfers trigger it, and hence will all be delayed anyway.
The best option would be to enable these delays by default, and only allow them to be disabled after a very clear warning of the potential consequences (and the clear message that the bank can and will not be liable should you fall for such a scam after the delay is disabled). Disabling a delay should of course be similarly delayed…