Biometrics & Liveness

Whether a live human being is present at the moment of capture. Not whether it is the right human; that is a separate check.

It analyses the video stream for signals that a printed photograph, a screen held up to the camera, or a replayed or synthetic video cannot reproduce. Presentation attacks of that kind are the usual way a stolen document gets past a remote check, because the attacker has the document image but not the person it belongs to.

When the signal is ambiguous the capture fails, not the person: the customer is asked to try again, instead of being recorded as a failed verification.

They are sequential checks answering different questions, and neither substitutes for the other.

Liveness detection asks: is there a real, live person in front of this camera right now?

Face matching asks: is that person the one pictured on the document?

Run alone, each leaves an obvious hole. Face matching without liveness can be satisfied by holding up a photograph of the document holder. Liveness without face matching confirms somebody real is present, but not that they are the person being verified.

Together with a DVS document check, the three answer the full remote verification question: the document is genuine, the face matches it, and the person is live.

Liveness detection covers deepfake playback, meaning a synthetic video presented to the camera in place of a live face. That is the form the attack takes in a remote verification flow. The check looks for the capture-time signals that a rendered or replayed stream does not reproduce.

It is worth being precise about the claim. This is a presentation-attack defence, and it is one layer of several.

The reason it is paired with a DVS document check and per-field data verification is that an attacker who defeats one layer still has to produce a genuine document and a set of personal details that resolve to a real, living person. Defeating all three is a materially harder problem than defeating any one.

Face matching returns a similarity score, not a bare yes or no, and you set the score that counts as a pass.

The trade-off is direct. A higher threshold means fewer false accepts and more captures routed to manual review; a lower one clears more customers automatically and lets more marginal matches through. Because that is a risk appetite decision, it is yours to set.

Most clients start at our recommended default and adjust after a few weeks of live traffic, once they can see the actual distribution of scores across their own customer base. The score is recorded alongside the result, so any decision can be reviewed later against the threshold that applied at the time.

A remote ID Pass check accepts five document types, four of which are read by OCR:

• Australian driver's licence — verified against NEVDIS
• Australian passport — verified against DFAT
• Medicare card — verified against Services Australia
• Foreign passport, for Australian visa holders — matched to the passport linked to their visa at DFAT
• Centrelink concession card — manual entry only, no OCR

You can require up to three documents, and the usual configuration is two with at least one photo ID. A document already used in a verification cannot be presented again for a later step in the same check.

This is a deliberately narrower set than the full DVS range. Where a customer holds a document outside this list (a birth or citizenship certificate, an ImmiCard), the check is run by your team through the portal or the API instead, which covers all 14 DVS document types.

Retention is configurable and defaults to zero days: captured images are deleted as soon as the verification completes.

Where you do choose to retain them, they are encrypted at rest under a key unique to that single verification, and processed in Australia under ISO 27001 controls.

Similarity scores and capture frames are retained to whatever setting you choose, and that is the material you would need for a dispute or an audit. The evidence record of the check itself (what ran, when, against what, with what result) is kept regardless of the image retention setting.

They are not locked out. The flow falls back to document and data verification, which establishes the same identity without a biometric step, and staff-assisted checks are available through IDFEX ID Check where someone needs help completing it.

This matters for accessibility as much as for edge cases. A customer may have no working camera, poor connectivity, or a disability that makes the capture difficult.

Designing the fallback in from the start is what stops a technical limitation from turning into a declined application, and from becoming a discrimination question later.

Yes. Four endpoint groups expose the capability at different levels:

• ID Pass — create, read and cancel a fully hosted verification flow
• Liveness Check — the hosted liveness flow on its own
• Likeness Check — a face similarity score between two images
• ID Document — OCR extraction and face image extraction from a document

Hosting the flow yourself gives you full control of the interface. Using ID Pass means capture, retries and browser compatibility are handled for you. Both run the same checks and produce the same evidence record.