1) Scopul și domeniul de aplicare

• Catalog de rapoarte și program
• Formate și scheme de date
• norme de validare și control al calității;
• canale de transmitere și confirmare;
• roluri și RACI, jurnal artefact, și retenție.

2) Roluri și RACI

Proprietar: Head of Compliance - aprobă versiuni, priorități (A).
Schema Steward (DWH Lead) - sprijin pentru scheme și mapări (R).
Producători: AML/RG/Payments/Game Ops - surse de date (R).
QA/DQ: Echipa de calitate a datelor - validări, kituri de testare (R).
Juridic: interpretarea normelor, aprobarea modificărilor (C).
Securitate/DPO: PII/Aliasing, Canale de livrare (C).
Ops de raportare: încărcați, semnați, trimiteți, confirmați (R).

3) Raport catalog (clase)

1. Rapoarte de joc - pariuri/victorii/solduri/sesiuni, RTP, onestitate.
2. Financiar - depozit/retragere, deduceri, taxe, GGR/NGR, chargebacks.
3. AML/CFT - tranzacții suspecte, PEP/sancțiuni, agregate de risc.
4. Joc responsabil (RG) - auto-excluderi, limite, intervenții.
5. Incident - disponibilitate, scurgeri, notificări și termene limită.
6. Marketing/afiliați - surse de trafic, restricții de publicitate (dacă este necesar prin licență).
7. Tehnic - uptime, versiuni RNG, build/configuration hashes, audit log.

Fiecare raport este descris de un card (§ 4).

4) Card de raport (șablon)

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

SELECTEAZĂ

DATE_TRUNC ('zi', ts_utc) CA report_date,

game_code,

monedă,

SUMA (miza) CA stake_sum,

SUMA (câștig) CA win_sum,

SAFE_DIVIDE (SUMĂ (câștig), NULLIF (SUMĂ (miză), 0)) AS rtp

DE LA fact_game_rounds

UNDE ts_utc> =: DE LA ȘI ts_utc <: la

GRUPA CU 1,2,3;

Payments (deposits/withdrawals/fees):

sql

SELECTEAZĂ

DATE_TRUNC ('zi', ts_utc) CA report_date,

method_code, psp_id, valută,

SUMA (CAZUL ÎN CARE TIPUL = 'DEPOZIT' APOI SUMA ALTFEL 0 END) CA DEPOZITE,

SUMA (CAZUL ÎN CARE TIPUL = „RETRAGERE” APOI SUMA ALTFEL 0 CAPĂT) CA RETRAGERI,

SUMA (taxa) CA taxe

DE LA fact_payments

UNDE ts_utc ÎNTRE: DE LA ȘI: la

GRUPA CU 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"," cantitate":" 200. 00 „,” ts _ utc': „2025-10-31T13: 45: 22Z”}

13. 3 AML aggregate (XML, fragment)

xml

14) Procesul operațional de cifră de afaceri

1. Pregătirea ferestrelor: congelare, calcularea agregatelor, reîncărcarea evenimentelor târzii.
2. Validări: schema + reguli de afaceri + reconciliere.
3. Generarea fișierelor: versiune schemă în nume ("REP-GB-GAME-v1. 3_2025-10-31. csv ').
4. Semnătură/hash: PGP + SHA256.
5. Livrare: portal/API/SFTP; jurnalul de recepție (ID/chitanță).
6. Arhivare: original + semnătură + chitanță în magazinul de rapoarte.
7. Monitorizare: tabloul de bord „Raportare de reglementare” - starea „gata/trimis/acceptat/eroare”.
8. Retro: analiză eroare/deviație, CAPA.

15) Liste de verificare

Înainte de a trimite

[] Fereastra și data fusului orar confirmate.
[] Toate validările sunt verzi, sumele raportate sunt reconciliate cu GL/PSP.
[] Schema versiune se potrivește registru.
[] PII mascat/aliased.
[] Fișier semnat/verificat, hash comis.
[] Contactul autorității de reglementare este actualizat (portalul este disponibil).

După trimiterea

[] Primirea/ID-ul primit, arhivat.
[] Starea actualizată în tabloul de bord.
[] Planul de actualizare în caz de eroare validator este de acord.

16) Măsurători și SLO

Actualitatea:% din rapoartele prezentate la timp.
Acceptare First-Try:% acceptată fără corecții.
Scor DQ: procentaj de intrări fără erori (schemă/afacere).
Decalaj de reconciliere: discrepanță absolută/procentuală cu GL/PSP.
Timp de plumb pentru a raporta: ora de la închiderea ferestrei la depunerea.
Modificarea ratei de eșec (formate): cota de versiuni de schemă cu rollback-uri.

17) Guvernanță

Revizuirea trimestrială a cererilor de despăgubire; neprogramate - în timpul actualizărilor regulatorului.
RFC pentru modificările schemei: analiza impactului, interoperabilitatea, pilotul sandbox.
Descărcare dublă la ciclul MAJOR ≥ 1.
Echipele de instruire pe versiuni, actualizarea cărților de redare și întrebări frecvente.

18) Greșeli frecvente și cum să le evitați

Fus orar incorect: consolidați întotdeauna în UTC, stocați localizarea separat.
Rotunjire: utilizați zecimale, reguli uniforme de rotunjire bancară.
Inconsecvența identificatorilor: single registers 'game _ code', 'method _ code', 'psp _ id'.
Localizarea numerelor/datelor: numai ISO-8601 și perioada ca separator zecimal.
PII în clar: verificarea măștilor în pre-comite și CI.

19) Încorporarea în ecosistem

Comunicarea cu secțiunile: Tabloul de bord de conformitate, Notificări și termene limită, Cărți de redare incidente, Gestionarea crizelor, Jurnale de audit.
În bot incident: comanda '/raport <jurisdicție> <report_id>' - obține schema și termenele limită.
Exportul de instantanee pe S1/S2 este adăugat la pachetul de artefact.

20) Planul de implementare (30 de zile)

Săptămâna 1

1. Inventarul tuturor rapoartelor de reglementare a licențelor.
2. Creați carduri (§ 4) și dicționare de cod.
3. Aprobarea formatelor și canalelor de transmisie.

Săptămâna 2
4. Construirea de vitrine DWH și descendență; validări primare.
5. Generarea de fișiere pilot (o piață/clasă).
6. Configurarea semnătură/hash-uri și arhivă.

Săptămâna 3
7. Integrarea cu portalul sandbox/API/SFTP.
8. Stări de bord și alerte după termene limită.
9. Raportarea Ops de formare și liste de verificare.

Săptămâna 4
10. Livrarea pilot a 2-3 rapoarte; colectarea de feedback.
11. CAPA pentru DQ/validări; ajustări ale schemelor.
12. Eliberare v1. 0; calendarul revizuirii și un calendar limită unic.

Secțiuni conexe:
Notificări privind încălcările și termenele de raportare
Tabloul de bord și monitorizarea conformității
Cărți de redare incidente și scripturi
Gestionarea crizelor și comunicații
Planul de continuitate a afacerii (BCP )/DRP
Jurnale de audit al tranzacțiilor