Google Plays neue Altersregeln für Dating-Apps mit eID erfüllen

Seit dem 28. Januar 2026 verlangt Google Play von Dating-Apps, ebenso wie von Echtgeld-Glücksspiel-Apps, die Einstellung Restrict Declared Minors in der Play Console zu aktivieren. Dadurch werden Nutzer, die als unter 18 Jahre alt deklariert sind, vom Zugriff auf die App ausgeschlossen. Die Vorgabe baut auf Googles Child Safety Standards Policy auf, die seit 2025 gilt und Social- sowie Dating-Apps bereits verpflichtet, Kinderschutzstandards zu veröffentlichen und einen Kinderschutzkontakt zu benennen.

Wer eine Dating-App betreibt, sollte das nicht als Randnotiz in einer Plattformrichtlinie lesen. Es ist der Moment, in dem App Stores Alter nicht länger als Checkbox behandeln, sondern als Compliance-Pflicht mit unmittelbaren Folgen für die Distribution. Eine App, die diese Pflicht ignoriert, riskiert die eine Strafe, die kein Growth-Team verkraftet: die Entfernung aus dem Store.

Dieser Beitrag erklärt, was die Regeln tatsächlich verlangen, warum das „deklarierte Alter“ nur der Anfang ist und wie europäische Dating-Plattformen mit eID-basierter Altersverifikation vor die Kurve kommen: einem Ansatz, der Regulierer überzeugt, ohne den Signup-Funnel oder die Privatsphäre der Nutzer zu beschädigen.

Was Google Play jetzt verlangt

Das Update von Januar 2026 hat für Dating-Apps zwei praktische Komponenten:

1. Restrict Declared Minors. Ihre App muss so konfiguriert sein, dass Nutzer sie nicht verwenden können, wenn ihre deklarierten Alterssignale auf unter 18 Jahre hinweisen. Google bestimmt das „deklarierte“ Alter aus Signalen auf Kontoebene; Ihre Aufgabe ist es, die Einschränkung zu aktivieren und sicherzustellen, dass Ihr eigenes Onboarding sie nicht unterläuft.

2. Compliance mit den Child Safety Standards. Veröffentlichte Sicherheitsstandards, ein Feedback-Mechanismus in der App und ein benannter Kinderschutzkontakt: Anforderungen, die Dating-Apps bereits seit der Richtlinienwelle 2025 erfüllen müssen.

Entscheidend ist das Wort deklariert. Googles Mechanismus stützt sich aktuell auf das Alter, das ein Nutzer in seinem Google-Konto angegeben hat. Das ist eine Untergrenze, keine Obergrenze, und genau dort wird die regulatorische Geschichte größer als Google selbst.

Warum deklariertes Alter nicht lange reichen wird

Ein entschlossener 16-Jähriger mit gefälschtem Kontoalter kommt an einem Filter für „deklarierte Minderjährige“ direkt vorbei. Regulierer wissen das, und die Richtung ist in allen großen Märkten dieselbe: weg von der Selbstauskunft, hin zur Assurance.

• Im Vereinigten Königreich stuft Ofcom Dating-Apps unter dem Online Safety Act als User-to-User-Dienste ein, mit der Erwartung einer hochwirksamen Altersabsicherung und Bußgeldern von bis zu 10 % des weltweiten Umsatzes für Dienste, die scheitern.
• In den USA zielen App-Store-Accountability-Gesetze, angeführt von Texas, im Namen des Online-Schutzes Minderjähriger zunehmend ausdrücklich auf Dating-Plattformen.
• In der EU zeigen die Leitlinien der Kommission zum Minderjährigenschutz unter dem Digital Services Act, ihre Durchsetzungsverfahren gegen große Plattformen und ihre neue White-Label-App zur Altersverifikation alle in dieselbe Richtung: Selbstdeklaration hat ausgedient.

Für Dating-Apps gibt es zusätzlich einen rein wirtschaftlichen Grund, aufmerksam zu sein. Romance Scams kosten Verbraucher allein in den bei der FTC gemeldeten Fällen mehr als eine Milliarde Dollar pro Jahr und weisen den höchsten Medianverlust aller Imposter-Betrugsarten auf. Fake-Profile sind Ihr Churn-Motor. Dieselbe Verifikation, die Google und Regulierer zufriedenstellt, ist zugleich das stärkste Vertrauenssignal, das Sie auf ein Profil setzen können.

