Every age verification method in production today asks the user to hand something over. A selfie. A photo of their driving license. A scan of their passport. A face for the estimation model. Even open banking — which this blog has covered before — requires a bank login redirect.
Carrier-based age verification asks for nothing. The user’s mobile operator already knows their date of birth, verified during SIM registration or account creation under local telecom regulations. A single API call checks whether the user meets an age threshold and returns a yes-or-no answer. No document leaves the user’s device. No biometric template is created. No redirect interrupts the flow. The check completes in under two seconds, often invisibly.
This is not a theoretical protocol. The GSMA Open Gateway initiative — backed by 85 operator groups representing 300 networks and 81 percent of global mobile connections — has standardized the Age Verification API through the CAMARA open-source project under the Linux Foundation. Telefonica, Vodafone, Deutsche Telekom, Orange, AT&T, Verizon, and dozens more operators are live or in active rollout. TikTok has publicly partnered with Telefonica to integrate the API into its onboarding flow.
For platforms that need to verify age at scale without creating biometric data liabilities, this is the most significant infrastructure shift since Apple and Google introduced their device-level age signals.
How Carrier-Based Age Verification Works
The architecture is simple because the hard work — identity verification — already happened when the user opened their mobile account.
What the User Experiences
In most implementations, the user experiences nothing. The verification happens in the background:
- The user opens your app or website on their mobile device.
- Your platform calls the Age Verification API through your operator aggregator or directly through the carrier’s API gateway.
- The API identifies the user’s mobile operator from their network connection (or from a phone number the user has already provided).
- The operator checks the user’s date of birth against your specified age threshold — for example, “Is this user 18 or older?”
- The operator returns a boolean response:
trueorfalse. - Your platform grants or restricts access accordingly.
The entire flow happens without the user uploading anything, taking a selfie, or leaving your app. On a mobile data connection, the operator can identify the user from the network session itself, making the check completely frictionless.
When the user is on Wi-Fi or when additional confirmation is needed, the API can fall back to a phone number lookup, which requires the user to enter or confirm their mobile number — still far less friction than a document upload.
The Technical Architecture
Under the hood, the CAMARA Age Verification API follows a standard OIDC/OAuth 2.0 authorization pattern:
- API request: Your backend sends a POST request to the operator’s API endpoint (or through an aggregator) with the phone number or network token and the age threshold to check.
- Operator lookup: The operator resolves the user’s identity from their subscriber database — the same system used for billing, SIM provisioning, and regulatory compliance.
- Age threshold check: The operator compares the stored date of birth against the requested threshold. No date of birth is transmitted — only the boolean result.
- Signed response: The operator returns a cryptographically signed response confirming whether the user meets the age threshold, along with a confidence indicator.
Here’s a simplified request and response:
// Request
POST /age-verification/v0/verify
{
"phoneNumber": "+44712345678",
"ageThreshold": 18
}
// Response
{
"verified": true,
"verificationTimestamp": "2026-05-27T14:30:00Z"
}The critical property: no personal data transits your infrastructure. The operator already holds KYC-verified identity data, collected under telecom regulations that in many jurisdictions require proof of identity at point of sale. Your platform receives only a boolean — the minimum data necessary to make an access decision.
Why This Matters Now
Three forces are converging to make carrier-based verification the fastest-growing method in the age assurance stack.
The Regulatory Squeeze on Biometric Data
Every jurisdiction tightening age verification requirements is simultaneously tightening biometric data regulation. The EU AI Act classifies facial recognition as high-risk. Illinois’ BIPA imposes per-violation penalties for biometric data collection without consent. The UK’s ICO has signaled that facial age estimation systems must demonstrate strict necessity and proportionality.
Carrier-based verification sidesteps this entirely. No biometric data is collected, processed, or stored — by anyone in the chain. For platforms operating across jurisdictions, this eliminates an entire category of compliance risk.
The Scale Problem
Roblox mandated facial age estimation for all users in January 2026 and achieved 45 percent verification within a month — an impressive adoption rate. But it also generated significant user backlash, bypass attempts trending on social media, and ongoing questions about the accuracy of facial age estimation for younger demographics.
Carrier-based verification scales without friction because it doesn’t require the user to do anything new. If you have their phone number or they’re on a mobile data connection, you have what you need. There’s no camera permission to request, no selfie to retake, no lighting conditions to worry about.
Operator Coverage Is Now Global
The GSMA Open Gateway initiative has reached critical mass. As of early 2026, the participating operators cover:
- Europe: Vodafone, Deutsche Telekom, Orange, Telefonica, Swisscom, TIM, Telenor
- North America: AT&T, Verizon, T-Mobile
- Asia-Pacific: Singtel, KDDI, KT, Bharti Airtel, Telstra, Reliance Jio
- Middle East and Africa: e& Group, STC, MTN
- Latin America: America Movil, Telefonica
Through Aduna — the joint venture bringing together AT&T, Deutsche Telekom, Orange, Vodafone, and others — developers can access multiple operator networks through a single API integration. This means a platform can verify users across dozens of countries without building separate integrations for each carrier.
Where Carrier-Based Verification Fits in Your Stack
Carrier-based age verification is powerful but not universal. It works best as part of a layered verification strategy, not as a standalone solution.
When It Excels
- Mobile-first platforms: Apps where users are already on mobile data connections benefit from completely invisible verification.
- High-volume, low-friction flows: Social media sign-ups, content access gates, and in-app purchase restrictions where any friction causes drop-off.
- Privacy-sensitive markets: Jurisdictions with strict biometric data laws (EU, UK, Illinois, Texas) where document or facial verification creates compliance overhead.
- Returning user re-verification: Periodic age re-checks where asking for a fresh document upload would frustrate users.
Where It Falls Short
- Desktop-only users: Without a mobile data connection, the API needs a phone number, adding a step.
- Prepaid SIMs without KYC: In markets where prepaid SIM cards don’t require identity verification at purchase, operator data may be incomplete or missing.
- Users without mobile subscriptions: A shrinking but non-zero population, particularly among younger users sharing family plans.
- High-assurance scenarios: Regulatory frameworks that require document-level verification (e.g., online gambling KYC in some jurisdictions) may not accept carrier-based checks alone.
The Multi-Method Approach
The most robust implementations use carrier-based verification as the first layer in a tiered system:
- Tier 1 — Carrier API: Check the user’s age via their mobile operator. If confirmed, grant access immediately. This handles the majority of mobile users with zero friction.
- Tier 2 — Device-level signals: For users where carrier verification is unavailable, fall back to Apple’s Declared Age Range API or Google’s Play Age Signals — probabilistic but frictionless.
- Tier 3 — Document or biometric verification: For users who can’t be verified through network or device signals, offer document upload, facial age estimation, or open banking as fallback options.
This layered approach maximizes the percentage of users verified without friction while ensuring no one falls through the gaps. In practice, platforms using this architecture report verification rates above 95 percent with completion rates 30 to 40 percent higher than document-only flows.
Privacy Architecture: What Data Goes Where
The privacy properties of carrier-based verification are among the strongest in the age assurance space.
Data Minimization by Design
The operator already holds the user’s date of birth as part of their subscriber record. The Age Verification API doesn’t transmit this date of birth — it only answers a threshold question. This is data minimization in its purest form: the minimum information necessary to fulfill the purpose.
Compare this to other methods:
| Method | Data Collected by Verifier | Data Stored | Biometric Processing |
|---|---|---|---|
| Document upload | Name, DOB, document number, photo | Image + extracted data | Optional (face match) |
| Facial age estimation | Facial image/video | Biometric template | Yes |
| Open banking | Bank login session (redirected) | Boolean result | No |
| Carrier API | Phone number or network token | Boolean result | No |
Carrier-based verification collects the least data and requires the least processing. The phone number (if used) is already known to the platform in most cases — it’s the user’s login credential or account identifier.
GDPR and Data Protection Compliance
Under GDPR, the carrier-based approach maps cleanly to the principle of purpose limitation. The phone number is processed for the sole purpose of age verification. The operator acts as a data controller for the subscriber data and as a processor for the age check. No special-category data (biometric data under Article 9) is involved.
For platforms, this means:
- No Data Protection Impact Assessment (DPIA) for biometric processing.
- No biometric consent flows to build.
- No biometric data retention and deletion policies to maintain.
- Simpler data processing agreements with your verification provider.
Integration Patterns
Direct Operator Integration
For platforms with specific geographic focus, direct integration with individual operators provides the most control. Telefonica’s Open Gateway developer portal, Vodafone’s Developer Marketplace, and Orange’s developer platform all expose the CAMARA Age Verification API with standard REST endpoints.
Aggregator Integration
For global reach, aggregator platforms like Aduna, Vonage (part of Ericsson), and other GSMA-certified aggregators provide a single API endpoint that routes to the appropriate operator based on the user’s network or phone number. This is the recommended approach for platforms operating in multiple markets.
Hybrid Integration with Existing Verification
If you already use a verification provider for document or biometric checks, carrier-based verification slots in as an additional method. The typical pattern:
User arrives → Check if on mobile data
├─ Yes → Call Carrier Age Verification API
│ ├─ Verified → Grant access
│ └─ Not verified / unavailable → Fall back to existing flow
└─ No → Check if phone number available
├─ Yes → Call Carrier API with phone number
│ ├─ Verified → Grant access
│ └─ Not verified → Fall back to existing flow
└─ No → Use document/biometric/banking verificationThis progressive approach means you never force a heavier verification method on a user who can be verified through their carrier.
Limitations and Honest Trade-offs
Carrier-based verification is not a silver bullet. Platform teams should understand the constraints before relying on it.
Accuracy Depends on Operator KYC Quality
The verification is only as accurate as the data the operator collected at sign-up. In markets with strict SIM registration requirements (EU, UK, Australia, India), operator data is highly reliable. In markets with lax prepaid SIM regulation or where SIMs can be purchased without identity verification, the data may be incomplete.
Before deploying, audit the KYC requirements in your target markets. If your user base is heavily concentrated in markets with weak SIM registration laws, carrier-based verification may not provide sufficient assurance on its own.
Coverage Gaps Are Real
Not every operator has deployed the CAMARA API yet. While 85 operator groups have signed the GSMA Open Gateway MoU, commercial availability varies by market and by specific API. A user on a smaller MVNO (mobile virtual network operator) may not be reachable through the API even if the underlying network operator supports it.
Plan for graceful fallback. Your UX should never dead-end a user because their carrier doesn’t support the API — it should silently route them to an alternative verification method.
The Wi-Fi Problem
When users are on Wi-Fi, the operator can’t identify them from the network session alone. The API then requires the user’s phone number, which adds a step. For mobile apps that already have the user’s phone number (most do), this is seamless. For web-based platforms where you don’t have a phone number, you’ll need to either collect one or skip to a different method.
Not Suitable for High-Assurance KYC
For regulated industries that require full identity verification — not just age verification — carrier-based checks are insufficient. Online gambling platforms in the UK, for example, need to verify name, address, and source of funds. Carrier-based verification confirms age but not identity. It’s a complement to KYC, not a replacement.
What’s Coming Next
The GSMA and CAMARA project continue to expand the API surface. Several developments are worth watching:
Know Your Customer (Full)
Beyond age verification, the CAMARA project is developing a broader Know Your Customer API that can verify name, address, and phone number against operator records. This would expand the use cases from age-only checks to light-touch identity verification.
Number Verification API
The companion Number Verification API confirms that a user actually controls the phone number they claim to have, using a cryptographic challenge through the mobile network. Combined with age verification, this creates a two-factor confirmation: the user is who they say they are, and they’re old enough.
Regulatory Recognition
As ISO/IEC 27566-1 (the international age assurance standard) and IEEE 2089.1 gain adoption, carrier-based verification is being included as a recognized method in regulatory guidance. Ofcom’s age assurance framework already acknowledges operator-verified data as a potential source. Expect more regulators to follow.
The Bottom Line
Carrier-based age verification through the GSMA Open Gateway is not going to replace document verification or biometric age estimation entirely. But for the majority of mobile users in the majority of markets, it can resolve the age question instantly, invisibly, and without collecting any sensitive personal data.
The platforms that integrate it first will see measurable improvements in verification completion rates and measurable reductions in data protection compliance burden. The ones that wait will eventually be asked by regulators why they’re collecting biometric data when a less invasive method was available.
The API is live. The operators are connected. The standard is published. The question isn’t whether carrier-based age verification will become mainstream — it’s whether your platform will adopt it before your competitors do.
Xident supports carrier-based age verification alongside document verification, facial age estimation, NFC chip reading, and open banking — giving your users the fastest path to verified access while keeping you compliant across every jurisdiction. Start integrating today.
