Autor

Max Nikolas Mischa Hortmann ist Rechtsanwalt in Frankfurt am Main, Gründer von Hortmann Law und Vertragsautor bei juris. Er ist spezialisiert auf Plattformhaftung, digitale Organisationspflichten und die rechtliche Architektur datengetriebener Geschäftsmodelle – insbesondere dort, wo Produktentscheidungen (Matching, Sichtbarkeit, Monetarisierung, Coins/Token) in Haftungs-, Regulierungs- und Organrisiken umschlagen.

Dating-App rechtssicher eröffnen

Monetarisierung, Coins/Token, Holding, Steuern, DSGVO & DSA – ein juristisches Mutterschiff für Entwickler

Vorbemerkung

Dieser Beitrag ist ein strategischer Überblick und ersetzt keine individuelle Rechtsberatung, weil Strukturfragen (insbesondere Coins/Token, Payment, Internationalisierung, Targeting, Inhalte) stark vom konkreten Produkt abhängen. Er ist aber so geschrieben, dass Entwickler und Gründer die entscheidenden juristischen Entscheidungspunkteverstehen – und erkennen, wo professionelle Begleitung Mandatswert hat.

1. Warum Dating-Plattformen rechtlich anders sind als „normale Apps“

Eine Dating-App ist nicht nur Software, sondern eine Interaktionsinfrastruktur, die Identität, Kommunikation, Sichtbarkeit und Monetarisierung in einem System bündelt. Genau diese Bündelung macht sie rechtlich besonders: Sie verarbeitet sensible Lebensrealitäten, sie steuert Reichweite algorithmisch, sie lebt von Vertrauen, und sie ist naturgemäß missbrauchsanfällig (Fake‑Identitäten, Romance‑Fraud, Social Engineering, Erpressung, Scraping).

Für Herausgeber ist entscheidend: Das Haftungsrisiko entsteht selten dadurch, dass „ein Nutzer etwas tut“, sondern dadurch, dass das System so gebaut ist, dass Risiken vorhersehbar und skalierbar werden – und dann ohne angemessene Gegenarchitektur weiterlaufen. Das ist keine moralische Kategorie, sondern eine juristische: Organisationspflichten, Sicherheitsniveau, Governance‑Pflichten, DSA‑Prozessanforderungen und – bei Monetarisierung – die Frage, ob Sie faktisch Erfolg verkaufen oder Zugang.

2. Die erste Grundentscheidung: Was ist Ihr Produkt – technisch und rechtlich?

Entwickler denken in Features. Juristen müssen daraus eine belastbare Leistungsbeschreibung ableiten. Das ist nicht „Marketing“, sondern die Definition dessen, was später als vertraglich geschuldete Beschaffenheit oder als objektive Erwartung an digitale Leistungen bewertet wird.

Typischerweise besteht das Produkt aus drei Ebenen:

Erstens: Core‑Service (Registrierung, Profile, Matching, Chat).
Zweitens: Visibility‑Layer (Boosts, Super‑Likes, Priorisierung, „Seen“-Funktionen).
Drittens: Monetization‑Layer (Abo, In‑App‑Purchases, Coins/Credits, ggf. Token).

Aus Herausgeberperspektive ist die zentrale juristische Frage nicht, ob Sie monetarisieren – sondern wie: Verkaufen Sie eine „Chance“ (sichtbarkeits- und erfolgsbezogen) oder „Funktionen“ (zugangsbezogen)? Je mehr das Modell outcome‑nah wird („mehr Matches“, „deutlich mehr Sichtbarkeit“), desto näher rückt es an Angriffsflächen: Irreführung, Täuschung, deliktische Anspruchskonstruktionen, AGB‑Kontrolle, Compliance‑Pflichten, und im Extremfall sogar Vorwürfe struktureller Inkaufnahme von Schädigungen, wenn Monetarisierung Missbrauch incentiviert.

3. Monetarisierung als Betreiberhaftungsthema: Premium, Boosts, Coins – nicht Verbraucherrecht, sondern Systemverantwortung

Sie wollten zu Recht weg vom „Nutzer will Coins zurück“-Ton. Aus Betreiberperspektive lautet der Kern:

Monetarisierung erzeugt Haftungsverdichtung, weil sie Erwartungen, Leistungsversprechen und Anreizstrukturen juristisch relevant macht.

3.1 Premium: Wenn „Mehr Sichtbarkeit“ zur geschuldeten Leistung wird

