Which error code tells me that a face looks generated or swapped?

The code [face] is deepfake means that the face in the image shows signs of generation or substitution. Branch on the code, never on message text. See errors.

Does a failed check reject the user automatically?

The result is added to the session. Your rules decide what happens next, and a reviewer can make a manual decision in the dashboard.

Can reviewers see a recording of the liveness step?

Session video is an option of the liveness step. When it is switched on and stored, the session carries the recorded video for the reviewer.

Face-swap fraud at onboarding

The job

A selfie in an onboarding flow can show a real person, a face that a model generated, or a real person's face swapped onto another face. The flow has to meet all three. This page is about the flow: where each check sits, what each result tells your team, and which sessions a person should look at. The capability itself is described on the deepfake detection page, and the whole range of fraud classes on the fraud prevention page.

Why one check is not enough

The three faces fail in different places. A generated face has no person behind it, so the document it is presented with has to carry a portrait that matches it, and that is where the document checks and the face match apply. A swapped face belongs to a live session, so it has to survive the movement the user is asked to make. A real face held in front of the camera as a photo or on a screen meets the liveness challenge. Putting the checks in one session means an attempt has to pass the whole chain, not one gate. For the wider picture of attacks, read the article on presentation attacks, deepfakes and injection attacks.

Where the checks sit

Step of the session	What runs	What the result tells you
Document	The document is read and checked for fraud with 20+ checks.	Whether the document is genuine and unaltered, and which portrait it carries.
Selfie	The selfie is compared with the document portrait, and the deepfake check runs on the image.	Whether the face matches the document, and whether it shows signs of generation or substitution.
Liveness	The user moves the face closer through two ovals. Deepfake and face-swap detection runs inside the selfie and liveness steps.	Whether a live person was in front of the camera.
Faces	The face matching of the session.	The step is always present and comes last, and the session does not pass without it.
Search, optional	Repeat-user search and your blocklists.	Whether the face belongs to an earlier verified user or to a listed person.

Each step has its own status in the results list, so your rules can weigh the layers separately. See the session object.

What goes to manual review

Decide in advance which results go to a person and which are refused or retried by rule. A reasonable split looks like this.

What your server reads	Where it goes
`suspicious`	A reviewer. The platform flagged the result.
`failed`, with `[face] is deepfake` in the errors	A reviewer, or a refusal by your policy. Do not offer unlimited retries on this code.
`failed`, with `[face] is not alive` or `[face] bad face matching`	A retry within the attempts the step allows, then a reviewer.
`success`, with the liveness step unverified	A reviewer for high-risk products. The `verified` field is false when the attempt passed without the verifying services.
A face found among earlier verified users or on a blocklist	A reviewer. A match is a signal, and your rules decide what it means.
`expired` or `exception`	A fresh session. These are processing outcomes.

Document-side codes, such as [fraud] image edited or [fraud] display or screen, are listed on the errors page. Treat a code that is not in the list as a failure with an unknown reason.

What the reviewer sees

In the dashboard the session card has a tab for each step: the document with its authenticity checks, the selfie, the faces match, the liveness result, and the full JSON of the session. Session video is a separate option of the liveness step, and the session object carries the recorded video when it was stored. The reviewer settles the case by changing the session status by hand after a confirmation, or you do the same from your tooling with the status change method. To keep a refused face from coming back, the reviewer can add it to the blacklist from the selfie tab, once the scenario has a faces black list selected. See KYC and AML in the dashboard.

Give the review queue to people with the right role. The permission to change a status by hand is separate from the permission to view images, so reviewers need both. See access rights.

Scenario setup

In the scenario editor add the document step, the selfie step with the deepfake check, and the liveness step, and switch on session video if your reviewers want a recording. Choose the faces black list and the repeat-user options if you use them. One more setting limits brute force: the number of critical errors before a session is blocked. It protects against brute-forcing forged images, and zero means no limit.

What your system receives

A session status and a list of results for each step, with symbolic error codes. A webhook announces completion. See session statuses and webhooks.

See the layers on sample data in the interactive tour, or talk to us about the attack patterns you face.