Insider fraud and the reset that starts inside the bank
A ring pays an employee to change the mobile number on a handful of accounts on a quiet evening. Days later it resets the credentials, receives every one-time code and empties the accounts. DeepID reads the customer side: a changed number is a new-phone event, so nothing is bound again until the customer’s face from sign-up holds, and payments cool off. The link to the employee is yours to draw, from the reasons DeepID logs.
The decision at the last step, as your console shows it. Real codes and their names are agreed in the sandbox.
On this page
Hold the takeover that starts with a contact change made from the inside.
A ring finds an employee with access to customer records and offers money for a small favour. On a quiet evening shift the employee changes the mobile number and email on a handful of accounts. Each change is within the employee’s role and each is logged. Days later the ring resets the credentials on those accounts, receives every one-time code on its own SIM and moves the balances out.
An illustrative scenario, not a real customer’s case.
Step by step.
1
A ring pays an employee
A branch officer, contact-centre agent or field agent with access to customer records is offered money. The arrangement is made outside the bank, so no system records it.
Your checks saw
An authorised employee. Nothing unusual recorded.
DeepID reads
Nothing yet. Each account is bound to its customer’s own phone and SIM, and that binding does not change with a record.
2
The employee changes the contact details
The mobile number, email or address on the target accounts is changed, out of hours and in a batch, with no customer contact behind the request.
Your checks saw
An authorised action. Logged, and never read.
DeepID reads
A new number on the account, which DeepID treats as a new-phone event: the old binding stays until the customer proves it is them.
3
The ring takes over the account
With its own number on the account, the ring resets the credentials, enrols its own phone and receives every one-time code on its SIM.
Your checks saw
Correct one-time code. The registered number.
DeepID reads
A new device and SIM days after a contact change, and a face check against the face from sign-up that the ring cannot pass. Nothing is re-bound, and the account enters a cool-off.
4
The balances are moved out
New payees are added and the accounts are emptied into mule accounts, some of which the same insider helped to open. The losses surface as separate complaints.
Your checks saw
Separate fraud cases. No common link.
DeepID reads
New payees inside the cool-off, held, and the same payees across several of the changed accounts on the graph.
Each check, on its own.
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.
Role-based access
Access controls confirm that the employee is authorised for the action and do not ask whether it is part of a pattern.
Staff audit logs
Every staff action is logged, and the logs are read only after a loss has been reported.
Maker and checker approval
The checker sees one valid-looking request at a time and has no view across accounts.
Customer fraud monitoring
It scores the takeover and the payment as separate events and holds no record of which employee touched the account first.
Before a new phone or SIM is bound, the customer passes a face check with liveness matched to the face from sign-up. A changed record does not change the face, so the ring cannot re-bind the account to its own phone.
The account is bound to the customer’s own device and SIM, not to the number in the record. A new number or SIM is a re-binding event, and a cool-off set per market limits what can leave afterwards.
New payees added inside the cool-off on several accounts, and the same payees across them. The graph shows the accounts moving to the same places, which is the pattern a case tool can then trace back to one employee.
Each decision is logged with its reasons and the time, to your FRM and your case tool. The link between the staff action and the outcome is yours to draw there; DeepID reads sessions, not staff.
The decision.
Step up any re-binding after a contact change to a face check against the face from sign-up, cool off the account in the hours after, and hold a payment to a new payee inside the cool-off. Drawing the line from those holds back to one employee is your investigation team’s work, with the reasons in the case file.
Allow
A login from the bound phone after a contact change the customer made herself. It passes, and the reasons are logged.
Step up
A new phone or SIM after a contact change. The customer completes a face check with liveness before anything is bound again.
Cool off
The face check passes on a new phone. New payees and larger payments wait for the cool-off set for your market.
Hold
A payment to a new payee starts inside the cool-off, on a session unlike the owner’s. The payment waits, and your fraud team receives the reasons.
Block
The face does not match the one from sign-up. Nothing is re-bound, the existing binding stays, and a case opens with the time of the contact change beside it.
“Is this your new phone? Your number moved to a new phone, so payments from this account are paused until we check it’s you.”
Shown on the new phone at the first login, while payments are held. The genuine customer sees it too, on her own phone, if the number was changed without her. Illustrative.
Reasons sent to your FRM.
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.
SIM_MOVEDA different SIM from the bound one, days after a contact change
NEW_DEVICEA phone not bound to this customer, at the first login after the change
STEP_UP_NOT_COMPLETEDFace check requested and not completed on the new phone
FIRST_TIME_PAYEEFirst-time payee added inside the cool-off
What to measure in a pilot.
Agreed in writing before the pilot starts, and counted on your own traffic against what you see today. Contact changes followed by a new device and new payees can be measured on your own history first, in a free retrospective. The face check and the binding are proved in a shadow proof on live sessions. We publish no figures for these.
Takeovers that began with a contact change, against today
Re-bindings refused that your investigators later link to an insider
Payments held inside the cool-off that you later confirm as fraud
Genuine customers delayed after a contact change, against the tolerance you set
Time from the contact change to the first hold
Questions fraud teams ask.
Does DeepID monitor our staff?
No. It reads customer sessions, devices and payees, and logs each decision with its reasons. The link from a hold to the employee who changed the record is drawn in your own case tool, under your own people and legal processes.
What if the employee changes the number and the customer never notices?
The binding does not follow the record. The ring’s phone still has to pass a face check against the customer’s face from sign-up, and until it does the account stays bound to her phone. A retrospective on your own history shows how many past takeovers began with a contact change.
Will this slow customers who change their own number?
A customer who changes her number and then logs in on her own bound phone passes as normal. A new phone after the change meets a face check and a short cool-off, which is the same path as any new phone.
Rules it supports.
The controls below are the binding, cool-off and risk measures on the rule map, dated and sourced on each market page. Staff accountability under RBI’s fraud risk management directions is not mapped yet.
Bind the customer to the phone
SIM and device binding at onboarding and re-binding on change, with the number confirmed by the network and device integrity read every session.