Premium-Modelle geraten rechtlich nicht deshalb in Schieflage, weil Nutzer kündigen, sondern weil Premium häufig mit einem impliziten Leistungsversprechen verkauft wird: schnellerer Erfolg, bessere Trefferquote, bevorzugte Sichtbarkeit. In der Praxis sind das algorithmische Steuerungsentscheidungen. Juristisch werden daraus zwei Risikofelder:

(a) Beschaffenheits- und Erwartungsrisiko
Je konkreter Sie Effekte kommunizieren, desto eher wird daraus eine überprüfbare geschuldete Beschaffenheit oder zumindest eine objektive Erwartung an die Leistung. Das führt nicht automatisch zu einer Erfolgshaftung, aber es verschiebt die Verteidigungsposition: Sie müssen erklären können, was Premium leistet – und warum es leistet. Wer Premium als „Outcome‑Booster“ verkauft, braucht eine belastbare Definition des „Was“ und „Wie“ auf Produkt‑ und Dokumentationsebene.

(b) Wettbewerbs- und Irreführungsrisiko
Erfolgskommunikation ist marketingrechtlich riskant, wenn sie nicht verifizierbar oder nicht repräsentativ ist. „Mehr Matches“ klingt nach Statistik; Statistik verlangt methodische Wahrheit und klare Parameter. Eine Plattform, die mit „Wahrscheinlichkeit“ wirbt, sollte jederzeit erklären können, was gemessen wird, über welchen Zeitraum, in welchem Nutzersegment, und welche Faktoren die Aussage begrenzen. Sonst wird Monetarisierung schnell zur Angriffsfläche über Irreführung – und Irreführung ist für Plattformen nicht nur „Abmahnung“, sondern Reputations- und Folgehaftungsrisiko.

3.2 Boosts und Super‑Likes: Add‑ons als „Haftungsbeschleuniger“

Boosts sind juristisch heikel, weil sie genau das verkaufen, was später streitig wird: Sichtbarkeit. Aus Betreiberperspektive entsteht das Risiko nicht nur im Vertragsrecht, sondern in der Frage, ob Boosts zu „verdeckten“ Erfolgsversprechen werden und ob sie in Konflikt mit Transparenzanforderungen geraten. Wer Add‑ons anbietet, die in Wahrheit algorithmische Priorisierung sind, muss vor allem zwei Dinge beherrschen: saubere Kommunikation (kein unhaltbarer Outcome‑Claim) und saubere Prozesstechnik (Checkout‑Eindeutigkeit, Logging, Nachweisbarkeit).

Für ein Litigation‑Szenario ist entscheidend, dass Sie als Betreiber beweisfähig bleiben: Wie wurde das Add‑on gebucht? Was war der Leistungszeitraum? Welche Sichtbarkeitslogik wird in dieser Zeit aktiviert? Was sind zulässige Schwankungen? Ohne diese Ebene entsteht ein Graubereich, in dem jede Nutzerenttäuschung wie ein Leistungsdefekt behauptet werden kann – und Sie haben keine belastbare Gegenstory.

3.3 Coins/Credits: Nicht „Rückerstattung“, sondern Bilanz, Aufsicht und Systemrisiko

Coins sind nicht primär ein Verbraucherproblem, sondern eine Architekturentscheidung mit drei Betreiberfolgen:

Erstens: Bilanzielle Verpflichtungslogik.
Coins sind wirtschaftlich häufig ein „Vorauszahlungs‑Äquivalent“. Wer Echtgeld gegen Coins nimmt, nimmt regelmäßig eine zukünftige Leistungspflicht in die Bücher. Je nachdem, ob Coins verfallen, rücktauschbar sind oder in mehreren Leistungsarten eingelöst werden können, entsteht eine anspruchsvolle Frage: Sind Coins Umsatz, sind sie passive Rechnungsabgrenzung, sind sie Verbindlichkeit, wie wird Breakage (Nicht-Einlösung) behandelt? Das ist nicht „Nice to have“, sondern steuerlich und handelsbilanziell relevant, und es entscheidet auch über Krisenfestigkeit und Insolvenzrisiken.

