GH GambleHub

Compliance Dashboards und Monitoring

1) Zweck und Aufgabenbereich

Ein einziges Panel für die tägliche Kontrolle der Einhaltung der Anforderungen: Lizenzen und Aufsichtsbehörden, Datenschutz (DSGVO/PII), Zahlungen und PCI, AML/CFT, Responsible Gaming (RG), Marketing- und Affiliate-Richtlinien, Spieleanbieter, obligatorische Benachrichtigungen und Berichterstattung. Das Dashboard dient als Wahrheitsquelle für Compliance/Legal/Security/Payments/RG/AML und Prüfungsmaterial.

2) Rollen und RACI

Product Owner (Head of Compliance) - Vision, Prioritäten, Release-Versionen. (A)

Data Owner (DWH Lead) - Schaltungen, SLA Frische, Lineage. (R)

Compliance Analysts/AML/RG - KPI/KRI, Alert, Interpretation anpassen. (R)

Sicherheit/DSB - DSGVO/PII/Vorfälle, Betroffenenrechte. (R)

Payments Lead - PSP/PCI, Retouren, chargebacks. (R)

CS/CRM - Kommunikation mit den betroffenen Kunden. (C)

Legal - Interpretation von Normen, Harmonisierung der Texte von Benachrichtigungen. (C)

Engineering - Sammlung von Telemetrie, Integration von Anbietern. (R)

3) Dashboard-Framework: Abschnitte und Schlüssel-Widgets

3. 1 KYC/KYB

KYC-Abschlussrate (D-1) = verifizierte Konten/Neuanmeldungen.
Pending> SLA (Stück): Anwendungen in der Warteschlange länger als X Stunden.
Tier Escalations: Übertragungen auf ein erhöhtes Verifizierungsniveau.
False Positive Rate (KYC-Betrugsflags).
Dokumente, die ≤30 Tage verfallen (Reisepass/Adresse).

3. 2 AML/CFT

SAR/STR Queue: offene Fälle nach Stufen.
High-Risk Segments:% des Umsatzes der Kunden von HR-Ländern/Methoden.
Unusual Patterns (velocity/structuring): Anomaliedetektor (Tag).
PEP/Sanctions Hits: Neue Zufälle, Time-to-Review.
Average Case Closure Time и % в SLA.

3. 3 Verantwortungsvolles Spielen (RG)

Self-Exclusion/Timeouts: neu/aktiv, Einzahlungsrückzahlungen.
Loss/Session Limits Breaches: Verstöße,% der verarbeiteten Benachrichtigungen.
Vulnerable Players Outreach: Reichweite und Kontaktzeit.
RG-Interventionseffektivität: Verringerung der Verluste nach der Intervention.

3. 4 Zahlungen und PCI

PSP Health: auth-rate, decline-rate, latency by methods/geo.
Chargeback Ratio (М-к), Refund SLA, Disputes Age.
PCI Events: Scan von Schwachstellen, Schlüsselrotation, Pan-Tokenisierung.
Anomale Cashouts: Überschreitung von Schwellenwerten/Scoring.

3. 5 DSGVO/PII und Vorfälle

Data Access Requests (DSAR): eingehende/in SLAs, überfällig.
Privacy Incidents: offen/geschlossen, TTS (Time-to-Statement), MTTR.
PII Inventory Drift: Änderungen im Feld-/Retentionsregister.
Breach Notification Timeliness:% der Benachrichtigungen auf Zeit.

3. 6 Regulierungsbehörde/Lizenzen

Pflichtberichte: Terminkalender (30/7/1 Tag).
Einhaltung der Bedingungen für Werbung/Boni: Flags von Inkonsistenzen auf den Märkten.
Protokoll der Interaktion mit den Regulierungsbehörden: Status der Tickets/Anfragen.

3. 7 Marketing/Affiliates

Attribution Integrity: Post-Back-/Pixel-Diskrepanzen, „fehlende Klicks“.
Compliance Flags: Verbotene Kreative/Zielgruppen.
Partner Score: Index der Partnerdisziplin (KPIs/Deadlines/Reklamationen).

3. 8 Spieleanbieter und Ehrlichkeit

RTP Drift Monitor: Abweichungen vom angegebenen RTP (Titel/Studio Granularität).
Fairness Incidents: Stopps/nicht synchronisierte Runden, Balance-Fehler.
Game Provider Health: API-Fehler, Anteil der Nichtverfügbarkeit.