Der eID-Ansatz: „18+, echt, eindeutig“ beweisen — und nichts weiter

Die klassische Antwort auf Altersabsicherung lautet Dokumentenprüfung: Ausweis hochladen, Selfie machen, warten. Das funktioniert, legt Ihrer Plattform aber einen Stapel sensibler biometrischer und Identitätsdaten auf den Tisch, samt der DSGVO-Exponierung, die daraus folgt. Und es tötet Conversion im schlechtesten Moment: beim Signup.

Europäische eID-Systeme bieten einen grundlegend besseren Tausch. Nutzer authentifizieren sich über eine Identität, die sie bereits besitzen und der sie vertrauen:

• itsme in Belgien, genutzt von der überwältigenden Mehrheit der belgischen Erwachsenen.
• iDIN in den Niederlanden, mit Altersbestätigung über den eigenen Bank-Login des Nutzers, derselbe Handgriff wie bei einer iDEAL-Zahlung. (itsme besitzt iDIN, eine Integration erreicht also beide Märkte.)
• BankID, MitID, Smart-ID, Freja und weitere Systeme in den nordischen und baltischen Ländern.

Die zentrale Designeigenschaft ist selektive Offenlegung, und sie ist stärker, als viele annehmen. Wenn eine Dating-App einen 18+-Check anfordert, teilt die Bank über das Altersindikator-Attribut von iDIN nur mit, ob der Kunde über 18 ist oder nicht, nicht das Geburtsdatum. Der Qualify-Dienst von itsme bestätigt Schwellen wie 18+, ohne das Geburtsdatum oder ein Ausweisdokument offenzulegen. Die Antwort wird an der Quelle berechnet, von der Bank oder von itsme, und bei Ihrer Plattform kommt nur ein signiertes Ja oder Nein an.

Ihre Plattform erfährt drei Dinge: Dieser Nutzer ist über 18, ist eine echte Person und ist eine eindeutige Person. Sie speichert keine der zugrunde liegenden Identitätsdaten. Bei diesen Systemen erreicht das Geburtsdatum weder Sie noch uns.

Dieses eine Ja/Nein bringt drei Vorteile auf einmal:

1. App-Store- und regulatorische Compliance: eine nachweisbare Altersprüfung, die weit über deklariertes Alter hinausgeht, mit einem Audit-Trail, den Sie Google, Ofcom oder einer DSA-Behörde zeigen können.
2. Trust & Safety: Ein „Verifiziert“-Badge auf Basis einer bankstarken Prüfung ist für Betrüger das am schwersten zu fälschende Signal, und Nutzer verstehen es.
3. Privacy by Design: keine Ausweis-Uploads, keine biometrische Datenbank, minimale DSGVO-Oberfläche. Das ist dasselbe Modell selektiver Offenlegung, das die EU Digital Identity Wallet ab Ende 2026 zum Standard machen wird. Sie bauen also in Richtung Zukunft, nicht von ihr weg. (Diese Brücke erklären wir in Warum wir eID integrieren.)

Schichtweise gedacht — und die Policy bestimmen Sie

eID ist die erste und beste Schicht, aber nicht jeder Nutzer hat eine: neue Einwohner, ausländische Besucher, Randfälle. Eine datenschutzorientierte Plattform löst das mit geschichteter Verifikation, in einer bewussten Reihenfolge:

1. eID zuerst (itsme, iDIN oder das System Ihres Marktes): der datenschutzoptimale Weg und der Standard.
2. Alterschätzung danach, optional: datensparsame Gesichtsaltersschätzung, die aus einem Selfie das Alter schätzt, ohne die Person zu identifizieren, und das Bild sofort löscht. Altersabsicherung, keine Identifizierung.
3. Dokumentenscan zuletzt, optional: die datenintensivste Option, wirklich nur als letzter Ausweg.

