A customer relies on the local business correspondent to open an account or withdraw cash. The agent takes an extra fingerprint scan, says the first failed, and the second authorises a withdrawal she never sees. DeepID asks the customer to confirm a high-risk assisted action on her own bound phone, and reads the agent’s device like any other.
Step up
STEP_UP · assisted action · face check requestedA customer relies on the local business correspondent to open an account and withdraw cash. The agent asks for a fingerprint, says the scan failed and asks again. The extra scan authorises a withdrawal she never sees. Another agent opens an account in a customer’s name and keeps control of it. The loss surfaces weeks later, when the balance is checked.
An illustrative scenario, not a real customer’s case.
The customer places a finger on the reader or faces the camera for a routine service. The agent takes an extra capture, or says the scan failed and asks again.
Your checks saw
A registered agent device. A genuine customer biometric.
DeepID reads
An assisted action starting on the agent’s device, with the customer’s own bound phone known to the account.
The agent uses the capture to open an account in the customer’s name or to authorise activity on an existing one. She has left the counter, or does not know what was approved.
Your checks saw
Valid authentication. Account opened as normal.
DeepID reads
No confirmation from the customer’s own phone, and scripted input on the agent device.
The agent withdraws cash or moves the balance, often in a run across several customers. Some skim part of a genuine withdrawal instead.
Your checks saw
Authorised transactions inside the agent’s limits.
DeepID reads
A step-up to the customer: a face check on her own phone before a withdrawal above the threshold you set.
She finds the loss at the next balance check. By then the record shows a genuine biometric on a trusted device.
Your checks saw
A complaint arrives weeks later.
DeepID reads
Accounts opened on this device that later received from many unrelated senders, visible on the graph.
Each of these trusts the credential, not the person holding it. Read together across the journey, they stop agreeing, and that is what DeepID reads.
The device is registered and trusted, so every transaction from it starts with a clean record.
The fingerprint or face is genuine, and the check cannot show whether the customer was present for this transaction.
Each transaction sits inside the agent’s limits, so the pattern across many customers goes unseen.
Visits and complaint reviews look back over weeks, long after the cash has left.
Before a high-risk assisted action, the customer confirms it with a face check with liveness on her own bound phone, matched to the face from sign-up. An agent holding the reader cannot answer for her.
The account bound to the customer’s own device and SIM, so the confirmation has somewhere to go that the agent does not hold. A customer with no phone follows your own exception process.
The agent device’s fingerprint, and emulator, cloned-app and remote-access signs on it. A registered device that is cloned or driven from elsewhere stops looking trusted.
A run of transactions keyed with identical timing is input no queue of customers produces. Script detection reads it on the agent device as on any other.
Accounts opened on one agent device linked to what they did next. Accounts that later received from many unrelated senders point back to the device that opened them.
Step up a high-risk assisted action, such as an account opening or a large withdrawal, to a face check on the customer’s own bound phone, hold when the confirmation does not come, and block when the agent device is cloned or scripted. Suspending an agent, and what counts as high-risk, is your own policy, with the reasons in front of the channel manager.
A routine transaction on a registered device with no device or input signals. It completes with nothing added for the customer or the agent.
A high-risk assisted action. The customer confirms it with a face check on her own phone before it goes through.
The confirmation does not arrive, or the input on the agent device is scripted. The transaction waits, and your team confirms with the customer.
The agent device is cloned, or driven by a remote-access app. The transaction does not go, and the channel manager receives the reasons.
“Confirm it’s you. A cash withdrawal of ₹10,000 has been requested at an agent. Take a quick face check to approve it. If you didn’t ask for this, leave it and it will not go.”
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. Accounts opened per agent device and what they did next can be measured on your own history, in a free retrospective. The face check and the device signals are proved in a shadow proof on live transactions. We publish no figures for these.
It applies to the actions you mark as high-risk, so routine transactions run as before. You decide which actions and amounts trigger it, and the shadow proof shows how often it would have fired.
The confirmation needs the customer’s own bound phone. For customers without one, your own exception process applies, and DeepID still reads the agent device and the input on it.
DeepID does not suspend agents. It returns one decision per transaction with its reasons, and a cloned device or scripted input is a reason your channel manager can test before acting. Every decision is logged.
The controls below are the binding, authentication and risk measures on the rule map in India and the Philippines. Business-correspondent and cash-agent rules are not mapped yet.
SIM and device binding at onboarding and re-binding on change, with the number confirmed by the network and device integrity read every session.
One-tap login that tries the network check, the SIM check and Aadhaar consent before any one-time code, and face checks with injection defence where identity is in doubt.
Device, behaviour, scam and payee signals read at login, new payee and payment, returned as one decision with its reasons.
No further dated rule for this control is mapped yet in India or the Philippines.
DeepID supports compliance with these rules. It never claims to guarantee it.
Sign-up or login end to end, with the decision back in the app and as an event, so your engineers see the shape of it before anyone signs anything.