Detecting and preventing the use of accounts by money mules has long been an important part of Fraud and Financial Crime strategy.  In some Financial Institutions it has received investment and facilitated improved capability in recent years.  Lloyds Bank is one of the institutions that has invested, developing its own solution for mule detection back in 2018.  The bank protected its customers and the customers of other banks, with over £91m of fraudulent funds being stopped from reaching the fraudsters across over130,000 accounts. 

For other Financial Institutions, there is an aspiration for a single solution to address both Fraud and AML. But the focus on this goal, or even the smaller target of identifying mules, haven’t reached the priority needed to gain investment for significant change.   

International impact of UK regulatory changes

The recently published Payment Systems Regulator (PSR) reimbursement policy in the UK is changing priorities, with liability being applied to banks that receive fraudulent Authorized Push Payments (APP) from April 2024.  The impacts of the change are potentially international.  The EU, seemingly looking to the UK, is progressing with a version of Confirmation of Payee, and introducing refunds for victims of “bank impersonation” scams.   

UK Payment Service Providers (PSPs) receiving APP fraudulent payments will have to send 50% of the value of the payment to the sending PSP, and thus sharing the loss of the scam.  This has triggered PSPs to review their controls and quantify the size of losses that are likely to come from liability for mule accounts in scam cases.  The size is likely to depend on the strength of controls and may not relate to the size of the PSP, with some smaller PSPs having larger proportions of mule accounts.  This is also the case in the US, where similar conversations about liability on Zelle transactions have led to some banks suggesting they couldn’t afford the refunds and would have to stop being part of the Zelle network. 

Whether you work for a UK or US bank with concerns about being on the wrong side of a liability shift, or a bank elsewhere in the world that intends to do more to prevent money reaching the organised crime gangs running scams and money mules, machine learning with real-time detection is the favoured solution. 

The lifecycle of a money mule

Money mules are accounts used to transfer fraudulently obtained money to the criminals behind the fraud.  They are setup and controlled in different ways, with some fraudsters using bots to setup and control the whole process, while others use a system of recruiters and herders to setup, control and/or take over accounts more manually. Below are the phases in the lifecycle of money mules. 

Onboarding and application stage – Some accounts are mule accounts from inception; they were applied for with the intention of being used as a mule. 

Early use and funding – Once opened, accounts may be used quickly, with little to no genuine looking activity, with even the funding deposit being proceeds of crime. Accounts not used straight away will likely have a small number of low value transactions over a period of weeks or months rather than no activity.  This is to create a profile that appears to be more genuine than no activity, and thus reduce the chance of being blocked and investigated. 

Longer term use – In some cases, criminals running mule accounts can be very patient and keep up activity for months to appear genuine.  However, it can also be the case the fraudsters buy existing accounts for use or pay for temporary use of an account so that the applicant information and behaviour is genuine before receiving any proceeds of crime.  Historically, it was younger people and particularly students that were targeted by mule recruiters to act as money mules, but more recently, trends have changed to see many more from older generations becoming mules as well.  Some mules may say that it is just easy money and not realise it is criminal activity, whilst others are scams for online jobs that revolve around transferring money between bank accounts or buying gift cards. 

Receiving funds and dispersing funds – Volumes and values of fraudulent transactions into an account can vary depending on the type of fraud and how the mule network is structured.  It might be a single large payment that is quickly withdrawn in cash. Or, it  could be multiple smaller payments that are transferred on or used to make purchases.  Usually, timeframes are short with the expectation of detection or reporting not being far behind, but there are occasions when fraudsters are able to reuse an account because it hasn’t been blocked yet. 

Controls needed for mule accounts

Each phase of the lifecycle can have its own controls, with the expectation of detecting mules at each point. For example, as part of onboarding and application fraud controls, applications can be compared to previous applications and other data sources to identify data that is consistent with previous mule data and trends or inconsistent with genuine data.  This can stop some of the more obvious mule accounts from being opened.  It is likely that there is insufficient data at this stage to stop most mule accounts being opened though, particularly when accounts are initially opened with genuine intent and later become mules.  Any insights gained can be part of further assessments made during the account lifecycle. 

The remaining phases of a mule lifecycle become a sequence of events that can be profiled to identify whether behaviour aligns to the applicant and when behaviour changes and signifies an account changing from being genuine to being primed to be used as a mule. 

Detect and prevent mule activity

The earlier any financial crime is detected, the better, as it gives the opportunity to learn, disrupt and prevent harm. Early detection must be balanced with when action can be taken though, with a requirement for evidence and not just suspicion.

Declining suspicious applications prevents a mule being able to receive any funds but can be challenging to justify if there are no clear links to previous fraud. Accounts may need to be let through for monitoring to collect more information and insight regarding the customer intent.

Inbound payment monitoring can quantify suspicion and give a trigger point for action. For example, when a payment is received in an account that is not aligned to the customer’s actual or expected behaviour profile, an alert can be created and even accounts blocked while reviews take place. Combining inbound and outbound payment profiling can strengthen the detection as it gives extra insight into the potential mule behavior before and after the inbound payment.

The optimal solution for detecting and preventing mule activity would have insights and profiling of the application as well as payments and card transactions, with the ability to intervene at any point across the lifecycle. This enables the best point and mode of intervention to be chosen in each instance that minimises risk and maximizes evidence of intent.

Featurespace can help detect authorized push payment mules

Featurespace built the ARIC™ Risk Hub to serve as a real-time layer of protection for financial institutions and their customers using their payment systems.

ARIC Risk Hub uses patented Adaptive Behavioral Analytics technology to learn about customer behaviors — the accounts they open and the transactions they make, when, to whom, why? The machine learning that powers this technology continuously learns the transactions that are legitimate and those transactions that are suspicious. It can make these assessments in real-time. This is already industry proven in our work with our customers and can act as the risk engine across the mule lifecycle. You can read about our success detecting scams with Natwest here.

If replacing the payments detection solution isn’t the right option currently, then Featurespace’s Scam Detect can help augment your detection with a Scam Detect score that is easy to integrate with your current platform to monitor inbound payments, outbound payments, or both. This option has simple integration requirements and a rapid deployment model. You can see further details here.