Liveness detection for Australian AML checks
Home / Insights / Seven Year Audit Trail: Liveness Detection…

Liveness detection for Australian AML checks

What liveness detection actually catches, how active and passive compare, and the ISO 30107-3 test evidence to demand from a vendor before you buy.

AML/CTF Compliance 3 September 2026 11 min read AML Guard

Liveness detection confirms a real, physically present person is completing an identity check, not a photo, video, or mask held up to a camera. It is a presentation-attack control that hardens the biometric verification step, not an AML/CTF obligation in its own right. Compliance officers should pair it with document authenticity checks, government source verification, and human review, then expect vendors to hand over ISO-tested presentation attack detection (PAD) reports as evidence.

TL;DR:

Table of Contents

What is liveness detection in AML identity checks?

Liveness detection meaning, stripped of vendor gloss, is simple: it is a test that the face (or occasionally the voice or fingerprint) presented to a sensor belongs to a live human being physically in front of that sensor at that moment. It is distinct from identity proofing, which asks “is this person who they claim to be?” Liveness only asks “is this a real, present human, or a spoof?”

The distinction matters because a biometric match against a passport photo tells you nothing if the “face” on the other end is a printed photograph or a deepfake video. That is the gap liveness closes. In an AML identity verification workflow, it sits between document capture and biometric face matching, acting as a gatekeeper that stops fabricated inputs before they ever reach the matching engine.

Two flavours show up in most platforms:

Both defend against a specific set of presentation attacks: printed photographs held up to a webcam, video replay of a previously recorded clip, silicone or paper masks, and increasingly, synthetic deepfake video generated in real time. None of these attacks require sophisticated hacking. A decent printer and a stolen selfie from social media is often enough to beat a system with no liveness control at all.

Liveness on its own proves presence, not identity. Reporting entities meeting customer due diligence obligations still need document verification and independent source checks to confirm who that live person actually is. A platform capable of running both together closes far more of the fraud gap than liveness checks bought as a standalone add-on.

Active vs passive liveness: which one fits your risk profile?

Active liveness asks the customer to do something: turn their head, blink, smile, or read a number aloud. The system watches for the requested motion and rejects anything that does not respond correctly. It is highly visible, gives customers a clear sense that something rigorous is happening, and tends to resist crude spoofing attempts well.

Passive liveness runs invisibly in the background while the customer takes a normal selfie. It analyses skin texture, micro-movements, light reflection, and depth cues without asking for any deliberate action. Sumsub’s analysis of liveness notes passive methods typically reduce friction compared with active challenge-response flows, because there is nothing extra for the customer to perform or get wrong.

The trade-off runs two directions:

A passive-first posture is harder for fraudsters to defeat precisely because they cannot see or predict what the system is checking in the background. For higher-risk customers, escalate to an active challenge as a second layer rather than defaulting every applicant into the same friction.

Pro Tip: Set your default flow to passive liveness for standard customer due diligence, then trigger an active challenge automatically when other signals (device risk, mismatched geolocation, PEP hits) suggest enhanced due diligence is warranted. This keeps the bulk of your onboarding fast while reserving friction for the cases that need scrutiny.

How liveness detection works and what it catches

Liveness engines rarely rely on a single signal. Most combine several detection channels, weighting each differently depending on the vendor and the customer’s device.

  1. Texture analysis examines skin, distinguishing the fine, irregular texture of real skin from the flatter surface of a printed photo or a screen.
  2. Motion and depth response tracks how a face moves relative to the camera, since a flat image cannot produce genuine parallax or depth shift.
  3. Light interaction checks how light falls across facial contours in real time, something screens and printed photos reproduce poorly.
  4. Micro-expression and blink detection looks for the small involuntary movements a static image or looped video cannot replicate convincingly.
  5. Device telemetry inspects signals like camera metadata, sensor consistency, and capture timing to spot injection attacks where a video feed is substituted for a live camera.

Architecturally, vendors split between processing these signals on-device, inside a secure application layer, or centrally on a server after capture. Central processing raises the bar for template protection: where matching happens off the device, the Digital ID (Accreditation) Data Standards expect biometric templates to be protected in line with ISO/IEC 24745:2022, with separate cryptographic keys for device identification and biometric data. Authenticated capture channels, where the app cryptographically confirms the image came from a genuine, unaltered camera session, protect against injection attacks that try to feed a pre-recorded or synthetic video stream directly into the pipeline.

Against this architecture, the common attack types line up predictably: a static photo fails texture and depth checks; a looped video fails motion consistency over time; a physical mask usually fails light interaction and micro-expression detection; injection attacks fail device telemetry checks; and deepfakes, the fastest-moving threat, are countered by combining several of these signals at once rather than relying on any single one. industry overviews of liveness technology points out that advanced spoofing increasingly demands layered visual, temporal, and device-level signals working together, because no single check reliably catches a well-made synthetic face on its own.

Layered liveness checks blocking spoof attempts

Where liveness sits in your AML/KYC workflow

Liveness is one step in a sequence, not a standalone gate. A defensible CDD workflow generally runs in this order:

  1. Pre-capture fraud signals — device risk, IP geolocation, and behavioural anomalies flagged before the customer even opens the camera.
  2. Document authenticity checks — verifying the identity document itself is genuine and unaltered.
  3. Liveness detection — confirming a live person is presenting themselves for the biometric capture.
  4. Biometric face match — comparing the live selfie against the photo on the verified document.
  5. Reviewer escalation or enhanced due diligence — for inconclusive results, high-risk customers, or PEP and sanctions hits.
  6. Ongoing monitoring — re-screening and periodic re-verification as the customer relationship continues.

