Selfie and liveness checks: what is actually being compared

Scope

Liveness and face match only

Decisions made

Two, independently, from one capture

Face template

Sensitive information under the Privacy Act

Operators

Offshore - not AU licensed

Audience

18+ only

The two comparisons hiding inside one selfie request

The request reads as one task and resolves as two independent decisions. One is a biometric comparison: the live capture measured against a reference face already held. The other asks whether the subject was a living human or a photograph, a screen, a printed mask or synthesised video. Either fails on its own, and the refusal message never says which.

The reference face decides most outcomes and is rarely named in the request. At a first verification it is usually the portrait on the identity document already uploaded, so the quality of that earlier submission is part of this check rather than a closed matter. At a re-verification it can instead be a template enrolled from your first successful capture.

The two references fail in opposite directions. A document portrait can be years old, laser-engraved into polycarbonate and shot through a holographic overlay, so the reference is degraded before the comparison begins. An enrolled template is recent and clean, and its existence means a biometric record of you is stored rather than discarded.

So the first question for the account's own message thread is which reference the comparison used. If it is a poor document image, a better selfie will not rescue it and a re-photographed document might. No operator's threshold, retry allowance or review time appears on this page, because those are build-specific and get changed without announcement.

Active, passive and hybrid liveness: three different asks

Active liveness gives instructions and scores whether you followed them as a living face would: turn your head one way then the other, blink, smile, follow a moving dot, read digits aloud. The point is not the task but that a photograph cannot comply, and a pre-recorded video cannot comply with an instruction it was never given.

Passive liveness asks nothing and analyses the capture for signals separating a face from a picture of one: skin texture at close range, depth cues, the interference pattern a camera picks up from a screen, reflections behaving flat rather than curved, and involuntary micro-movement. From your side the check simply happened, which is why a passive failure feels arbitrary.

Some implementations light your face with changing colour from the device screen and measure how the reflection falls across it, which is a depth test run without asking you to move. If flashing or rapidly changing light is a health concern for you, that matters before the capture starts rather than during it.

Hybrid flows assess passively and escalate to an active challenge only when the passive result is weak, so an identical account can clear silently one month and be asked to turn its head the next. Active failures usually mean following the instruction fully at a moderate speed; passive failures are environmental. A third concern sits behind both: injection attacks that bypass the lens entirely, feeding synthetic video into the capture path through a virtual camera driver or an intercepted stream, which is why some engines check the device and channel as well as the face and will refuse on a rooted phone, an unsupported browser or camera-virtualising software. ISO/IEC 30107-3 sets out how this class of detection is tested, though where any vendor sits in published evaluations is not something an operator discloses.

The verification vendor behind the operator's camera window

The camera window sits inside the operator's site and the decision usually is not the operator's. Verification is contracted out: a third company builds the flow, runs the comparison, holds the images and returns a result. Front-line support frequently cannot see why the vendor refused a capture, only that it did.

That changes what to ask for. The useful request is not that a decision be overturned but that the refusal reason the vendor returned be read out, in the vendor's own words. Compliance teams can see those structured reasons even when support cannot, and asking for the reason text rather than a reconsideration is what moves a stalled retry loop.

It also changes the count of copies. Your face image can exist at the vendor, at the operator, and at a payment processor that imposed the check as a settlement condition — three holders, three retention policies, and a deletion request to one binds none of the others, as the documents guide notes about identity files.

Where this step turns up at Safe Casino or WinCrown, it is normally reached from the verification or documents area of the account rather than the lobby, and whatever each site states there on the day is the version that governs. Two questions are worth asking before the first capture: which company performs the check, and in which country it processes the image.

Match scores, thresholds and the borderline face

A face comparison does not return yes or no. It returns a similarity score, and a configured threshold turns that score into a decision. Everything uncomfortable about these checks follows from that: the same two faces can clear the step under one configuration and fail it under another, and neither result is an error in the system's own terms.

The threshold trades two errors and cannot reduce both. A false match accepts someone who is not you; a false non-match refuses you. Lowering it to stop refusing legitimate players necessarily accepts more impostors, and raising it does the reverse. An operator pressed by a licensor or a processor moves it toward refusing people, because that error's cost lands on the player.

The arithmetic, with illustrative figures chosen only to show the shape and matching no operator's configuration: suppose a threshold set so false matches occur about once in ten thousand comparisons, and suppose a hundred thousand comparisons run, so roughly ten impostors clear. Tighten it tenfold and that becomes about one, while refusals of genuine faces rise by some larger multiple depending on the engine. The figure actually in force is a build setting rather than a published specification, so the only places it can be read are the verification vendor's own documentation and whatever the operator's compliance team is willing to put in writing.

