Document Verification

It confirms that an Australian identity document is genuine and that the details presented match the record held by the authority that issued it, through the national Document Verification Service.

The check is a comparison, not a lookup. The details from the document are sent to the issuing authority's system and compared against their record, and the answer comes back as a match or a non-match in seconds.

That is what makes it a reliable and independent source: the confirmation comes from the issuer, not from a database copy that may be out of date.

The full range of Australian identity documents available through the DVS, each checked against its issuing authority:

• Driver's licences — every state and territory
• Passports and travel documents — DFAT
• Medicare cards and Centrelink concession cards — Services Australia
• Birth, marriage, death and change-of-name certificates — the state registries of births, deaths and marriages
• Citizenship certificates, registration by descent, ImmiCards and visas — Home Affairs
• Aviation and maritime security cards — ASIC and MSIC, via the issuing scheme

A single integration covers all of them, so adding support for another document type later is a configuration change, not a new project.

It confirms that a document with those details exists on the issuing authority's record, and that the details presented match it.

What it does not do is return a photograph, hand back a copy of the underlying record, or prove that the person in front of you is the document's rightful holder. The DVS answers a question about the document, not about the person presenting it.

Closing that second gap is what biometric and data checks are for: face matching ties the document to the person holding it, and per-field data verification confirms the details belong to a real, living individual. Most KYC programs combine them for exactly this reason.

Verification against reliable, independent government sources is the sourcing standard the AML/CTF Act sets for identity verification, and a DVS check meets it: the confirmation comes from the authority that issued the document.

What the Act does not do is prescribe one fixed combination of checks for every customer. Your AML/CTF program defines your customer types and risk-based procedures and determines which checks apply to each.

Every check produces its own evidence record, so the trail an auditor or AUSTRAC would ask for exists as a by-product of running the checks, not something assembled afterwards.

Yes. A DVS check can only be run with the consent of the person whose document is being verified, and consent must be obtained before the check runs.

The division of responsibility matters. The platform requires you to confirm you have consent, and records that confirmation with the check and its result. Obtaining and retaining the underlying evidence of consent is the business's responsibility, and DVS checks are auditable: you may be asked to produce evidence of consent for any check conducted.

So build consent capture into your own onboarding flow and keep it with the customer record. The check history shows the check was authorised and when; it is not a substitute for the consent record itself.

Seconds. The check runs in real time against the issuing authority, so a customer verifying cleanly can complete onboarding in a single sitting instead of waiting on a manual review queue.

That speed is a conversion question as much as an operational one. Verification sits at the very start of the relationship, and every additional minute at that point costs completed sign-ups.

A non-match is not the same thing as fraud, and it is worth designing for that.

The most common causes are mundane: a mistyped licence number, a name recorded differently on the document than in your form, or a document that has been renewed and superseded. Allowing a retry, or accepting a different document type, resolves most of them without any friction for a legitimate customer.

Where a retry also fails, the usual designs escalate to a biometric check or route the application to manual review. Your policy decides which path applies, and the evidence of each attempt is recorded either way.

Both are available, and they suit different volumes.

• API — document verification endpoints integrate the check directly into your existing onboarding flow, so verification happens without anyone leaving your product
• Cloud portal — your team runs checks in a browser, with no integration work at all

The checks and the resulting records are identical either way. Most organisations start in the portal to prove the process, then integrate once the volume justifies it.