GH GambleHub

<επωνυμία επίσημης έκθεσης>

1) Σκοπός και πεδίο εφαρμογής

Τυποποίηση της συλλογής, παραγωγής και υποβολής ρυθμιστικών εκθέσεων για όλες τις άδειες και τις αγορές. Το έγγραφο ορίζει:
  • Κατάλογος εκθέσεων και χρονοδιάγραμμα
  • Μορφότυποι δεδομένων και σχήματα
  • κανόνες επικύρωσης και ποιοτικού ελέγχου·
  • διαύλους μετάδοσης και αναγνώρισης·
  • ρόλοι και RACI, καταγραφή τεχνουργημάτων και διατήρηση.
💡 Αποποίηση ευθύνης: συγκεκριμένα πεδία/όροι εξαρτώνται από τους όρους της άδειας. Τα τελικά έντυπα εγκρίνονται από τη νομοθεσία/συμμόρφωση.

2) Ρόλοι και RACI

Ιδιοκτήτης: Επικεφαλής Συμμόρφωσης - εγκρίνει εκδόσεις, προτεραιότητες (A).
Schema Steward (μόλυβδος DWH) - υποστήριξη για σχήματα και χαρτογραφήσεις (R).
Παραγωγοί: AML/RG/Payments/Game Ops - πηγές δεδομένων (R).
QA/DQ: Ομάδα ποιότητας δεδομένων - επικυρώσεις, κιτ δοκιμών (R).
Νομική: ερμηνεία των κανόνων, έγκριση των αλλαγών (Γ).
Security/DPO: PII/Aliasing, Delivery Channels (C).
Λειτουργία αναφοράς: αποστολή, σήμανση, αποστολή, επιβεβαίωση (R).

3) Κατάλογος εκθέσεων (κλάσεις)

1. Αναφορές παιχνιδιού - στοιχήματα/νίκες/ισορροπίες/συνεδρίες, RTP, ειλικρίνεια.
2. Χρηματοοικονομικά - καταθέσεις/αποσύρσεις, εκπτώσεις, φόροι, GGR/NGR, χρεώσεις.
3. AML/CFT - ύποπτες συναλλαγές, PEP/κυρώσεις, συγκεντρωτικά μεγέθη κινδύνου.
4. Υπεύθυνο παιχνίδι (RG) - αυτοαποκλεισμοί, όρια, παρεμβάσεις.
5. Συμβάν - διαθεσιμότητα, διαρροές, κοινοποιήσεις και προθεσμίες.
6. Μάρκετινγκ/θυγατρικές - πηγές κυκλοφορίας, περιορισμοί διαφήμισης (εάν απαιτείται από την άδεια).
7. Τεχνικά - uptime, εκδόσεις RNG, hashes κατασκευής/διαμόρφωσης, ημερολόγιο ελέγχου.

Κάθε έκθεση περιγράφεται με κάρτα (§ 4).

4) Κάρτα αναφοράς (υπόδειγμα)


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

. 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

ΕΠΙΛΟΓΉ

(«ημέρα», ) AS ,

,

νόμισμα,

ΑΘΡΟΙΣΜΑ (μερίδιο) AS stake_sum,

ΆΘΡΟΙΣΜΑ (win) AS win_sum,

(SUM (win), NULLIF (SUM (stake), 0)) AS rtp

ΑΠΟ ΤΟ fact_game_rounds

ΟΠΟΥ ts_utc> =: ΑΠΟ ΚΑΙ ts_utc <: εια

ΟΜΑΔΑ BY 1,2,3;


Payments (deposits/withdrawals/fees):

sql

ΕΠΙΛΟΓΉ

(«ημέρα», ) AS ,

, , νόμισμα,

ΑΘΡΟΙΣΜΑ (ΠΕΡΙΠΤΩΣΗ ΚΑΤΑ ΕΙΔΟΣ = «ΚΑΤΑΘΕΣΗ» ΜΕΤΑ ΤΟ ΠΟΣΟ ΑΛΛΟΥ 0 ΤΕΛΕΙ) ΚΑΤΑ ΚΑΤΑΘΕΣΗ,

ΑΘΡΟΙΣΜΑ (ΠΕΡΙΠΤΩΣΗ ΚΑΤΑ ΤΥΠΟ = «ΑΠΟΣΥΡΣΗ» ΜΕΤΑ ΤΟ ΠΟΣΟ ΑΛΛΟΥ 0 ΤΕΛΟΣ) ΚΑΤΑ ΤΙς ΑΠΟΣΥΡΣΕΙς,

