<דיווח רשמי שם>

1) מטרה והיקף

• דיווח קטלוג ולוח זמנים
• תבניות נתונים ותרשימים
• אימות וכללי בקרת איכות;
• ערוצי שידור והכרה;
• תפקידים ו-RACI, רישום חפצים, ושימור.

2) תפקידים ו ־ RACI

בעלים: ראש ציות - מאשרת גרסאות, סדר עדיפויות (א).
Schema Steward (DWH Lead) - תמיכה בתרשימים ומפות.
יצרנים: AML/RG/Professions/Game Ops - מקורות מידע (R).
QA/DQ: צוות איכות נתונים - אימות, ערכות בדיקה (R).
משפטי: פרשנות לנורמות, אישור לשינויים (ג).
אבטחה/DPO: PII/Aliasing, ערוצי משלוח (C).
דיווח Ops: להעלות, לחתום, לשלוח, לאשר (R).

3) קטלוג דוח (מחלקות)

1. דוחות משחק - הימורים/ניצחונות/מאזן/הפעלות, RTP, כנות.
2. הפקדה כספית/משיכה, ניכויים, מיסים, GGR/NGR, מטענים.
3. עסקאות חשודות, פפ/סנקציות, סיכונים מצטברים.
4. משחק אחראי (ר "ג) - בלעדיות עצמית, גבולות, התערבויות.
5. תקרית - זמינות, דליפות, הודעות ומועדים.
6. שיווק/השתייכות - מקורות תנועה, הגבלות פרסום (אם נדרש רישיון).
7. טכני - למעלה, גרסאות RNG, בניית/הגדרות דשוני, רישום ביקורת.

כל דיווח מתואר על ידי כרטיס (# 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

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

בחר את

DATE_TRUNC (”יום”, ts_utc) כמו report_date,

game_code,

מטבע,

Sum (יתד) כמו stake_sum,

סאם (ניצחון) כמו win_sum,

SAFE_DIVIDE (SUM (win), NULLIF (SUM (יתד), 0)

מתוך fact_game_rounds

• קבוצה ב ־ 1,2,3;

Payments (deposits/withdrawals/fees):

sql

בחר את

DATE_TRUNC (”יום”, ts_utc) כמו report_date,

method_code, psp_id, מטבע

סכום (מקרה כאשר סוג 'הפקדה' אז סכום אחר 0 סוף) כהפקדות,

סכום (מקרה כאשר סוג = ”משיכה” אז סכום אחר 0 סוף) כמשיכות,

סכום (עמלה) כעמלות

מתוך fact_payments

• קבוצה של 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 _ EXCUSTION", "TS _ UC": "2025-10-31T09: 11: 02Z

”report _ date”: ”2025-10-31”, ”player _ id _ hash”: ”c01a”..., ”rg _ event”: ”limit _ BURE”, ”limit _ type”: ”LOST _ DAILY”, ”כמות”: ”200”. 00, ”ts _ utc”: ”2025-10-31T13: 45: 22Z”

13. 3 AML aggregate (XML, fragment)

xml

14) תהליך תחלופה מבצעית

1. הכנת חלונות: הקפאה, חישוב צבירים, טעינה מחדש של אירועים מאוחרים.
2. אימות: סכימה + כללים עסקיים + פיוס.
3. דור קבצים: סכימה בשם ('REP-GB-GAME-v1. 3_2025-10-31. csv).
4. חתימה/חשיש: PGP + SHA256.
5. משלוח: פורטל/API/SFTP; יומן הקבלה (תעודת זהות/קבלה).
6. ארכיון: מקורי + חתימה + קבלה בחנות הדו "ח.
7. ניטור: לוח מחוונים ”דיווח רגולטורי” - מצב ”מוכן/נשלח/מקובל/שגיאה”.
8. רטרו: ניתוח שגיאה/סטייה, CAPA.

15) רשימות בדיקה

לפני שליחהName

[ ] חלון ואזור הזמן אושר.
[ ] כל האישורים ירוקים, כמויות מדווחות מתפייסות עם GL/PSP.
[ ] סכימה תואמת את הרישום.
[ ] PII במסכה/כינוי.
[ קובץ ] חתום/נבדק, חשיש מחויב.
[ ] איש הקשר של הרגולטור מעודכן (הפורטל זמין).

לאחר שליחה

[ ] קבלה/תעודת זהות התקבלה, בארכיון.
[ ] סטטוס מעודכן בלוח המחוונים.
[ ] תוכנית עדכון למקרה של טעות בתוקף מוסכם.

16) מדדים ו ־ SLO

זמן:% מהדו "חות מוגשים בזמן.
קבלה ראשונה:% התקבלו ללא תיקונים.
ציון DQ: אחוז הרשומות ללא שגיאות (סכימה/עסק).
פער פיוס: חוסר התאמה מוחלט/אחוז עם GL/PSP.
הובל את הזמן לדווח: הזמן מסגירת החלון ועד להגשה.
שינוי קצב כישלון (פורמטים): שיתוף של סכימה משחררת עם רולבקס.

17) ממשל

סקירה רבעונית של תביעות בתחום השיפוט; לא מתוכנן בזמן עדכוני הרגולטור.
RFC לשינויי סכימה: ניתוח השפעה, אינטרפרטציה, טייס ארגז חול.
פריקה כפולה במחזור 1.
צוות אימון על שחרור, עדכון ספרי משחק ורשות שדות התעופה.

18) טעויות תכופות וכיצד להימנע מהן

זמן שגוי: תמיד להתאחד UTC, לאחסן את המקום בנפרד.
שימוש עשרוני, כללי עיגול בנק אחידים.
חוסר עקביות של מזהים: רגיסטרים בודדים "game _ code", "method _ code", "psp _ id'.
איתור של מספרים/תאריכים: רק ISO-8601 וזמן כהפרדה עשרונית.
מח "ש ברורים: בדיקת מסכות מראש להתחייב ומודיע.

19) הטבעה במערכת האקולוגית

תקשורת עם קטעים: לוח מחוונים, הודעות ומועדים, חוברות משחקים, ניהול משברים, יומני ביקורת.
בוט התקרית: פקודה '/דיווח <תחום שיפוט> <report_id>' - קבל את התוכנית ואת המועדים.
יצוא תמונות על S1/S2 מתווסף לחבילת החפץ.

20) תוכנית יישום (30 יום)

שבוע 1

1. רשימת המלאי של כל דוחות הרישוי.
2. צור קלפים (# 4) ומילוני קוד.
3. אישור של פורמטי תמסורת וערוצים.

שבוע 2
4. בניית אוצרות תצוגה של DWH ושושלות; אימות עיקרי.
5. דור קבצי פיילוט (שוק אחד/מחלקה).
6. הגדרת חתימה/חשיש וארכיון.

שבוע 3
7. אינטגרציה עם פורטל ארגז החול/API/SFTP.
8. סטטוסים לוח מחוונים והתראות על ידי מועדים.
9. דיווח על אימוני מבצעים ורשימות בדיקה.

שבוע 4
10. משלוח פיילוט של 2-3 דיווחים; אוסף של משוב.
11. CAPA עבור DQ/אימות; התאמות של מזימות.
12. שחרר V1. 0; לוח זמנים ותאריך יעד אחד.

קטעים קשורים:
הודעות על הפרות ומועד דיווח
לוח מחוונים ציות וניטור
ספרי משחקים ותסריטים
ניהול משברים ותקשורת
תוכנית המשכיות עסקית (BCP )/DRP
רישומי ביקורת חשבונות