Die Gemeinsame Glücksspielbehörde der Länder hat ihren Downloadbereich für Glücksspielanbieter am 23. Juni 2026 aktualisiert und damit mehrere Dokumente sichtbar gebündelt, die weit über normale Antragsformulare hinausgehen. Zwischen Payment Blocking, OWASP-Pentest, LUGAS-Zugang und Safe-Server-Datenschutzhinweisen entsteht ein technischer Leitfaden für reguliertes Online-Glücksspiel. Für Glücksspielregulierung ist das relevant, weil die GGL hier zeigt, welche IT-, Zahlungs- und Datenschutzprozesse hinter einer Erlaubnis stehen.
Auf den ersten Blick wirkt der Downloadbereich wie eine Behördenseite mit PDFs. Technisch ist er aber ein Fenster in die Infrastruktur des deutschen Glücksspielmarkts. Wer eine Erlaubnis für virtuelle Automatenspiele, Online-Poker, Sportwetten, Pferdewetten oder gewerbliche Spielvermittlung beantragt, muss nicht nur wirtschaftliche und rechtliche Unterlagen liefern. Anbieter müssen Zahlungswege offenlegen, Sicherheitsprüfungen dokumentieren, LUGAS anbinden, Safe-Server-Daten bereitstellen und Datenschutzpflichten für unterschiedliche Verarbeitungsschichten beachten.
Die Unterlagen erklären damit die Rückseite der Whitelist. Wer bei legalen Online-Casinos auf die GGL-Whitelist achtet, sieht nur das sichtbare Ergebnis. Der Downloadbereich zeigt, welche technischen Kontrollpunkte im Hintergrund wirken. Es geht um Zahlungsdaten, Audit-Berichte, Testsysteme, Schnittstellen, personenbezogene Daten, Aufsichtszugriff und belastbare Nachweise.
Payment Blocking hängt an Zahlungskennungen, nicht nur an Webseiten
Payment Blocking ist der erste große Technikblock im GGL-Downloadbereich. Die Unterlagen zeigen, dass die Aufsicht nicht nur Webseiten und Marken betrachtet. Sie betrachtet auch Zahlungswege, Händlerkennungen und Bankverbindungen. Genau dort wird sichtbar, wie eng Regulierung, Payment-Infrastruktur und Vollzug gegen illegales Glücksspiel zusammenhängen.
Welche Zahlungsdaten die GGL für Blocking-Prozesse braucht
Die Zustimmungserklärung Payment Blocking ist nur eine Seite lang, aber technisch wichtig. Der Anbieter stimmt zu, dass die GGL Angaben zu Bankdaten an Zahlungsdienstleister und Finanzinstitute weitergeben darf. Das Formular nennt konkret IBAN, BIC und die Händler-ID des jeweiligen Zahlungsdienstleisters. Diese Informationen sind keine Marketingdaten. Es sind operative Identifikatoren im Zahlungsverkehr.
Warum Payment Blocking mehr ist als eine URL-Sperre
Payment Blocking wird oft als Sperre gegen illegale Glücksspielseiten verstanden. Das greift zu kurz. Eine URL kann wechseln. Eine Marke kann umziehen. Ein Zahlungsweg kann über Dienstleister, Händlerkennungen und Abwickler laufen. Für wirksame Aufsicht reicht es nicht, nur Domains zu kennen. Die Behörde muss Zahlungsströme zuordnen können. Gerade bei unerlaubtem Glücksspiel sind Zahlungsdienstleister, Acquirer, Wallets und Bankverbindungen ein wichtiger Angriffspunkt.
Die GGL nutzt Payment Blocking als Vollzugsinstrument gegen unerlaubtes Glücksspiel. Im Zusammenspiel mit Untersagungsverfügungen und Netzsperren soll es dafür sorgen, dass illegale Angebote für Spieler schlechter nutzbar werden. Der Downloadbereich zeigt aber auch die andere Seite: Erlaubnisfähige Anbieter müssen ihre Zahlungsinfrastruktur nachvollziehbar machen. Das hilft bei Abgrenzung, Kontrolle und Kommunikation mit Finanzinstituten.
| Dokument im GGL-Downloadbereich | Technischer Kern | Warum es für Anbieter zählt |
|---|---|---|
| Zustimmungserklärung Payment Blocking | Weitergabe von IBAN, BIC und Händler-ID | Zahlungswege werden regulatorisch adressierbar |
| OWASP-Pentest-Muster | strukturierter Sicherheitsbericht nach OWASP Testing Guide | Web- und API-Sicherheit wird messbar dokumentiert |
| Anschluss LUGAS Live und Testsystem | Zugangspfad für Test- und Live-Systeme | Integration beginnt vor dem Live-Betrieb |
| Erklärung Zugang technische Richtlinien | Identifikation des Anbieters und EU/EWR-Sitzangabe | technische Unterlagen bleiben nicht öffentlich frei abrufbar |
| Datenschutzhinweise LUGAS und Safe-Server | Datenkategorien, Zwecke, Speicherfristen und Rechtsgrundlagen | Datenschutz wird Teil der Systemarchitektur |
| Preisliste Zentraldateien LUGAS | Kostenrahmen für zentrale Aufsichtssysteme | Compliance-Kosten müssen eingeplant werden |
Was Payment-Teams intern dokumentieren sollten
Für Zahlungs- und Compliance-Teams ergibt sich daraus ein klarer Prüfpunkt. Händler-IDs, Bankverbindungen und Zahlungsdienstleister dürfen nicht nur in Buchhaltungssystemen gepflegt werden. Sie gehören auch in das regulatorische Stammdatenmanagement. Änderungen bei Acquirern, Wallet-Anbietern oder Bankkonten sollten intern wie ein Compliance-Ereignis behandelt werden. Sonst kann die Dokumentation gegenüber der Aufsicht schnell hinter der tatsächlichen Zahlungsarchitektur zurückfallen.
OWASP-Pentest wird zum messbaren Freigabekriterium
Der zweite technische Schwerpunkt liegt bei der Sicherheit der Plattform selbst. Die GGL verlangt keinen allgemein gehaltenen Prüfvermerk nach dem Muster „Sicherheitsprüfung bestanden“. Das Muster für den Prüfbericht legt eine strukturierte Prüfung nach OWASP Testing Guide nahe. Damit wird Web- und API-Sicherheit zu einem nachvollziehbaren Bestandteil des Erlaubnis- und Betriebsprozesses.
Was im Prüfbericht stehen muss
Das Muster für den Prüfbericht Pentest OWASP ist der technisch dichteste Teil des Downloadbereichs. Das Dokument nennt Zielsetzung, Management Summary, Rahmenbedingungen, Zielsystem, verfügbare Informationen, eingesetzte Tools, Portscan, Schwachstellenscan und eine Analyse nach OWASP Testing Guide. Es geht also nicht nur um das Ergebnis. Es geht auch um Prüftiefe, Prüfumfang, Testmethode und Nachvollziehbarkeit.
Welche Schwachstellen für Glücksspielplattformen besonders kritisch sind
Besonders wichtig ist die Breite der Prüfpunkte. Das Muster nennt nicht nur klassische Fehler wie SQL-Injection oder Cross-Site-Scripting. Es adressiert Identitätsmanagement, Authentisierung, Autorisierung, Session Management, Eingabevalidierung, Fehlerbehandlung, Verschlüsselung, Business-Logik, Client-seitige Schwachstellen und API Testing. Für Glücksspielanbieter ist das entscheidend. Ihre Portale sind nicht nur Webseiten. Sie verbinden Login, Wallet, Spielstart, Bonuslogik, Zahlungsabwicklung, Limits, Sperrdateien, LUGAS-Abfragen und Reporting.
| OWASP-Prüfbereich | Beispiele aus dem GGL-Muster | Glücksspiel-spezifische Relevanz |
|---|---|---|
| Identitätsmanagement | Rollen, Berechtigungen, Provisionierung | Admin- und Spielerkonten müssen sauber getrennt sein |
| Authentisierung | Standardzugänge, Lockout, Passwortspeicherung | Kontoübernahme gefährdet Geld, Limits und Identität |
| Autorisierung | Path Traversal, Privilege Escalation, IDOR | Spieler- und Betreiberrechte dürfen nicht eskalieren |
| Session Management | Cookie-Parameter, CSRF, Timeout, Hijacking | lange Sessions treffen auf echtes Guthaben |
| Eingabevalidierung | XSS, SQL Injection, SSRF, Command Injection | Eingaben steuern Zahlungen, Limits und Spielzustände |
| Business-Logik | gefälschte Anfragen, Workflow-Umgehung, Funktionslimits | Bonus-, Einsatz- und Limitlogik darf nicht aushebelbar sein |
| Client Side und API Testing | WebSockets, Browser-Speicher, GraphQL | Apps und APIs sind genauso kritisch wie das Webportal |
Wie CVSS über Freigabe und Fristen entscheidet
Der harte Punkt steht in der Bewertung. Das Muster fordert eine Übersicht mit CVSS-String und CVSS-Score. Die Freigabe der Anwendung erfolgt maßgeblich anhand dieser Übersicht. Eine Freigabe kann verweigert werden, wenn ein einzelner CVSS Base Score den Wert 7 überschreitet oder die Summe der CVSS Base Scores über 70 liegt. Das macht den Pentest zu einem quantifizierten Gate im Erlaubnis- und Betriebsprozess.
Auch die Maßnahmenlogik ist konkret. Schwachstellen sollen mit Empfehlungen versehen werden. Die Priorisierung reicht von zeitnah für unmittelbare Reaktion über kurzfristig innerhalb von vier Wochen bis mittelfristig innerhalb von drei Monaten und langfristig innerhalb von sechs Monaten. Damit entsteht eine Übersetzung zwischen technischem Risiko und regulatorischem Zeitplan.
Für Anbieter heißt das: Der Pentest darf nicht erst kurz vor Einreichung beginnen. Ein Glücksspielsystem sollte OWASP-Prüfungen bereits in Entwicklung, Staging und Release-Prozess integrieren. Sonst werden Findings mit CVSS-Wert plötzlich zum Go-Live-Risiko. Besonders kritisch sind Authentisierung, Session-Handling, API-Endpunkte, Payment-Flows, Admin-Portale und jede Logik, die Einsatz, Gewinn, Limit oder Aktivstatus beeinflusst.
LUGAS und Safe-Server machen Compliance zur Datenpipeline
Der dritte große Bereich betrifft die laufende technische Aufsicht. LUGAS und Safe-Server sind keine bloßen Meldeformulare. Es sind Daten- und Kontrollsysteme, die direkt in Registrierung, Einzahlung, Aktivitätsprüfung, Spielbetrieb und Aufsichtsauswertung hineinreichen. Für Anbieter wird Compliance dadurch zu einem dauerhaften Datenprozess.
Limitdatei und Aktivitätsdatei als zentrale Kontrollsysteme
LUGAS ist der technische Kern der laufenden Glücksspielaufsicht. Die GGL beschreibt das System als verpflichtend für Anbieter von Glücksspielen im Internet. Es besteht aus zwei großen Bausteinen: den Zentraldateien und dem Auswertesystem der Safe-Server. Die Zentraldateien umfassen die Limitdatei und die Aktivitätsdatei. Die Limitdatei überwacht anbieterübergreifende Einzahlungslimits. Die Aktivitätsdatei soll paralleles Spielen bei mehreren Anbietern verhindern.
Safe-Server liefern aufsichtsrelevante Ereignisdaten
Die Safe-Server-Seite ist noch näher an der Technik. Veranstalter von Sportwetten, Online-Poker und virtuellen Automatenspielen müssen auf eigene Kosten ein System betreiben, das alle für die Aufsicht erforderlichen Daten zutreffend erfasst, digital nicht veränderlich ablegt und elektronische Kontrolle durch die Aufsicht ermöglicht. Dieses System nennt die GGL Safe-Server. Das Auswertesystem der Behörde holt Datenpakete von den Safe-Servern ab und wertet sie aus.
Wie Anbieter an Test- und Live-Systeme kommen
Die LUGAS-Anschlussunterlagen zeigen vier praktische Wege. Anbieter mit vorhandener Erlaubnis und vollständig getesteter LUGAS-Anbindung beantragen Zugang zum Live-System und legen den Erlaubnisbescheid bei. Anbieter mit vorhandener Erlaubnis, aber ohne finalen LUGAS-Test, beantragen zunächst Zugang zu technischen Richtlinien und Testumgebung. Bei Erstanträgen sollen nach Eingang der Papierunterlagen Zugangsdaten für das Testsystem folgen. Wer einen Erstantrag vorbereitet, kann LUGAS bereits vorab testen.
| GGL-System | Daten oder Funktion | Praxisfolge für Anbieter |
|---|---|---|
| Limitdatei | anbieterübergreifendes Einzahlungslimit | Einzahlungen müssen synchron zum Limitmodell laufen |
| Aktivitätsdatei | Prüfung auf paralleles aktives Spiel | Spielstart braucht vorherige Abfrage |
| Safe-Server | nicht veränderbare Ablage aufsichtsrelevanter Ereignisse | Events müssen vollständig, korrekt und auditierbar entstehen |
| Auswertesystem | Abholung und Auswertung der Safe-Server-Daten | tägliche Bereitstellung und Fehlerfreiheit werden Betriebsaufgabe |
| LUGAS-Testsystem | technische Integration vor Live-Betrieb | Sandbox gehört in den Projektplan |
| Datenschutzhinweise | Information zu Zwecken, Rechtsgrundlagen, Datenkategorien und Fristen | Datenschutz ist Teil der Architektur, nicht nur ein PDF |
Welche Daten in LUGAS und Safe-Server-Prozessen auftauchen
Die Datenschutzhinweise machen klar, wie umfangreich die Datenlage ist. Für die Zentraldateien nennt die GGL persönliche Daten, Einzahlungslimits, Einzahlungsdaten, Aktivstatus, Pseudonym und anbieterbezogene Kennungen. Für das Auswertesystem der Safe-Server kommen weitere Ereignisse hinzu: spielerbezogene Anfragen an Zentraldateien und Sperrdatei, Registrierungen, Limits, genutzte Zahlungswege und Zahlungsdienstleister, Kontostand, Transaktionen, Logins, Hinweise zur verstrichenen Spielzeit, Einsätze, Gewinne, Verluste und Marker aus dem Monitoring des Spielverhaltens.
Die Speicherlogik ist ebenfalls technisch. Daten zur Pseudonymbildung sollen nach Erstellung des Pseudonyms gelöscht werden. Einzahlungsdaten werden mit Ablauf des jeweiligen Kalendermonats gelöscht. Safe-Server-Datenpakete liegen als Chunks mit Events vor. Die Chunks haben eine Löschfrist von 24 Monaten nach Abholung beim Anbieter. Das Auswertesystem ist auf tägliche Abholung ausgelegt, Anbieter müssen Daten täglich bereitstellen.
Für IT-Teams ist das kein Randthema. LUGAS ist eine Datenpipeline mit regulatorischer Wirkung. Event-Erzeugung, Zeitstempel, Pseudonymisierung, Fehlerbehandlung, Wiederholmechanismen, Monitoring und Datenqualität müssen stabil laufen. Ein technischer Fehler ist nicht nur ein Bug. Er kann Spielerschutz, Einzahlungslimits, paralleles Spiel, Aufsichtsauswertung und Nachweispflichten berühren. Die technische Einordnung der LUGAS-Datenplattform mit Limitdatei und Aktivitätsdatei wird durch den Downloadbereich damit konkreter.
Checkliste: Was Anbieter jetzt intern prüfen sollten
Aus den GGL-Unterlagen lässt sich eine praktische Checkliste für Anbieter, Plattformbetreiber und Dienstleister ableiten. Die Dokumente sollten nicht einzeln betrachtet werden. Payment Blocking, OWASP-Pentest, LUGAS, Safe-Server und Datenschutz bilden zusammen einen technischen Compliance-Stack. Wer einen Teil davon isoliert behandelt, übersieht schnell Abhängigkeiten zwischen Payment, Security, Datenschutz und Betrieb.
Technische Due Diligence für Payment, Security und Datenschutz
Der Downloadbereich eignet sich als Prüfliste für technische Due Diligence. Wer Plattformen für deutsches Online-Glücksspiel baut oder betreibt, sollte die Dokumente in Projektplanung, Betriebshandbuch, Datenschutzkonzept und Release-Prozess übersetzen. Entscheidend ist nicht nur, ob ein PDF vorliegt. Entscheidend ist, ob die Plattform jeden dort genannten Prozess technisch zuverlässig abbildet.
- Payment: Bankdaten, Händler-IDs, Zahlungsdienstleister und Änderungen zentral dokumentieren.
- Security: OWASP-Prüfpunkte in Entwicklung, QA und Release-Freigabe integrieren.
- CVSS: Findings nicht nur sammeln, sondern gegen Freigabeschwellen und Fristen steuern.
- LUGAS: Testsystem früh anbinden und Fehlerfälle in der Sandbox simulieren.
- Safe-Server: Event-Vollständigkeit, Unveränderbarkeit, tägliche Bereitstellung und Monitoring prüfen.
- Datenschutz: Datenkategorien, Speicherfristen und Informationspflichten mit der technischen Architektur abgleichen.
- Betrieb: Zuständigkeiten zwischen Compliance, IT, Datenschutz, Payment und externen Dienstleistern schriftlich festlegen.
Warum die GGL-Unterlagen ein RegTech-Stack sind
Der sicherste Ansatz ist ein gemeinsames Kontrollmodell. Payment-Team, Plattform-Entwicklung, Security, Datenschutz und Rechtsabteilung sollten dieselben Stammdaten und dieselbe technische Realität sehen. Ein Pentest findet Schwachstellen. LUGAS meldet und sammelt Events. Payment Blocking adressiert Zahlungswege. Safe-Server liefern Aufsichtsdaten. Datenschutz ordnet Verarbeitung, Zweck, Rechtsgrundlage und Frist. Wenn diese Bereiche getrennt arbeiten, entstehen Lücken.
Genau hier wird das Thema zum RegTech-Fall. Bei Compliance-Dashboards für Casinos geht es um dieselbe Grundidee: Regulierung wird technisch messbar. Der GGL-Downloadbereich zeigt die deutsche Variante. Statt nur Regeln zu formulieren, verlangt die Aufsicht Nachweise, Schnittstellen, Berichte, Datenlieferung und technische Prüfpfade.
Der am 23. Juni 2026 aktualisierte GGL-Downloadbereich ist kein reines Formulararchiv. Er ist eine technische Landkarte für reguliertes Online-Glücksspiel in Deutschland. Anbieter müssen Zahlungswege offenlegen, Pentests nach OWASP dokumentieren, LUGAS im Test- und Live-Betrieb anbinden, Safe-Server-Daten korrekt liefern und Datenschutzpflichten systemnah umsetzen. Wer illegales Online-Glücksspiel technisch und regulatorisch einordnet, sieht an diesen Unterlagen auch, warum erlaubte Anbieter deutlich mehr Infrastruktur betreiben müssen als eine normale Webseite.
Der GGL-Downloadbereich macht sichtbar, wie technisch die Glücksspielaufsicht geworden ist. Payment Blocking hängt an konkreten Zahlungskennungen, der OWASP-Pentest wird über CVSS messbar, LUGAS verbindet Limitdatei, Aktivitätsdatei und Testsystem, und Safe-Server liefern tägliche Aufsichtsdaten. Für Anbieter ist das ein Compliance-Stack aus Payment, Security, Datenschutz und Betrieb. Für Spieler erklärt es, warum regulierte Angebote nicht nur eine Lizenz, sondern eine komplette Kontrollarchitektur brauchen.