Liveness outcomes should feed into a risk decision, never stand as the decision itself. A “pass” tells you the biometric capture was not spoofed. It does not tell you the person is who their documents claim, and it says nothing about sanctions exposure, beneficial ownership, or source of funds. Treating a liveness pass as definitive identity proof is a mistake regulators and internal auditors will both flag, and it is worth stating plainly: liveness is a supporting control, not standalone proof of identity.

Where genuine identity risk shows up early, it’s often through behavioural red flags rather than a failed biometric check. Fraud patterns in property transactions, for instance, frequently surface as inconsistencies in documentation or urgency around settlement timing well before any biometric mismatch appears. Recognising common fraud red flags alongside your technical controls gives reviewers more to work with than a pass/fail biometric score alone.

Every liveness attempt, pass or fail, needs to sit in an audit trail: timestamp, confidence score, reviewer notes if escalated, and a record of which document and biometric checks it was paired with. A supervisor reviewing your program will want to see that inconclusive results triggered a documented reviewer decision, not a silent auto-approval. Knowing exactly when your AML obligations actually start in a transaction helps determine where in this sequence liveness capture needs to happen relative to other engagement triggers.

What to demand from vendors: standards and test evidence

Liveness vendors will happily claim their technology is “bank-grade” or “certified.” Push past the marketing language and ask for the specific test evidence that backs it.

The relevant technical benchmark is ISO/IEC 30107-3:2023, the international standard for presentation attack detection testing methodology. Where an identity service provider conducts online biometric binding, its PAD and liveness technology must be tested by a biometric testing entity against this standard, as set out in the Digital ID (Accreditation) Data Standards 2024. This is a technical testing framework, not an AUSTRAC requirement. AUSTRAC does not accredit, approve, or endorse biometric vendors; the standard exists to give buyers a consistent way to compare PAD claims across products.

A credible test report should show:

Benchmark: Australian government identity services set the bar here. The Digital ID (Accreditation) Data Standards 2024 require PAD and liveness technology used for online biometric binding to be tested by a biometric testing entity, with template protection and data minimisation controls alongside it. That is the calibre of evidence a private-sector compliance program should expect too.

Contract clauses worth writing into any vendor agreement include the identity and accreditation of the testing lab used, the exact scope and PAIS species tested, the APCER/BPCER results, and explicit provisions for biometric deletion on failed or abandoned checks.

Getting the balance right: accuracy, friction and privacy

Every liveness threshold setting is a trade-off. Set it too strict and genuine customers get bounced, generating false rejects that frustrate onboarding and push people toward less-secure manual workarounds. Set it too loose and false accepts let spoofed attempts through. Neither failure mode is free, and the two rarely trade off in a straight line.

Drop-out at the liveness step is one of the more overlooked metrics in AML programs, and it deserves the same scrutiny as your false positive rates in screening. If a meaningful share of legitimate customers abandon onboarding at the biometric step, that is a signal worth investigating, not a cost of doing business.

Pro Tip: Track your liveness drop-out rate alongside your false-accept rate every quarter. A rising drop-out rate with a flat false-accept rate usually means your thresholds have drifted too strict for your actual customer base, not that fraud attempts have increased.

AML Guard: liveness as one layer, not the whole check

AML Guard pairs biometric liveness detection with document capture, Australian government source checks, and PEP and sanctions screening inside a single customer due diligence workflow. Liveness output informs the risk decision. It does not auto-approve a customer, and a compliance officer reviews every outcome before onboarding proceeds.

That review sits inside a broader platform: guided AML/CTF program documents built from the same risk assessment your policies rely on, a seven-year tamper-evident audit trail, ongoing PEP and sanctions re-screening, and status indicators that sync to REX CRM without exposing sensitive CDD data outside the compliance workflow.

Where compliance teams get liveness wrong

The single biggest mistake AML Guard sees is treating a liveness pass as if it settles the identity question. It settles one question only: was a real person present for capture? Everything else, document authenticity, sanctions exposure, beneficial ownership, still needs its own evidence trail.

The second mistake is under-investing in reviewer workflows. A slick liveness engine with no clear escalation path for inconclusive results just shifts risk downstream to whoever eventually has to make a judgment call without context. Track your onboarding drop rates as closely as your fraud catch rates.

Technical evidence and governance paperwork need to move together. A PAD test report proves the technology works in a lab. Your policy documents, training records, and audit trail prove your business actually uses it the way the report assumes. Supervisors want both, not one propped up by the other.

Ready to see liveness working inside a full CDD workflow?

Buying a standalone liveness API leaves you to wire together document checks, sanctions screening, reviewer workflows, and audit evidence yourself, and to prove all of it holds together when a supervisor comes asking. AML Guard is built the other way around: biometric liveness, document capture, and Australian government source checks run inside one customer due diligence workflow, with an officer reviewing every outcome and a seven-year tamper-evident audit trail behind it.

AML Guard identity verification with document capture and biometric liveness

That means the checklist covered above, ISO-tested PAD evidence, reviewer SLAs, retention terms, ongoing re-screening, is not something you assemble from five vendors. It’s already mapped into guided AML/CTF program documents, CDD workflows, and a governance dashboard built specifically for Tranche 2 reporting entities. If you’re weighing up how liveness detection should fit into your verification stack, the fastest way to see it in context is to book a demo and walk through a real customer file from capture to audit trail.

Sources

See How AML Guard Works

Tranche 2 obligations are now in force.
Book a 20-minute demo to see how AML Guard supports your compliance from the moment your designated service begins.

Book a Demo
This article is for general information purposes only and does not constitute legal advice. Firms should obtain independent professional advice on their specific AML/CTF obligations.
Last reviewed: 3 September 2026.