Zweitens: Aufsichtsrechtliche Trigger.
Sobald Coins wie ein Zahlungsmittel funktionieren, übertragbar sind, zwischen Nutzern gehandelt werden oder außerhalb eines eng begrenzten Leistungsnetzwerks eingesetzt werden können, rücken Zahlungsdienste‑ und E‑Geld‑Fragen in Reichweite. Viele Plattformen glauben, Coins seien automatisch „Spielwährung“. Das stimmt nur, wenn der Coin strikt als internes, nicht übertragbares, nicht rücktauschbares Leistungsabrechnungsinstrument funktioniert und keine Payment‑ähnliche Funktion annimmt. Schon kleine Produktentscheidungen – etwa Wallet‑Logik, Peer‑to‑Peer‑Transfers, Cash‑out‑Optionen – können Aufsichtsnähe erzeugen.

Drittens: Missbrauchsincentives.
Coins können ein Missbrauchsverstärker sein, wenn sie Interaktionen monetarisieren, die typischerweise für Social Engineering genutzt werden. Wenn bestimmte Kommunikationsschritte oder Freischaltungen coin‑basiert sind, muss man sich als Betreiber die unbequeme Frage stellen, ob das Geschäftsmodell strukturell dazu beiträgt, dass Täter ihre „Conversion“ erhöhen. Sobald ein Monetarisierungsmechanismus Missbrauch erleichtert oder belohnt, wächst nicht automatisch die Haftung – aber es wird erheblich schwerer, bei strukturellen Schadenslagen überzeugend zu argumentieren, man habe das Risiko nicht gesehen oder nicht beherrschen können. Monetarisierung ist dann Teil der Risikoarchitektur.

3.4 Token: Wenn aus Monetarisierung Kapitalmarkt wird

Token‑Modelle sind für Dating‑Apps selten nötig, aber sie tauchen auf, wenn Plattformen Community‑Ökonomien bauen oder Finanzierung „kreativ“ strukturieren wollen. Juristisch ist das ein Sprung in eine andere Liga: Token können (je nach Ausgestaltung) in den EU‑Krypto‑Regelungsraum hineinragen, Prospekt‑ und Offenlegungspflichten berühren und Haftungsregime auslösen, die deutlich schärfer sind als „App‑AGB“.

Für Herausgeber ist die zentrale Governance‑Frage: Wenn Token überhaupt, dann nur mit klarer rechtlicher Qualifikation, sauberer Risikooffenlegung und einer Gesellschaftsstruktur, die Verantwortlichkeiten trennt. Alles andere ist „Juristenroulette“ mit Investorendynamit.

4. Plattformregulierung als Produktfeature: DSA‑Pflichten als Trust‑&‑Safety‑Architektur

Entwickler bauen Reporting‑Buttons oft als Support‑Feature. Rechtspraktisch ist es eine Kernpflicht und ein Haftungsanker. Der Digital Services Act (DSA) zwingt Plattformen nicht zu allgemeinem Monitoring, verlangt aber robuste Prozesse, um Hinweise auf illegale Inhalte/Handlungen zu bearbeiten, Entscheidungen zu begründen und Beschwerdewege zu eröffnen.

Aus Herausgeberperspektive lautet die Leitfrage: Haben Sie ein Trust‑&‑Safety‑System, das Kenntnislagen strukturiert erfasst und Reaktion standardisiert? Denn in Streitfällen ist „Kenntnis“ der Scharnierbegriff: Was wussten Sie, wann wussten Sie es, was haben Sie getan, und war das verhältnismäßig?

Ein juristisch tragfähiges DSA‑Design bedeutet nicht „alles löschen“, sondern Governance: Klassifizierung von Meldungen, Priorisierung (insbesondere bei Identitätsbetrug, Erpressung, Minderjährigenrisiken), dokumentierte Entscheidungspfade, nachvollziehbare Sperr- und Wiederherstellungsprozesse, und eine interne Beschwerdelogik, die nicht nur formal existiert, sondern materiell funktioniert.

5. Datenschutz ist nicht nur DSGVO‑Text, sondern Engineering‑Pflicht: Privacy by Design/Default und Sicherheit

Dating‑Apps sind „High‑Trust‑Produkte“. Datenschutz ist hier nicht bloß Compliance, sondern Kern der Marktfähigkeit. Rechtsdogmatisch stehen zwei Pflichten im Zentrum: datenschutzfreundliche Voreinstellungen (Privacy by Default) und ein angemessenes Sicherheitsniveau (Art. 32 DSGVO). Das ist für Entwickler unmittelbar relevant, weil es Designentscheidungen betrifft:

Wie sichtbar sind Profile standardmäßig? Welche Informationen sind standardmäßig öffentlich? Wie granular ist Standort? Welche Schnittstellen erlauben Scraping? Wie verhindert man massenhaftes Harvesting? Welche Logs existieren? Welche Zugriffskontrollen haben Admins? Wie ist Incident Response organisiert?

Der juristische Punkt, den viele Plattformen unterschätzen: Im Streitfall ist nicht entscheidend, ob man „Sicherheitsmaßnahmen“ behauptet, sondern ob man sie konkret darlegen und plausibilisieren kann. Das bedeutet: Security‑ und Privacy‑Architektur müssen nicht nur existieren, sondern auch dokumentierbar und auditierbar sein. „Wir nutzen Bot‑Detection“ ist keine Verteidigung; „wir können erklären, welche Signale wir auswerten, wie wir false positives handhaben, wie wir Maßnahmen überprüfen und nachschärfen“ ist Verteidigung.

6. Jugendschutz, Altersverifikation und sexualisierte Inhalte: Der unterschätzte Compliance‑Komplex

Dating‑Apps bewegen sich in einem Umfeld, in dem Minderjährigenschutz nicht „Policy“, sondern Rechtsrealität ist. Je nach Ausrichtung der App (reine Dating‑App, „Sugaring“-Anmutung, explizite Inhalte) steigen die Anforderungen an Altersverifikation, Content‑Moderation und Risikosteuerung.

Für Herausgeber bedeutet das: Die Frage ist nicht nur „ab 18“, sondern ob das System in der Lage ist, Minderjährigenzugang und Grooming‑Risiken effektiv zu minimieren. Ein bloßer Self‑Declare‑Dialog kann je nach Risikoprofil unzureichend sein. Gleichzeitig müssen Maßnahmen datenschutz- und diskriminierungsrechtlich verhältnismäßig bleiben. Genau diese Abwägung – Sicherheit versus Datenminimierung – ist eine typische Stelle, an der Entwickler ohne juristische Steuerung in Widersprüche bauen.

7. Das „Sugaring“-Spezialrisiko: Abgrenzung Kontaktplattform vs. faktische Vermittlung

Wenn ein Dating‑Produkt strukturell in Richtung „Arrangement“ und monetärer Austauschbeziehungen geht, entstehen besondere Risiken: Nicht, weil das Konzept per se „illegal“ wäre, sondern weil Plattformdesign schnell in eine Zone geraten kann, in der Behörden oder Gerichte eine faktische Vermittlungsfunktion sehen könnten. Entscheidend ist dabei nicht ein Marketingbegriff, sondern die konkrete Produktlogik: Welche Filter, welche Kategorien, welche Zahlungs- oder Kontaktmechanismen, welche expliziten Leistungsangebote werden ermöglicht oder gefördert?

Für Herausgeber bedeutet das: Gerade bei grenzwertigen Konzepten ist die rechtliche Architektur im Produktdesign entscheidend – nicht nur in AGB. Die falsche Kombination aus Kategorien, Textbausteinen und Monetarisierungsmechanik kann ein Risiko schaffen, das später nicht mehr „wegzuargumentieren“ ist.

8. Gesellschaftsrechtliche Architektur: Wie man die App „eröffnet“, ohne Organrisiken und Durchgriff zu bauen

Jetzt zum Kern Ihres Aufsatz‑3‑DNA: Gesellschaftsrecht ist nicht Gründungsformular, sondern Risikotechnik.

8.1 Rechtsform: Haftungsbegrenzung ist Basis, nicht Ergebnis

In der Praxis ist eine Kapitalgesellschaft (GmbH/UG, bei Skalierung ggf. AG) der Ausgangspunkt. Die Haftungsbegrenzung funktioniert aber nur, wenn die Gesellschaft als eigenständiges Vermögenssubjekt ernst genommen wird: saubere Buchführung, klare Verträge, keine Vermögensvermischung. Entwickler unterschätzen oft, wie schnell operative „Shortcut‑Praktiken“ (privat gezahlte Server, vermischte Konten, fehlende Verträge mit Freelancern, unklare IP‑Inhaberschaft) später zu Haftungs- und Due‑Diligence‑Katastrophen führen.

8.2 Holding, IP‑Gesellschaft und Betriebsgesellschaft: Sinn und Grenzen