ΑΘΡΟΙΣΜΑ (τέλος) τελών AS

ΑΠΟ ΤΟ fact_payments

ΟΠΩΣ ts_utc ΜΕΤΑΞΥ: ΑΠΟ ΚΑΙ: ΕΩΣ

ΟΜΑΔΑ ΜΕ 1,2,3,4;


13) Sample files

13. 1 Gaming Unit (CSV)

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

. 50,119800. 00,0. 9585


13. 2 RG Events (JSON Lines)

{"report _ date": "2025-10-31", "player _ id _ hash": "b93e"..., "rg _ event": "SELF _ EXCLUSION", "performance _ day : 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"," ποσό":" 200. 00 ", "ts _ utc":" 2025-10-31T13: 45: 22Z"}


13. 3 AML aggregate (XML, fragment)

xml

🚨 amlReport date =» 2025-10-31» Id =» OP123» xmlns = «urn: operator: aml: v1»>
τμήμα riskTier = κύκλος εργασιών" HIGH" =" 98500. 00" νόμισμα =" EUR "/>
Αριθμός σπίρτων =» 2 »/>
Αριθμός αγώνων =» 0 »/>
/amlReport>

14) Διαδικασία κύκλου εργασιών

1. Προετοιμασία παραθύρων: πάγωμα, υπολογισμός συγκεντρωτικών στοιχείων, επαναφόρτωση καθυστερημένων γεγονότων.
2. Επικυρώσεις: schema + επιχειρηματικοί κανόνες + συμφωνία.
3. Παραγωγή αρχείων: έκδοση σχήματος στο όνομα ('REP-GB-GAME-v1. 3_2025-10-31. csv ').
4. Υπογραφή/hash: PGP + SHA256.
5. Παράδοση: πύλη/API/SFTP. ημερολόγιο παραλαβής (ταυτότητα/απόδειξη παραλαβής).
6. Αρχειοθέτηση: πρωτότυπο + υπογραφή + παραλαβή στο κατάστημα αναφοράς.
7. Παρακολούθηση: ταμπλό «Regulatory Reporting» - κατάσταση «έτοιμο/αποστελλόμενο/αποδεκτό/σφάλμα».
8. Ρετρό: ανάλυση σφάλματος/απόκλισης, CAPA.

15) Κατάλογοι ελέγχου

Πριν από την αποστολή

[] Ημερομηνία παραθύρου και χρονικής ζώνης επιβεβαιωμένη.
[] Όλες οι επικυρώσεις είναι πράσινες, οι αναφερόμενες ποσότητες συμφωνούν με το GL/PSP.
[] Η έκδοση Schema ταιριάζει με το μητρώο.
[] PII μασκοφόρος/ψευδώνυμος.
[] Αρχείο υπογεγραμμένο/ελεγμένο, διεπράχθη hash.
[] Η επαφή της ρυθμιστικής αρχής είναι επικαιροποιημένη (η πύλη είναι διαθέσιμη).

Μετά την αποστολή

[] Παραλαβή/ταυτότητα, αρχειοθετημένη.
[] Η κατάσταση επικαιροποιείται στο ταμπλό.
[] Συμφωνείται επικαιροποιημένο σχέδιο σε περίπτωση σφάλματος επικυρωτή.

16) Μετρήσεις και SLO

Έγκαιρη υποβολή:% των εκθέσεων που υποβάλλονται εγκαίρως.
First-Try Αποδοχή:% αποδεκτή χωρίς διορθώσεις.
Βαθμολογία DQ: ποσοστό των καταχωρίσεων χωρίς σφάλματα (σχήμα/επιχείρηση).
Χάσμα συμφιλίωσης: απόλυτη/ποσοστιαία απόκλιση με GL/PSP.
Χρόνος αναφοράς: ο χρόνος από το κλείσιμο του παραθύρου μέχρι την υποβολή.
Ρυθμός αποτυχίας (μορφότυποι): μερίδιο των κυκλοφοριών σχήματος με rollbacks.

17) Διακυβέρνηση

