1) Cel i zakres

• Katalog raportów i harmonogram
• Formaty i schematy danych
• zasady walidacji i kontroli jakości;
• kanały transmisji i potwierdzenia;
• role i RACI, dziennik artefaktów i retencji.

2) Role i RACI

Właściciel: Szef Zgodności - zatwierdza wersje, priorytety (A).
Schemat Steward (DWH Lead) - wsparcie dla schematów i odwzorowań (R).
Producenci: AML/RG/Payments/Game Ops - źródła danych (R).
QA/DQ: Data Quality Team - walidacje, zestawy testowe (R).
Prawo: interpretacja norm, zatwierdzanie zmian (C).
Bezpieczeństwo/DPO: PII/Aliasing, Kanały dostawy (C).
Operacje raportowania: prześlij, podpisz, wyślij, potwierdź (R).

3) Katalog raportów (klasy)

1. Raporty z gry - zakłady/wygrane/salda/sesje, RTP, uczciwość.
2. Finanse - depozyt/wypłata, odliczenia, podatki, GGR/NGR, obciążenia zwrotne.
3. AML/CFT - podejrzane transakcje, PEP/sankcje, agregaty ryzyka.
4. Responsible play (RG) - samodzielne wyłączenia, limity, interwencje.
5. Incydent - dostępność, wycieki, powiadomienia i terminy.
6. Marketing/podmioty powiązane - źródła ruchu, ograniczenia w reklamie (jeśli jest to wymagane licencją).
7. Techniczna - czas pracy, wersje RNG, skróty budowania/konfiguracji, dziennik audytu.

Każdy raport opisany jest kartą (§ 4).

4) Karta raportu (szablon)

ID: REP- <code >/Version: v <MAJOR. MINOR >/Owner: <role>
Jurisdiction/License: <e.g. MT/MGA B2C, GB/UKGC, SE/Spelinspektionen>

5) Data formats: standards

5. 1 CSV/TSV

Encoding: UTF-8 without BOM.
Delimiter: ',' (CSV), or '\t '(TSV).
Escape '' around delimited/line feed fields.
Decimal separator: '.'; Date/Time - ISO-8601 'YYYY-MM-DDThh: mm: ssZ'.

Example (CSV, rates):

report_date,player_id_hash,game_code,currency,stake,win,round_id,session_id,geo,ts_utc

2025-10-31,4b1c...a9,EGT_40SUPERC,EUR,1. 00,0. 00,rd_789,ss_123,DE,2025-10-31T15: 02:11Z

5. 2 XML

Namespace fixed; XSD validation.
Null values as empty element with'nil = "true" 'attribute.

5. 3 JSON

JSON Lines for large offloads; JSON Schema v2020-12.
Timezones - UTC; sums - decimal with string representation.

5. 4 XLSX

Used only if prescribed by the regulator. The sheet template and column names are fixed.

6) Core dictionaries

6. 1 Common fields

'report _ date '(DATE, UTC) - key date (aggregation window).
'operator _ id '(STRING) - ID of the license/operator.
'player _ id _ hash '(STRING) - hashed player ID (salt per jurisdiction).
'geo '(STRING, ISO-3166-1 alpha-2) is the country of the player/session.
`currency` (STRING, ISO-4217).
'ts _ utc '(TIMESTAMP) is the moment of the event.

6. 2 Gaming

`game_code`, `provider_code`, `round_id`, `session_id`, `stake`, `win`, `bonus_flag`, `rtn_balance_before/after`, `rake`.

6. 3 Payments

`txn_id`, `method_code`, `psp_id`, `amount`, `fee`, `status`, `decline_reason`, `kya_level`, `chargeback_flag`.

6. 4 AML/RG

`risk_score`, `peps_hit`, `sanctions_hit`, `sar_id`, `rg_limit_type`, `rg_breach`, `self_exclusion`.

7) Jurisdictional features (examples)

MT (MGA): monthly gaming aggregates: bets/winnings/RTP by title and provider; CSV/XLSX format currency code, split into "cash/bonus."
GB (UKGC): reports on RG (self-exclusion), marketing (channel compliance), incident notifications; CSV/XML preference, portal.
NL (KSA): detailed game events (often JSON/XML), strict time synchronization and fields for CRUKS (self-exclusion register).
SE (Spelinspektionen): Spelpaus integration, reports on RG interventions; CSV format, SFTP.
DE (GlüStV): rate/deposit limits and compliance, RG events; locale DE, but the numbers are '.'.
ES/PT/IT: monthly GGR aggregates/taxes/active players, XLSX/CSV; separate report on bonuses and advertising.

