Betrieb und Compliance → Lizenztypen und Anforderungen

Lizenztypen und Anforderungen

1) Bild der Arten von Lizenzen

• B2C (Betreiber): das Recht, den Endnutzern Spiele anzubieten (Casino, Live, Wetten, Poker, Lotto usw.).
• B2B (Provider): das Recht, den Betreibern eine Plattform/Inhalte/Dienste zur Verfügung zu stellen (Plattform, Spiele/RNG, Live-Studios, Zahlungen als Technologieanbieter, Hosting).

• Casino/Slots, Live Casino, Sportsbook (fixed-odds, in-play), Poker (P2P), Bingo/Lottery, Fantasy/Skill-based.

• Eigene Lizenz (Betreiber/Markeninhaber).
• White-Label (B2C-Recht durch Plattformlizenz mit Markenunterlizenzierung/-berechtigung).
• Skin/Brand Authorization (Anbindung weiterer Marken an eine bestehende Lizenz).
• Verteiltes Modell (lokale Lizenz + regionalübergreifende Infrastruktur, Mirrors/Edge/Datenlokalisierung nach Normen).

2) Anforderungen: Was die Regulierungsbehörden fragen (Rahmen)

Legal/Corporate

Begünstigte, Eigentümerstruktur, keine Sanktionen/Verurteilungen.
Lokale Präsenz (juristische Person/Vertretung/verantwortlicher Offizier).
Verträge mit Anbietern (B2B), inhaltliche Rechte, Hosting/Rechenzentren.

Finanzen

Mindestkapital/Mindestreserven, Finanzgarantien/Bankgarantien.
Getrennte Kundenkonten/Trennung von Geldern, Anti-Chargeback-Verfahren.
Geprüfte Berichterstattung, Mittelquellen der Begünstigten (SoF/SoW).

Technisch (Plattform/Infrastruktur)

Architektur, Logging/Observability, Redundanz, DR/BCP.
Integrität der Spiele: RNG/Mathematik, Inhaltszertifizierung, Versionsänderungskontrolle.
Informationssicherheit: Verschlüsselung bei Rest/in Transit, IAM, Admin-Aktivitätsprotokoll.
Geo-Einschränkungen/Datenlokalisierung, Schutz vor Bots und Betrug.

RG/KYC/AML

Alter/Identitäts- und Adressverifikation, RER/Sanktionen, Limits/Selbstausschluss.
Transaktions- und Verhaltensüberwachung (Velocity, SoF), EDD-Verfahren.
Selbstausschlussregister/Schwarze Listen, Schulung des Personals.

Marketing/Werbung/Affiliates

Altersabhängige Disclaimer, das Verbot von „risikofreien“ Versprechungen, die Begrenzung von Kanälen/Zeitschlitzen.
KYB-Affiliates, Creative Library, UTM/Traffic Source Tracing.

Reporting und Audit

Periodische/Real-Time-Uploads (GGR, RG-Fälle, Reklamationen, AML/SAR).
Externe/interne Audits: Tech-Audits, Game/RNG-Audits, Sicherheits-/Datenschutzaudits.
Incident-Reporting (SLA-Benachrichtigungen der Regulierungsbehörde/Banken/Spieler).

3) Datenmodell „Lizenzregister“ (YAML)

yaml license_id: B2C-CASINO-<COUNTRY>-<NNN>
role: b2c      # b2c      b2b verticals: [casino, live, betting]
jurisdiction: <ISO-2>
holder: <legal_entity>
brands: [brandA, brandB]
local_presence: required  # required      optional      none valid_from: YYYY-MM-DD valid_to: YYYY-MM-DD financial_guarantee: {type: bank_guarantee, amount: <currency_amount>}
tech_requirements:
rng_cert: true siem_logs: true dr_rto: "30m"
data_localization: false rg_kyc_aml:
kyc_levels: [basic, address, edd]
self_exclusion: registry aml_ruleset: "v3. 1"
ads_affiliates:
disclaimers: [age, wagering_conditions]
restricted_channels: [tv_daytime]
reporting:
frequency: monthly formats: [csv, api]
realtime: [rg_cases]
contacts:
compliance_officer: email@domain mlro: aml@domain review_sla_days: 180 status: active

