Australia Can Now Demand Your Age Check Vendor's Records. What Would They Show?

On 20 October 2026, Australia’s Communications Minister, Anika Wells, told Bloomberg that the government is preparing to sue Facebook, Instagram, TikTok, Snapchat and YouTube. The claim is that they haven’t taken reasonable steps to keep under-16s off their services. Her words at the National Press Club on 15 October were short: “The law is not failing – platforms are failing to comply with the law.”

Nothing has been filed. But one change from last month matters more to your engineering team than the headline. The eSafety Commissioner can now compel documents, and the reports say that includes records held by age check vendors. Until September, she mostly had what platforms chose to tell her.

So here is a question to answer before a regulator asks it. If someone read your vendor’s logs for the last six months, what would they conclude about your age check?

What was announced, and what wasn’t

This is what we could confirm from reports published between 15 and 23 October.

• The minister said the government is preparing legal action against Meta (Facebook and Instagram), TikTok, Snap and Google (YouTube). Tech Times reports the case would be a civil-penalty action in the Federal Court, brought by the Commissioner, Julie Inman Grant.
• No proceedings have been filed. No platform has been formally accused of a specific failure in court.
• The law took effect on 10 December 2025. Platforms must take “reasonable steps” to stop under-16s holding accounts. It doesn’t name a method.
• Penalties were raised after the first six months. The original maximum was A$49.5 million. Reports now give the new figure as A$99 million or A$109.2 million. The sources disagree, so check the Act before you quote a number.
• A High Court challenge by Reddit and the Digital Freedom Project is due to be heard in November. If the law falls, the Federal Court case may fall with it.

What changed on 12 September

The enforcement bill was introduced in June and received assent on 11 September, according to Biometric Update. Tech Times and Reclaim The Net report that the new compulsory powers started the next day. As described in those reports, the Commissioner can:

• demand documents from anyone she reasonably believes holds relevant material, including board minutes, internal emails, technical logs and records held by third-party age assurance vendors;
• summon people, including current and former employees, to give evidence under oath;
• treat refusing a summons as an offence that carries up to 12 months in prison.

We could not open the operative text of the amendment. Treat the list above as press reporting, not a reading of the law. Two other sources point the same way. In a July submission to a Senate inquiry, the Age Verification Providers Association (AVPA, the trade body for vendors) said the powers would reach its members. It said most vendor confidentiality agreements already allow disclosure that the law requires. And the minister said the powers target third parties such as age assurance providers and app stores, not ordinary Australians.

In July, the Commissioner told a Senate inquiry that she couldn’t compel key internal documents. She relied on platforms’ own descriptions of what they did. Under the new powers, that is no longer the only source.

The test is the system, not the account

You might think a regulator needs to prove that some under-16s got in. It doesn’t. eSafety’s first compliance report, from March, says enforcement needs evidence of systemic failure, and that “reasonable” is judged on all steps taken in totality. A few teenagers on a platform proves nothing on its own.

The same report names the weaknesses it saw. Read each one as a question that logs can answer.

• Some platforms let users retry age checks many times. The report says some allowed double-digit attempts, and that good practice is no more than five.
• Some let users repeat the same method after each failure, even when it had returned a low-confidence 16+ result.
• eSafety expected a second, more robust check, such as a bank or ID check, when a user might be under 16.
• Most platforms hadn’t applied checks at or near sign-up.
• A parent survey (898 parents) found about 7 in 10 said their child still had an account. Among the under-16s who kept one, the most common reason (66.8%) was that the platform hadn’t yet asked for age verification.

Our earlier post on seven months of the ban covered the “deletion without verification” problem. This post is about the next stage: proving what your system did.

Five questions your vendor’s logs answer

Each row below is a question a regulator can ask, the record that answers it, and the gap we see most often. The first column is what they want to know. The third is where teams are caught out.

Question	Record that answers it	Common gap
How many attempts did one user get?	Attempt log keyed by a stable user reference	The vendor logs sessions, not users, so a retry looks like a new person
Could a user repeat a method that had just failed?	Method and outcome on every attempt	Only the final result is stored
What happened after a low-confidence pass?	Confidence band plus any later step-up	The pass is stored as a plain “verified”
Where in the journey did the check run?	Stage field: sign-up, first post, first message	The check runs, but nothing records when
Did production match what you were sold?	Dated configuration history: caps, thresholds, methods	Settings are changed in a dashboard with no change log

The last row is the one that hurts. A vendor’s sales deck says “five attempts, then step-up”. The regulator asks for the setting in force on 3 March. If neither you nor the vendor can show it, the deck is all you have.

Related reading: our UK evidence post covers the same lesson from Ofcom’s side, and retry abuse and attempt budgets covers how to design the caps. This post covers proving the caps worked.

You can’t rebuild this record afterwards

A decision log is cheap to write at the time and impossible to recreate later. Suppose a notice arrives in 2027 and asks how many users passed on a low-confidence result in October 2026. If you didn’t record the confidence band, no one can work it out from the final “verified” flag.

