How to Comply with Google Play's New Dating App Age Rules Using eID

Since 28 January 2026, Google Play requires dating apps — alongside real-money gambling apps — to enable the Restrict Declared Minors setting in Play Console, blocking users who are declared to be under 18 from accessing the app. It builds on Google's Child Safety Standards policy, in force since 2025, which already obliges social and dating apps to publish child-safety standards and designate a child-safety point of contact.

If you run a dating app, this is not a policy footnote. It is the moment the app stores stopped treating age as a checkbox — and started treating it as a compliance obligation with distribution consequences. An app that ignores it risks the one penalty no growth team can absorb: removal from the store.

This post explains what the rules actually require, why "declared age" is only the beginning, and how European dating platforms can get ahead of the curve with eID-based age verification — the approach that satisfies regulators without wrecking your signup funnel or your users' privacy.

What Google Play now requires

The January 2026 update has two practical components for dating apps:

1. Restrict Declared Minors. Your app must be configured so that users whose declared age signals indicate they are under 18 cannot use it. Google determines the "declared" age from account-level signals; your job is to enable the restriction and ensure your own onboarding doesn't undermine it.

2. Child Safety Standards compliance. Published safety standards, an in-app feedback mechanism, and a designated child-safety contact — requirements that dating apps have had to meet since the 2025 policy wave.

Notice the word declared. Google's mechanism currently keys off the age a user has stated to their Google account. That is a floor, not a ceiling — and it is exactly where the regulatory story gets bigger than Google.

Why declared age won't be enough for long

A determined 16-year-old with a falsified account age walks straight past a "declared minors" filter. Regulators know this, and the direction of travel across every major market is from declaration to assurance:

• In the UK, Ofcom has classified dating apps as user-to-user services under the Online Safety Act, with an expectation of highly effective age assurance — and fines of up to 10% of global turnover for services that get it wrong.
• In the US, app-store accountability laws — led by Texas — increasingly target dating platforms by name in the name of protecting minors online.
• In the EU, the Commission's minor-protection guidelines under the Digital Services Act, its enforcement proceedings against major platforms, and its new white-label age-verification app all point the same way: self-declaration is over.

For dating apps there is a second, purely commercial reason to care. Romance scams cost consumers over a billion dollars a year in FTC-reported losses alone, with the highest median loss of any imposter fraud. Fake profiles are your churn engine. The same verification that satisfies Google and the regulators is also the strongest trust signal you can put on a profile.

The eID approach: prove "18+, real, unique" — and nothing else

The traditional answer to age assurance is document verification: upload your ID, take a selfie, wait. It works, but it hands your platform a pile of sensitive biometric and identity data (with all the GDPR exposure that implies), and it kills conversion at the worst possible moment — signup.

European eID schemes offer a fundamentally better trade. Users authenticate through an identity they already hold and trust:

• itsme in Belgium — used by the overwhelming majority of Belgian adults.
• iDIN in the Netherlands — age confirmation through the user's own bank login, the same gesture as an iDEAL payment. (itsme owns iDIN, so one integration reaches both markets.)
• BankID, MitID, Smart-ID, Freja and others across the Nordics and Baltics.

The critical design property is selective disclosure, and it is stronger than most people assume. When a dating app requests an 18+ check, iDIN's age-indicator attribute has the bank share only whether the customer is over 18 or not — not the birthdate. itsme's Qualify service confirms thresholds like 18+ without exposing the birthdate or any ID document. The answer is computed at the source — by the bank, or by itsme — and what reaches your platform is a single signed yes or no.

Your platform learns three things — this user is over 18, is a real person, and is a unique individual — and stores none of the underlying identity data. In fact, with these schemes the birth date never reaches you (or us) at all.

That single yes/no unlocks three wins at once:

1. App store and regulatory compliance — a verifiable age check that goes far beyond declared age, with an audit trail you can show Google, Ofcom, or a DSA regulator.
2. Trust and safety — a "Verified" badge backed by a bank-grade check is the hardest possible signal for a scammer to fake, and users know it.
3. Privacy by design — no ID uploads, no biometric database, minimal GDPR surface. This is the same selective-disclosure model the EU Digital Identity Wallet will make standard from late 2026, so you are building toward the future rather than away from it. (We unpack that bridge in Why we're bringing in eID.)

Layered by design — and you set the policy

eID is the first and best layer, but not every user has one — a new resident, a foreign visitor. A privacy-first platform handles that with layered verification, in a deliberate order:

1. eID first (itsme, iDIN, or your market's scheme) — the privacy-optimal path, and the default.
2. Age estimation second, optional — privacy-preserving facial age estimation that estimates age from a selfie without identifying the person and deletes the image immediately. Age assurance, not identification.
3. Document scan last, optional — the most data-heavy option, a genuine last resort.

The layers you switch on are your policy, and the default is strict. Each fallback is opt-in, and the flow is fail-closed: if a user cannot pass a layer you have permitted, verification is refused — never quietly downgraded to a more invasive check to force a result through. A dating platform that runs eID-only literally cannot collect a document or a biometric, even in principle.

And when you do enable estimation or document fallback, the selfie or ID is captured by that specialist provider's own SDK and sent directly to them — it never passes through, or rests on, our servers. eIDAS Pro does not save your users' personal or sensitive data. We hold no names, no birth dates, no document images, no biometrics — only a non-identifying record that a check took place, and when.

Implementation: where the check belongs in your flow

A pattern that works in practice:

Signup stays frictionless. Let users create an account and build a profile exactly as today. Do not gate the front door.

Verify before interaction. Place the eID check as the gate to matching or messaging — the point where a minor could actually come to harm and where your compliance obligation genuinely bites. Users are invested by then, and completion rates are dramatically higher than at signup.

Make verification a reward, not a toll. Verified users get the badge, and unverified profiles get less visibility. You have turned a compliance cost into a growth mechanic: users verify because it gets them more matches.

Keep the audit trail. Log the fact and timestamp of each verification (never the identity data) so you can demonstrate systematic age assurance to any platform or regulator that asks.

A five-point compliance checklist

1. Enable Restrict Declared Minors in Play Console and confirm your Child Safety Standards page and contact are in place.
2. Map where under-18 users could realistically slip through your current onboarding.
3. Add an eID-based 18+ check (itsme, iDIN, or your market's scheme) before matching/messaging.
4. Decide your fallback policy deliberately — eID-only, or eID plus opt-in age estimation — and keep it fail-closed.
5. Turn verification into a product feature: badge, visibility boost, trust messaging.

The bottom line

Google Play's January 2026 rules are the first domino, not the last. The platforms that treat age assurance as a checkbox will retrofit it in a panic when the next regulation lands; the platforms that treat it as a trust feature will grow because of it. eID verification is the rare compliance measure that makes your product better — more real people, fewer scammers, and not a single ID document on your servers.

eIDAS Pro provides eID-based age and identity verification for European platforms — a single API covering itsme, iDIN and other national schemes, with optional privacy-preserving fallbacks, aligned with the upcoming EU Digital Identity Wallet. Book a consultation →

This article is general information, not legal advice. Verify current policy texts with Google Play's official documentation and your counsel.