> The register for all markets is kept in Git/Confluence; any changes are recorded by the changelog.

8) Transmission channels and security

Regulator portals: downloading a file, obtaining a registry ID.
API: OAuth2/MTLS, quota, retray with idempotency.
SFTP: encryption in transit, PGP file signature, atomic calculation ('.part' → '.csv').
Mail (secure): only on demand, encrypted/signed.

Artifacts: receipts/receipt ID, checksums (SHA256), send logs.

9) Data quality control (DQ) and validation

9. 1 Check layers

1. Schema validation: types, mandatory, value domains.
2. Business rules: balanced identities ('opening + deposit − within − bet + win = closing ± adj'), valid RTP ranges.
3. Cross-source reconciliation: PSP vs. wallet vs. GL (general ledger).
4. Freshness: SLA window display updates; late events are marked and loaded.
5. Uniqueness: 'txn _ id', 'round _ id' are unique within the window.

9. 2 Model rules

`stake ≥ 0`, `win ≥ 0`; when 'bonus _ flag = 1' - a separate bucket.
`currency ∈ ISO-4217`; `geo ∈ ISO-3166-1`.
'ts _ utc'inside the report window; time zone - UTC only.
For returns, separate records with'amount <0'and'status = REFUND'.

10) Liniage and circuit versioning

Lineage: for each field - source (table/column), transformation (SQL/udf), owner.
Semantic Versioning:
MAJOR - incompatible changes (deleting/renaming fields).
MINOR - Add optional fields.
PATCH - Description/Validation Corrections.
Deviation Policy: double unloading period (old + new format) ≥ 1 reporting cycle.
Change Log: date, author, reason, jurisdictions affected.

11) Aliasing and PII

Hashing 'player _ id' with salt on jurisdiction; salt is stored in a secret storage.
Masking e-mail/phone, if required.
Access Profiles: PII only sees DPOs/Commissioners; export to portals - already with hashes.

12) Mapping Examples (DWH → Report)

Game unit (day, title, currency):

sql

WYBIERZ

DATE_TRUNC („dzień”, ts_utc) AS report_date,

game_code,

waluta,

SUMA (stawka) JAKO stake_sum,

SUMA (wygrana) JAKO win_sum,

SAFE_DIVIDE (SUMA (wygrana), NULLIF (SUMA (stawka), 0)) AS rtp

OD fact_game_rounds

GDZIE ts_utc> =: od I ts_utc <: do

GRUPA PRZEZ 1,2,3;

Payments (deposits/withdrawals/fees):

sql

WYBIERZ

DATE_TRUNC („dzień”, ts_utc) AS report_date,

method_code, psp_id, waluta,

SUMA (PRZYPADEK, GDY TYP = "DEPOZYT' TO KWOTA INNA 0 KONIEC) JAKO DEPOZYTY,

SUMA (PRZYPADEK, GDY TYP = „WYCOFANIE” TO KWOTA INNA 0 KONIEC) JAKO WYCOFANIE,

Opłaty SUMA (opłata) JAKO

OD fact_payments

• GRUPA PRZEZ 1,2,3,4;

13) Sample files

13. 1 Gaming Unit (CSV)

report_date,operator_id,game_code,currency,stake_sum,win_sum,rtp

2025-10-31,OP123,NET_STARBURST,EUR,125000. 50,119800. 00,0. 9585

13. 2 RG Events (JSON Lines)

