A finance manager joins a video call with the chief executive and the finance director, who ask for an urgent, confidential transfer. Every other face on that call was generated. DeepID cannot see the call, and does not try to. It reads the approver’s session in your portal and asks for a face check on the approver’s own bound phone before an out-of-pattern payment goes.
Step up
STEP_UP · first-time payee · amount unusual · behaviour drift · face check requestedA finance manager joins a video call. The chief executive and the finance director are both on screen, and both sound as they always do. They describe a confidential deal, ask for an urgent transfer and insist that nobody else is told. The manager creates the payment and an approver releases it with a valid token. Every other face on that call was generated.
An illustrative scenario, not a real customer’s case.
Recordings from interviews, results calls and conference videos become a voice and face clone. The attackers also learn who in treasury can create and approve payments.
Your checks saw
Nothing. Preparation is outside every channel.
DeepID reads
Nothing yet. DeepID does not watch your client’s meetings.
A staff member receives a call or video meeting from the cloned executive about a confidential and urgent payment, with a deadline and an order to tell nobody.
Your checks saw
Nothing. The call is outside the bank.
DeepID reads
A portal session from the approver’s usual device, with no screen shared and no remote session.
Treasury adds a new payee and creates the payment; the approver authorises it with a valid login and token. A second approver may be drawn into the same call and sign within minutes.
Your checks saw
Valid login. Valid token. Within mandate.
DeepID reads
Hesitant, unfamiliar behaviour from this approver, a first-time payee abroad and an amount far from the client’s pattern.
The payment leaves for a recently opened account abroad with no history with the client, and is split and moved on before the real executive hears of it.
Your checks saw
Authorised payment. Screening clear.
DeepID reads
One step-up: a face check with liveness on the approver’s own bound phone, before the payment goes.
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.
They confirm that the right credential was used and say nothing about whether the voice behind the instruction is real.
Both approvers can be deceived by the same cloned voice on the same call, so two valid approvals arrive together.
The call back fails when the attacker controls the channel, by supplying the number, diverting the line or answering with the cloned voice.
Large urgent payments to new suppliers are normal in corporate banking, so limits are set wide enough to let this one through.
The approver confirms an out-of-pattern payment with a face check with liveness in the banking app on their bound phone, matched to the face enrolled. A cloned executive can answer a call back, but cannot pass as the approver in the approver’s own app.
Typing, navigation and hesitation in the portal compared with this approver’s usual sessions. An approver being talked through an unfamiliar payment pauses, corrects and pastes details in ways their usual sessions do not show.
Whether the approval comes from the approver’s usual device, and whether a screen-sharing or remote-access tool is active. A remote session during a large approval suggests someone else is watching or steering.
The payee set against the client’s past payments and known recipients. A recently opened account abroad with no trade history carries recipient risk when it receives a large, urgent payment.
Each approver bound to their own device and SIM once, so the step-up has somewhere to go that the attacker does not control.
Step up every out-of-pattern corporate payment to a face check on the approver’s own bound phone, hold when a remote session runs across the approval, and block when the payee is already linked to fraud. Confirming the instruction with the client on an established number stays your relationship team’s process.
The payment fits the client’s pattern, with a known payee, the usual device and the usual approver. It goes with nothing added.
An out-of-pattern payment to a new payee, with other signals clear. The approver completes a face check with liveness on their bound phone before release.
A first payment to a new payee abroad, outside the client’s usual amounts. Part can go now and the rest after a set time, which gives the real executive time to hear of it.
A screen is shared or a remote session runs on the approver’s device during the approval. The payment waits, and the case goes to your fraud team before any funds leave.
The payee is already linked to confirmed fraud. The payment does not go, the client is told through a contact you already hold, and the reasons are logged.
“Confirm it’s you. This payment is outside your company’s usual pattern. Nothing has been sent. Take a quick face check on this phone to release it. If someone asked you to approve it on a call, check with them on a number you already hold.”
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. These are proved in a shadow proof on live sessions; history cannot show a device or a session. Payees outside each client’s pattern can be found in a retrospective. We publish no figures for these.
No. That call takes place outside your channels, and DeepID does not monitor a client’s meetings or check voices. It reads what the bank can see: the approver’s session, the device, the payee and the pattern, and it asks the approver for a face check on their own phone.
Payments that fit the client’s pattern pass with nothing added. The step-up applies to out-of-pattern payments, and the thresholds are set with you for each client segment. How often genuine payments meet one depends on your clients and is measured in the shadow proof.
The step-up needs each approver to enrol a face and bind a phone once. Device, behaviour and payee signals work without enrolment once the portal carries the SDK. The rollout order depends on your client agreements.
No market on the rule map has a rule written for deepfake approvals yet. The controls this use case calls on, a face check with liveness and a bound device, are the ones the dated rules below already ask for.
Device, behaviour, scam and payee signals read at login, new payee and payment, returned as one decision with its reasons.
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.
SIM and device binding at onboarding and re-binding on change, with the number confirmed by the network and device integrity read every session.
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.