VerifyMy, AgeChecked, Persona and Didit are useful alternatives to evaluate for Yoti age checks. The first two are candidates when a dedicated age assurance service fits the product. Persona is worth examining when age is a step in an existing inquiry. Didit offers a standalone age estimation endpoint and a hosted workflow with an optional document fallback. The decision depends on the evidence you need, what happens near the cutoff, and whether you can return a threshold decision without collecting a full identity record.
Yoti is a sensible baseline because its documentation exposes distinct methods and a session result. Replacing it does not necessarily mean replacing an estimation model. You may need to replace a way of verifying date of birth, accepting a digital credential, or giving people another route when the first method cannot decide. An evaluation that starts with an average prediction error can miss the work the product actually needs to do.
Start from the claim your application needs
Age estimation predicts age from a signal such as a face image. Date-of-birth verification confirms information from an accepted record. An age assertion can represent that a person met a threshold without sending a full date of birth to the relying application. Each approach can be appropriate for a different decision. Write down the age threshold, the accepted methods, the actions it protects and what the application should record.
For an age-only screen, a stored age band or precise birth date may be unnecessary if a trustworthy over-threshold assertion meets the requirement. A system that needs to establish identity has a separate job. The same provider can offer both, but the two outputs should not be substituted for each other. Include the type of evidence in the result so you can tell why a user was allowed through.
Compare the replacement options by output
| Option | Approach worth evaluating | Key question |
|---|---|---|
| Yoti | Configurable age verification sessions with multiple methods | Can the service return the specific result and method your system needs? |
| VerifyMy | Specialist age assurance with a choice of methods | Which methods are available in the market and what does the relying app receive? |
| AgeChecked | Specialist age checks and alternative verification methods | How are inconclusive checks handled and how much evidence remains accessible? |
| Persona | Age checks that can be composed with an existing inquiry workflow | Can you return a minimum-data decision without running unnecessary identity steps? |
| Didit | Standalone facial estimate, or hosted workflow with an optional document fallback | Which fields are returned and who owns fallback when using the standalone endpoint? |
Yoti's API documents age, over-threshold and under-threshold session types, and lets an operator configure age estimation and other methods. Its estimation documentation recommends using a threshold above the age of interest. That margin is a policy parameter, not evidence that everyone above it is old enough. Use the rule with an accepted fallback and evaluate the results against the intended age boundary.
Didit documents the distinction between its standalone endpoint and hosted flow. The standalone result includes estimation data and does not run the hosted adaptive fallback for you. VerifyMy and AgeChecked appear in the Australian Age Assurance Technology Trial material, which distinguishes how methods treat and return evidence. When comparing those options, request the actual response schema and retention terms for the method you would enable. Persona's age assurance material is relevant if you already use its inquiry architecture; check that the configured steps match the claim.
Measure errors at the boundary, not across all ages
An age estimator can be accurate on average and still make the wrong decision too often at a specific threshold. Consider a synthetic test with two 18-plus gates. Model A estimates the ages of people far above the threshold more accurately. Model B makes fewer erroneous acceptances for people just below the threshold. Average error across the whole group might favor A even though the gate cares more about the boundary. This is why the distribution of ages and the policy matter.
Define a false adult as an under-threshold user accepted by the policy. Define an adult rejection or fallback separately. If someone is routed to documentary verification and later accepted, the first method did not make a final rejection. Report both the outcome of the first method and the outcome after fallback. Keep a separate count for users who could not capture an image or did not finish.
NIST's age estimation and verification evaluation provides a framework for comparing algorithms under stated conditions. The figures are meaningful in the context of the task, data and version evaluated. A provider quoting a published metric is not the same as the vendor reporting performance for your device mix, threshold and method. Use the guide to recording an experiment to record these differences before comparing results.
Evaluate the fallback as part of the policy
Choose a documented boundary rule and exercise users close to it. If the method cannot establish eligibility, offer a second approved route. Record the fraction that reaches fallback, the fraction that completes it and the time to a final decision. Measure these figures separately by device or capture condition where the sample is large enough to make a useful comparison.
Run a no-camera case and a case where a person has no supported document. Someone can be eligible and still unable to complete a particular method. Decide what the experience will show, how the alternative will be accessed and when the person can contact support. Keep the gate closed while the decision is unresolved. Avoid exposing raw model scores or teaching users how to tune their input to cross the threshold.
Also inspect what comes back after each route. It may be a Boolean decision, an age estimate, an age range or a record that can be retrieved later. Ask which data the vendor, application and support staff retain. A method that collects more than the application needs is a cost even if it is quicker to add to a demo.
Report uncertainty with the decision rates
For each decision rate, report the numerator and denominator and keep the cohort definition beside the result. A sample with three under-threshold users and no false adults is not strong evidence of a low error rate. Small age bands and rare failure modes need enough observations before comparisons can support a deployment decision. Where the sample is limited, describe which error you observed and what remains unresolved.
Keep the trial protocol with the result. A change to the buffer, accepted document or camera settings changes the effective policy even if the model has not changed. A later reader should be able to tell whether a difference comes from the provider, the evidence set or the rules that route users to fallback. Avoid collecting new sensitive samples when existing, approved evaluation material can answer the question.
Keep the threshold test separate from tuning
If a trial lets you adjust the buffer, use one set of approved examples to tune it and a separate set to check the result. Otherwise the same difficult cases that helped select the buffer also make the policy look better than it may be on a new cohort. Freeze the product configuration before the second run. Record the accepted methods, software version and how the fallback was triggered so the result can be compared after an update.
Decide in advance how to handle a missing result. If a device cannot complete capture, record that outcome separately from a prediction error. For the person using the product, either outcome can create a delay, but the remedy is different. The first may need a different device or verification method. The second may call for a different decision threshold or additional evidence. Reporting both prevents a system that returns fewer decisions from looking more accurate simply because its hardest cases were left out.
Review changes to fallback as carefully as changes to the estimate. A new document option can improve completion but can also collect more data or shift work to support. Keep evidence of which route resolved each case, using only the identifiers required by the evaluation. Then compare the full path rather than scoring the estimate and treating the rest of the work as invisible.
Use a small, reproducible trial to choose
Give each candidate the same policy and test conditions. Run a clear pass, a borderline estimate, a rejected attempt, a fallback and an interrupted session. Record the accepted evidence and exact settings, the response fields, and who can see or remove them. The site's editorial policy explains the approach to interpreting published evidence; the operational decision should be based on a record of your own agreed trial.
Shortlist a specialist when the product needs a narrow threshold claim and the supported methods fit. Compare a broader identity provider when the age decision is already part of a well-defined inquiry. An alternative earns its place when it reduces ambiguity at the boundary, keeps an accessible fallback and returns the evidence you need without turning an age gate into an unnecessary identity dossier.