Eine Holdingstruktur ist kein Muss, aber ab Monetarisierung und Skalierung häufig sinnvoll. Der klassische Gedanke ist, IP (Software, Marke) und operativen Betrieb zu trennen. Diese Trennung kann Haftungsrisiken begrenzen und Investorenlogik erleichtern – sie kann aber auch brandgefährlich werden, wenn sie als „Schutzschild ohne Substanz“ gebaut ist. Sobald die operative Einheit durch überhöhte Lizenzen, unfaire Konzernentgelte oder Cash‑Pooling faktisch ausgehöhlt wird, nähert man sich Durchgriffsdynamiken (Vermögensvermischung, existenzvernichtender Eingriff) und kapitalerhaltungsrechtlichen Problemzonen.

Das juristische Meisterstück ist nicht die Holding an sich, sondern eine Struktur, die in Wachstum und Krise plausibel bleibt: marktgerechte konzerninterne Verhältnisse, klare Zahlungsströme, dokumentierte Entscheidungen, und ein Risikosystem, das Organpflichten erfüllt.

8.3 Geschäftsleiterhaftung: Compliance ist Chefsache

Für Dating‑Apps ist Geschäftsleiterhaftung real, weil Risikolagen vorhersehbar sind: Datenschutz, Sicherheit, Missbrauch, Monetarisierung, Payment‑Trigger. Das heißt nicht, dass Geschäftsführer „immer“ haften. Es heißt: Sie müssen zeigen können, dass sie Organisations- und Überwachungspflichten ernst nehmen. Ein funktionierendes Compliance‑ und Kontrollsystem ist kein Luxus, sondern zunehmend der Standard ordnungsgemäßer Unternehmensführung – gerade bei digitalen Geschäftsmodellen, deren Risiko nicht in Maschinen, sondern in Daten und Interaktionen liegt.

Delegation ist zulässig und nötig, entlastet aber nur, wenn Auswahl, Instruktion und Überwachung stimmen. Ein externer Moderationsdienstleister ersetzt keine Governance; er ist Teil davon.

9. Steuerrecht: Der Bereich, den Entwickler gerne verdrängen – und der in Due Diligence wehtut

Sie wollten ausdrücklich den steuerlichen Aspekt: Zu Recht. Denn Monetarisierung in Apps ist steuerlich anspruchsvoll, und Fehler sind teuer.

9.1 Umsatzsteuer: Digitalleistung, B2C‑Ort der Leistung und OSS‑Logik

Dating‑Abos und digitale Add‑ons sind typischerweise elektronisch erbrachte Leistungen. Bei B2C‑Leistungen in der EU kann die Umsatzsteuerpflicht am Wohnsitzstaat des Verbrauchers anknüpfen. Für Plattformen mit internationalen Nutzerzahlen wird das schnell operativ: Billing muss Steuersätze, Nachweise und Reporting sauber abbilden. Wer das zu spät strukturiert, baut Nachzahlungsrisiken auf.

9.2 Coins/Credits als „Gutschein“-Problem: Einlösungszeitpunkt vs. Verkaufszeitpunkt

Coins können umsatzsteuerlich in die Nähe von Gutscheinlogik rücken. Ob Umsatzsteuer beim Verkauf der Coins oder erst bei Einlösung entsteht, hängt davon ab, ob bei Ausgabe bereits feststeht, welche konkrete Leistung mit welchem Steuersatz bezogen wird. Für Plattformen mit multiplen Einlösungen (Boost, Super‑Like, Message‑Unlock) ist das oft nicht trivial. Diese steuerliche Architektur muss mit Billing, Ledger und Produktlogik harmonieren. Steuerrecht ist hier kein Nachsatz, sondern ein Teil des Systems.

9.3 Ertragsteuer, Transfer Pricing und IP‑Lizenzierung

Wenn Sie Holding/IP‑Gesellschaften nutzen, kommen ertragsteuerliche Fragen: Lizenzgebühren müssen fremdüblich sein, Kostenallokationen nachvollziehbar, Funktionen und Risiken richtig zugeordnet. Wer IP‑Strukturen „nur wegen Haftung“ baut, aber steuerlich keine Substanz und keine Dokumentation hat, riskiert, dass die Struktur in Betriebsprüfungen oder bei Investorenfragen auseinanderfällt.

10. Accounting und „Product Truth“: Warum Buchhaltung und Plattformhaftung zusammenhängen

