Written to what the system does today. Where something is not yet in place, this page says so rather than describing an intention as a fact.
Privacy notice
This covers the information AML Direct handles when you request a check, and the information we handle about the person being checked. AML Direct is a registered business name of ABN 60 290 550 324, a sole trader in South Australia.
What we collect about the person being checked
Images of the identity document they present, a selfie captured for liveness and face match, the details read from that document such as name, date of birth and document number, the email or phone number you gave us so we could reach them, the device and network address the check was completed from, and the results of sanctions, politically exposed person and adverse media screening.
What we collect about you
Your name, your firm, your email address, and the reason you gave for each check. If your firm has a sign-in, we also hold the account it belongs to. Signing in is handled by Google Firebase Authentication, which receives your email address and the network address you sign in from, and keeps that network address for a few weeks.
Why we collect it
To run the check you asked for, to keep the record of it, and to be able to show later what was done and why. We do not sell it and we do not use it to build a marketing database. Our provider offers a re-usable identity feature that can share a completed verification between businesses; we have asked for it to be switched off on our account, and we will say so here once we have confirmed it.
Consent
A consent request is sent before the verification steps begin. The person is told who asked for the check and why before they are asked to consent, and the consent request and the time it was sent are stored with the case. The verification steps begin only after they accept on the screen they are shown; we do not separately record that acceptance.
Who else handles it
Identity verification and screening are performed by our verification provider. Our records are held in Google Cloud, and the emails we send are delivered by our email provider.
Where it goes
Your record is stored in Australia, in Google Cloud's Sydney region. The application that serves it runs on Google Cloud in Singapore. Our verification provider processes the check in the European Union, in Ireland. The emails we send you are delivered by our email provider from Japan. Those are the countries your information reaches today. Our provider is required to notify us of any change to its sub-processors, and we will update this page when we are told.
How long we keep it
Our verification provider is configured to hold the identity document images and the liveness selfie for one month and then delete them automatically. We set that on 15 August 2026 and have not yet watched a deletion happen, so we describe it as configured rather than proven. What survives is the result - the document type, the issuing country and whether it matched - not the pictures. The record is kept for seven years in Australia, which is the record-keeping period under the AML/CTF Act. That covers the result, the consent, the evidence behind it and the audit trail, and every record is stamped with its deletion date when the check completes. One thing is not yet automatic and we would rather say so than imply otherwise: deletion of the record at the end of that period is carried out by hand rather than on a schedule.
Getting a copy, or correcting it
You can ask us for a copy of what we hold, or ask us to correct it, by emailing support@amldirect.com.au. We will ask you to confirm who you are before we release anything. If you are the person who was checked rather than the firm that requested it, tell us that when you write - the firm that requested the check is the party we hold it for.
Complaints
Write to support@amldirect.com.au and we will respond within 30 days. If you are not satisfied with how we handled it, tell us and we will escalate it. Your check was requested by a firm that is itself a reporting entity under the AML/CTF Act, and you may also raise the matter with them directly.
Terms of service
NOT YET PUBLISHEDOur terms are with a lawyer and are not published here yet. We are not going to put a draft on this page and call it a contract - every AML Direct customer is a small business, and standard-form terms that have not been reviewed are exactly the kind that get struck out. Until they are issued, the terms of any check are what we agree with you in writing when you request one. Ask us for them before you send a request and we will send you what we have.
Security
Two separate things get confused here, so they are kept apart: what our infrastructure provider is certified for, and what AML Direct itself has been assessed for.
IN PLACE TODAYEncryption
Records are encrypted in transit and at rest.
IN PLACE TODAYAppend-only audit trail
Every event is written with its actor and time. There is no update or delete path for an audit event, in the application or in the database rules - a correction is a new event, never an edit to an old one.
IN PLACE TODAYRecord location
Records are held in Australia, in Google Cloud's Sydney region.
IN PLACE TODAYAudited infrastructure
Firestore, the Google Cloud service that holds your records, is independently audited to SOC 1, SOC 2 and SOC 3 and certified to ISO/IEC 27001, 27017 and 27018 - checked against Google per-service, not assumed from the platform, because not every Firebase service carries all six. Firebase Authentication, which secures sign-in, carries the same six. Our verification provider holds ISO/IEC 27001, Bureau Veritas certificate ES144068, expiring 3 June 2027.
NOT YETAML Direct's own certification
AML Direct's own SOC 2 Type II attestation and ISO/IEC 27001 certification are in progress. We will publish the reports when they exist, and until then we do not describe AML Direct as certified.
NOT YETAutomatic deletion of identity images
Configured, not yet confirmed. Our verification provider is set to delete identity document images and the liveness selfie one month after the check, automatically and permanently. That setting was made on 15 August 2026. We have not yet watched a session actually disappear, so we are not claiming it as proven - when we have, this card will move and carry the date.
NOT YETScheduled record deletion
Every record is stamped with its deletion date at completion, and the deletion itself is carried out by hand rather than on an automatic schedule. Automating it is the next piece of work on this list.
NOT YETHow you reach the record
In your portal. Every completed check keeps its result, its consent request and timestamp, the evidence behind the result and its full audit trail, and authorised people at your firm can review all of it there. What does not exist is a generated file - no document is produced, nothing is attached to an email, and there is no button that downloads one. During the managed pilot, anything you need beyond the portal is a person doing it by hand, and we would rather say that than imply a machine.
NOT YETRecording your own decision
Not yet. The record is built to carry your firm's decision on a result - who accepted it and the reason they gave, written to the append-only trail and attributable to a named person rather than a shared login. The screen to enter it does not exist, so no decision can be recorded today and we do not claim one. It is the next feature after delivery.
NOT YETCustomer accounts and sign-in
Built, not yet in service. Your firm will be able to sign in and see the checks you have requested and the record behind each one, read-only. Accounts are created by invitation only - there is no self-service sign-up - and each person gets their own, so an action is attributable to a person rather than to a shared password. No customer has signed in yet, so we are not claiming it as proven; when one has, this card will move and carry the date.
NOT YETTwo-factor authentication
Built alongside sign-in, and required rather than optional when it is in service: a password plus a code from an authenticator app, with the code checked before any session is created. We will not send codes by SMS or email, because a code sent to the address that also resets the password is not a second factor. Not yet confirmed in use.
Last reviewed 5 September 2026.