Accuracy is also not uniform across people. Public evaluations of face recognition have reported error rates differing across demographic groups, with the size of the difference varying substantially between engines. No percentages appear here, because any such figure belongs to one algorithm version measured against one test dataset rather than to face recognition in general; the authoritative numbers are published per algorithm in NIST's Face Recognition Technology Evaluation reports, including its reporting on demographic effects, and that is where a figure for a named engine should be read rather than taken from a page like this one. If good conditions and a clear document still refuse you, ask in writing for a manual human review.

Why a retry happens: the causes behind one generic message

Refusal causes fall into recognisable families and nearly all are mechanical. No face detected, which usually means distance, framing or darkness rather than anything about your face. More than one face in frame, which catches anyone verifying in a shared room, in front of a television or beside a poster. Face too close, cutting the chin, or too far to resolve.

The obstruction family is next: eyes closed mid-blink, sunglasses, glare across spectacle lenses, a mask, a scarf over the chin, a cap brim shadowing the eyes, hair covering one side. Document photo standards generally require features visible from chin to crown, and head coverings worn for religious reasons are normally accommodated provided that stays true.

The capture-quality family produces the vaguest messages: motion blur from moving during the shot, backlighting that silhouettes the face against a window, one hard side light that blows out a cheek and loses the other, and a lens smeared enough to soften skin texture below what a passive check needs. A refusal mentioning only quality is nearly always one of these.

Then the procedural family: a challenge timed out, a session expired while a camera permission dialog was answered, an unsupported browser or device, or a retry limit reached, which locks the step rather than refusing a capture. Separately, the chain of names still applies — profile, document, payment method — so a clean face match can sit beside an unverified badge.

The document half: a portrait you cannot retake

Half the comparison is fixed. Identity documents run for years, so the reference face can predate the live one by most of a decade, and every ordinary change in between reduces the similarity score: ageing, weight change, a beard grown or removed, a changed hairline, surgery, illness, or the difference between a studio portrait and a phone at arm's length.

The physical document fights the camera too. A modern driver licence is polycarbonate with the portrait laser-engraved rather than printed, overlaid with holographic features designed to resist copying. Those features scatter light, and a reflection across the portrait removes the exact region the comparison needs. Angle the document away from the light rather than moving the camera.

Some flows read the document electronically instead of photographing it. A chip-enabled passport holds a stored facial image readable over a phone's contactless interface, and a reference obtained that way is cleaner than any photograph of the page, because glare, tilt and resolution leave the equation. Whether a given vendor supports it is a question for the vendor.

If the document portrait is genuinely the weak half, there are two honest moves. Re-photograph the document under better conditions and ask for the reference to be rebuilt, which is often possible and almost never offered. Or ask for review by a person, stating that the portrait is old and describing what has changed. A reviewer resolves what a threshold cannot.

Camera, light and the room you are standing in

The controllable half of this check is physical, and five minutes of arrangement beats five attempts. Face a window during daylight so the light falls on you rather than behind you, or stand facing a lamp rather than with one over your shoulder. Backlighting is the commonest avoidable quality refusal: a dark shape with a bright outline and no detail inside it.

Use even frontal light rather than one hard source to the side, which blows out half the face and loses the other. Keep the background plain and still: a blank wall, not a doorway with movement behind it, a mirror, a television, or anything containing another face. Remove sunglasses, lift a cap brim clear of the eyes, and take spectacles off if they throw glare.

Hold the phone at eye level and roughly at arm's length, square to your face rather than angled up from your lap. Clean the lens, which on a front-facing camera is usually the dirtiest glass anyone owns. Stay still throughout, and perform any requested movement deliberately: a head turn completed in half a second is frequently too fast to produce usable frames.

Then the software side. Grant camera permission before starting, since the dialog can consume the session timeout. Use the browser the flow names, close other applications holding the camera, and remove virtual-camera or streaming software from the path. Do the whole step on the day you register, while no withdrawal is waiting on it.

When the check cannot work for you, and what to ask for

These flows assume a particular body using a particular device in a particular room. A tremor or limited head and neck movement makes a turn-your-head challenge hard to complete inside a timeout. Low vision makes a follow-the-dot instruction unworkable. Changing or flashing light used as a depth test is a health concern for some people.

