Global Age Assurance: Verifying Age Against Authoritative Sources

Brazil, Australia and the UK now set different duties for platforms managing younger users. The data available in each market determines what a platform can establish.

Three governments have now told platforms to stop taking a young person’s word for their age in the situations their rules cover:

• Brazil rules out self-declaration by statute for the relevant age-assurance duties
• Ofcom's guidance treats self-declaration as incapable of meeting the UK's highly effective standard
• Australia expects platforms to take reasonable steps to prevent under-16s from creating or holding accounts on designated services.

I see this regulation from the perspective of someone who has spent years building verification controls around authoritative data sources, their coverage, their permitted uses, and the records they leave behind. Almost all commentary on rules like these is written from the rulebook down: here is the article, here is what it requires, now go build a control. I work in the other direction, from the data up.

In the case of age assurance, the verification method is important, but the data underneath it is often even more significant. A platform may be able to estimate age from a selfie, match a date of birth against an authoritative source, or receive a signed age attribute through a digital credential, but those routes produce different levels of assurance and leave very different data footprints.

In this article, I offer a look at what really matters for platforms operating in these markets, covering the three live age verification regimes, what platforms don’t need to worry about, and how the data available in each market affects a platform’s ability to verify age.

Three rules, three standards to meet

Brazil, Australia, and the United Kingdom are pursuing the same broad objective of reducing children’s access to age-inappropriate online accounts, content, products, and services. However, each places age assurance at a different point in the user journey and applies a different standard to the evidence supporting the decision, as laid out in the table below.

While these regimes all seem similar at first glance, there are important nuances to pay attention to:

Brazil’s rule is tied to access. The Digital ECA (Article 9) requires reliable age-verification mechanisms at each access, and prohibits self-declaration outright. The law also sets out how that check can travel (Article 12), with app stores and operating systems passing an age signal to the app through a secure interface, subject to data minimization and a prohibition on continuous data sharing. The relevant question is whether the user meets the age requirement for that particular offering.

Australia’s rule is tied to the account. The Online Safety Act 2021 requires providers of age-restricted social-media platforms to take reasonable steps to prevent Australians under 16 from creating or keeping an account. Whether a service is captured depends on these rules, along with the Online Safety (Age-Restricted Social Media Platforms) Rules 2025, as amended by the Online Safety (Age-Restricted Social Media Platforms) Amendment Rules 2026. Together, the rules look at user interaction, whether a recommender or logged-in feature is present, and the significance of online social interaction to the service.

The UK’s rules are tied to service category, content, and child access. The Online Safety Act 2023 requires that providers that publish or allow pornography must use highly effective age assurance to prevent children from encountering it. User-to-user and search services first assess whether children are likely to access the service, and the highly effective standard then attaches to primary priority content rather than to everything on the service. Ofcom's guidance on highly effective age assurance evaluates a method against technical accuracy, robustness, reliability, and fairness.

It’s clear that a shared policy goal doesn’t produce shared control that platforms can simply adopt. Instead, they must build for the decision each rule requires, then support it with each market’s strongest available evidence of age.

A date of birth is only the start

A date of birth typed into a sign-up form used to be age verification for many platforms. These new regulations say that’s no longer enough. The question now is what evidence backs up age claims, whether it’s enough for the decision being made, and whether the platform can show how it reached that decision.

That doesn’t mean every platform needs to ask for a document or a selfie. There are several ways to establish age, and they don’t all produce the same kind of answer.

• Document capture ties an age to an identity document.
• Facial age estimation gives you an estimate or a probability that someone is over a threshold.
• A match against an authoritative record can return a date of birth or an eligibility result tied to a known source.
• Account, device, and behavioral data can provide a supporting signal from information the platform already holds.
• Banking, mobile-network, credit-card, and other commercial relationships can also support age assurance indirectly.
• A digital identity credential can return a signed age attribute — “16 or over,” for example — without necessarily passing over a full date of birth.

These methods aren’t interchangeable. A self-declared date of birth is a claim, and a selfie result is a probability. A match against a government or semi-government source is a verifiable record, while a credential is a signed assertion. The right route depends on what the platform actually needs to decide and how much confidence the rule requires.

Then there’s the question of explainability, which most platforms leave until it’s too late. An age check only becomes a proper control when you can reconstruct the route used, the source behind it, the result returned, the time of the decision, and the policy that determined the outcome. Brazil’s approach, for example, brings that evidence chain into the requirement itself. It requires the mechanism to be reliable (Article 9) and, for app stores and operating systems, proportionate, auditable, and technically secure (Article 12).

Technology is another factor at play, but the three regimes don’t tell platforms to use one common product or solution.

