<報告的正式名稱>

1）目的和範圍

• 報告目錄和時間表；
• 數據格式和模式；
• 驗證和質量控制規則；
• 傳輸和接收確認渠道；
• 角色和RACI，文物雜誌和復古。

2）角色和RACI

Owner： Head of Compliance-批準版本、優先級（A）。
Schema Steward（DWH Lead）：支持電路和mapping（R）。
生產者：AML/RG/Payments/Game Ops-數據源（R）。
QA/DQ：數據質量團隊-驗證，測試套件（R）。
法律：規範的解釋，變更的協調（C）。
安全/DPO：PII/別名，交付渠道（C）。
Reporting Ops：卸載、簽名、發送、確認（R）。

3）報告目錄（類）

1.遊戲報告-投註/獲勝/資產負債表/會話，RTP，誠實。
2.財務-存款/提取，保留，稅收，GGR/NGR，chargebacks。
3.AML/CFT-可疑交易，RER/制裁，風險單位。
4.負責任的遊戲（RG）-自我排序，限制，幹預。
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

SELECT

DATE_TRUNC('day', ts_utc) AS report_date,

game_code,

currency,

SUM(stake) AS stake_sum,

SUM(win) AS win_sum,

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

FROM fact_game_rounds

WHERE ts_utc >=:from AND ts_utc <:to

GROUP BY 1,2,3;

Payments (deposits/withdrawals/fees):

sql

SELECT

DATE_TRUNC('day', ts_utc) AS report_date,

method_code, psp_id, currency,

SUM(CASE WHEN type='DEPOSIT' THEN amount ELSE 0 END) AS deposits,

SUM(CASE WHEN type='WITHDRAWAL' THEN amount ELSE 0 END) AS withdrawals,

SUM(fee) AS fees

FROM fact_payments

WHERE ts_utc BETWEEN:from AND:to

GROUP BY 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）交貨操作過程

1.窗口準備：freeze,聚合計算,延遲事件加載.
2.驗證：schema+業務規則+reconciliation。
3.文件生成：名稱中的模式版本（'REP-GB-GAME-v1.3_2025-10-31.csv`).
4.標題/哈希：PGP+SHA256。
5.交付：門戶/API/SFTP；接收記錄（ID/收據）。
6.歸檔：原件+簽名+報告存儲庫中的收據。
7.監視：「法規報告」（Reporting Regulatory Reporting）-「準備/發送/接受/錯誤」狀態。
8.復古：錯誤/偏差分析，CAPA。

15）支票單

發貨前

［］窗口和時間段的日期已確認。
［］所有驗證均為「綠色」，報告金額已與GL/PSP核對。
［］該方案的版本對應於註冊表。
［］PII偽裝/化名。
［］文件已簽名/驗證,哈希已固定。
［］監管機構的聯系是最新的（門戶網站可用）。

發送後

［］收到收據/ID，保存在存檔中。
［］狀態已在dashboard中更新。
［］驗證器錯誤時的升級計劃是一致的。

16）度量和SLO

時效：按時提交報告的百分比。
First-Try Acceptance：在沒有修復的情況下接受的百分比。
DQ得分：無錯誤記錄比例（計劃/業務）。
Reconciliation Gap：與GL/PSP的絕對差異/百分比。
Lead Time to Report：從關閉窗口到提交的時間。
更改失敗率（格式）：回滾模式發行版的比例。

17）變更管理（政府）

對司法管轄區要求的季度審查；計劃外-調節器升級。
電路變更的RFC：影響分析，兼容性，試運行到「沙箱」中。
MAJOR雙上載≥ 1個循環。
發布時訓練命令，更新花花公子和FAQ。

18）頻繁的錯誤以及如何避免錯誤

不正確的時段：總是整合到UTC,分別存儲本地。
四舍五入：使用十進制，統一銀行四舍五入規則。
身份不一致：單一註冊表「game_code」，「method_code」，「psp_id」。
數字/日期的本地化：僅ISO-8601和點作為十進制分隔符。
公開形式的PII：在商場和CI中檢查口罩。

19）嵌入生態系統

與章節的聯系：Dashbord編譯，通知和時機，事件花花公子，危機管理，審計日誌。
在事件機器人中：命令'/報告<jurisdiction> <report_id>'-獲取模式和截止日期。
S1/S2時會將snapshot導出添加到工件包中。

20）實施計劃（30天）

第一周

1.清點所有許可證監管報告。
2.創建卡（§4）和代碼詞典。
3.格式和傳輸鏈路的批準。

第二周
4.建立DWH和線性店面；主要驗證。
5.生成試點文件（每個市場/類）。
6.設置簽名/哈希和存檔。

第3周
7.與「沙箱」門戶/API/SFTP集成。
8.Dashbord狀態和Alerta按截止日期。
9.Reporting Ops培訓和支票單。

第四周
10.試點2-3份報告；收集回饋。
11.通過DQ/驗證的 CAPA；調整方案。
12.V1版本。0;修訂時間表和單一截止日期日歷。

相關部分：
違規通知和報告時限
Dashboard complians和監控
事件花花公子和劇本
危機管理和溝通
業務連續性計劃（BCP）/DRP
運營審計日誌