Name the circumstance in the account's message thread before attempting the capture repeatedly, and ask what alternative route exists. Alternatives generally do, because the operator still has to verify you and a refused capture leaves that unmet: a different liveness mode, a supervised video call, a still-image review, or a different document route.

Keep the request narrow and in writing. State what the flow asks for, which part is not workable for you, and what you want offered instead. Ask for the answer in the thread rather than by phone, so there is a dated record. If a retry limit has already locked the step, say so in the same message, because unlocking it and arranging an alternative are separate actions.

Repeated refusals in good conditions with a clear document deserve the same treatment without any accessibility reason. After two or three honest attempts, further ones stop gathering evidence and start consuming a finite retry allowance. Switching from retrying to asking for a human review is the correct move, and the sooner it is made the fewer review cycles it costs.

Where the face template goes, who holds it, and under which law

A capture produces more than a picture. The engine derives a mathematical representation of the face, commonly called a template, and the comparison runs against that rather than pixels. A template is not reversible into a photograph in any ordinary sense, and it is not anonymous either: it is a durable identifier for your face. Deleting the image while keeping the template is a real distinction.

Count the holders before the capture rather than after: the vendor that ran the check, the operator if it stored the image or result, a payment processor where the check was a settlement condition, and possibly a sub-processor used for storage in a country neither party chose. Each is a separate holder with a separate policy.

Retention is likeliest to produce an unwelcome answer, and the unwelcome answer is often the lawful one. Anti-money-laundering regimes generally require identity verification records to be kept for a period after the relationship ends, which is why closing an account and deleting the record are different requests, the first usually grantable and the second usually not.

Four questions, asked once in the thread before you capture: who processes the image, in which country, how long the image and any derived template are retained, and what the privacy contact address is. Keep the written answer, as the delays guide recommends for every open request, and capture through the account you logged into rather than from an email link.

Australian law treats this category differently from an address proof. Biometric information, and biometric templates used for automated biometric verification or identification, are sensitive information under the Privacy Act 1988, and sensitive information generally cannot be collected without consent under Australian Privacy Principle 3. Everything then turns on whether the Act reaches the holder: it can extend to an overseas organisation with an Australian link, which turns broadly on carrying on business in Australia, and the separate requirement that the information be collected in Australia was removed by a 2022 amendment.

Where the Act does apply, the principles that matter are APP 11 on security, including reasonable steps to destroy or de-identify information no longer needed, APP 12 on access, APP 13 on correction, and APP 8 on steps before disclosing information across a border; complaints go to the OAIC. Whether a particular offshore operator or its vendor meets the Australian-link test is a legal question this page does not decide, and alongside it sit the licensing jurisdiction's own rules and a vendor contract you will not be shown.

Where the check sits inside a withdrawal, and when to escalate

The selfie step is rarely the whole blockage and often only the visible part. A withdrawal normally waits on a complete verification set rather than any single item, so a cleared face match can sit beside an outstanding address proof while the account still reads as unverified. Ask which items are cleared and which are outstanding, by name, before concluding the capture is what the payout waits on.

The retry loop is expensive because a refused capture restarts rather than resumes. Where a refusal routes the case to a manual queue, that queue runs on the compliance team's hours in their own timezone, and each fix re-enters it from the back with no credit for the wait served. Suppose the queue is reached once per business day and three successive refusals occur: three business days, from three refusals that took two minutes each to produce.

It worsens across a weekend. Suppose a Thursday capture is refused, the fix is submitted Friday, the review lands Monday, a second refusal follows, and the next fix is reviewed Tuesday: two refusals have cost five calendar days. Those figures are illustrative rather than any operator's timetable; the only stated processing times worth relying on are the ones a given operator publishes in its own withdrawal terms, read on the day. The conclusion matches the weekend processing page.

So front-load the effort. Arrange the light, background and device once, close every open request in one session, and after two or three honest failures stop capturing and ask for the vendor's refusal reason plus a manual review. If the payout is already requested and sitting still, the diagnosis of which stage holds it is on the failed withdrawal page.

Nothing here changes the legal position of the service. ACMA's position is that online casino services cannot lawfully be provided to people in Australia, so every operator referred to is offshore. Operator shortlists and current offers sit with pokiesledger.com (operator shortlists and bonus offers); how a game is built, its designed return and its volatility sit with pokiesalmanac.com (game mechanics, RTP, volatility). No genuine check asks for a banking password, a one-time code, a card security code or a fee to release a withdrawal. Gambling is for adults only, and free, confidential support is available on 1800 858 858.

Read next