• Ofcom looks at whether a method is technically accurate, robust, reliable, and fair.
• Brazil’s ANPD does not prescribe a single technology, and its preliminary guidance of March 2026 sets parameters for implementation rather than naming a method.
• Australia leaves the method open too, but puts specific limits around the data used for age assurance.

So, don’t build around the method a regulator happened to name. Build around the decision you have to make, then use the strongest evidence available in that market to support it.

Not all of these rules apply to everyone

At first glance, the three regimes can seem like they apply equally to all platforms, but once you actually read the rules, the scope narrows. For compliance and risk leaders who have their necks on the line, knowing which duties your platform can safely ignore matters as much as knowing which ones apply to it.

So here are three rules that most platforms don’t need to worry about:

1. Every service used by children now needs an age verification control.

   In practice, the rules are narrower than that broad statement. Australia’s minimum-age obligation applies to age-restricted social-media platforms, not every online service used by people under 16. The UK’s duties depend on the service category, the content available, and whether children are likely to access the service. Brazil has wider potential reach, though Article 9 concerns access to content, products, or services that are inappropriate, unsuitable, or prohibited for minors.

   The takeaway: age assurance should be targeted to the services, users, and content that the applicable regime actually covers.

2. Age assurance requires facial age estimation.

   Facial age estimation is one route among several. Ofcom identifies multiple approaches that may meet its highly effective standard in appropriate circumstances. Brazil does not prescribe a specific technology. Australia’s reasonable-steps standard leaves the method to the platform, subject to applicable privacy obligations.

   The takeaway: the appropriate method is the one that provides sufficient assurance for the decision at hand while handling users’ data proportionately.

3. One global method can meet every age-assurance requirement.

   The three regimes ask platforms to make different age-related decisions and apply different tests to the evidence supporting them. A company can set a consistent internal expectation for the level of assurance it needs. The evidence route still needs to reflect the duty, local source environment, and data-handling requirements in the market where the age decision is made.

   The takeaway: companies can standardize their governance and assurance principles, while adapting the evidence route and user journey to each market.

None of the three rules tells you whether the market your user lives in can supply the evidence its standard requires. Each sets the standard and stops there. Whether you can meet it depends on the sources available where the user is, and that changes from one market to the next.

The data decides the route

In an AML setting, two customers with identical risk profiles in two different countries are not equally verifiable, and the same principle of identity verification is true for age verification. The failure I see repeatedly is that firms apply risk-based thinking to the customer and leave the data environment to the operations team.

A mature program treats the availability and quality of authoritative data as a risk variable in its own right. Market to market, it plays out in three ways:

The wallet route

In Europe, a user presents a signed attribute from the EU Digital Identity Wallet, and the answer that comes back is that they are over the threshold. The platform ends the check holding an assertion and nothing else, because the document never leaves the holder. Anyone who can validate the signature can confirm the result, so the evidence doesn’t have to be stored to be defensible.

EU member states must make a certified wallet available by December 24, 2026, and until then the Commission’s age-verification blueprint, built on the wallet’s technical specifications, is the interim version of the same route. The Commission’s July 2025 guidelines under Article 28 of the Digital Services Act name the wallet and the blueprint as a reference standard for device-based age verification.

Australia shows the same credential idea developing differently. Its Digital ID Act 2024 accredits digital identity services, and an accredited service can be one option for the minimum-age check. Under the Online Safety Act, a platform that uses government ID or an accredited Digital ID must also offer a reasonable alternative method, so an identity document cannot be the only route to an account.

The registry route

Across much of Latin America and parts of APAC, verification comes from a match against a government or semi-government register, and what comes back is usually a date of birth, which is more than the access decision needs.

The user supplies identifying details, the platform sends them to the source, and what it keeps afterward is the evidence, because the evidence is what it can show a supervisor later. Assurance on a match is high, and the variable is coverage. Most of these markets have no wallet equivalent, so that assurance rests on the source behind the match rather than on a signature the platform can validate for itself.

The triangulation route

Where official data is thin or fragmented, no single source answers the question, so you triangulate across several and the result carries genuinely higher residual risk. The honest response there is to accept that and adjust controls rather than claim equivalence.

Combining sources only helps if they are independent, and independence is a stricter test than it sounds. The one I apply is whether the existence of one source depends on the existence of another. Two files built from the same marketing campaign are one source wearing two names. A passport record and a driver’s license record are two, because they have different issuers, sit under different regulations, and are maintained separately. Triangulation across sources that fail that test adds volume without adding assurance.

Triangulation leaves a platform in the weakest position of the three. You hold the most data, spread across the most sources, and you can prove the least.

