An 18+ Button Can Quietly Demand That Your Face Look 25

The concrete object in this audit is Yoti’s Challenge 25 configuration: a platform selling or showing something restricted to adults can set facial age estimation to pass only people estimated to be 25 or older, even when the legal threshold is 18. The buffer is meant to reduce the chance that a child who looks older slips through.

It also means an adult can be old enough and still fail.

That gap between the rule and the machine’s threshold is where age assurance becomes more than a neutral check. The vendor supplies a score, status or age band. The platform turns that output into access, rejection or a demand for more evidence. If the first method fails, you may be invited to upload a government ID, expose a longer trail of account history or leave.

This roundup compares public documentation from Yoti, Persona and VerifyMy. They represent three common approaches: estimating age from a face, checking identity documents and inferring age from an email address’s digital history. This is not legal advice, and a product page is not a contract. It is an audit of what these companies tell customers and users before their systems decide who counts as an adult online.

Yoti measures a face, then the platform makes the decision

Yoti’s facial age estimation analyzes an image and returns an estimated age without trying to identify the person. The company says its system does not compare the face against an identity database and that the image used for the estimate is deleted after processing. That is a narrower data exchange than an ID check. A face still has to reach Yoti’s system, but the advertised output concerns age rather than name, address or document number.

The Challenge 25 setting shows how error handling works before any person complains. Instead of treating 18 as the pass line, the platform raises the machine threshold to create a safety margin. Someone estimated at 23 fails an 18+ gate even if they are 27. From the buyer’s perspective, that is the point: false rejections are easier to push into a fallback flow than false approvals are to explain to a regulator.

Yoti publishes testing material that breaks performance down across age ranges and demographic categories. Its reports use measures including mean absolute error, the average distance between estimated and known ages in a test set. That is useful evidence. It does not tell an individual why this particular image produced this particular result, nor does an average disclose how many people landed on the wrong side of a platform’s chosen threshold.

The distinction matters. An estimate can be statistically strong while the access decision built on it remains harsh, especially near the cutoff. Lighting, image quality and presentation can trigger retries; apparent age varies among people who share a chronological age. The system does not need to identify you to misclassify you.

Yoti documents fallback methods, which can include proving age through an identity document or another supported route. That is error handling, but it is not necessarily an appeal. A retry asks the machine to look again. A fallback asks you to submit different evidence.

An appeal asks a decision-maker to reconsider the denial. Public product documentation is much clearer on the first two.

The Challenge 25 configuration therefore gives the platform a convenient arrangement. It can advertise a privacy-preserving face check, set a conservative threshold and route rejected adults toward a more revealing method. Yoti’s deletion claim limits one layer of retention. It does not decide what the platform logs about the attempt, whether the failure becomes an account signal or how long the final pass-or-fail result survives.

Persona turns an age gate into an identity workflow

Persona’s government ID tools occupy the heavier end of the market. A customer can configure an inquiry that requests a document image, extracts information, checks the document and, where selected, compares it with a selfie. Persona then returns statuses and verification results to the business running the gate.

This route can establish age from a birth date rather than estimating it from appearance. It also creates a richer record. A passport or driver’s license contains details that an adult-content site, social platform or marketplace does not need merely to learn that someone is over 18. Persona lets businesses configure what they collect and how their workflows respond, which makes its documentation revealing in a different way: the vendor has built the controls, but the customer chooses many of the consequential settings.

Retention follows that division. Persona’s documentation describes configurable data-retention and deletion tools, while its privacy materials explain that it processes information for the business using Persona and may retain data according to that relationship, applicable requirements and the customer’s instructions. The important answer is therefore not a universal number. It is a contract and a dashboard setting that most users will never see.

This is where the words controller and processor matter. A controller decides why and how personal data will be used; a processor handles it on the controller’s instructions. The labels vary by product and jurisdiction, but in a typical outsourced check the platform remains responsible for choosing the purpose and acting on the result, even though the vendor operates the verification machinery.

Persona gives customers structured failure information and workflow branches. A document can be unreadable, unsupported, expired, inconsistent or rejected by a configured check. That helps the platform diagnose a failed inquiry. It does not guarantee the user a meaningful explanation, human review or restoration of an account that was locked after the failure.

An appeal exists only if the platform builds one. Persona can support retries and additional verification steps, but its customer-facing tools do not convert those steps into due process by themselves. The person at the gate may see a generic failure message while the business sees detailed reason codes. The asymmetry is functional.

