A caller posing as police keeps the customer on a video call and tells her to move her savings to a safe account. She passes every check herself. DeepID reads the call, the shared screen and the payee, and holds the payment until you call her back.
Hold
HOLD · active call · screen share · dictation pauses · mule-linked payeeA video call comes in from an unknown number. A man in uniform, in front of an official-looking backdrop, tells Ananya Rao that a crime is linked to her identity, that she is under digital arrest and must stay on camera. After 41 minutes she opens her banking app at home, on her own phone, shares her screen when he asks, adds the payee he reads out and starts a payment of ₹96,000.
An illustrative scenario, not a real customer’s case.
A caller posing as a police, customs or tax officer reaches Ananya on a video call. He says a crime is linked to her identity and orders her to stay on camera and speak to nobody.
Your checks saw
Nothing. The call happens outside the bank.
DeepID reads
No banking session yet. Her usual rhythm in the app is already on record.
He keeps up the pressure and tells her to move her savings to a safe account while the case is checked. After 41 minutes she opens her banking app with the call still running, and shares her screen when he asks.
Your checks saw
A normal login. Known device. Face matched.
DeepID reads
An active call and a shared screen running across the session.
He reads out the account details and she types them in a few characters at a time, pausing, cancelling and starting again as he continues.
Your checks saw
New payee added. Correct UPI PIN.
DeepID reads
Dictation pauses and repeated cancels, and a first-time payee whose account is 2 days old and linked to 14 others. The new payee starts on a cool-off of ₹10,000 for 12 hours.
Three minutes after adding the payee she starts the transfer. Without a hold, the money would move on through mule accounts within minutes.
Your checks saw
Authorised payment. Each check passed on its own.
DeepID reads
The call, the shared screen, the dictated typing and the mule-linked payee together: one hold, with those four reasons, until you have called her back.
Each of these passes because the customer is real. Read together across the journey, they stop agreeing, and that is what DeepID reads.
The payment comes from her own registered phone, at home, so the device check passes.
She opens the app herself, so her face or fingerprint matches as usual.
The code arrives on her own phone and she types it in, exactly as the control expects.
A threshold on value alone either lets this transfer through or holds thousands of genuine large payments.
A call that runs across the payee change and the payment, with a screen shared so the caller can watch. A customer following spoken instructions looks like this; a customer acting alone does not.
Typing a few characters at a time, cancelling and starting again, and an unusual route through the app to add a payee. Compared with Ananya’s own rhythm, this is a person being read to.
The payee was added 3 minutes ago, its account is 2 days old and it is linked to 14 others. Money arriving from many senders with no link to the account holder marks the “safe account” as the account the scam collects into.
Screen sharing or a remote-access app active on her phone during the payment. The fake officer asks for it so he can watch and direct each step.
The call, the dictated typing, the first large transfer and the payee’s links become one hold, and your FRM receives each reason as a code. Nothing reaches your team as a score alone.
Warn when a payee is added on a call, cool off the first large payment to a new payee, and hold when the call, the shared screen and the payee combine. The call back on her registered number is your team’s, with the reasons in front of them.
A known payee, no active call and typing that matches the customer. The payment goes, and the reasons are logged.
A first-time payee added during a call, with nothing else unusual. She sees a warning written for this scam and confirms before she continues.
A first large payment to a payee added minutes ago. ₹10,000 can go now and the rest after 12 hours, and she can cancel at any point.
The call, the shared screen and the dictated typing run across a ₹96,000 payment to a mule-linked payee. The payment waits until your team has called her back on her registered number.
The payee is already receiving from other customers in the same pattern. The payment does not go, and the case reaches your fraud team with every reason attached.
“Payment paused. Your money hasn’t left your account. The police never ask you to move money to a safe account. If someone is on a call with you now, end it. 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. Payee and mule links can be measured on your own history first, in a free retrospective. The call, the screen and the typing only exist once the SDK runs, so they are proved in a shadow proof on live traffic. We publish no figures for these.
No single signal decides it. A call during a payment is common, so DeepID reads it with the shared screen, the dictation pauses, the first-time payee and the payee’s links. Each adds a reason, and the thresholds are set on your own traffic during the shadow proof.
Scammers do coach customers to tap through warnings and to rehearse answers for a call back. That is why the stronger signals move the decision to a cool-off or a hold, which cannot be tapped away while the caller is still on the line. Your call-back team then has the time to break the isolation.
Call activity is read on the phone that runs the banking app. If the call is on a second phone, the dictated typing, the long session, the new payee and its links still carry the decision. How much each signal contributes depends on your channels and your traffic.
In India, a bank’s response to the digital arrest advisories rests on the controls below: DoT’s Financial Fraud Risk Indicator marks numbers tied to fraud, and MuleHunter.AI is the mule-detection work the Finance Ministry has asked banks to adopt. In Singapore, the Protection from Scams Act 2025 lets the police restrict transfers from someone likely to be scammed. (PIB (DoT introduces the Financial Fraud Risk Indicator (FRI) to strengthen cyber-fraud prevention, opens in a new tab), May 2025; MHA Singapore (Restriction orders issued under the Protection from Scams Act 2025, opens in a new tab), 2026)
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.
A payee and mule graph across accounts and devices, with recipient risk scored before the payment is sent.
Decision logs with their reasons and the message shown to the customer, and versioned policies, as evidence of what the bank did.
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.