Welche Schichten Sie aktivieren, ist Ihre Policy, und der Standard ist streng. Jeder Fallback ist opt-in, und der Flow ist fail-closed: Wenn ein Nutzer eine von Ihnen erlaubte Schicht nicht besteht, wird die Verifikation abgelehnt. Sie wird nie still auf eine invasivere Prüfung heruntergestuft, nur um doch noch ein Ergebnis zu erzwingen. Eine Dating-Plattform, die eID-only betreibt, kann buchstäblich kein Dokument und keine Biometrie erfassen, nicht einmal im Prinzip.

Und wenn Sie Altersabschätzung oder Dokumenten-Fallback aktivieren, wird das Selfie oder der Ausweis vom SDK des spezialisierten Anbieters selbst erfasst und direkt an diesen Anbieter gesendet. Es läuft nicht über unsere Server und liegt dort auch nie. eIDAS Pro speichert keine persönlichen oder sensiblen Daten Ihrer Nutzer. Wir speichern keine Namen, keine Geburtsdaten, keine Dokumentbilder, keine Biometrie, sondern nur einen nicht identifizierenden Eintrag, dass eine Prüfung stattgefunden hat, und wann.

Implementierung: Wo der Check in Ihren Flow gehört

Ein Muster funktioniert in der Praxis besonders gut:

Der Signup bleibt reibungsarm. Lassen Sie Nutzer wie bisher ein Konto anlegen und ein Profil erstellen. Sperren Sie nicht die Eingangstür.

Verifizieren Sie vor der Interaktion. Setzen Sie den eID-Check als Gate vor Matching oder Messaging, also an den Punkt, an dem Minderjährigen tatsächlich Schaden entstehen könnte und an dem Ihre Compliance-Pflicht praktisch greift. Nutzer sind dann bereits investiert, und die Abschlussraten sind deutlich höher als beim Signup.

Machen Sie Verifikation zur Belohnung, nicht zur Mautstelle. Verifizierte Nutzer erhalten ein Badge, unverifizierte Profile bekommen weniger Sichtbarkeit. So wird aus Compliance-Kosten ein Growth-Mechanismus: Nutzer verifizieren sich, weil sie mehr Matches erhalten.

Bewahren Sie den Audit-Trail auf. Protokollieren Sie Fakt und Zeitstempel jeder Verifikation, niemals die Identitätsdaten, damit Sie gegenüber jeder Plattform oder Behörde systematische Altersabsicherung nachweisen können.

Eine Compliance-Checkliste in fünf Punkten

1. Aktivieren Sie Restrict Declared Minors in der Play Console und prüfen Sie, dass Ihre Child-Safety-Standards-Seite und der Kontakt eingerichtet sind.
2. Kartieren Sie, wo unter 18-Jährige realistisch durch Ihr aktuelles Onboarding rutschen könnten.
3. Fügen Sie einen eID-basierten 18+-Check (itsme, iDIN oder das System Ihres Marktes) vor Matching oder Messaging ein.
4. Entscheiden Sie Ihre Fallback-Policy bewusst: eID-only oder eID plus optionale Altersabschätzung, und halten Sie den Flow fail-closed.
5. Machen Sie Verifikation zu einem Produktfeature: Badge, Sichtbarkeitsboost, Trust-Messaging.

Unterm Strich

Google Plays Regeln von Januar 2026 sind der erste Dominostein, nicht der letzte. Plattformen, die Altersabsicherung als Checkbox behandeln, werden sie panisch nachrüsten, wenn die nächste Regulierung kommt. Plattformen, die sie als Vertrauensfunktion behandeln, werden daran wachsen. eID-Verifikation ist eine seltene Compliance-Maßnahme, die Ihr Produkt besser macht: mehr echte Menschen, weniger Betrüger und kein einziges Ausweisdokument auf Ihren Servern.

eIDAS Pro bietet eID-basierte Alters- und Identitätsverifikation für europäische Plattformen: eine einzige API für itsme, iDIN und andere nationale Systeme, mit optionalen datensparsamen Fallbacks und ausgerichtet auf die kommende EU Digital Identity Wallet. Beratung buchen →

Dieser Artikel dient der allgemeinen Information und ist keine Rechtsberatung. Prüfen Sie die aktuellen Richtlinientexte in der offiziellen Dokumentation von Google Play und mit Ihrer Rechtsberatung.