4) Lizenzlebenszyklus und Verpflichtungen

4. 1. Lizenzanspruch (Antrag)

Pre-DD: Struktur, SoF/SoW, lokales Unternehmen/Agent, B2B-Verträge.
Technisches Paket: Architekturplan, Sicherheit, BCP/DR, Freigabe-/Änderungsprozesse, Logging/Audit.
Inhalt: RNG/Mathematik, Anbieterliste, Integrationen.
Operative Richtlinien: RG/KYC/AML, Vorfälle, Werbung, Beschwerden.
Finanzen: Kapital/Garantien, Businessplan, Berichts- und Steuerprognose.

4. 2. Betriebsphase (Post-Grant)

Einhaltung des Policy/Controls-as-Code.
Berichterstattung nach Zeitplan, Führung von Registern (Beschwerden, AML/RG-Fälle, Vorfälle).
Änderungsabsprachen: Releases, neue Anbieter, Hosting-/Datacenter-Wechsel, neue Zahlungsmethoden.

4. 3. Erneuerung (Renewal)

Aktualisierte RNG/Sicherheitszertifikate.
Periodenaudit, RG/AML-Kennzahlen, Reklamationsstatistik.
Nachweis der finanziellen Nachhaltigkeit/Garantien.

4. 4. Änderungen (Variation)

Hinzufügen von Vertical/Brand, White-Label/Skin, Plattform-Migration.
Mitteilungen über den Wechsel der Begünstigten/Direktionen.
Änderungen der Werbepolitik und des Affiliate-Netzwerks.

5) Rollen-/vertikale Verpflichtungsmatrix (Beispiel)

6) Checkliste für die Bewerbung (Application Dossier)

Unternehmenseinheit

• Eigentümerstruktur/Begünstigte/SoF/SoW.
• Lokale juristische Person/Vertreter, Befugnisse der Offiziere.

Finanzen

• Geprüfte Berichterstattung/Plan.
• Bankgarantie/Versicherung/Kaution.

Technik

• Architektur, Beobachtbarkeit/Logging/Audit, CI/CD, Change Management.
• BCP/DR (RTO/RPO, Testprotokolle), Sicherheit (Verschlüsselung, IAM, Geheimnisse).
• RNG/Content-Zertifizierung, Kontrolle von Spiel-Releases.

Vorgänge/Richtlinien

• RG/KYC/AML, Beschwerden, Incidents/Reporting, Sapport/SLA.
• Werbung/Affiliates: Regeln, Vorlagen, Kreativbibliothek.

Berichterstellung

• Upload-Formate, Frequenzen, Testdateien, Ansprechpartner.

7) Kontrolle im Verkauf: Policy-/Controls-as-Code

yaml control_id: RG-LIMIT-LOSS-DAILY scope: bets trigger: loss_today > limit_loss_daily actions:
- block: further_bets
- notify: player_template_rg_limit evidence:
fields: [loss_today, limit, messages_sent, ack]
overrides:
- country: <ISO>
set: {limit_loss_daily: <amount>, cool_off_hours: <N>}
owner: rg_officer review_sla_days: 180

yaml control_id: AML-VELOCITY-01 scope: deposits trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3 OR count_unique(payment_method,1h)>=3 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- notify: mlro evidence:
store: s3://evidence/aml-velocity/{player_id}/{ts}
owner: mlro

yaml policy_id: RELEASE-GATE-COMPLIANCE require:
- country_overrides_present: true
- report_schemas_valid: true
- rg_controls_enabled: true
- ads_templates_localized: true on_fail: block_release

8) Änderungsmanagement unter Lizenz (SOP, Snippets)

SOP: Hinzufügen einer neuen Marke (Skin)

1. Überprüfen Sie die Lizenzbedingungen (ob Markenautorisierung zulässig ist).
2. brend/domen/lokalisaziju/wosrastnyje die Zeichen zu registrieren.
3. Binden RG/KYC/AML/Ads Richtlinien und Berichterstattung.
4. Berichte testen (Brand-Split), Protokollierung aktivieren.
5. Benachrichtigen Sie die Regulierungsbehörde/Banken (falls erforderlich), erfassen Sie evidence.