What your platform needs to account for

Supervisors are moving toward asking which source you verified against, and not only whether you verified. That question separates the three routes immediately, and it is hardest to answer on the third, where the answer is a combination of sources instead of a single authoritative record.

Put the three routes against one company’s age-assurance policy and the consequence follows. A single global standard, expressed as a prescribed method, cannot be implemented. What works is one risk appetite expressed as assurance outcomes, with a different evidentiary route per market. Most firms have it backwards, running one prescribed method and a growing pile of exceptions.

Holding age data responsibly

The industry has spent 15 years building AML programs on collect-everything, keep-it-forever logic. The identity infrastructure now arriving, from digital wallets to age-signal APIs, is built on the opposite principle. Age assurance is where this contradiction is especially clear. A stronger check usually leaves a platform with more data about a child than it held before. To manage child privacy responsibly, every one of these regimes includes data rules to minimize data collection and retention during age assurance processes.

Brazil’s Digital ECA limits data collected for age verification to that purpose. Brazil allows age data to be used for the age check and nothing else, and it bars behavioral profiles of children built from that data for advertising purposes (Article 26). The provision I would watch is the guardian link, since an age check on a 15-year-old ends with two identities on file, one of them an adult's. This adds complexity that may be hard to navigate, since a minor’s data is linked with an adult’s, and each has to be managed in a different way.

Australia puts its data limits in the statute. Australia lets a platform use age-assurance information for the age decision and then requires it be destroyed, with de-identification ruled out. Australia is where inherited AML instincts do the most damage, since the rule butts against how compliance teams are trained. They keep evidence so they can prove later that they checked, but age assurance data must be deleted and only the decision can be recorded.

The UK’s duty focuses on the effectiveness of the check. In the UK a platform answers to two regulators at once, with Ofcom judging whether a method is effective and the ICO governing the data it collects. Their joint statement from March 2026 tells providers to satisfy both frameworks together. A face scan or a document capture may seem like the most reliable way to verify age, but those methods also collect the most sensitive data about a child. Ofcom also accepts mobile-network and open banking checks, which can clear the same bar while keeping more data privacy intact.

Across all regimes, the kind of selective disclosure I just mentioned can reduce the data burden on platforms. A user can prove they meet an age threshold without providing the date of birth or document behind it. Europe’s digital identity wallet is one model, but it isn’t the only route. However, whether it works in a given market depends on whether the sources there can return an age attribute instead of a full record, and whether the platform can accept it.

Build for the outcome, then the market

The operating model you choose has to carry the legal decision, the evidence behind it, and the rules governing the data used to make it. That starts with defining the outcome the service needs from each check, then connecting it to the evidence and retention rules available in the relevant market.

1. Start with the access decision the service needs to make. Set the relevant age threshold and the assurance level required for that decision, then map the evidence route available in each market. The decisioning layer should consume an eligibility outcome, so a new national scheme can be added through local sources, rules, and retention settings rather than through a new global user journey.
2. Treat date of birth as a high-value attribute, not a default data field. Give it a defined source, assurance level, permitted purpose, and retention clock. Where the access decision requires only a threshold answer, such as whether a user is 16 or over, return that answer instead of collecting or retaining a full date of birth. A platform that stores dates of birth where it needs only a yes-or-no outcome takes on risk it was never asked to carry.
3. Minimize retention deliberately. Holding identity, document, or biometric data about minors is a risk that the platform can directly control. Set retention periods by data type, purpose, and market before the first check runs. Otherwise, the retention policy is likely to be discovered during an incident, complaint, regulator inquiry, or inspection.
4. Review each evidence route in the market where it will operate. A method that satisfies one regime satisfies that regime alone. Test it against the relevant legal duty, regulator guidance, source terms, coverage, assurance performance, accessibility needs, and data-handling rules.

One global risk appetite can support different evidentiary routes in different markets. A program built that way can absorb the next regime as a configuration change rather than a redesign.

One policy, different evidence routes

Three legislatures set out to protect children. Each wrote a different rule to do it, and the data underneath those rules was never going to line up neatly.

Which threshold a platform can prove and how it proves it are determined market by market and source by source, well outside the statute. That makes a platform responsible for building a control that can use that local evidence, retain only what the decision requires, and explain the result when a regulator, partner, parent, or user asks.

When it comes to the new standard of age verification, the policy can travel, but the evidence has to fit the market.

Learn more

For more on how Data Zoo approaches source vetting, data sovereignty and audit-ready verification, see Compliance at Data Zoo.

Building age assurance for a new market and need to understand what authoritative age data is available? Talk to our team.