One SDK for Android, iOS and web
Scam signals Read the pressure a customer is under.
A real customer, on their own phone, being talked into sending money. The call, the screen and the payee, read before the money leaves.
Why it matters.
In a scam, every credential is right. What gives it away is what is happening around the payment.
The call, across the journey
Whether a call has been running while the payee is added and the payment made, and for how long.
The screen, shared
A screen being shared or a remote-control app running while money moves.
How the payee arrived
Details pasted from the clipboard or typed in pauses as someone dictates them.
A graduated answer
Warn, cool off, hold and call back, or block. A call alone does nothing.
Four layers of scam signals, one SDK.
Read in the minutes before the payment exists, and weighed together.
A call running while a payee is added or a payment made, and how long it has run across the journey.
A screen being shared or a remote-control app running, read with the device check, while money moves.
Device intelligenceHow the payee details arrived: pasted from the clipboard, or typed a few characters at a time as someone reads them out.
Behavioural biometricsThe amount compared with what the customer usually sends: ₹96,000 is 14 times her usual, which is under ₹7,000.
Scam signals adapt to every scam, wherever your customers are.
Impersonation scams
A caller posing as the bank, the police or a court.
payment.initiateYour console
- Signal
- Call active, payee new
- Decision
- Hold
- Reasons
ACTIVE_CALL FIRST_TIME_PAYEE
A long call, a new payee: the customer sees “Payment paused. Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.” Your console records Hold, for Call active, payee new, with ACTIVE_CALL and FIRST_TIME_PAYEE.
payee.addYour console
- Signal
- Urgency signs
- Decision
- Warn
- Reasons
URGENCY_SIGNS ACTIVE_CALL
Urgency, read early: the customer sees “Check before you send. If someone on a call asked you to make this payment, stop. Banks, police and courts never ask you to move money to keep it safe.” Your console records Warn, for Urgency signs, with URGENCY_SIGNS and ACTIVE_CALL.
payment.initiateYour console
- Signal
- Call, new payee, unusual amount
- Decision
- Hold
- Reasons
ACTIVE_CALL AMOUNT_UNUSUAL
Digital arrest: the customer sees “Payment paused. Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.” Your console records Hold, for Call, new payee, unusual amount, with ACTIVE_CALL and AMOUNT_UNUSUAL.
Remote-control scams
Someone else on the customer’s screen while money moves.
payment.initiateYour console
- Signal
- Screen shared, call active
- Decision
- Hold
- Reasons
SCREEN_SHARED ACTIVE_CALL
A screen shared on a call: the customer sees “Payment paused. Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.” Your console records Hold, for Screen shared, call active, with SCREEN_SHARED and ACTIVE_CALL.
login.attemptYour console
- Signal
- Remote access
- Decision
- Step up
- Reasons
REMOTE_ACCESS
A remote-access app at sign-in: the customer sees “Confirm it’s you. Someone may be able to see your screen. Stop sharing it, then confirm it’s you.” Your console records Step up, for Remote access, with REMOTE_ACCESS.
payee.addYour console
- Signal
- Details pasted, screen shared
- Decision
- Hold
- Reasons
DETAILS_PASTED SCREEN_SHARED
Details pasted in: the customer sees “Payment paused. Payee not added yet. We’ll call you on +91 •••• 3210 before anything changes.” Your console records Hold, for Details pasted, screen shared, with DETAILS_PASTED and SCREEN_SHARED.
Investment and job scams
Payments the customer chooses to make, to the wrong people.
payment.initiateYour console
- Signal
- Amount unusual, payee new
- Decision
- Cool off
- Reasons
AMOUNT_UNUSUAL FIRST_TIME_PAYEE
Growing amounts to a new payee: the customer sees “Limit for now. You can send up to ₹10,000 to this payee now. You get the full limit in 12 hours.” Your console records Cool off, for Amount unusual, payee new, with AMOUNT_UNUSUAL and FIRST_TIME_PAYEE.
payee.addYour console
- Signal
- Payee reported
- Decision
- Hold
- Reasons
PAYEE_SCAM_REPORTED
A payee others reported: the customer sees “Payment paused. Payee not added yet. We’ll call you on +91 •••• 3210 before anything changes.” Your console records Hold, for Payee reported, with PAYEE_SCAM_REPORTED.
payment.initiateYour console
- Signal
- Many unrelated senders
- Decision
- Hold
- Reasons
FAN_IN_UNRELATED PAYEE_MULE_LINKED
A payee many are paying: the customer sees “Payment paused. Payment paused. Your money hasn’t left your account. We’ll call you on +91 •••• 3210.” Your console records Hold, for Many unrelated senders, with FAN_IN_UNRELATED and PAYEE_MULE_LINKED.
One SDK, every module.
Scam signals are weighed with everything else DeepID reads.
Behavioural biometrics
How the owner types, taps and swipes, against this session.
Device intelligence
A fingerprint that survives resets, and tampering read every session.
Payee and mule graph
Where the money is going, before it goes.
SIM and device binding
The account bound to the customer’s own phone and SIM.
Silent network verification
One-tap login: the mobile network confirms the number silently, then the SIM, Aadhaar or a code.
One decision, with reasons
Allow to block, sent to the app and the FRM.
Read next.
Scam interventions
What to do when the customer is the one being played.
SIM and device binding
What each one ties down, and why banks use both.
Injection attacks
How a fake camera feed reaches a selfie check, and how the device gives it away.
Questions banks ask.
How do you tell a coached customer from a busy one?
Not from one signal. A call during a payment is common. A 41-minute call with an unknown number, a shared screen, a payee saved minutes ago and typing in long pauses, all together, is not. Your fraud team sets which combinations warn, cool off or hold, on your own traffic, in the shadow proof.
Will it hold genuine payments?
Some, if the policy is strict, which is why the shadow proof comes first: you see how many genuine payments each policy would have held before any customer is affected.
Who calls the customer?
You do. DeepID returns the action and the words your app shows, and your call-back team sees what was read before it phones. The scripts and channels stay yours.
What does the SDK read about a call?
That a call is active and how long it has run across the payment journey, together with whether the screen is being shared or a remote-control app is running.
Try one-tap login on your own number.
See the network confirm your number with nothing to type, and the next check take over when it can’t. Then plan a shadow proof on one journey, measured on your own traffic.