Das Landerubergreifende Glucksspielaufsichtssystem LUGAS ist der zentrale Baustein der operativen Aufsicht uber virtuelle Automatenspiele, Online-Poker und Sportwetten in Deutschland. Aus IT-Sicht ist es ein Register mit Anbindung an alle lizenzierten Anbieter, das den Zustand jedes Spielerkontos in Bezug auf Einzahlungslimit und Sitzungsaktivitat halt und pro Transaktion validiert.

TBB Zahlenwerk beschreibt in diesem Beitrag Architektur, Datenmodell und Betriebspraxis von LUGAS aus datenjournalistischer Perspektive. Unser Ziel ist die verstandliche Aufarbeitung der zugrundeliegenden Systemlogik, nicht die produktnahe Anleitung fur Endverbraucher.

Grundlagen des LUGAS-Systems aus IT-Sicht

LUGAS steht fur Landerubergreifendes Glucksspielaufsichtssystem und ist eine 2021 eingerichtete zentrale IT-Infrastruktur, die im Zusammenhang mit dem Glucksspielstaatsvertrag geschaffen wurde. Das System agiert als authoritative Datenquelle fur zwei operative Regeln: das monatliche Einzahlungslimit von 1.000 Euro pro Kalendermonat und die Sperrung paralleler Sitzungen bei mehreren Anbietern. Beide Regeln gelten anbieterubergreifend und wirken damit auf der Personenebene, nicht auf der Kontenebene.

Anbieter als Client, Register als Server

Aus IT-Perspektive ist LUGAS ein klassisches zentrales Register, das synchrone Anfragen der angeschlossenen Anbieter beantwortet. Die Anbieter greifen an definierten Punkten ihres eigenen Datenflusses auf das Register zu. Diese Punkte sind vor jeder Einzahlung, vor jedem Sitzungsstart und in periodischen Kontrollen wahrend laufender Sitzungen. Der Anbieter verhalt sich in dieser Anordnung wie ein Client, das Register wie ein Server mit hoher Verfugbarkeitsanforderung.

Der Zugriff erfolgt uber standardisierte Schnittstellen. Die Authentifizierung der Anbieter erfolgt uber Zertifikate, die Datenubertragung uber verschlusselte Kanale. Fur den Endnutzer ist LUGAS unsichtbar. Er sieht nur die Anbieterseite, die die Ergebnisse der Anfragen an ihn weitergibt.

Berechnungslogik des Monatszahlers

Der Monatszahler in LUGAS lauft fur jede Spielerkennung getrennt und bezieht sich auf den laufenden Kalendermonat. Am Ersten eines Monats steht jeder Person mit dem vollen Rahmen von 1.000 Euro zur Verfugung. Jede erfolgreiche Einzahlung reduziert den Rahmen um den entsprechenden Betrag. Am Ersten des Folgemonats steht wieder der volle Rahmen bereit. Die Ruckstellung ist automatisch und erfolgt zeitgleich fur alle Personen im Register.

Verhalten des Zahlers bei Boni und Auszahlungen

Der Zahler unterscheidet nicht zwischen Anbietern und nicht zwischen Segmenten. Eine Einzahlung bei einem Sportwettenanbieter belastet den gleichen Zahler wie eine Einzahlung bei einem Anbieter virtueller Automatenspiele. Ebenso wirken sich Bonusgutschriften des Anbieters nicht auf den Zahler aus, weil sie keine Einzahlung des Spielers darstellen. Auszahlungen an den Spieler fullen den Zahler ebenfalls nicht wieder auf. Wer 500 Euro einzahlt, verspielt 300 und lasst sich 200 auszahlen, hat trotzdem 500 Euro seines Rahmens verbraucht.

Erstattungen aufgrund technischer Fehler oder gerichtlich anerkannter Ruckforderungen sind ein Sonderfall. Sie werden in der Regel nicht als reguliere Einzahlung gefuhrt und wirken sich entsprechend nicht auf den Zahler aus. Die exakte Handhabung solcher Sonderfalle liegt in der Verantwortung der Anbieter und wird aufsichtlich uberpruft.