τριμηνιαία επανεξέταση των απαιτήσεων κατά δικαιοδοσία· μη προγραμματισμένη - κατά τη διάρκεια επικαιροποιήσεων της ρυθμιστικής αρχής.
RFC για αλλαγές σχήματος: ανάλυση επιπτώσεων, διαλειτουργικότητα, χειριστής αμμοκιβωτίων.
Διπλή εκφόρτωση στον κύκλο MAJOR ≥ 1.
Εκπαιδευτικές ομάδες για τις κυκλοφορίες, την ενημέρωση των βιβλίων παιχνιδιού και τις συχνές ερωτήσεις.

18) Συχνά λάθη και τρόπος αποφυγής τους

Εσφαλμένη χρονική ζώνη: να ενοποιείται πάντα σε UTC, να αποθηκεύεται ο τόπος ξεχωριστά.
Στρογγυλοποίηση: χρήση δεκαδικών, ενιαίων κανόνων στρογγυλοποίησης τραπεζών.
Ασυνέπεια των αναγνωριστικών: παιχνίδι _ κωδικός ενός μητρώου ',' μέθοδος _ κωδικός ',' psp _ id '.
Εντοπισμός αριθμών/ημερομηνιών: μόνο ISO-8601 και περίοδος ως δεκαδικός διαχωριστής.
PII με σαφήνεια: έλεγχος μάσκες πριν από τη δέσμευση και CI.

19) Ενσωμάτωση στο οικοσύστημα

Επικοινωνία με τις ενότητες: Ταμπλό συμμόρφωσης, κοινοποιήσεις και προθεσμίες, βιβλία αναπαραγωγής περιστατικών, διαχείριση κρίσεων, αρχεία καταγραφής ελέγχου.
Στο σημείο αναφοράς του συμβάντος: εντολή '/αναφορά <δικαιοδοσία> <report_id>' - πάρτε το σύστημα και τις προθεσμίες.
Η εξαγωγή στιγμιότυπων σε S1/S2 προστίθεται στο πακέτο τεχνουργημάτων.

20) Σχέδιο εφαρμογής (30 ημέρες)

Εβδομάδα 1

1. Απογραφή όλων των ρυθμιστικών εκθέσεων αδειοδότησης.
2. Δημιουργία καρτών (§ 4) και κωδικών λεξικών.
3. Έγκριση μορφοτύπων και διαύλων μετάδοσης.

Εβδομάδα 2
4. Οικοδομικές επιδείξεις DWH και γενεαλογίας. πρωτογενείς επικυρώσεις.
5. Δημιουργία πιλοτικών φακέλων (μία αγορά/τάξη).
6. Ρύθμιση υπογραφής/hashes και αρχειοθήκης.

Εβδομάδα 3
7. Ενσωμάτωση με την πύλη sandbox/API/SFTP.
8. Κατάσταση του ταμπλό και προειδοποιήσεις εντός προθεσμιών.
9. Ενημερωτικοί κατάλογοι εκπαίδευσης και ελέγχου των επιχειρήσεων.

Εβδομάδα 4
10. Υποβολή από τον χειριστή 2-3 εκθέσεων· συλλογή ανατροφοδότησης.
11. CAPA για DQ/επικυρώσεις· προσαρμογές των συστημάτων.
12. Απελευθέρωση v1. 0; χρονοδιάγραμμα αναθεώρησης και ενιαίο χρονοδιάγραμμα προθεσμιών.

Σχετικά τμήματα:
Ανακοινώσεις παραβάσεων και προθεσμίες υποβολής εκθέσεων
Ταμπλό συμμόρφωσης και παρακολούθηση
Βιβλία και σενάρια περιστατικών
Διαχείριση κρίσεων και επικοινωνίες
Σχέδιο επιχειρησιακής συνέχειας (BCP )/DRP
Αρχεία καταγραφής ελέγχου συναλλαγών
Contact

Επικοινωνήστε μαζί μας

Επικοινωνήστε για οποιαδήποτε βοήθεια ή πληροφορία.Είμαστε πάντα στη διάθεσή σας.

Telegram
@Gamble_GC
Έναρξη ολοκλήρωσης

Το Email είναι υποχρεωτικό. Telegram ή WhatsApp — προαιρετικά.

Το όνομά σας προαιρετικό
Email προαιρετικό
Θέμα προαιρετικό
Μήνυμα προαιρετικό
Telegram προαιρετικό
@
Αν εισαγάγετε Telegram — θα απαντήσουμε και εκεί.
WhatsApp προαιρετικό
Μορφή: κωδικός χώρας + αριθμός (π.χ. +30XXXXXXXXX).

Πατώντας «Αποστολή» συμφωνείτε με την επεξεργασία δεδομένων.