The paying customer gets operational clarity; the person surrendering the document gets whatever explanation the customer has chosen to expose.

Compared with the Challenge 25 face check, Persona’s ID route reduces uncertainty about birth date while increasing the stakes of storage and breach. The trade is not hidden. It is merely presented as a smooth fallback button.

VerifyMy asks an email address to carry your age

VerifyMy markets an Email Address Age Estimation option that lets a platform assess whether an email is associated with an adult, without requiring a face or government document at the first step. This belongs to the broader family of inference systems that use account history and digital signals as proxies for age.

The appeal is obvious. Typing an email address feels ordinary. There is no passport on the screen, no face scan and less visible friction at checkout or account creation. Yet the low-friction interface hides the evidentiary chain.

The user generally cannot inspect which associations made the address look adult, which missing history counted against it or whether a shared, new or privacy-focused account weakened the result.

VerifyMy’s public product material emphasizes coverage, conversion and privacy-conscious verification. It offers businesses multiple methods and fallback routes. Its public-facing explanation of email estimation is thinner on individual error diagnosis than Persona’s documentation for document failures or Yoti’s published model testing. That difference is structural.

A document can fail for a legible reason. A face estimate can be benchmarked against known ages. A digital-footprint inference may depend on signals the user neither supplied for this purpose nor has a practical way to correct.

Retention is harder to read for the same reason. The platform has the email already. VerifyMy and any supporting data providers may process signals to return an age result, while contractual privacy terms determine what each party stores. A promise that the method avoids collecting an ID does not answer whether the platform keeps the score, the method used, the failure, the retry history or the fact that the address could not be confidently classified.

Error handling again favors substitution over explanation. If the email method cannot establish adulthood, the platform can offer another route. That may rescue the transaction, but it leaves the original inference intact and unexplained. A person with little account history, several compartmentalized addresses or an email shared within a household may be pushed toward an ID check precisely because they minimized their digital trail.

Return to the Challenge 25 gate. Facial estimation overcompensates by raising the visible-age threshold. Email estimation overcompensates through confidence rules that remain largely invisible to the person being classified. ID verification overcompensates by collecting authoritative evidence.

Each system manages uncertainty by shifting a different cost onto the user: rejection, opacity or disclosure.

The documentation stops where accountability should begin

Vendor documentation is written for two audiences with unequal power. The platform buyer needs integration instructions, result codes, retention controls and a way to keep users moving. The person being checked needs to know what happened, what remains stored and how to challenge a wrong result. The first audience gets a dashboard.

The second usually gets a retry button.

Some documents carry more weight than others. Marketing pages describe the product but rarely bind every deployment. Privacy notices make public commitments, although the platform’s own notice and the vendor contract may allocate responsibilities differently. Data-processing agreements can impose deletion, security and audit duties between companies.

None of those documents automatically creates a usable appeal inside the product.

A credible age gate would show the method used, disclose whether the platform retained the attempt, separate a technical retry from an appeal and offer a route that does not punish users for refusing the most intrusive option. It would also tell an adult rejected by Challenge 25 that the system did not determine they were a child. It determined that their face did not clear a deliberately higher machine threshold.

That sentence is less convenient than a red failure screen. It is also the truth.

Questions people ask

Does facial age estimation identify you?

Yoti says its facial age estimation predicts age without identifying the person or matching the image against an identity database, and that it deletes the image after processing. The platform may still retain the result, attempt history or account action, so the vendor’s image-deletion promise does not describe the whole data trail.

Is uploading an ID more accurate than a face scan?

An authentic ID can provide a recorded birth date instead of an estimate, but the check may collect document images, identifying details and a selfie. Accuracy about age therefore comes with a larger privacy and security exposure, while failed authenticity or face-matching checks can still block a legitimate adult.

Can someone appeal a failed age check?

Only if the platform offers an appeal. Vendor tools commonly support retries, alternate methods and reason codes for business customers, but those are not the same as independent human review. Public documentation often leaves the final explanation and reversal process to the platform that bought the service.

Which age-assurance method stores the least data?

A facial estimate that deletes the image can disclose less than a full ID check, but the answer depends on what the platform logs and retains. Email-based inference avoids a document while drawing on a less visible signal chain. The least intrusive screen can still feed a durable account decision.