A fake trading group shows the customer profits she cannot withdraw, then tells her where to pay. On the bank side DeepID reads the instruction in the session and slows the first large payment. On the broker side it reads the device, the face and the funding behind a trading account someone else controls.
Cool off
COOL_OFF · screen share · details pasted · first-time payee · amount unusualA customer is added to a trading group on a messaging app. Members post screenshots of gains, an adviser shares daily tips, and a trading app shows her balance growing. To invest more, or to withdraw, she is told to pay a named bank account. She opens her bank app and sends the money herself.
An illustrative scenario, not a real customer’s case.
A messaging group poses as a trading club run by an adviser. Scripted members post gains and tips for days or weeks, and she comes to trust the group more than any warning screen.
Your checks saw
Nothing. The contact is outside the bank.
DeepID reads
No signal yet. Her usual rhythm in the app is on record.
She installs a trading app or opens a site that shows a rising balance. Sometimes a small early withdrawal is paid out to prove the platform is real.
Your checks saw
A small credit from an unknown payer.
DeepID reads
A small credit from an account the payee graph already links to other customers in the same pattern.
The group tells her to pay a named bank account, or to fund a trading account it controls. She follows the instructions live, with the screen shared and the account details pasted in.
Your checks saw
Known device. Correct login. Authorised payment.
DeepID reads
A shared screen, pasted payee details, a first-time payee, a round amount larger than her usual, and recipient risk on the payee.
The mule account forwards the money within hours, through other accounts or through trades and withdrawals at a broker. The controller runs many such accounts from a few devices.
Your checks saw
Outward payments within the account’s limits.
DeepID reads
Money out within minutes of money in, a device shared across trading accounts, and links to a mule ring.
Each of these passes because the customer is real. Read together across the journey, they stop agreeing, and that is what DeepID reads.
She signs in with the right credentials on a known device, so authentication passes.
Rules see an authorised payment from the account holder and have no view of the instruction behind it.
The trading account was opened with genuine documents, and nobody checks again when someone else takes control.
The same warning appears on every payment, and the group tells her in advance to ignore it.
A screen shared or a remote-access app running while the payee is added, and payee details pasted rather than typed. A customer who is being told where to pay looks like this.
A long-standing, low-activity customer who starts sending large round amounts to new payees has changed, measured against her own history. That change is worth slowing.
A device fingerprint that survives reinstalls, and a count of the accounts it operates. A trading account run from a device that also runs others points to a controller behind the named holder.
The payee graph links payees and trading accounts to the devices and accounts around them. A payee that is new to this customer can already sit inside a mule ring, so recipient risk is scored before the money leaves.
Face search across your customers finds the same live face behind several trading accounts, the sign of rented identities opened to order.
Warn on the first payment to an investment payee, cool off a large round payment made with the screen shared, and hold when the payee sits in a mule ring. At the broker, hold withdrawals from an account that a shared device or a reused face shows someone else controls; restricting the account afterwards is your compliance team’s process.
A known payee, a usual amount and no sign of instruction in the session. The payment goes with nothing added.
A first large payment to a new investment payee, with nothing else unusual. She sees a warning about fake trading groups and confirms before it goes.
A large round payment with the screen shared and the payee pasted in. Part of it can go now and the rest after a set time, and she is asked to check the firm through a source of her own.
The payee is linked to a mule ring. The payment waits until your team has spoken to her.
At the broker, a trading account run from a device shared across accounts, with money out within minutes of money in. Withdrawals do not go, and your compliance team opens the case.
“Sending in two parts. This is your first large payment to this account. ₹10,000 can go now, the rest in 12 hours. Before then, look the firm up yourself, not through the group.”
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. Payee and mule links can start from your own history, in a free retrospective. The shared screen and the pasted details only exist once the SDK runs, so they are proved in a shadow proof on live traffic. We publish no figures for these.
How the payment was made, not only who made it. A shared screen, pasted details, a break from her own history and a payee already in a mule ring each show instruction. A retrospective on your own history shows how strong the payee signals are in your book before anything changes.
Payments to known payees at usual amounts pass with nothing added. The response is graduated: a warning before a cool-off, and a cool-off before a hold. Thresholds are set with your team and tested in the shadow proof before any customer sees them.
No. A shared device, a reused face and money out within minutes of money in are read in the broker’s own traffic. The bank side reads its own sessions and payees. Each decides on what it can see.
No market on the rule map has a rule written for investment scams alone. The controls below are the anti-scam and mule measures each market page dates and sources.
Device, behaviour, scam and payee signals read at login, new payee and payment, returned as one decision with its reasons.
Cool-off and hold decisions after a new device, SIM or payee, or when a payment looks coerced, set per market and journey.
No further dated rule for this control is mapped yet in India, Singapore or Malaysia.
A payee and mule graph across accounts and devices, with recipient risk scored before the payment is sent.
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.