Sitzungssteuerung und Cross-Provider-Locks

Die zweite operative Aufgabe von LUGAS ist die Sitzungssteuerung. Ein Spieler kann pro Zeitpunkt nur bei einem einzigen lizenzierten Anbieter eine aktive Sitzung haben. Aus IT-Sicht ist das eine klassische Cross-Provider-Lock-Konstellation. Bei jedem Sitzungsstart pruft der Anbieter den Zustand der Spielerkennung im Register. Ist bereits eine Sitzung bei einem anderen Anbieter offen, verweigert das Register den Start und der zweite Anbieter meldet dem Spieler eine Ablehnung.

Die Konstellation setzt voraus, dass die Anbieter das Sitzungsende zuverlassig an das Register melden. Ohne diese Meldung bliebe der Lock bestehen, und der Spieler konnte bei keinem Anbieter mehr eine Sitzung starten. Aus IT-Betriebssicht ist das Sitzungsende deshalb einer der sensibelsten Punkte in der Integration. Alle lizenzierten Anbieter mussen Sicherheitsmechanismen fur den Fall implementieren, dass eine Sitzung nicht sauber beendet wird, etwa durch Browserabsturz oder Verbindungsabbruch.

Ein typisches Mittel ist ein Timeout, nach dem eine Sitzung serverseitig automatisch geschlossen wird, wenn keine Aktivitat mehr registriert wurde. Ein zweites Mittel ist die aktive Nachfrage beim Spieler nach langerer Inaktivitat. Aus datenjournalistischer Sicht sind diese Mechanismen deshalb interessant, weil sie die Grenze zwischen guter und schlechter Integration markieren. Die Aufsicht pruft die Qualitat der Sitzungsverwaltung im Rahmen der Auditierung.

Datenmodell und Datenschutz im LUGAS-Backend

Das Datenmodell von LUGAS umfasst pro Spielerkennung mehrere Kategorien. Erstens Identifikationsdaten wie Vor- und Nachname, Geburtsdatum, Steuer-ID und Wohnanschrift. Zweitens Transaktionsdaten mit Einzahlungshohe, Zeitstempel und Anbieter-ID. Drittens Sitzungsdaten mit Beginn, Ende und Anbieter-ID der aktiven Sitzung. Viertens Konfigurationsdaten wie personliches Limit, gegebenenfalls durch Paragraph 6c erhohtes Limit und aktive Zeitlimits.

Rechtsgrundlage und Zweckbindung im Backend

Rechtsgrundlage der Verarbeitung ist Artikel 6 Absatz 1 Buchstabe c DSGVO in Verbindung mit den Regelungen des GluStV 2021. Die Verarbeitung ist streng zweckgebunden. Eine Weitergabe an Dritte ist auf die Aufsichtsbehorden und die angebundenen Anbieter im Rahmen ihrer Aufgaben beschrankt. Fur andere Zwecke, etwa Marketinganalyse, ist die Datenverwendung nicht zulassig.

Betroffene haben die ublichen DSGVO-Rechte. Sie konnen Auskunft nach Artikel 15 verlangen, die Berichtigung fehlerhafter Daten fordern und im Rahmen der gesetzlichen Aufbewahrungsfristen die Loschung beantragen. Die Aufbewahrungsfristen ergeben sich aus dem Steuerrecht und dem Aufsichtsrecht und liegen typischerweise bei mehreren Jahren. Wahrend dieser Zeit ist eine vollstandige Loschung nicht moglich, wohl aber die Berichtigung fehlerhafter Angaben.

Betriebspraxis und Verfugbarkeit

LUGAS ist im laufenden Betrieb ein System mit hoher Verfugbarkeitsanforderung. Jede Einzahlung eines Spielers erzeugt eine synchrone Anfrage an das Register. Die Antwortlatenz ist damit fur die Benutzererfahrung im Anbieter direkt spurbar. Aus IT-Betriebssicht ist eine Antwort im Bereich unter 200 Millisekunden ein realistischer Zielwert, der nur durch geografisch verteilte Infrastruktur und ausreichende Kapazitatsreserven erreichbar ist.