{"report _ date": "2025-10-31", "player _ id _ hash": "b93e"..., "rg _ event": "SELF _ EXCLUSION", "duration _ days": 180, "ts _ utc':" 2025-10-31T09: 11: 02Z "}

{"report _ date": " 2025-10-31 ", "player _ id _ hash ": "c01a "..., "rg _ event ": "LIMIT _ BREACH"," limit _ type":" LOSS _ DAILY"," amount":" 200. 00 „,” ts _ utc': „2025-10-31T13: 45: 22Z”}

13. 3 AML aggregate (XML, fragment)

xml

14) Proces obrotu operacyjnego

1. Przygotowanie okna: zamrażanie, obliczanie kruszyw, przeładowywanie późnych zdarzeń.
2. Walidacje: schemat + zasady biznesowe + uzgodnienie.
3. Generowanie plików: wersja schematu w nazwie ('REP-GB-GAME-v1. 3_2025-10-31. csv ").
4. Podpis/hash: PGP + SHA256.
5. Dostawa: portal/API/SFTP; dziennik odbioru (ID/paragon).
6. Archiwizacja: oryginał + podpis + paragon w magazynie raportów.
7. Monitorowanie: tablica kontrolna „Raport regulacyjny” - status „gotowy/wysłany/przyjęty/błąd”.
8. Retro: analiza błędów/odchyleń, CAPA.

15) Listy kontrolne

Przed wysłaniem

[] Potwierdzono datę okna i strefy czasowej.
[] Wszystkie walidacje są zielone, zgłoszone kwoty są uzgadniane z GL/PSP.
[] Wersja schematu pasuje do rejestru.
[] PII zamaskowane/aliased.
[] Plik podpisany/zaznaczony, hash committed.
[] Kontakt regulatora jest aktualny (portal jest dostępny).

Po wysłaniu

[] Otrzymany paragon/identyfikator, archiwizowany.
[] Status zaktualizowany w desce rozdzielczej.
[] Plan aktualizacji w przypadku błędu walidatora jest uzgodniony.

16) Metryka i SLO

Terminowość:% sprawozdań złożonych na czas.
First-Try Acceptance:% akceptowane bez korekt.
Wynik DQ: procent wpisów bez błędów (schemat/biznes).
Różnica w uzgodnieniu: bezwzględna/procentowa rozbieżność z GL/PSP.
Czas realizacji raportu: czas od zamknięcia okna do złożenia.
Zmiana wskaźnika awarii (formaty): udział wersji schematu z rolkami.

17) Zarządzanie

kwartalny przegląd roszczeń według jurysdykcji; nieplanowane - podczas aktualizacji regulatora.
RFC dla zmian schematu: analiza wpływu, interoperacyjność, pilotaż piaskownicy.
Podwójne rozładowanie w cyklu MAJOR ≥ 1.
Zespoły szkoleniowe na temat wydań, aktualizacji odtwarzaczy i często zadawanych pytań.

18) Częste błędy i jak ich uniknąć

Nieprawidłowy timezon: zawsze konsolidować w UTC, przechowywać lokalizację oddzielnie.
Zaokrąglenie: użyj dziesiętnych, jednolitych zasad zaokrąglania banków.
Niespójność identyfikatorów: pojedyncze rejestry "game _ code", "method _ code", "psp _ id'.
Lokalizacja numerów/dat: tylko ISO-8601 i okres jako separator dziesiętny.
PII w jasny: sprawdzanie masek w pre-commit i CI.

19) Osadzanie w ekosystemie

Komunikacja z sekcjami: Deska rozdzielcza zgodności, Powiadomienia i terminy, Playbooks incydentów, Zarządzanie kryzysowe, Dzienniki audytu.
W bot incydent: command '/report <jurisdiction> <report_id>' - uzyskać schemat i terminy.
Eksportowanie migawek na S1/S2 jest dodawane do pakietu artefaktowego.

20) Plan realizacji (30 dni)

Tydzień 1

1. Spis wszystkich raportów regulacyjnych dotyczących licencji.
2. Tworzenie kart (§ 4) i słowników kodowych.
3. Zatwierdzanie formatów i kanałów transmisji.

Tydzień 2
4. Budynek DWH i pokazy lineage; walidacje pierwotne.
5. Generowanie plików pilotażowych (jeden rynek/klasa).
6. Konfigurowanie podpisu/haseł i archiwum.

Tydzień 3
7. Integracja z portalem piaskownicy/API/SFTP.
8. Statusy deski rozdzielczej i wpisy według terminów.
9. Szkolenie operacyjne i listy kontrolne.

Tydzień 4
10. pilotażowe dostarczenie 2-3 sprawozdań; zbieranie informacji zwrotnych.
11. CAPA dla DQ/walidacji; dostosowania systemów.
12. Zwolnienie v1. 0; harmonogram zmian i jeden kalendarz terminów.

Sekcje powiązane:
Zawiadomienia o naruszeniach i terminach sprawozdawczych
Deska rozdzielcza zgodności i monitorowanie
Playbooks incydentów i skryptów
Zarządzanie kryzysowe i komunikacja
Plan ciągłości działania (BCP )/DRP
Dzienniki kontroli transakcji