<公式レポート名>

1）目的と範囲

• レポートカタログとスケジュール
• データフォーマットとスキーマ
• 検証と品質管理規則；
• 伝達および確認チャネル；
• ロールとRACI、アーティファクトログ、および保持。

2）役割とRACI

所有者：コンプライアンス責任者-バージョン、優先順位（A）を承認します。
スキーマスチュワード（DWHリード）-スキーマとマッピング（R）のサポート。
プロデューサー：AML/RG/ペイメント/ゲームオプス-データソース（R）。
QA/DQ：データ品質チーム-検証、テストキット（R）。
法的：規範の解釈、変更の承認（C）。
セキュリティ/DPO： PII/エイリアシング、配信チャンネル（C）。
Reporting Ops：アップロード、サイン、送信、確認（R）。

3）レポートカタログ（クラス）

1.ゲームレポート-賭け/勝利/バランス/セッション、RTP、正直。
2.財務-預金/出金、控除、税金、GGR/NGR、チャージバック。
3.AML/CFT-疑わしい取引、PEP/制裁、リスク集計。
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

。 。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、

、 、

通貨、

SUM（ステーク）AS stake_sum、

SUM（勝利）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

グループで1,2,3；

Payments (deposits/withdrawals/fees):

SQL

SELECT

DATE_TRUNC （'day'、 ts_utc） AS report_date、

method_code、 psp_id、通貨、

預金として合計（CASE WHEN TYPE='DEPOSIT' THEN AMOUNT ELSE 0 END）、

SUM （CASE WHEN TYPE='DETHIRAL' AND AMOUNT ELSE 0 END）引き出しとして、

SUM（手数料）AS手数料

FROM fact_payments

WHERE ts_utc BETWEEN： from AND： to

グループ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"、 "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.ウィンドウの準備：フリーズ、集計の計算、遅延イベントの再読み込み。
2.検証：スキーマ+ビジネスルール+和解。
3.ファイル生成：名前のスキーマバージョン（'REP-GB-GAME-v1。3_2025-10-31.csv'）。
4.署名/ハッシュ：PGP+SHA256。
5.配達：ポータル/API/SFTP；受付ログ（ID/領収書）
6.アーカイブ：レポートストアでのオリジナル+署名+領収書。
7.監視：ダッシュボード「規制報告」-ステータス「ready/sent/accepted/error」。
8.レトロ：エラー/偏差解析、CAPA。

15）チェックリスト

送信する前に

［］ウィンドウとタイムゾーンの日付が確認されました。
［］すべての検証は緑色で、報告された量はGL/PSPと調整されます。
［］スキーマバージョンはレジストリにマッチします。
［］PIIマスク/エイリアス。
［］ファイルが署名/チェックされ、ハッシュがコミットされました。
［］レギュレータの連絡先は最新です（ポータルが利用可能です）。

送信後

［］受信した領収書/ID、アーカイブ。
［］ダッシュボードで更新されたステータス。
［］バリデータエラーが合意された場合の更新計画。

16）メトリクスとSLO

適時性：時間通りに提出されたレポートの％。
First-Try Acceptance：％は修正なしで受け入れられます。
DQスコア：エラーのないエントリの割合（スキーマ/ビジネス）。
和解ギャップ：GL/PSPとの絶対/パーセンテージの不一致。
レポートへのリードタイム：ウィンドウを閉じてから送信までの時間。
Change Failure Rate （formats）：ロールバックによるスキーマリリースの共有。

17）ガバナンス

管轄裁判所による請求の四半期ごとの見直し;スケジュールされていない-レギュレータの更新中。
スキーマ変更のためのRFC：影響分析、相互運用性、サンドボックスパイロット。
MAJOR ≥ 1サイクルでの二重アンロード。
リリース、プレイブック、FAQの更新に関するトレーニングチーム。

18）頻繁なミスとそれらを回避する方法

間違ったタイムゾーン：常にUTCに統合し、ロケールを個別に保存します。
丸め：10進数、均一な銀行丸めルールを使用します。
識別子の不一致：シングルレジスタ'game_code'、 'method_code'、 'psp_id'。
数字/日付のローカライズ：小数点区切りとしてのISO-8601と期間のみ。
明確なPII：事前コミットとCIでマスクをチェックします。

19）生態系への埋め込み

セクションとのコミュニケーション：コンプライアンスダッシュボード、通知と期限、インシデントプレイブック、危機管理、監査ログ。
incident bot： command '/report<管轄><report_id>'-スキームと期限を取得します。
S1/S2上のスナップショットのエクスポートは、アーティファクトパッケージに追加されます。

20）実施計画（30日）

ウィーク1

1.すべてのライセンス規制レポートの在庫。
2.カード（4）とコード辞書を作成します。
3.伝送フォーマットおよびチャネルの承認。

ウィーク2
4.建物DWHおよび系統のショーケース；プライマリ・バリデーション。
5.パイロットファイルの生成（1つの市場/クラス）。
6.署名/ハッシュとアーカイブの設定。

ウィーク3
7.サンドボックスポータル/API/SFTPとの統合。
8.ダッシュボードのステータスと締め切りまでのアラート。
9.Reporting Opsトレーニングとチェックリスト。

ウィーク4
10.2-3レポートのパイロット配信。フィードバックの収集。
11.DQ/検証のためのCAPA；スキームの調整。
12.v1をリリースします。0;改訂スケジュールと単一の締め切りカレンダー。

関連セクション：
違反の通知と報告期限
コンプライアンスダッシュボードと監視
インシデントプレイブックとスクリプト
危機管理とコミュニケーション
事業継続計画（BCP ）/DRP
トランザクション監査ログ