An attacker joins a video KYC call behind a face swap built from a stolen ID photo, fed in through a virtual camera. The officer sees a calm face that matches the document. DeepID reads the stream and the device below it, and gives your officer one decision with its reasons while the call is still running.
The same face, under four names, at a lender: Loan stacking
The decisionS-2147
Block
BLOCK · virtual camera · emulator · face reused · details pasted
Your customer sees
We couldn’t verify this session. This camera isn’t a real one. Try again on your own phone, with its own camera.
Your FRM receives
VIRTUAL_CAMERAEMULATORFACE_REUSEDDETAILS_PASTED
Stopped or heldIllustrative
The decision at the last step, as your console shows it. Real codes and their names are agreed in the sandbox.
On this page
A live person, in front of a real camera, on every video KYC call.
An applicant joins a video KYC call. The officer sees a calm face that matches the photo on the identity document. The applicant blinks, turns his head, reads out a code and answers each question. The person on screen never existed in that form: the attacker sat behind a face swap built from a stolen identity photo, and a virtual camera fed that video into the call in place of the real one.
An illustrative scenario, not a real customer’s case.
Step by step.
1
A stolen or synthetic identity is prepared
The attacker buys a leaked identity record with its document image, or builds an identity from real and invented details, and prepares a face swap from the document photo.
Your checks saw
A valid document. Details match the record.
DeepID reads
Details pasted into the form on a device that has started other applications.
2
A virtual camera injects the face swap
The attacker joins from an emulator, a rooted phone or a desktop where a virtual camera driver replaces the real camera. The video platform receives the face swap as an ordinary camera feed.
Your checks saw
Camera on. Stream connected.
DeepID reads
A virtual camera driver, hooks and emulator signs below the app.
3
The officer sees a real-looking face
The face blinks, turns and answers questions in time with the attacker. It matches the document photo because it was built from that photo.
Your checks saw
Face matches the document. Questions answered.
DeepID reads
An injected stream, caught by liveness, and a face already seen on an earlier application.
4
The account opens for fraud
With a completed video verification on file, the account is used to receive mule money, take credit or be sold on.
Your checks saw
KYC complete. Account active.
DeepID reads
One block, with the stream, device and face reasons, and a signed record of the session for audit.
Each check, on its own.
Each of these trusts the picture it is given. Read together across the journey, they stop agreeing, and that is what DeepID reads.
Officer visual check
A trained officer watching a compressed video stream sees a convincing face that blinks, turns and answers on cue.
Selfie liveness check
Liveness built for a single selfie looks for a photo, a screen or a mask in front of the lens, not for a stream fed in behind it.
Video call platform
Virtual camera drivers and injection tools sit below the app, so the platform receives the fake feed as a normal camera.
Document and database checks
A stolen identity is genuine, so the document, the ID number and the record all verify.
Liveness catches photos, videos, masks, deepfakes and injected camera streams, with an instant answer on the phone and a final verdict from the server before you act. When in doubt it fails closed: deny or send for review, never pass.
Virtual camera drivers, emulators, rooted systems and hooking read in the device, not the picture. Injection bypasses the lens, so the strongest evidence often sits here and never appears in the stream.
Name, date of birth and address pasted rather than typed, with the same uniform speed across applications from one device. An attacker working through a list fills forms like this.
Face search across your customers finds the same face on an earlier application under another name. An attacker refused once often returns with the same kit.
The video KYC module runs the call, with the live face and document captured during it and a signed, replayable record kept for audit. DeepID’s decision reaches the officer during the call, not after it.
The decision.
Step up on one weak signal, hold for a second officer when face-swap signs or pasted details appear, and block when the virtual camera or the injected stream is caught. The officer still completes the call; the KYC decision is yours, with the evidence kept.
Allow
A live face, a real camera, a clean device and a form filled by hand. The officer sees the reasons and completes the call as normal.
Step up
One weak signal, such as a screen-recording tool running. The applicant completes an active liveness challenge during the call before the officer continues.
Hold
Possible face-swap signs, or pasted details on a device with other applications. The account does not open until a second officer has read the evidence.
Block
A virtual camera, an injected stream or an emulator, caught with confidence. The officer sees the decision and its reasons, the application closes and the signed record is kept for audit.
“We couldn’t verify this session. This camera isn’t a real one. Try again on your own phone, with its own camera.”
Shown on the applicant’s screen when the session is blocked. 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.
VIRTUAL_CAMERAVirtual camera driver active during the video call
EMULATOREmulator signs below the app
FACE_REUSEDSame face seen on an earlier application under another name
DETAILS_PASTEDPersonal details pasted into the form before the call
What to measure in a pilot.
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 camera or a device. Faces reused across past applications can be found in a retrospective. We publish no figures for these.
Sessions blocked that your KYC team confirms were injected or deepfaked
Officer time per call, against today
Accounts later confirmed as fraud per 10,000 opened, against today
Genuine applicants held or blocked, against the tolerance you set
Faces found on more than one application
Questions fraud teams ask.
Does DeepID replace our video KYC platform or our officers?
No. DeepID can run the call, or run beside the platform you already use, and the officer still makes the decision. It adds one decision with its reasons during the call and keeps a signed record of the session.
How does DeepID keep pace with new deepfake tools?
By reading the stream, the device and the session together. A clean-looking face swap can still be exposed by the virtual camera that delivered it. Performance is measured on your own traffic in the shadow proof, against criteria agreed before it starts.
Will genuine applicants on poor connections be rejected?
Low video quality alone leads to a step-up or a hold, never a block. A block needs the virtual camera, the injected stream or the emulator. The share of genuine applicants sent to a second officer depends on your traffic and thresholds, and the shadow proof measures it before go-live.