A ring sends scam money through the same corridors that workers use to support their families, on identities rented from real workers. DeepID reads the face behind the sender ID, the device behind many senders and the receiver paid by senders who have no link to each other, so a remittance app can hold or block the transfer before payout.
Hold
HOLD · face mismatch · device shared · receiver fan-in · mule-linked receiverA remittance app serves workers in the Gulf who send money home. Most transfers are small, regular and go to the same family member. Inside that volume, a ring sends scam money on identities rented from real workers. The sender ID is valid in the app and at the counter, and the money lands with a receiver who cashes out and passes it on.
An illustrative scenario, not a real customer’s case.
A ring pays a worker for the use of a genuine ID and remittance profile. Ring members then sign in as that worker in the app, or present the document at a counter.
Your checks saw
A valid ID. A registered customer.
DeepID reads
A live face that does not match the face registered on this ID.
In the app it comes from a device the ring controls; at a counter it is handed over as cash. Amounts are sized to look like ordinary family support.
Your checks saw
Amount within limits. Screening clear.
DeepID reads
A device already linked to many senders, or an emulator.
The money goes to a bank account, wallet or cash pick-up point in the home market. The receiver collects from many senders with no family link between them.
Your checks saw
The receiver’s name passes screening.
DeepID reads
A receiver paid by many unrelated senders, linked to a mule ring.
The receiver withdraws cash or forwards the money within a short time. The money is out of the corridor and the trail thins.
Your checks saw
Transfer complete. No further view.
DeepID reads
One hold before payout, with the sender and receiver reasons for your compliance team.
Each of these sees one end of the transfer. Read together across the journey, they stop agreeing, and that is what DeepID reads.
The document is genuine and current, so the check passes whoever presents it.
Screening tests names against lists and says nothing about a mule receiver with a clean name.
Rings spread value across many rented identities so that each sender stays inside the limits.
The receiving bank sees an inbound remittance from an established provider and has no view of who presented the sender ID.
A face check with liveness in the app at registration and before higher-risk transfers, matched to the face registered on this ID. An ID presented by several different faces over time is a rented identity that a document check will pass.
The sender profiles linked to each device, and the devices linked to each sender. Many senders on one phone, or a sender who moves across many phones, both point to ring control.
Receivers linked to the senders, phones and accounts around them. A receiver paid by many senders who have no link to each other carries recipient risk that the sender check never reaches.
The remittance app bound to the sender’s own device and SIM at registration, and checked again when either changes, so a profile moved to the ring’s phone is read as a change.
One decision at the moment of transfer, with the sender and receiver reasons, so your compliance officer can act and audit can follow.
Step up a sender on a new device or adding a new receiver, cool off a device linked to several sender profiles, and hold or block when the receiver is paid by unrelated senders or sits in a mule ring. The receiver stays marked on the graph for the next transfer.
The sender’s face matches, the device is known and the receiver is a regular family payee. The transfer goes at normal speed.
A sender signs in on a new device or adds a new receiver. She passes a face check with liveness in the app before the transfer goes.
A device linked to several sender profiles, with no receiver risk yet. Transfers from those profiles start with a lower limit for a set time.
The receiver is paid by many unrelated senders, or linked to a mule ring. The transfer waits before payout, and the case goes to your compliance team with the reasons.
The ID is used by several faces and the receiver is a confirmed mule. The transfer does not go, and the receiver stays marked on the graph.
“This transfer is paused while we check it. Your money hasn’t left your account, and we’ll call you on your registered number. If someone has asked to use your ID to send money, stop here.”
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. Receiver and device links can be measured on your own history first, in a free retrospective. The face check is proved in a shadow proof on live sessions. We publish no figures for these.
The receiver and sender links work on any channel, because they come from transfer and identifier data. Face and device signals are strongest in the app, where the SDK runs. A retrospective shows where the risk sits by channel in your own business.
From your own transfers. A receiver paid by many of your unrelated senders is visible from the start, without any data from the receiving bank.
Regular senders paying a known family receiver see no change. The step-up and the hold are reserved for transfers where sender and receiver signals combine. The thresholds are agreed with you and tested in the shadow proof before they go live.
The controls below are the mule, risk and binding measures on the rule map, dated and sourced on each market page. Exchange-house rules in the UAE and Saudi Arabia are not mapped yet.
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.