A ring pays a real person to be the director of a business that exists only on paper, opens a merchant account and collects scam payments through it. DeepID reads the director’s face, the device behind the dashboard and the settlement account’s links, so you can hold the payout and offboard the linked merchants together.
Hold
HOLD · face reused · device shared · settlement mule-linked · payout account sharedA person is paid a small fee to lend a name, an ID and a face, and becomes the director of a business that exists only on paper. The ring submits the documents and a bank account to a payment aggregator and the merchant goes live. Soon the checkout link appears in scam chats and on illegal betting sites. The money settles to mule accounts and the merchant goes quiet before a review opens.
An illustrative scenario, not a real customer’s case.
The ring pays a real person for the use of an ID, a face and sometimes a bank account. That person completes verification, often on a device the ring controls.
Your checks saw
A real person. Valid documents.
DeepID reads
A director face already seen on other merchant applications, and a device that has onboarded other merchants.
The application passes the document and bank account checks. The business has no customers, stock or trading history.
Your checks saw
Documents verified. Bank account confirmed.
DeepID reads
A settlement account linked to mule accounts in the payee graph.
The payment link or QR code is sent to people caught in scams and to bettors. Each payment is authorised by the payer, and disputes arrive late.
Your checks saw
Authorised payments. Few disputes so far.
DeepID reads
A dashboard run from a device shared across merchants, with scripted input.
The aggregator settles to the nominated account and the ring moves the money on at once. A new shell takes the merchant’s place before the review.
Your checks saw
Settlement to the registered account.
DeepID reads
One hold on the settlement, and the linked merchants shown as a ring.
Each of these sees one merchant at a time. Read together across the journey, they stop agreeing, and that is what DeepID reads.
The director is a real person with genuine documents who was paid to lend the identity.
The check confirms that the account exists and the name matches, and says nothing about its links.
Rules watch each merchant alone, and scam payments are authorised by the payer, so disputes arrive late.
The ring churns the account and opens a new merchant before the scheduled review.
The director’s live face is matched to the document at onboarding and searched across your merchants. A rented identity returns as director of many businesses, and the reuse exposes the ring behind them.
The business checked against the registry and the settlement account verified against the name on it. Both pass for a shell with a real director, which is why they are read with the device and the graph.
The device behind each application and dashboard login. Many merchants run from the same phones, emulators or remote-access sessions show one operator behind businesses that claim to be unrelated.
Each merchant linked to its settlement account, director, devices and payers. A settlement account inside a mule ring shows that the merchant is collecting for a scam.
The decision runs at onboarding and again before each settlement, with its reasons. Which merchants you hold, and when you offboard a ring, is your policy.
Step up a director whose face or device appears on another application, cool off a new merchant that shares identifiers with others, and hold settlement when the settlement account or the payers link to a mule ring. Offboarding the linked merchants together is your own process, with the ring evidence attached.
No shared director, device or account. The merchant onboards at standard limits and settles on the normal cycle.
The director’s face or the onboarding device appears on another merchant application. The director passes a face check with liveness before approval.
A new merchant shares a device or a director with others but shows no mule links. It goes live with a lower settlement limit for a set time.
The settlement account links to a mule ring. Settlement waits, and your risk team receives the case with the graph attached.
The review confirms a ring across merchants, devices and settlement accounts. Payouts to the linked merchants do not go, and you offboard them together.
“Settlement paused. We’re checking something on your account. You don’t need to do anything now. If we need more from you, we’ll ask in your dashboard.”
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. Director faces, devices and settlement accounts can be measured on your own history first, in a free retrospective against the merchants you have already offboarded. Dashboard behaviour is proved in a shadow proof on live traffic. We publish no figures for these.
Most signals are read during the journey you already run, so a merchant with no shared face, device or account keeps moving. The share sent to a step-up depends on your thresholds, and the shadow proof measures it before any merchant is affected.
Through faces, devices and settlement accounts as well as documents. A ring that changes its paperwork usually keeps the same phones and payout accounts.
You do. DeepID returns the decision, the linked merchants and the reasons, and your policy sets what each triggers. Every decision is logged with its reasons for your analysts and for audit.
The controls below are the mule and risk measures on the rule map, dated and sourced on each market page. Merchant due diligence rules for payment aggregators 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.
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.