4) Schwellenwerte und Schweregrad (Beispiel)

S1 (kritisch): Auth-Rate nach Top-PSP <60% ≥ 15 min; bestätigte PII-Leckage; massiver Verstoß gegen die RG.
S2 (hoch): Ladungsverhältnis> 1. 5% für 7 Tage; DSAR> SLA für 48 Stunden; Rückgang der KYC-Konversion> 20% d/d.
S3 (Durchschnitt): Anstieg der Ausfälle des Spieleanbieters> 5% Stunde zu Stunde; 2 + Partner mit verbotenen Kreativen.
S4 (niedrig): lokale Mängel, Einzelreklamationen.

SLA-Updates: S1 - die erste Nachricht ≤15 min; S2 - ≤30 Minuten S3 - nach Schichtplan.

5) Alert-Regeln (Skelett)

Detect: Die X-Metrik überschreitet die Y-Schwelle im Z-Fenster.
Suppress/Dedupe: Gruppierung nach Markt/Methode/Anbieter.
Route: Kanal (War-Room/On-Call/Status), RACI-Empfänger.
Escalate: Auto-Eskalation bei Dauer> T oder Wiederholung N mal/Tag.
Explain: Link zum Playbook und FAQ für CS.
Record: Autologation in Incident Log + Snap-Charts.

6) Datenquellen und Architektur

Die transakzionnyje Hohlwege: die Depositen/Schlussfolgerungen der Tagung.
KYC/KYB-Anbieter: Prüfstatus, Ablehnungsgründe.
AML-System/SIEM: Alerts, Cases, Scoring.
PSP/Acquirer/Card Schemes: API für Berichte und Status.
CRM/CS: Fälle, Makros, ausgehende Benachrichtigungen.
Status-Seite/Incident-Bot: Timelines, Nachrichtentexte.
GDPR/PII-Register: DSAR, Retentionen, Verarbeiter.
Game Providers: API Telemetrie, RTP, Status.

Datenanforderungen:
  • Frische (Freshness SLA): KYC/PSP - ≤15 min AML/SIEM: ≤5 Minuten DSAR — D-1; RTP — D-1; RG - ≤15 min.
  • Lineage: Jedes Feld, das die Quelle/Transformation angibt.
  • Qualität: Schema-Validierer (Pflichtfelder, Coderegister, Deduplizierung).

7) Formeln und KPI/KRI-Definition (Stichprobe)

Auth Rate (Methode/Geo): "approved/attempts'.
Chargeback Ratio (мес): `chargebacks / successful transactions`.
KYC Completion Rate: `verified_accounts / new_registrations`.
SAR Submission Timeliness: „% der SARs, die ≤ X Stunden nach dem Trigger gesendet wurden“.
DSAR SLA: „% der ≤ 30 Tage abgeschlossenen Anfragen“.
RTP Drift (тайтл): `|observed_RTP − declared_RTP|`.
RG Outreach SLA: `median(time_contacted − time_triggered)`.

8) Widgets (Vorlagen)

8. 1 „Regulatorische Fristen“ (Kalender):

Liste der Berichte mit Termin, Eigentümer, Bereitschaft (%), Verzugsrisiko.
Filter: Gerichtsbarkeit, Typ (Lizenz/AML/Spiele).

8. 2 „PSP Map“ (Geo/Methoden):

Heatmap auth-rate, latency, Vorfälle in 24 Stunden

Klick → Detail nach Anbieter/Methode → Links zu Playbooks.

8. 3 “GDPR/DSAR Pipeline”:

Trichter: → in der Arbeit erhalten → wartet auf die Überprüfung → geschlossen.
Verspätung mit Gründen.

8. 4 “AML Caseboard”:

Kanban nach Stufe: Detection → Review → SAR → Closed.
SLA-Timer, Auto-Beleuchtung verspätet.

8. 5 “RG Risk Monitor”:

Limit-Brichi, Selbstausschluss, Kontakte; Wirksamkeit der Interventionen.

9) Zugriffsrichtlinien und Audit

RBAC/ABAC: Analysten sehen Aggregate; Zugriff auf PII - nur durch Maskierung/DPO-Layer.
Aktivitätsprotokoll: Wer Schwellenwerte und Regeln geöffnet/geändert hat.
Versionierung: Alert-Konfigurationen und KPI-Formeln in Git; Veröffentlichungen mit changelog.

