Skip to content
Try one-tap loginBook a demo

Coached payments: why the session is the whole attack

In a coached payment, the real customer sends the money, on their own phone, while someone instructs them. Each check the bank runs passes on its own. The attack shows where the session around the payment breaks.

5 min read7 sources

Request a retrospectiveDigital arrest
In this guide

A different kind of fraud

For years, fraud meant someone breaking into an account: stolen passwords, intercepted codes, a swapped SIM. Banks got better at stopping it. The fraud that grows now is the one the customer is talked into.

  • In the UK in 2025, losses to scams in which customers are tricked into paying rose 19% to £576.4 million, while unauthorised fraud fell 5%.1
  • In India, “digital arrest” scams, in which fake officials hold people on video calls, took ₹1,935 crore in 2024 across about 1.24 lakh reported incidents.2
  • Reported cyber-fraud losses in India rose from ₹7,465 crore in 2023 to ₹22,846 crore in 2024.3

These are authorised payments. The customer is real, the phone is theirs and each factor is correct. That is why they get past each check on its own.

How a coached payment unfolds

The example below is illustrative. Ananya Rao is the customer this site follows from sign-up to payment, here in the pattern of DeepID’s digital arrest use case. The details vary by scam, whether a fake police officer, a fake banker or a fake investment adviser, but the shape is the same.

  1. A call from someone posing as the police. Ananya Rao answers a call from an unknown number. The caller says a crime is linked to her identity, tells her to speak to nobody and to move her savings to a safe account while the case is checked.
  2. She signs in on her own phone. Still on the call, she opens her banking app on the phone and SIM bound to her account and signs in as usual. The caller asks her to share her screen so he can watch each step.
  3. She saves the payee he dictates. He reads out the account details and she types them a few characters at a time, pausing and starting again. The payee is linked to 14 other accounts.
  4. She sends ₹96,000 to a so-called safe account. Three minutes after saving the payee, 41 minutes into the call, she confirms ₹96,000 with her own UPI PIN. Without a read of the session, the money moves on through mule accounts before she understands what has happened.

Why each check passes on its own

Each control does exactly what it was built to do, and each can be beaten alone.

  • Device recognition. The payment comes from the customer’s own registered phone, at home.
  • Biometric login. The real customer opens the app, so the face or fingerprint matches.
  • One-time passwords. The code arrives on the customer’s own phone, and the customer enters it.
  • Amount rules. A threshold on value either lets the transfer through or blocks thousands of genuine large payments.

Stronger authentication alone does not change this: in a coached payment the real customer signs. Singapore’s central bank has said how hard the problem is. Telling deceived, self-authorised transfers apart from legitimate ones “is not an easy task even for sophisticated fraud detection systems”.4

The attack shows in the session

A coached payment needs four things, and each leaves a trace in the session around the payment.

The call

The scammer has to keep the customer on the line while the money moves. An active call that runs across the whole payment journey is one of the clearest signals there is. Platforms have noticed too: Android now warns when a banking app is opened during screen sharing with an unknown caller.5

The shared screen

Scammers ask the customer to share the screen so they can watch and direct each step. In June 2025, Singapore Police warned about impersonation scams that use WhatsApp’s screen-sharing function, citing at least 46 cases and losses of at least S$3 million.6

The dictation

A customer typing account details a few characters at a time, pausing, cancelling and starting again, is behaving like someone being read to. Behaviour alone can be imitated: Android banking malware now inserts random pauses of 300 to 3,000 milliseconds between keystrokes to pass as human.7 Read with the call, the shared screen and the device, it is much harder to fake.

The payee

The money has to land somewhere. A first-time payee linked to mule accounts, or one receiving from many unrelated senders, is a signal that no rule on the sending side can see on its own.

One decision, not four alerts

Each signal alone raises false alarms. Customers take calls while they bank, and some people type slowly. Read together in the same session, an active call, a shared screen, dictated typing and a mule-linked payee are a different matter. In Ananya’s session, a 41-minute call with an unknown number, a shared screen and a payee linked to 14 accounts add up to a hold before the payment is sent.

So the answer is one decision with its reasons, graduated to the risk: warn, cool off, or hold and call back. The customer is told in words written for them. For the digital arrest pattern, the message reads:

“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 bank’s FRM receives the same decision as an event, with reason codes such as an active call throughout the payment journey and a first-time payee linked to a known mule cluster. The FRM keeps its rules, queues and cases. The guide to scam interventions sets out all six actions and the words for each.

What to measure

No vendor figure tells you how this works on your book. Measure it on your own history first, then on live traffic without acting on it:

  • Coerced payments held that you later confirm as fraud
  • Value of held payments you later confirm as fraud
  • Genuine payments held, against the tolerance you set before the pilot
  • Time from hold to the call back
  • Held payments the customer cancels after the warning

Where DeepID fits

DeepID checks every login, new payee and payment against what was bound before it, and reads the session around it: scam signals such as the call and the shared screen, behaviour, device integrity and the payee graph. It returns one decision, with its reasons, to the app and to the FRM before the payment is created. It sits beside the FRM and never replaces it.

A free retrospective shows the payee and mule links in your own closed cases. The call, the screen and the typing only exist once the SDK runs, so they are proved in a shadow pilot on live traffic.

Sources

Secondary sources are news or trade reporting of a rule or figure. Check the regulator’s own text before relying on them. Nothing in this guide is legal advice.

  1. UK Finance (opens in a new tab), Jun 2026Annual Fraud Report 2026
  2. IndiaSpend (opens in a new tab), 2024 data, press reportHow India’s cyber crime incidence is rising, citing official data
  3. MHA (opens in a new tab), Dec 2025Ministry of Home Affairs, Lok Sabha reply on cyber-fraud losses reported to I4C
  4. MAS (opens in a new tab), Feb 2026Written reply to parliamentary questions on the SRF and fraud surveillance
  5. Google (opens in a new tab), May 2025What’s new in Android security and privacy in 2025
  6. Singapore Police Force (opens in a new tab), Jun 2025Police advisory on impersonation scams involving the WhatsApp screen-sharing function
  7. ThreatFabric (opens in a new tab), Oct 2025New Android malware Herodotus mimics human behaviour to evade detection

More guides.

Each one dated, with every rule and figure cited to its source.

Start with what your history can show.

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.

Request a retrospectiveBook a demo