Ein juristischer Mutterschiff‑Gedanke, den viele übersehen: Ihre Buchhaltung ist nicht nur Steuerbasis, sondern in Streitfällen oft indirekter Beweis Ihrer Leistungslogik. Wenn Sie Coins verkaufen, aber bilanziell so tun, als seien es sofortige Umsätze ohne Leistungspflicht, entsteht eine Widerspruchslage. Wenn Sie Premium verkaufen, aber nicht dokumentieren können, welche Leistung wann aktiviert wird, entsteht eine Nachweisproblematik.

Seriöse Plattformen bauen deshalb Ledger‑ und Audit‑Trails so, dass sie die juristische Wahrheit stützen: wann gekauft, was aktiviert, wie lange, unter welchen Bedingungen, und wie Rückabwicklungen oder Sperren behandelt werden.

11. Internationalisierung und App‑Store‑Realität: Recht folgt Distribution

Entwickler launchen selten „nur Deutschland“. Internationalisierung bedeutet nicht nur Übersetzung, sondern Rechtsvielfalt: Verbraucherrechtliche Pflichten, Steuerorte, Inhaltsregeln, Altersvorgaben, Store‑Policies, Datenexporte. App‑Store‑Policies (Apple/Google) sind dabei faktisch „quasi‑regulatorisch“, weil sie Monetarisierung, Adult‑Content‑Grenzen, Refund‑Prozesse und Payment‑Flows diktieren können. Wer sein Geschäftsmodell nicht store‑kompatibel plant, hat nicht nur juristische Risiken, sondern Distribution‑Risiken.

12. Der rote Faden: Legal‑by‑Design ist nicht „mehr Papier“, sondern weniger Haftung

Wenn man den Beitrag in eine einzige Leitthese kondensiert:

Eine Dating‑App wird rechtssicher nicht durch AGB am Ende, sondern durch Architektur am Anfang.
Architektur heißt hier: Gesellschaftsstruktur, Monetarisierungslogik, Trust‑&‑Safety‑Prozesse, Datenschutz‑ und Sicherheitsdesign, steuer- und bilanzfähiges Billing, dokumentierbare Governance.

Und genau deshalb ist dieses Thema mandatsfähig: Entwickler können das nicht „nebenbei“, ohne dass Produktentscheidungen später mit Rechtsfolgen kollidieren.

Handlungsbox

Warum es sich lohnt, die Eröffnung einer Dating-App juristisch begleiten zu lassen

Wenn Sie eine Dating‑Plattform mit Premium/Boost/Coins (oder Token‑Ambitionen) eröffnen, entscheiden die ersten 8–12 Wochen Architektur über die nächsten 3 Jahre Haftungs- und Regulierungsrisiko. Juristische Begleitung bedeutet nicht, dass Legal „alles verbietet“, sondern dass Produkt, Monetarisierung, Governance, Steuern und Plattformpflichten so aufeinander abgestimmt werden, dass Sie skalieren können, ohne später in Rückbau, Streit und Reputationsschäden zu geraten.

Wenn Sie wollen, sprechen wir das pragmatisch entlang Ihrer Produkt-Roadmap und Ihres Tech‑Stacks durch.

Soft CTA: 0160 9955 5525
Kontakt: hortmannlaw.com/contact

FAQ

Muss ich eine Holding gründen, um rechtssicher zu sein?

Nein. Eine Holding ist kein gesetzliches Muss. Sie wird aber oft sinnvoll, sobald IP‑Wert, Monetarisierung, Payment‑Nähe oder regulatorische Komplexität steigen. Entscheidend ist nicht „Holding ja/nein“, sondern ob Struktur und konzerninterne Beziehungen in Wachstum und Krise plausibel, dokumentiert und marktgerecht sind.

Ab wann werden Coins aufsichtsrechtlich heikel?

Coins werden heikel, wenn sie funktional in Richtung Zahlungsmittel/E‑Geld kippen: Übertragbarkeit, Rücktausch, Peer‑to‑Peer‑Transfers, externe Nutzbarkeit oder Wallet‑Logik können Trigger sein. Viele Modelle bleiben unkritisch, wenn Coins strikt internes Leistungsabrechnungsinstrument bleiben – aber das muss im konkreten Produkt sauber bewertet werden.

Darf ich Premium mit „mehr Matches“ bewerben?

Man kann mit Vorteilen werben – aber je näher Sie an messbare Erfolgsclaims gehen, desto höher sind Irreführungs- und Erwartungsrisiken. Wer outcome‑nah wirbt, braucht saubere Parameter, repräsentative Aussagen und eine Produktlogik, die die Behauptung plausibel trägt.

