The situation
Regulators across several jurisdictions introduced age assurance obligations on different timelines with different definitions of adequate. Each one, read alone, implied a different implementation. Read together, they implied an architecture.
The actual problem
The request was
“Get us compliant in these markets by the deadlines.”
Discovery showed
Compliance per market would have produced a stack of one-off integrations, each collecting more personal data than necessary and each degrading signup in a different way.
The durable answer was a single assurance model with market-configurable strictness, meeting the strictest requirement structurally while minimizing data collected and friction imposed everywhere else.
What I learned
- Compared obligations across markets to find the shared structural requirements underneath different wordings.
- Evaluated assurance vendors on accuracy, data minimization, accessibility, and regional coverage.
- Modeled signup friction and drop-off against each assurance method.
How I framed it
Exhibit
Assurance Method Decision Matrix
- 01
Self-declaration
- Certainty
- Low
- Data collected
- Minimal
- Friction
- None
- Accepted where
- Lowest-risk contexts
- 02
Behavioral / inference signals
- Certainty
- Moderate
- Data collected
- Existing only
- Friction
- None
- Accepted where
- Supplementary
- 03
Third-party estimation
- Certainty
- High
- Data collected
- Transient biometric
- Friction
- Low
- Accepted where
- Several markets
- 04
Document verification
- Certainty
- Highest
- Data collected
- Sensitive ID
- Friction
- High
- Accepted where
- Strictest regimes
| Certainty | Data collected | Friction | Accepted where | |
|---|---|---|---|---|
| 01Self-declaration | Low | Minimal | None | Lowest-risk contexts |
| 02Behavioral / inference signals | Moderate | Existing only | None | Supplementary |
| 03Third-party estimation | High | Transient biometric | Low | Several markets |
| 04Document verification | Highest | Sensitive ID | High | Strictest regimes |
Escalate strictness only when the market or the risk demands it. Never collect a tier more than needed.
What we built
- 01A single age-assurance model with market-configurable strictness.
- 02A vendor and method decision framework balancing certainty, data minimization, and friction.
- 03Implementation sequencing tied to regulatory deadlines by market.
My role
- Product
- Owned the assurance experience and its strictness model.
- Regulatory
- Translated obligations across markets into product requirements.
- Vendor & risk
- Led evaluation and the data-minimization position.
The outcome
- One architecture serving multiple regimes instead of per-market bolt-ons.
- Data collection held to the minimum each market genuinely required.
- Regulatory deadlines met without a punitive signup experience.
What I'd do differently
Regulation reads like a constraint and behaves like a product brief. Treating it that way earlier in the process would have gotten design involved sooner, and design is what kept the strictest path from feeling like a punishment.