There is a tension here, and it’s a real one. Privacy law pushes you to keep less. Evidence pushes you to keep more. The way through is to keep decisions, not images. A decision record holds a pseudonymous user reference, the method, the outcome, the confidence band, the stage and the time. It doesn’t need the face image, the document image or the date of birth. Our post on the data retention breach wave argues why those should be deleted fast.

A retry report you can run this week

If your vendor gives you a decision export, you can answer three of the five questions with a short script. The sketch below takes a list of attempts and reports how many users went over the cap, passed after an early failure, repeated a failed method, or got a low-confidence pass with no step-up.

type Method = "estimation" | "bank" | "document";
type Outcome = "pass_high" | "pass_low" | "fail";

interface Attempt {
  userRef: string;   // a pseudonymous reference, not a name or an email
  method: Method;
  outcome: Outcome;
  at: string;        // ISO time
}

interface Report {
  users: number;
  overCap: number;            // tried more than `cap` times
  passedAfterFail: number;    // first try failed, a later try passed
  repeatedSameMethod: number; // retried the method that had just failed
  lowPassNoStepUp: number;    // low-confidence pass, no later high-confidence pass by another method
}

export function retryReport(attempts: Attempt[], cap = 5): Report {
  const byUser = new Map<string, Attempt[]>();
  for (const a of attempts) byUser.set(a.userRef, [...(byUser.get(a.userRef) ?? []), a]);

  const r: Report = { users: byUser.size, overCap: 0, passedAfterFail: 0, repeatedSameMethod: 0, lowPassNoStepUp: 0 };

  for (const list of byUser.values()) {
    list.sort((x, y) => x.at.localeCompare(y.at));
    if (list.length > cap) r.overCap++;

    const last = list[list.length - 1];
    if (list[0].outcome === "fail" && last.outcome !== "fail") r.passedAfterFail++;

    if (list.some((a, i) => i > 0 && list[i - 1].outcome === "fail" && a.method === list[i - 1].method)) {
      r.repeatedSameMethod++;
    }

    const lowIdx = list.findIndex((a) => a.outcome === "pass_low");
    if (lowIdx >= 0) {
      const stepped = list.slice(lowIdx + 1).some((a) => a.outcome === "pass_high" && a.method !== list[lowIdx].method);
      if (!stepped) r.lowPassNoStepUp++;
    }
  }
  return r;
}

We ran it with eight tests on Node’s built-in test runner. All eight passed. They cover the cases that matter: users are counted once, six attempts go over a cap of five, a pass after an early failure is flagged, a different method after a failure isn’t a repeat, and a high-confidence pass by the same method doesn’t count as a step-up.

Two limits. First, this reads attempts, so it can’t see users who never tried. The March survey found that most retained accounts belonged to users the platform hadn’t asked at all, and no attempt log shows that. Second, the numbers aren’t a verdict. A rate of passes after failure is normal for honest users with bad lighting. What matters is whether the system answers a low-confidence pass with a stronger check.

Ask your vendor these in writing

AVPA says confidentiality terms usually allow legal disclosure. Check yours, and ask for more than that.

1. Which of the five records above do you keep, and for how long?
2. Is the log keyed by user or by session? Can you export it per user reference?
3. Is every change to caps, thresholds and enabled methods logged with a date and an author?
4. If a regulator serves you a notice about our account, do you tell us first, and how fast?
5. In what format can we export decision records, and what does it cost?
6. What do you hold that we don’t? Images, device data, raw scores?
7. What do you delete, and when? Can you show the job that does it?

A vendor that can’t answer number 3 can’t tell you what ran in production last March. That isn’t a reason to panic. It’s a reason to find out now.

What we could not confirm

• Whether the Federal Court case will be filed, and against which of the five platforms. As of 23 October it is a stated plan.
• The exact reach of the September powers over vendors. We relied on press reports and the vendor trade body. We could not read the operative text.
• The new maximum penalty. Sources give A$99 million and A$109.2 million.
• Which specific failures the Commissioner will allege. The March report describes practices across five platforms and doesn’t match each one to a company.
• The High Court result in November, and what it does to the rest.

Checklist for the next seven days

1. Write down where each of the five records lives: your system, your vendor’s, or nowhere.
2. Ask your vendor for a decision export for one week, and run a retry report on it.
3. Set your cap at five attempts or fewer, and check that the cap is per user, not per session.
4. Make sure a low-confidence pass triggers a different, stronger check, and that the step-up is logged.
5. Turn on a change log for every age check setting. If the vendor has none, keep your own.
6. Send the seven questions above to your vendor, in writing, and file the answers.
7. Check that the stored record has no images and no date of birth.

The short version

Australia’s regulator no longer has to take a platform’s word for what its age check did. If the reports are right, it can read the logs, including the ones your vendor holds. A regulator judges the whole system, so the best evidence is a dated record of every decision. Start keeping it before anyone asks.

---

Xident provides age verification and age estimation with a decision record on every check, a lower-cost Check for everyday access, and a document Verification for high-risk steps. On paid plans a Check costs from €0.01 to €0.03, and a document Verification costs from €0.10 to €0.30, so a step-up for the few users near the line stays cheap. Talk to us about an evidence export for your age check, or see pricing.