<نام گزارش رسمی>

1) هدف و محدوده

• گزارش کاتالوگ و برنامه
• فرمتها و طرحوارههای داده
• اعتبار سنجی و قوانین کنترل کیفیت ؛
• کانال های انتقال و تأیید ؛
• نقش ها و RACI، ورود به سیستم مصنوعی و نگهداری.

2) نقش ها و RACI

مالک: رئیس انطباق - نسخه ها، اولویت ها (A) را تصویب می کند.
Schema Steward (DWH Lead) - پشتیبانی از طرح ها و نقشه ها (R).
تولید کنندگان: AML/RG/پرداخت/عملیات بازی - منابع داده (R).
QA/DQ: تیم کیفیت داده - اعتبار سنجی، کیت تست (R).
حقوقی: تفسیر هنجارها، تصویب تغییرات (C).
امنیت/DPO: PII/Aliasing، کانال های تحویل (C).
گزارش عملیات: آپلود، امضا، ارسال، تایید (R).

3) کاتالوگ گزارش (کلاس ها)

1. گزارش های بازی - شرط/برنده/تعادل/جلسات، RTP، صداقت.
2. مالی - سپرده/برداشت، کسر، مالیات، GGR/NGR، بازپرداخت.
3. AML/CFT - معاملات مشکوک، PEP/تحریم ها، جمع آوری ریسک.
4. بازی مسئولانه (RG) - خود حذفی، محدودیت ها، مداخلات.
5. حادثه - در دسترس بودن، نشت، اطلاعیه ها و مهلت.
6. بازاریابی/وابسته - منابع ترافیک، محدودیت های تبلیغاتی (در صورت نیاز به مجوز).
7. فنی - uptime، نسخه های 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) AS report_date،

game_code،

واحد پول،

SUM (سهام) به عنوان stake_sum،

SUM (برنده) به عنوان win_sum،

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

از fact_game_rounds

از کجا ts_utc> = از و ts_utc <: به

گروه توسط 1,2,3 ؛

Payments (deposits/withdrawals/fees):

SQL

انتخاب کنید

DATE_TRUNC («روز»، ts_utc) AS report_date،

method_code، psp_id، واحد پول

مجموع (مورد زمانی که نوع = 'سپرده' سپس مقدار دیگری 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

2025-10-31,OP123,NET_STARBURST,EUR,125000 است. 50,119800. 00,0. 9585

13. 2 RG Events (JSON Lines)

{«گزارش _ تاریخ»: » 2025-10-31 «، «بازیکن _ شناسه «: «b93e «...، «rg _ event «: «SELF _ EXCLUSION»،» duration _ days»: 180،» ts _ utc»:» 2025-10-31T09: 11: 02Z»}

{"گزارش _ تاریخ": "2025-10-31"، "player _ id _ hash": "cp1a"...، "rg _ event": "LIMIT _ BREACH"، "limit _ type": "LOSS _ DAILY"، "مقدار": "200. 00 "، "ts _ utc":" 2025-10-31T13: 45: 22Z"}

13. 3 AML aggregate (XML, fragment)

XML

14) فرآیند گردش عملیاتی

1. آماده سازی پنجره: انجماد، محاسبه aggregates، بارگیری مجدد رویدادهای اواخر.
2. اعتبار سنجی: طرح + قوانین کسب و کار + آشتی.
3. تولید فایل: نسخه طرح در نام ('REP-GB-GAME-v1. 3_2025-10-31. CSV ').
4. امضا/هش: PGP + SHA256.
5. تحویل: پورتال/API/SFTP ؛ ثبت پذیرش (شناسه/رسید).
6. بایگانی: اصلی + امضا + دریافت در فروشگاه گزارش.
7. نظارت: داشبورد «گزارش نظارتی» - وضعیت «آماده/ارسال/پذیرفته/خطا».
8. Retro: تجزیه و تحلیل خطا/انحراف، CAPA.

15) چک لیست

قبل از ارسال

