Mule account detection at top-up

The control is a real-time hold on the inbound top-up, with the velocity and payee-network reasons attached, before the credit posts to available balance. The score is not a close-account decision. A human in financial-crime ops releases, returns, or escalates using those cites.

If the funds post first and the alert arrives later, the mule has already moved the money.

A mule account is a customer account used to receive and rapidly pass on proceeds of fraud or other crime. At top-up, the useful signal is a burst of inbound credits from payers the customer has no prior relationship with, plus a payee graph that already connects those payers, this account, or the intended onward destination to known mule or layering activity. Volume without that network context is how you freeze a payroll top-up or a family transfer.

This sits next to first-party fraud detection at first deposit for the opening-balance problem, and next to authorized push payment scam detection for the victim-side push. Here the customer is the receiving account, and the window is the inbound credit.

Score two families of features on every inbound top-up that can increase available balance: card load, Faster Payments, internal transfer, cash, and wallet top-up. Run them in the authorization or posting path, not in an overnight batch.

Velocity is the rate and composition of inbound credits, not a single amount threshold. Look at the count of distinct payers in a short window, time from account open to first inbound, the gap between successive credits, and whether the sources are new to this customer. A single large transfer from a named joint holder who has paid this account for months is high value and low mule risk. Three modest credits from three new payers inside an hour is the opposite pattern, even if each amount would pass a static limit.

Payee network is who those payers are connected to, and who this account has already paid or been paid by. Features that discriminate: the payer already funded other accounts that rapidly drained; this account sits one hop from a confirmed mule or high-risk wallet cluster; or the inbound is a many-to-one fan-in with no household or employer edge. The graph is the same family of signal used in AML transaction network monitoring, applied here at the moment of credit rather than in a later monitoring cycle.

Do not treat high inbound volume as mule activity. Salary, bonus, house-sale proceeds, and a parent funding a student account all produce large credits. What you need is novelty of the payer set plus graph proximity to known pass-through behaviour. If you cannot explain the score in those terms, do not hold.

Suppress or down-weight when the payer is a known joint account holder, a linked internal product of the same customer, a payroll originator already on file, or a recurring family counterparty with a stable history.

On a score above the hold threshold, block posting of that credit only. Leave the account open. Do not freeze outbound as an automatic side effect of the mule score, and do not issue a closure from the model. Closure, suspicious-activity reporting, and relationship exit are case outcomes after review.

The hold payload must cite the velocity window (how many distinct new payers, over what interval, relative to account age) and the graph edges that fired (which counterparties, which clusters or prior mule cases they connect to). A queue item that only shows a mule score is not operable. The reviewer needs to see why this top-up, not why this customer in the abstract.

Queue to a financial-crime ops workbench with a release, return-to-originator, and escalate path. Time-box the queue. A hold that sits until the next morning is a silent decline for a legitimate customer, and a race the mule already won if they have other channels.

Illustrative path: a current account opened last week receives three inbound Faster Payments from three personal accounts the customer has never been paid by, clustered inside two hours, and one of those payers already funded two other recently opened accounts that drained to the same e-money wallet. The control holds the third credit before it posts, cites the three-payer burst and the shared wallet cluster, and parks the item for a human. The reviewer can still release if the customer is aggregating gifts and the wallet is their own. The score does not close the account. Contrast that with a joint current account where the second holder, already named on the mandate, sends a large internal top-up from their linked savings product on payday. Velocity is high, the payer is known, and the graph edge is household, not mule. That credit should post.

If your stack posts first and alerts second, you do not have this control. You have a lookback, which is how mule proceeds leave before ops sees the case. Move the score into the posting path, or accept that you will be recovering funds rather than preventing the pass-through.

Holds that later release should still be available to AML case disposition at funding so the same facts are not re-investigated from a blank case file. The hold is a quality gate on the credit, not a substitute for disposition.

Blocking a known joint-account top-up. Joint holders, named third-party mandate payers, and linked own-product transfers are high-volume, high-frequency, and economically normal. If the model treats inbound from another account as novel without resolving the relationship to the mandate and the household graph, you will hold the credits customers use to live. Fix this with relationship features in the score, not with a manual whitelist after the complaint.

Treating volume alone as mule. A static amount or daily-credit cap will fire on house deposits, tax refunds, and family support. Mule typology at top-up is fan-in from novel payers plus rapid intended fan-out, often into wallets already on a pass-through cluster. Amount is a secondary feature. If volume is your primary reason code, you will train ops to ignore the queue.

Posting the funds then alerting. Once available balance updates, the mule can outbound in seconds. An after-the-fact case is recovery and correspondent noise, not prevention. Real-time means the credit is not available until the hold is released or the score is below threshold. Near-real-time that still posts is not a hold.

Banks typically run this control on transaction-monitoring and fraud platforms such as NICE Actimize, Featurespace, and Temenos. Treat those vendors as a class of scoring and case-routing systems that sit in or next to the payment and core posting flow. Do not assume any one of them interrupts posting, attaches velocity and graph cites, or suppresses joint-account top-ups unless you have configured that path. The policy is yours: hold this credit, never close from the score, never treat a family transfer as a mule.

Ops still owns the reason-code contract with the posting engine, the queue SLA, the distinction between hold this credit and exit this customer, and the suppressions for household and payroll. If the platform cannot attach velocity and graph cites to the hold, you will get a score without a reviewable case. If it cannot interrupt posting, you will get an alert after the mule has paid the next hop.

Wire the same network view that monitors layered transactions after the fact into this inbound gate, rather than running two disconnected graphs.