Age checks that hold up: from a birthday field to a verified date of birth
A reliable age check uses a date of birth established by an identity check (the government record, the document or its chip), compares it with a per-country limit, and fails closed when no date can be read. A typed birthday proves nothing, and a face gives an estimate with a margin of error.
Charles Archibong, Co-founder
· 5 min read
Key takeaways
- An age gate is only as good as the date of birth behind it; a typed birthday is a claim, not evidence.
- Use the date of birth the identity check established: government record, document or chip.
- When no date of birth can be read, fail closed rather than waving the applicant through.
- NIST found facial age estimates vary with gender, region of birth and image quality.
To verify age reliably, take the date of birth from an identity check (the government record, the document the person holds, or its chip), compare it with the age limit that applies in the person's country, and fail closed when no date of birth can be read. That is the whole method. Everything else is detail about limits, exceptions and what happens to people outside them.
Two common shortcuts do not hold up. A birthday field is a claim anyone can type. Estimating age from a face gives you a number with a margin of error, and near the limit a margin of a few years is the difference between allowed and refused. For an age-restricted service, a verified date of birth is the evidence; a face-based estimate is at best a screening signal.
Why isn't a birthday field enough?
A typed date of birth tells you what the applicant wants you to believe. It is useful for one thing: comparing against the record. If a person types 1998 and their government record says 2009, you have learnt something, but not from the typed date alone.
Age rules also often apply to the account holder, not whoever happens to fill in the form. Tying the date of birth to a verified identity (with a selfie matched to the record or document) is what links the age to the person.
Why not estimate age from a face?
Facial age estimation predicts an age from facial features. It is attractive because it needs no document. Its limits are measurable, and an independent public evaluation from the US National Institute of Standards and Technology (NIST) shows them.
In its age estimation evaluation, published 30 May 2024 (opens in a new tab), NIST tested six algorithms and reported that:
"There is no single standout algorithm, and a given algorithm's accuracy is influenced by image quality, gender, region of birth, the age of the person in the photograph, and interactions among these factors."
"Error rates were almost always higher for female faces than for males."
On a common set of visa photos, mean absolute error fell from 4.3 years in 2014 to 3.1 years.
NIST also states that it "makes no recommendations on whether the software is fit for particular use cases". An average error of about three years is a real improvement, and it is still large relative to an 18-year limit: a 16-year-old estimated three years high reads as 19. Because accuracy varies by region of birth, you also cannot assume the published average holds for your own customers.
Myaza Trust does not offer facial age estimation, for these reasons. Age checks run on a date of birth from a verified source.
How do you build an age check that holds up?
1. Decide the limit per country
The legal age for a service is not the same everywhere, and the age of majority itself differs between countries. Set a minimum per country (and a maximum, if your policy needs one), and write down where each value comes from. Requirements differ by jurisdiction and by product, and this article is general information, not legal advice.
2. Take the date of birth from the verified source
Use the date of birth the identity check established:
Source | Strength for age |
|---|---|
Government record returned by a database check | Strong, provided the selfie matched the record |
Chip on an ePassport, when the chip is authenticated | Strong |
Date of birth read from the document image | Good, if the document passed its checks |
Date of birth typed by the applicant | A claim, useful only for comparison |
3. Fail closed when you cannot read a date
A document with glare across the date of birth, or a record that returns none, leaves you unable to judge age. If "unknown" is allowed through, the gate restricts nobody who photographs their document badly on purpose. Treat an unreadable date of birth as a failure, and tell the applicant how to retake the photo.
4. Choose decline or review for people outside the range
For most age gates, under the minimum means decline. Some services prefer a review, for example where a parent's consent route exists, or where an age limit applies to some products and not others. Decide per case, and make sure a rule actually routes reviewed applications.
5. Do not name the limit in the rejection
A rejection message that says "you must be 18" tells a determined underage applicant which date to present next time. Say that the applicant does not meet the service's requirements, and handle questions through support.
A worked example
An online gaming operator serves customers in several African countries. It sets a minimum of 18 as its policy in each market, checks each value against local rules, and adds a higher minimum in one market where its licence requires it.
An applicant verifies with a national ID whose government record gives a date of birth making them 17. The verification fails as age-restricted. The message does not mention 18.
Another applicant's document has a glare patch across the date of birth, and the document read cannot establish it. The verification fails as age unverified, with guidance to photograph the document again in better light.
A third applicant types a birthday that makes them 25, but the record shows 19. They pass the age rule on the record's date, and the mismatch between typed and recorded data is handled by the data-match rule, not the age rule.
How Myaza Trust handles age limits
In a workflow, the ID Verification step has an Age tab that limits verification by age in each country. The minimum defaults to each country's legal age of majority (18 in most countries, between 16 and 21 elsewhere), the tab shows it beside every country, and you can set your own minimum, a maximum, or country-specific limits. The check always uses the date of birth the verification established, never a typed one.
Outside the range, you choose per case: decline (the default) fails the verification with age_restricted, or review keeps the result and a decision rule on verification.ageLimit sends it to a person. A date of birth that cannot be read always fails with age_unverified. Neither reason names an age. Sandbox test scenarios 22 and 23 let you exercise both against your own limits before launch. The workflows documentation and the age verification solution page cover the details.
Checklist
Write down the minimum (and any maximum) for each country, with its source.
Take the date of birth from a verified record, document or chip, tied to a selfie match.
Treat typed dates of birth as claims for comparison only.
Fail closed when the date of birth cannot be read.
Choose decline or review for each side of the range, and make sure reviews are routed.
Keep ages out of rejection messages.
Test every outcome in sandbox before you go live.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