Reicht ein „Report“-Button aus, um DSA‑Pflichten abzudecken?

Ein Button allein ist nur Oberfläche. Entscheidend sind dahinterliegende Prozesse: Klassifizierung, Priorisierung, Entscheidung, Begründung, Beschwerdeweg und Dokumentation. Ohne funktionierende Prozesskette entsteht ein Kenntnis- und Organisationsrisiko.

Was sind die größten steuerlichen Fehler bei Dating‑Apps?

Typisch sind falsche Annahmen zur Umsatzsteuer bei internationalen B2C‑Leistungen und eine unklare Behandlung von Coins/Credits (Zeitpunkt der Besteuerung, Einlösung, Breakage). Bei Holding‑Strukturen kommen fremdübliche Lizenz- und Transfer‑Pricing‑Fragen hinzu.

Muss ich als Geschäftsführer persönlich Angst haben?

Angst ist unproduktiv – aber Respekt vor Organpflichten ist sinnvoll. Wer Risiken kennt und ein angemessenes Governance‑, Security‑ und Compliance‑System etabliert und dokumentiert, reduziert persönliches Haftungsrisiko erheblich. Problematisch wird es bei struktureller Blindheit, fehlender Dokumentation oder bewusster Untätigkeit trotz klarer interner Hinweise.

Vertiefende Beiträge zur rechtssicheren Dating-App-Gründung

Wie man eine Escort-Agentur rechtssicher eröffnet
Gründungsfragen, ProstSchG, Haftung und Struktur sensibler Plattformmodelle.
www.hortmannlaw.com/articles/wie-man-eine-escort-agentur-rechtssicher-eroffnet

Anwalt für KI-Apps & Startups – Haftung und Pflichten
Rechtsrahmen für digitale Plattformen, Governance und Entwicklerverantwortung.
www.hortmannlaw.com/articles/anwalt-ki-apps-startup-haftung

AI Act Zertifizierungspflicht
Wann Matching-Algorithmen regulatorisch relevant werden und welche Pflichten greifen.
www.hortmannlaw.com/articles/ai-act-zertifizierungspflicht

AML/KYC für Token-Plattformen
Geldwäschepflichten und organisatorische Anforderungen bei Coin- oder Wallet-Modellen.
www.hortmannlaw.com/articles/aml-kyc-token-plattformen-geldwaeschepflicht

ART-Token 2025 – Governance & Struktur
Rechtssichere Token-Architektur im regulatorischen Umfeld.
www.hortmannlaw.com/articles/art-token-2025-anwalt-governance-preisstabilitaet

MiCA 2025 – Tokenangaben & Transparenz
Was Plattformbetreiber bei Kryptostrukturen beachten müssen.
www.hortmannlaw.com/articles/mica-2025-tokenangaben-krypto-betrug-anwalt

AGB im Krypto-Handel – Verantwortung der Plattform
Vertragsarchitektur und Haftungsrisiken digitaler Intermediäre.
www.hortmannlaw.com/articles/agb-krypto-plattform-verantwortung-haftung

Compliance-Verstöße dokumentieren – Haftung der Geschäftsführung
Organpflichten, CMS und Risikomanagement in Plattformunternehmen.
www.hortmannlaw.com/articles/compliance-verstosse-dokumentieren---haftung-der-geschaeftsfuehrung

Datenschutz & KI – Anforderungen der DSGVO
Datenschutzrechtliche Maßstäbe für algorithmische Systeme.
www.hortmannlaw.com/articles/datenschutz-und-ki-anforderungen-der-dsgvo-fur-ki

Datenschutz & Intimsphäre – Art. 9 DSGVO
Sensible Daten in digitalen Nähe-Modellen rechtssicher verarbeiten.
www.hortmannlaw.com/articles/datenschutz-intimsphaere-art9-dsgvo-digitale-sexarbeit

DAC7 und DAC8 – Meldepflichten für Plattformen
Steuertransparenz, Plattformmeldungen und internationale Datenweitergabe.
www.hortmannlaw.com/articles/dac7-und-dac8-meldepflichten-fur-krypto-und-plattformen

Creators & Startups in Deutschland – Steuerliche Grundlagen
Umsatzsteuer, Strukturfragen und steuerliche Fallstricke digitaler Geschäftsmodelle.
www.hortmannlaw.com/articles/creators-startups-deutschland-steuern

‍