Twenty-Three Accounts, One Employer
A retail bank's analytics flag a cluster of 23 accounts opened within six weeks across five branches. All list the same employer, Ridgeway Logistics, and similar income figures. All receive inbound faster payments within 48 hours of opening, then make three to six outbound transfers to two crypto exchanges and one account held at another bank. Total inflow is $740,000. The accounts were opened through a 'streamlined' digital journey introduced three months ago that removed address verification for applicants matching credit bureau records. Two genuine customers who match the cluster profile have complained that their accounts were frozen, one during a rent payment.
1. What fraud type is this, and what distinguishes a mule account from a genuine customer who merely resembles the profile?
Read the worked answer
The pattern is money mule / funnel accounts: accounts opened to receive criminal proceeds and pass them on quickly.
The discriminating features are behavioural, not demographic:
- No payroll credit despite a stated employer. A genuine Ridgeway employee shows a salary credit from Ridgeway. These accounts show inbound payments from many unrelated senders - the opposite of employment.
- Rapid pass-through with near-zero retention. Genuine accounts accumulate balances, pay rent, utilities, direct debits. Funnel accounts are conduits.
- Destination concentration. Off-ramping to crypto exchanges is a fast exit; genuine customers use crypto too, but alongside ordinary spending.
- Shared non-financial attributes - device, IP, onboarding session, address normalisation - are the strongest cluster evidence and are the ones a fraud analyst should weight most.
- Time-to-first-inbound of 48 hours indicates the account was opened for the purpose, not adopted later.
A genuine customer with a similar income and age will show tenure signals: payroll, direct debits, a device seen before, gradual activity growth. Profile matching alone would have caught those two complainants - which is exactly the failure mode the cluster review must correct.
2. How do you size and prioritise the response, and what do you do about the two false positives?
Read the worked answer
Prioritise by shared attributes, not by list order. Rank the 23 by strength of cluster evidence - common device or IP, identical onboarding session, same beneficiary accounts. Restrict the strongest first; the three outbound beneficiaries are the choke point and a single request to the receiving bank may freeze the value faster than freezing 23 accounts.
Size the exposure properly. $740,000 inflow is not the loss; the loss is what has already left and is unrecoverable. Establish how much remains, how much reached the exchanges, and whether the exchange will freeze on request. That number, not the inflow, drives escalation.
Treat the control change as the root cause. Removing address verification for bureau-matched applicants was a control design decision. It needs a written risk assessment, a test of whether fraud rates in the streamlined cohort differ from the control cohort, and a recommendation - revert the change, or add a compensating control such as device-binding or delayed first outbound payment. Investigating the 23 without fixing the journey guarantees a repeat.
On the false positives: compensate and apologise, unblock quickly, and cover consequential loss such as a returned rent payment. But do not conclude the friction was wrong - the bank is entitled to act on a cluster. The defensible position is that the design change raised the false-positive rate, and that is a further argument for fixing the journey. Log both cases as complaints and feed them into the control review.
3. Assuming an authorised push payment reimbursement regime applies, is the bank liable here?
Read the worked answer
State your assumptions, because the answer is regime-specific and the facts cut both ways.
Arguments that the bank bears responsibility: the mule accounts were opened through a journey the bank itself weakened, removing address verification. If the receiving bank's onboarding deficiency is what allowed the proceeds to be laundered onward, that is the bank's own control failure, not the victim's error. Under regimes that require reimbursement absent gross negligence by the payer, this points toward liability.
Arguments that it does not: the victims here are the senders who paid the mules, and whether they were themselves deceived, and whether they ignored warnings, is unknown. Reimbursement regimes typically exclude the payer's gross negligence and often require the sending institution, not the receiving one, to reimburse.
What to actually do:
- Establish which institution each victim paid from - the liability question may not be yours.
- Preserve the cluster evidence before any account closure; the receiving bank's own records will be needed by the payer's bank.
- Distinguish two duties that are often conflated: the duty to reimburse (customer outcome) and the duty to report and remediate (regulatory). Failing one does not excuse the other.
- Do not let the reimbursement question delay the control fix - the journey is still open and still generating accounts.