Face Matching and Biometric Data

Every verification with a face step runs more than one biometric analysis, and they are easy to confuse. Face matching compares faces. Liveness detection does not compare anything — it decides whether the captured subject is a genuine, physically present human. This page explains each check, which result field reports it, and what biometric data iDenfy stores as a consequence.

---

​

The Three Checks at a Glance

---

​

1:1 Face Matching

The face is extracted from the portrait on the submitted identity document and compared against the face captured during the verification session. Only these two images are involved, and both come from the same session — hence one-to-one. The outcome is reported on autoFace (and on manualFace if the verification goes to human review):

• FACE_MATCH — the person and the document owner are the same.
• FACE_MISMATCH — the faces could not be matched.
• Quality codes such as NO_FACE_FOUND, TOO_MANY_FACES, or FACE_TOO_BLURRY mean the comparison could not be completed reliably.

​

Second-Opinion Check on a Mismatch

Two matching algorithms are available, and one of them runs first. When it returns FACE_MISMATCH or NO_FACE_FOUND, the other one runs automatically and the better of the two verdicts is the one reported. This means a selfie and a document photo of the same person are far less likely to be reported as a mismatch just because one algorithm struggled with that particular pair. The fallback runs in whichever direction is needed, depending on which algorithm went first, and it is active for all accounts — there is nothing to enable. Match thresholds can also be tuned for specific countries and document types where the general threshold produces too many false mismatches. Contact iDenfy if mismatches on a particular country or document type are sending more verifications to review than you would expect. Thresholds used for duplicate face detection are separate and unaffected.

---

​

1:N Face Matching

The session’s face data — the selfie, the face on the document, or both — is compared against biometric templates already stored for your account. This is one-to-many: one new face against many stored records. Its purpose is to recognize a returning person, not to validate the current document. Two features rely on it: A hit does not deny the verification — the submitted data is still valid, so the result becomes Approved (Suspected) with the tag attached, and you decide whether to onboard the user. See Suspected Status.

---

​

Liveness Detection Is Not Face Matching

Because the two checks answer unrelated questions, they can disagree — and each can fail while the other passes: A perfect face match therefore proves nothing about presence, which is why liveness is configured and evaluated separately. For the detection methods, spoofing categories, and configuration options, see Liveness Checks.

---

​

What Biometric Data Is Stored

The only biometric artifact iDenfy can retain is a facemap — a mathematical template derived from a face image, not the image itself. A facemap is stored only when your account uses a feature that needs a reference set to match against:

• Duplicate Check — selfie, document face, or both
• Face Blocklist — selfie, document face, or both
• Face Authentication — re-authenticates a returning user against the template from their original verification

Biometric template retention is a separate question from document and image retention. Captured images and extracted data follow the data retention period configured for your account, regardless of whether any facemap is stored. For legal bases, special-category obligations, and retention configuration, see GDPR Compliance.

---

​

Next Steps