A mule account is opened with a real face and a genuine document, handed to a ring and left quiet until stolen money needs to move. DeepID reads the face, the device and the behaviour at opening and after it, and the money arriving from senders with no link to the account holder, so you can cool off and hold before the first payment out.
Hold
HOLD · face reused · device shared · handover · fan-in unrelatedA job offer on social media promises easy money for light work. The recruit opens an account with a genuine document and a live face, then sells or rents it to a ring. The account sits quiet until the ring needs it. Then it wakes up, takes credits from people who have never met the account holder and sends the money on at once.
An illustrative scenario, not a real customer’s case.
Job offers and social media find people who will open an account for a fee. Some know what they are selling and some believe the work is genuine.
Your checks saw
Nothing. Recruitment happens outside the bank.
DeepID reads
No session yet. Faces, devices and payees from earlier openings are already in the graph.
The recruit applies with a genuine document and a live face, from a device that has opened other accounts, or from an emulator the ring runs.
Your checks saw
Genuine document. Live face. KYC passed.
DeepID reads
The same face under other names, and many accounts on the same device.
The recruit passes over the credentials, the SIM or the phone itself. The account stays dormant until the ring needs it.
Your checks saw
A returning customer. Valid credentials.
DeepID reads
A new operator: the typing and the device no longer match the opening, and a SIM or phone change puts the account in a cool-off.
Credits arrive from senders with no link to the account holder and leave again almost at once. One account can pass money from dozens of customers in a few days.
Your checks saw
Alerts fire after the money has moved.
DeepID reads
Money arriving from many unrelated senders, money out within minutes, and links to a known ring: one hold before the first payment out.
Each of these sees one account at a time. Read together across the journey, they stop agreeing, and that is what DeepID reads.
The document is genuine and the face is live, because the mule is often a real person.
It sees the account only after money flows, when the first customers have already paid.
A reactivated account arrives with valid credentials and looks like a returning customer.
The recruit has no adverse record, so a check on the name returns nothing.
Face search across your customers finds the same live face behind earlier applications and other names. A person who opens accounts to order leaves this trail even when each application looks clean.
A device ID that survives reinstalls and resets, so the accounts on one phone can be counted, and emulators used to open accounts in bulk. A device handed to a new operator after opening points to a sold or rented account.
Typing, touch and navigation after opening compared with the rhythm seen at sign-up. A clear change shows a different person now runs the account, which is the moment of handover.
Money arriving from many senders with no link to the account holder, passed on within minutes, and links through shared devices and payees to a known ring. This separates a mule from a busy genuine account early.
The account is bound to one device and SIM at sign-up. When either changes, the customer proves it is them with a face check before anything is bound again, and a cool-off set per market limits what can leave.
Cool off a new account, and any account whose SIM or phone has changed, and hold outward payments when money arrives from unrelated senders. Freezing the account and filing the report stay under your own procedures, with the reasons in the case file.
A new account with no face, device or graph links. It opens as normal, and DeepID decides again at every key event.
The operator appears to change, or a dormant account wakes up on a new phone. The account holder passes a face check against the face from sign-up before payments continue.
A new account, or one whose SIM or phone just changed. Outward payments start with a lower limit for the set time.
Handover signs are followed by credits from unrelated senders. Outward payments wait while your team investigates, with the reasons in the case.
The account is linked to a known ring, or the same face sits behind several accounts. Payments do not go, and you freeze the account under your own procedures.
“Payments from this account are limited while we check something. Your balance hasn’t changed. We’ll call you on +91 •••• 3210.”
The same decision reaches your FRM, case manager or SIEM as an event, with one code per reason. The codes here are illustrative; real codes and their names are agreed in the sandbox.
Agreed in writing before the pilot starts, and counted on your own traffic against what you see today. Faces, devices and payee links can be measured on your own history first, in a free retrospective against the mules you have already confirmed. Behaviour and SIM changes are proved in a shadow proof on live traffic. We publish no figures for these.
A single signal is rarely enough, because families share phones and new customers behave in many ways. A reused face, a crowded device, a change of operator and money from unrelated senders are read together, and each is a reason in the decision. You set the thresholds for a cool-off, a hold and a freeze on your own traffic.
Then the device and SIM signals look unchanged. The typing and navigation can still show a different person, and the graph still reads the money arriving once credits begin. With fewer signals you may choose a cool-off before a hold.
Yes. The face at opening, the device, the behaviour and the money arriving are all read in your own traffic. DeepID adds nothing from other banks, and claims no integration with any registry or shared model; its reasons reach your FRM and your case tool beside the alerts you already have.
The controls below are the mule, risk and binding measures on the rule map. In India, MuleHunter.AI and the I4C Suspect Registry are the mule-detection work the Finance Ministry has asked banks to adopt; DeepID claims no integration with either.
A payee and mule graph across accounts and devices, with recipient risk scored before the payment is sent.
Device, behaviour, scam and payee signals read at login, new payee and payment, returned as one decision with its reasons.
SIM and device binding at onboarding and re-binding on change, with the number confirmed by the network and device integrity read every session.
DeepID supports compliance with these rules. It never claims to guarantee it.
A free retrospective on 30 to 90 days of your own transactions shows the payee and mule links in them. Session signals follow in a shadow proof, once the SDK runs.