Storungsbild und operative Folgen fur Anbieter

Storungen im Betrieb kommen vor, sind aber vergleichsweise selten. Bei einem Ausfall des Registers durfen Anbieter keine neuen Einzahlungen mehr verarbeiten, weil die Validierung fehlt. Der Betrieb kommt fur die Dauer des Ausfalls zum Erliegen. Kurzere Unterbrechungen unter einer Minute sind fur Endnutzer meist nicht wahrnehmbar. Langere Ausfalle fuhren zu sichtbaren Storungen und werden von den Anbietern kommuniziert.

Die Aufsicht veroffentlicht keine granularen Betriebskennzahlen. TBB Zahlenwerk arbeitet mit offentlich zuganglichen Storungsmeldungen und Betreiberberichten. Aus diesen Quellen ergibt sich das Bild eines uberwiegend stabilen Systems, das gelegentliche Wartungsfenster und selten langere Ausfalle aufweist. Fur die Marktentwicklung ist die Verfugbarkeit zentral, weil sie den Servicecharakter der lizenzierten Angebote im Vergleich zu nicht lizenzierten Alternativen mitbestimmt.

Fehlerbilder und Datenkorrektur

Aus der Betriebspraxis sind mehrere typische Fehlerbilder bekannt. Das erste ist eine Diskrepanz zwischen dem tatsachlichen Rahmen und dem im Anbieter angezeigten Rest. Solche Diskrepanzen entstehen meist durch Verzogerungen bei der Aktualisierung des Anbietercaches. Sie losen sich in der Regel nach kurzer Zeit von selbst auf. Halt die Diskrepanz an, ist der Anbieter die erste Anlaufstelle.

Das zweite Fehlerbild ist eine falsche Ablehnung einer Einzahlung trotz vorhandenem Rahmen. Auch hier ist der Anbieter erste Anlaufstelle. In seltenen Fallen liegt der Fehler tiefer und muss uber die Aufsicht geklart werden. Betroffene konnen eine Auskunft nach Artikel 15 DSGVO verlangen und erhalten ihren aktuellen Datenstand.

Das dritte Fehlerbild ist eine dauerhaft nicht schliessbare Sitzung. Wenn ein Sitzungsende nicht sauber an LUGAS gemeldet wurde, bleibt der Lock bestehen. Der betroffene Spieler kann keine neue Sitzung starten. Die Losung liegt beim Anbieter, der eine manuelle Freigabe im Register initiieren muss. In der Regel dauert das nicht langer als eine Stunde, in Ausnahmefallen erfordert es eine Ruckfrage bei der Aufsicht.

LUGAS im Verbraucheralltag

Fur den taglichen Umgang mit LUGAS gelten mehrere praktische Beobachtungen. Erstens ist der Aufenthaltsort bei einer Einzahlung nicht ausschlaggebend. Wer im Auslandsurlaub uber die App eines deutschen Anbieters einzahlen mochte, wird ebenso gegen den Rahmen validiert wie zu Hause. Massgeblich ist der Wohnsitz, der zum Zeitpunkt der Kontoeroffnung angegeben wurde und dokumentiert ist.

Zweitens werden Demospiele und Testkonten von LUGAS nicht erfasst. Wer keine Einzahlung tatigt, generiert keine Transaktionsdaten im Register. Ab der ersten realen Einzahlung greift das System vollumfanglich, sowohl fur die Limitprufung als auch fur die Sitzungsverwaltung.

Drittens wird der Spielsteuerabzug von 5,3 Prozent nicht durch LUGAS erhoben, sondern vom Anbieter im Hintergrund abgefuhrt. LUGAS erfasst nur die Einzahlungssumme. Fur den Spieler ist der Abzug in der Regel im Konto sichtbar. Er reduziert das effektive Spielguthaben und erklart die im Vergleich zu unregulierten Anbietern niedrigere Rendite.