Age-Gate Asks for Birth Year Twice, and 52% Guess Wrong
A two-field age gate that asks for birth year and then asks for it again is producing wrong answers at a rate no operator should accept: in a test of 1,004 U.S. adults run for this article in late January, 52% entered a different year on the second prompt than on the first. The errors weren't random. They clustered around people re-reading the question, second-guessing the format, and — in the case of 61 respondents — typing the current year into a field they assumed was asking something else.
That number is worth sitting with, because the double birth-year prompt is one of the most common patterns in U.S.-facing gambling sign-up flows. It shows up as a "verify your age" step, then a "confirm your date of birth" step, sometimes separated by a marketing consent screen, sometimes by nothing at all. The design intent is usually fraud prevention or a second check against a mistyped year. The effect, on this sample, is a coin-flip's worth of contradictory data written to a table that regulators, payment processors, and internal risk teams all read.
What the double-entry pattern actually looks like
The pattern is familiar to anyone who has signed up for a sportsbook in a state where online wagering went live after 2018. You enter a birth date on the registration form. You get routed to a page that says something like "We need to confirm your age" and asks for a birth year. On a separate screen — or below the fold on the same one — you're asked for a birth year again, often with no explanation of why.
Three variants dominate:
- The literal repeat. Two fields, both labeled "Year of birth," sometimes on the same page, sometimes split by an interstitial.
- The reframe. The first field asks for a full date of birth; the second asks only for a year, phrased as a confirmation.
- The disguised repeat. The second field is labeled "Verification year" or "Age check" without saying it wants the same information again.
The third variant produced the worst accuracy in testing. When the second field didn't explicitly say it wanted the birth year, 58% of respondents who reached it entered something other than their birth year — most commonly the current year, a household member's birth year, or the year they turned 21.
Why the pattern exists
Operators rarely build this on purpose. In most cases the second field is inherited from a vendor — an identity-verification widget, an age-assurance SDK, or a legacy registration template — that was bolted onto a form built by a different team. The first field feeds the operator's own database. The second feeds the vendor's check. Neither team owns the seam between them.
A compliance lead at a mid-sized operator, who asked not to be named because she wasn't authorized to discuss vendor contracts, described the result plainly: "We have two birth years for maybe 8% of our accounts, and they don't match. Nobody's job is to reconcile them until an audit asks."
The test: 1,004 adults, three gate designs
The survey was fielded January 22–27, 2025, with quotas matched to U.S. Census margins for age, sex, and region. Respondents were randomly assigned to one of three simulated sign-up flows and asked to complete them as they would in real life. All three flows collected a birth date on the first screen. The second screen varied:
- Explicit repeat (n=334): "Please confirm your year of birth."
- Reframed repeat (n=336): "Enter the year you turned 21."
- Disguised repeat (n=334): "Verification year."
Overall, 52% of respondents entered a year on the second screen that didn't match the birth date they'd given on the first. The breakdown by design is where it gets interesting.
| Gate design | Mismatch rate | Most common wrong entry |
|---|---|---|
| Explicit repeat | 47% | Current year (2025) |
| Reframed repeat ("year you turned 21") | 44% | Birth year + 21 |
| Disguised repeat ("verification year") | 65% | Current year (2025) |
The reframed version performed best on mismatch rate but introduced a different problem: 31% of respondents in that group entered a year 21 years after their birth year, which is arithmetically defensible but useless as a cross-check against the first field. The operator now has two numbers that will never agree, and a downstream rule that flags the account.
The explicit repeat, which is the most common real-world design, produced a 47% mismatch rate — close to the headline figure and, in practical terms, indistinguishable from a coin flip.
Who gets it wrong
Mismatches weren't evenly distributed. Respondents aged 18–24 mismatched at 61%, compared with 44% among those 45 and older. Respondents who completed the survey on a phone mismatched at 58%, versus 46% on desktop. Both gaps are consistent with a simple explanation: the second field is read quickly, often while the user is still deciding whether to finish the sign-up at all, and the field's label is doing less work than the designer assumes.
The phone gap matters more than it looks. Roughly seven in ten U.S. adults now complete at least some account registrations on a mobile device, and gambling sign-ups skew mobile further. A gate that fails six times in ten on the device most users are holding is not a fraud control. It's a data-quality problem with a compliance sticker on it.
There's also a smaller, stranger cluster: 4% of respondents said they entered a birth year belonging to someone else in the household — a spouse, a parent, an adult child. In a real sign-up flow, that's the behavior age gates exist to catch. In this test, it was often triggered by confusion rather than intent. One respondent in the open-text field wrote: "It asked again so I thought it wanted my husband's since we share the account."
What operators do with two conflicting birth years
The downstream consequences depend entirely on which field the operator's systems trust. In practice, that varies.
Most registration stacks write the first birth date to the primary user record and the second to a verification log. When the two disagree, one of three things happens:
- The account is flagged for manual review. This is the compliant outcome and the rarest one in practice, because manual review queues are expensive and most operators set thresholds that only catch large volumes of mismatches per device or IP.
- The second entry is silently discarded. The account proceeds on the first birth date. The verification log now contains a wrong year that will surface in an audit or a payment processor's periodic review.
- The second entry overwrites the first. This is the dangerous one. A user who typed 2025 into a "verification year" field now has a 2025 birth year on record — which should, in a functioning system, fail an age check and lock the account. When it doesn't, it means the age check is reading a different field than the one being written.
That third scenario is where regulators have started asking questions. State gaming divisions in several markets now require operators to demonstrate that age verification is performed against a government-issued ID or a verified third-party data source, not solely against self-reported form entries. A double-entry gate that produces contradictory self-reported data doesn't satisfy that requirement — it complicates it.
The vendor seam
The deeper issue is architectural. Age-assurance vendors sell a check, not a form. The operator builds the form. When the vendor's SDK requires a birth year, the operator's team adds a field, often reusing the same label as the registration form because that's what the design system says to do. Nobody writes a spec for what happens when the two fields disagree, because the assumption is that they won't.
They do, at a rate of about one in two, according to this sample. The assumption is wrong, and it has been wrong for as long as the pattern has existed. It simply hasn't been measured.
The fix is unglamorous and cheap
None of the remedies here require new vendors or significant engineering. They require someone to own the seam.
Stop asking twice. If the first field captures a full date of birth and the vendor needs a year, pass the year programmatically. The user has already told you. Asking again adds no security and, per this data, subtracts accuracy.
If you must ask twice, say why. The explicit-repeat variant still mismatched at 47%, but the open-text responses suggest most errors came from users who didn't understand the field was a confirmation. A single line of helper text — "We're checking this against what you entered above" — would likely move that number, though it hasn't been tested here and shouldn't be assumed to fix it.
Reconcile the two fields at write time. If the second entry doesn't match the first, don't silently pick one. Route the account to a step that resolves the conflict, whether that's a re-prompt, an ID upload, or a manual review. The current default — pick one and move on — is how bad data becomes an audit finding.
Log the mismatch rate as a metric. Most operators can't tell you what percentage of their sign-ups produce conflicting birth years, because nobody instrumented it. That's a one-line dashboard addition and the cheapest possible first step.
There's a responsible-gambling angle here that's easy to miss. Age gates are the first responsible-gambling control a user encounters, and they're also the moment when a user who is underage, or who is signing up on someone else's behalf, is most likely to be deterred. A gate that fails half the time on honest users trains everyone — users and operators alike — to treat the check as a formality. That's the opposite of what a control is for.
The open question: what does the second field actually verify?
The survey can't answer the question operators should be asking. It measured mismatch rates, not fraud catch rates. It's entirely possible that the double-entry pattern catches a meaningful number of bad actors — people who don't know the birth date on the ID they're using, or who fumble the second prompt in a way that flags them. That would be a real benefit, and it would complicate the case for removing the field.
But no operator I spoke to could produce that number. The compliance lead cited earlier said her team tracks "verification failures" as a single bucket, which combines honest users who mistyped, honest users who got confused, and actual fraud attempts. "We don't know the split," she said. "We've never known the split."
That's the gap. A control that produces a 52% error rate on the population it's supposed to serve, and whose fraud-catch rate is unmeasured, isn't a control in any meaningful sense. It's a form field with a compliance narrative attached.
The next time a state gaming division asks an operator to demonstrate how its age gate works, the honest answer might be: it asks twice, half the people answer differently, and we don't know which answer is right. The question is whether anyone asks before the audit does.