Scammers pick the customers least confident with the app, win their trust over several calls and return once one has paid. DeepID reads the call, the remote-access app and the unfamiliar way through the screens, cools off the first large payment to a new payee and holds it when the call runs across the payment. Who counts as higher-risk, and how much extra time, is your policy.
Hold
HOLD · active call · remote access · dictation pauses · first-time payee · amount unusualA customer in her seventies takes a call from a man who says he works in her bank’s security team. He is patient and polite, and he calls again the next day. He asks her to install an app so he can help, then stays on the line while she opens her banking app and types what he reads out. She sends her savings to a payee she has never paid before.
An illustrative scenario, not a real customer’s case.
He poses as the bank, a public office or a service provider, and makes contact by phone or message. Nothing has touched the account yet.
Your checks saw
No account activity. Nothing to see.
DeepID reads
No session yet. Her usual pace through the app is on record, and so is how rarely she changes anything.
Over several calls he asks her to install a remote-access app so he can help. She begins to open the banking app while the call is still live.
Your checks saw
Routine logins from a known device.
DeepID reads
An active call during her sessions, and a remote-access app newly present on her phone.
Guided step by step, she adds a new payee and sends a large payment, after being told to ignore any warning. She pauses for long periods, moves through screens she rarely uses and corrects what she types.
Your checks saw
Customer authorised. Within the daily limit.
DeepID reads
Long pauses, an unfamiliar route through the app, the live call, a first-time payee and an amount far above her usual.
Once she has paid, he returns, or a new caller offers to recover the loss for a fee. Each request is another authorised payment from the same genuine customer.
Your checks saw
Another authorised payment. No link to the last.
DeepID reads
A second first-time payee linked to the first, and the same call pattern around it.
Each of these passes because the customer is real. Read together across the journey, they stop agreeing, and that is what DeepID reads.
Every customer sees the same message, and a customer being coached on a call is told to tap through it.
Support needs are noted in branch records, if at all, and digital payment decisions never read them.
She signs in on her own phone with her own PIN, so every authentication check passes.
Rules look at the amount and the payee history and cannot see the call, the remote-access app or the hesitation around the payment.
Long pauses, repeated corrections and screens she has rarely used, measured against her own pace. This is a person following instructions and unsure of each step.
A call, a shared screen or remote control while the payee is added and the payment is made. With the hesitation, the payee and the amount, it becomes one decision: a warning, a cool-off, or a hold and a call back.
Whether the payee is linked to mule accounts or to payees that other customers of yours paid in the same pattern, and whether this customer has been here before. A second attempt is recognised early.
A new device on the account, or a remote-access app on her phone. For a customer who rarely changes anything, either shortly before a large payment is a strong sign of outside control.
Which customers count as higher-risk, how much extra time a cool-off gives them and when a call back is made are your policy, tuned per journey and market. DeepID returns the decision and its reasons; your team makes the call.
Cool off the first large payment to a new payee, hold when a call or a shared screen runs across the payment, and call the customer back on her registered number. Who counts as higher-risk, and any extra time, is your policy.
A familiar payee, a usual amount and no call or remote access. The payment goes as normal.
A first-time payee with some hesitation and nothing else. She sees a plain message about common scams and confirms the payee.
A first large payment to a new payee by a customer your policy marks as higher-risk. Part can go now and the rest after the extra time you set, and she can cancel at any point.
A remote-access app or a shared screen is active while the payment is made. The payment waits, and your customer protection team calls her back on her registered number.
The payee is linked to mule accounts or to an earlier scam payment from this customer. The payment does not go, and your team reaches her through a channel you already hold.
“Payment paused. This payment is larger than usual and goes to someone you haven’t paid before. Your money is still in your account. 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 links and repeat patterns can start from your own history, in a free retrospective. The call, the remote-access app and the hesitation only exist once the SDK runs, so they are proved in a shadow proof on live traffic. We publish no figures for these.
That is your process. Some banks agree support needs with the customer, some use age and how the account is used, and some set one policy for everyone. DeepID applies the policy you set to the session; it holds no list of its own.
Not by DeepID. The decision and its reasons reach your app and your FRM; who your bank then contacts, and how, is your own process and consent model.
Some will find it slower, which is why the extra time applies to first large payments to new payees, and only for the customers your policy covers. Familiar payees and usual amounts go through as normal. The shadow proof shows how often the cool-off would have applied before anything changes.
In April 2026 RBI proposed transaction delays and protections for senior citizens in digital payments. The controls below are the anti-scam, cool-off and liability measures each market page dates and sources. (The Paypers (RBI proposes transaction delays and senior-citizen protections to combat digital payment fraud, opens in a new tab), Apr 2026, press report)
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, Malaysia or the UAE.
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.