10) Integration in den Incident-Prozess

Die Schaltfläche „Declare Incident“ aus dem Widget → ein vorgefülltes Ticket (ID, Screenshots, Ebenen S1-S4).
Auto-Generierung Holding Statement (Status-Seite/CS-Makro).
Links zu: Incident Playbooks, Benachrichtigungen und Fristen, Krisenmanagement.

11) Datenqualitätskontrolle (DQ)

Coverage: Vollständigkeit der Ereignisse vs. Benchmark (PSP-Bericht).
Consistency: Beträge/Währungen/Zeitzonen.
Outliers: IQR/3σ, visuelle Flagge.
Backfill: Dosierungsverfahren und Markierung von Retro-Änderungen.
DQ-Alerts: wenn die Frische sinkt/der Anteil null/die Aggregate divergieren.

12) Checklisten

Vor der Dashboard-Veröffentlichung

  • KPI/KRI und Formeln genehmigt.
  • Schwellenwerte und Alert-Routing konfiguriert.
  • Die Besitzer von Widgets und Frische SLAs sind registriert.
  • Aktivitätsprotokollierung und Artefakt-Export aktiviert.

Wöchentlich

  • Prüfung der Schwellenwerte für Vorfälle der Woche.
  • Überprüfung auf Fehlalarme/Auslassungen.
  • Abstimmung mit den Berichten der Regulierungsbehörden/PSP.

Vierteljährlich

  • PII-Zugriffs- und Maskenprüfung.
  • Überarbeitung der KPIs/KRIs für neue Lizenzanforderungen.
  • Übungstest: AML SAR, DSGVO DSAR, PSP-Fehler.

13) Artefakte und Exporte

Schnappschüsse von Dashboards bei der S1/S2 (PNG/PDF).
Export von KPIs (CSV/Parkett) mit Hashes und Zeitsignatur.
Alert-Protokolle mit Ursache/Button „an Vorfall binden“.
Termin-/Benachrichtigungsregister (Verknüpfung mit Tickets und Bestätigungen).

14) Eine Reihe von Warnungen (Beispiel Regeln)

PSP. AuthRate <70% (15 Min., 3 Zonen) → S2, Kanal „Payments On-Call“, Eskalation nach 30 Min.
GDPR. DSAR> 30 Tage (≥10 Stück) → S2, „DPO On-Call“, Bericht Legal.
AML. PEP Matches New> 0 (Tag) → S3, AML-Kanal, Auto-Erstellung von Fällen.
RG. SelfExclusions Spike> p95 (Tag) → S3, RG-Kanal + CS-Brief.
Game. RTP Drift > 0. 7 pp (7 Tage) → S2, Provider Ops, Freeze des Titels.
Compliance. Report Deadline ≤ 7 Tage & Fortschritt <50% → S3, Compliance-Kanal.

15) Schnellstart (30 Tage)

Woche 1

1. Vereinbaren Sie eine Liste von KPIs/KRIs und Schwellenwerten (Abschnitte 3-7).
2. Bestimmen Sie SLA Frische und Schaufensterbesitzer.
3. Heben Sie das Skelett des Dashboards an (leere Widgets + Quellen).

Woche 2

4. PSP/KYC/AML/RG-Threads anschließen.
5. Richten Sie 6 kritische Warnmeldungen ein (Punkt 14).
6. Verlinken Sie mit dem Incident Bot und der Status-Seite.

Woche 3

7. Validierung der Datenqualität (DQ-Checkliste).
8. Pilot in der On-Call-Woche, Feedback sammeln.
9. Dokumentation der Formeln/Schwellen in Git.

Woche 4

10. Release v1. 0, Benutzerschulung.
11. Post-Release Retro, Anpassung der Schwellenwerte.
12. Plan v1. 1: neue Widgets (RTP, Partner Score) und Berichte.

Verwandte Abschnitte:
  • Incident Playbooks und Szenarien
  • Meldungen von Unregelmäßigkeiten und Meldefristen
  • Krisenmanagement und Kommunikation
  • Business Continuity Plan (BCP )/DRP
  • Aktivitätsprüfungsprotokolle
  • Benachrichtigungs- und Warnsystem
Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.