[] تاریخ پنجره و منطقه زمانی تایید شده است.
[] تمام اعتبار سنجی سبز هستند، مقدار گزارش شده با GL/PSP آشتی.
[] نسخه Schema با رجیستری مطابقت دارد.
[] PII ماسک/aliased.
[] فایل امضا شده/چک شده، هش متعهد است.
[] تماس با تنظیم کننده به روز است (پورتال در دسترس است).

پس از ارسال

[] دریافت/شناسه دریافت شده، بایگانی شده است.
[] وضعیت به روز شده در داشبورد.
[] طرح به روز رسانی در صورت خطای اعتبار سنج توافق شده است.

16) معیارها و SLO

به موقع بودن:٪ از گزارش های ارسال شده در زمان.
پذیرش اولین تلاش:٪ بدون اصلاحات پذیرفته شده است.
DQ Score: درصد ورودی ها بدون خطا (طرح/کسب و کار).
شکاف آشتی: اختلاف مطلق/درصد با GL/PSP.
زمان سرب برای گزارش: زمان از بسته شدن پنجره تا ارسال.
Change Failure Rate (formats): سهم انتشار schema با رول بک.

17) حکومت

بررسی سه ماهه ادعاهای صلاحیت ؛ برنامه ریزی نشده - در طول به روز رسانی تنظیم کننده.
RFC برای تغییرات طرح: تجزیه و تحلیل تاثیر، قابلیت همکاری، خلبان ماسهبازی.
دو بار تخلیه در چرخه MAJOR ≥ 1.
آموزش تیم در نسخه های منتشر شده، به روز رسانی playbooks و پرسش و پاسخ.

18) اشتباهات مکرر و چگونگی اجتناب از آنها

منطقه زمانی نادرست: همیشه در UTC تحکیم، ذخیره محلی به طور جداگانه.
گرد کردن: استفاده از دهدهی، قوانین گرد کردن بانک یکنواخت.
ناسازگاری شناسه ها: رجیسترهای تک «game _ code»، «method _ code»، «psp _ id».
محلی سازی اعداد/تاریخ: فقط ISO-8601 و دوره به عنوان جداساز اعشاری.
PII در روشن: چک کردن ماسک در قبل از ارتکاب و CI.

19) تعبیه در اکوسیستم

ارتباط با بخش ها: داشبورد انطباق، اطلاعیه ها و مهلت ها، دفترچه های حوادث، مدیریت بحران، گزارش های حسابرسی.
در ربات حادثه: command '/report <jurisdiction> <report_id>' - طرح و مهلت را دریافت کنید.
صادرات عکس های فوری در S1/S2 به بسته artifact اضافه شده است.

20) برنامه پیاده سازی (30 روز)

1 هفته

1. فهرست تمام گزارش های قانونی مجوز.
2. ایجاد کارت (§ 4) و فرهنگ لغت کد.
3. تصویب فرمت ها و کانال های انتقال.

2 هفته
4. ساخت ویترین های DWH و lineage اعتبار سنجی اولیه
5. تولید فایل های آزمایشی (یک بازار/کلاس).
6. پیکربندی امضا/هش ها و آرشیو.

3 هفته
7. ادغام با پورتال sandbox/API/SFTP.
8. وضعیت داشبورد و هشدار توسط مهلت.
9. گزارش آموزش عملیات و چک لیست.

4 هفته
10. تحویل خلبان 2-3 گزارش ؛ جمع آوری بازخورد
11. CAPA برای DQ/اعتبار سنجی ؛ تعدیل طرح ها
12. v1 را آزاد کنید. 0; برنامه تجدید نظر و یک تقویم مهلت واحد.

بخش های مرتبط:
اطلاعیه های نقض و مهلت گزارش
داشبورد انطباق و نظارت
کتاب های بازی و اسکریپت های حادثه
مدیریت بحران و ارتباطات
برنامه تداوم کسب و کار (BCP )/DRP
گزارش های حسابرسی معاملات