SOP: Anbindung eines neuen Spieleanbieters

1. Überprüfen Sie den Status/die Zertifikate des Anbieters im Register.
2. Content Set/Verticals abstimmen, RNG/Metriken/Logging konfigurieren.
3. Aktualisierung der Berichterstattung (Spiel/Anbieter-IDs).
4. Freigabe über policy-gate, evidence sammeln.

9) RACI (Funktionen)

10) Verpflichtungskalender (Compliance Kalender, Beispiel)

Täglich: RG/AML Monitoring, Incident-Reporting unter Fakten.
Wöchentlich: Integrationsberichte der Anbieter/Zahlungen, Alert-Compliance-Check.
Monatlich: regulatorische Entladungen (GGR/Beta/RG-Fälle), Abstimmungen mit DWH.
Vierteljährlich: Tech-Audits/Sicherheitsscans, Berichte von Anbietern, Policy/Controls Revue.
Halbjahr/Jahr: Verlängerung der RNG/IB-Zertifikate, Prüfung der Wirksamkeit der Kontrollen, Verlängerung der Lizenzen/Genehmigungen.

11) Anti-Muster

„Die Lizenz ist da - die Prozesse danach“: fehlende Controls-as-Code, Berichte und Evidence.
Zwei Versionen der Wahrheit: Excel-Berichte ≠ produktive Protokolle.
Kein Brand-Split in den Daten, ein „gemeinsamer Haufen“ von Metriken.
Manuelle EDDs ohne Vorschriften/Fristen und Protokollierung.
Werbung über Affiliates ohne KYB und Creative Library.
Keine DR-Tests/Änderungsprotokolle für RNG/Spiele.

12) Reifegradmetriken

Coverage kontrolej: ≥ 95 % der kritischen Punkte (registrazija/deposit/stawki/wywod/bonussy).
Reporting SLA: Aktualität der Entladungen ≥ 98%, schematische Fehler = 0.
Evidence completeness: ≥ 98% der Fälle mit korrekten Paketen.
RG/AML KPIs: Anteil der verhinderten/eskalierten Fälle, False Positive ↓ QoQ.
Audit Findings TTR: Schließung ≤ 90 Tage.
Policy Review SLA: überfällige Revisionen = 0.

13) 30/60/90 - Umsetzungsplan

• Erstellen Sie ein Lizenzregister und eine Anforderungstaxonomie nach Rollen/Vertikalen.
• Anhebung des Basissatzes Controls-as-Code (RG/AML/Reporting).
• Sammeln Sie Application Dossier-Vorlagen (Corporate/Financial/Tech/Operational).
• Aktivieren Sie release-gate compliance im CI.

• Verbinden Sie die Berichtsvitrinen und automatisieren Sie die Entladungen (Brand-Split, Country-Split).
• RG/KYC/AML in Produkt-Flows einbetten; evidence-by-design starten.
• Führen Sie das erste interne Tech-Audit und den DR/BCP-Test unter lizenzierten RTO/RPOs durch.

• Decken Sie ≥ 95% der kritischen Punkte mit Kontrollen ab, SLA Reporting ≥ 98%.
• Formalisierung des RACI und des Verpflichtungskalenders; KPIs an OKRs von Teams binden.
• Bereiten Sie das Paket für die Lizenzverlängerung/-variation vor (Variationen von Marken/Verticals).

14) FAQ

Q: Was zu wählen: eigene Lizenz oder White-Label?
A: Eigene Lizenz - über SAREH/Begriff, aber Kontrolle und Unternehmensbewertung sind höher. White-Label - schnellere Einführung, geringere Flexibilität/Bewertung, Abhängigkeit vom Lizenzinhaber.

F: Wie kann ich das Risiko einer Ablehnung der Bewerbung minimieren?
A: Starkes technisches Paket (Sicherheit/DR/Beobachtbarkeit), finanzielle Garantien, transparentes SoF/SoW, ausgereifte RG/AML-Prozesse und „evidence-by-design“.

F: Wie verwalte ich Änderungen an Anbietern/Inhalten?
A: Durch Variationsverfahren: Vorabverhandlung, Versionskontrolle von Spielen/RNG, Reporting und Logging von Releases.