<اسم التقرير الرسمي>

1) الغرض والنطاق

• قائمة التقارير والجدول الزمني
• أشكال ومخططات البيانات
• وقواعد التصديق ومراقبة الجودة ؛
• وقنوات الإرسال والإقرار ؛
• الأدوار و RACI، سجل القطع الأثرية، والاحتفاظ.

2) الأدوار و RACI

المالك: رئيس الامتثال - يوافق على الإصدارات والأولويات (أ).
Schema Steward (DWH Lead) - دعم المخططات والخرائط (R).
المنتجون: AML/RG/Payments/Game Ops - مصادر البيانات (R).
QA/DQ: فريق جودة البيانات - التحقق من صحة مجموعات الاختبار (R).
القانون: تفسير القواعد، الموافقة على التغييرات (جيم).
الأمن/DPO: PII/Aliasing، قنوات التسليم (C).
عمليات الإبلاغ: تحميل، توقيع، إرسال، تأكيد (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

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 (حصة) AS stake_sum،

SUM (win) AS win_sum،

SAFE_DIVIDE (SUM (win)، NULLIF (SUM (حصة)، 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، العملة،

SUM (الحالة عندما يكون النوع = «الإيداع» ثم المبلغ الآخر 0 النهاية) كودائع،

SUM (الحالة عندما يكون النوع = «السحب» ثم المبلغ الآخر 0 النهاية) كسحب،

رسوم (رسوم)

من 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)

{"report _ date": "2025-10-31"، "player _ id _ hash": "b93e"...، "rg _ event": "SELF _ EXPLUSION"، "المدة _ الأيام": 180، "ts _ utc':" 2025-10-31T09: 11: 02Z "}

{"report _ date": " 2025-10-31 "، "player _ id _ hash ": "c01a "...، "rg _ event ": "LIMITE _ BREACH"،" الحد _ النوع":" LOSE _ 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. التسليم: البوابة/واجهة برمجة التطبيقات/منتدى تنمية الغابات ؛ سجل الاستقبال (بطاقة الهوية/الاستلام).
6. الأرشفة: الأصل + التوقيع + الإيصال في متجر التقارير.
7. الرصد: لوحة القيادة «الإبلاغ التنظيمي» - الحالة «جاهزة/مرسلة/مقبولة/خطأ».
8. الرجعية: تحليل الخطأ/الانحراف، CAPA.

15) القوائم المرجعية

قبل الإرسال

[] تم تأكيد تاريخ النافذة والمنطقة الزمنية.
[] جميع عمليات التحقق خضراء، ويتم مطابقة المبالغ المبلغ عنها مع GL/PSP.
[] نسخة المخطط تطابق سجل.
[] PII مقنعة/مسرورة.
[] ملف موقع/فحص، هاش ملتزم.
[] اتصال المنظم محدث (البوابة متاحة).

بعد الإرسال

[] استلام/هوية، محفوظة.
[] تم تحديث الحالة في لوحة القيادة.
[] خطة التحديث في حالة الاتفاق على خطأ المصادق.

16) المقاييس و SLO

التوقيت: النسبة المئوية للتقارير المقدمة في الوقت المحدد.
قبول المحاولة الأولى:% مقبول بدون تصحيحات.
درجة DQ: النسبة المئوية للإدخالات بدون أخطاء (مخطط/عمل).
فجوة التسوية: التناقض المطلق/النسبي مع GL/PSP.
الوقت المناسب للإبلاغ: الوقت من إغلاق النافذة إلى التقديم.
معدل فشل التغيير (تنسيقات): حصة إصدارات المخطط مع التراجع.

17) الحوكمة

الاستعراض الفصلي للمطالبات حسب الولاية القضائية ؛ غير مجدولة - أثناء تحديثات المنظم.
RFC لتغييرات المخطط: تحليل الأثر، قابلية التشغيل البيني، طيار صندوق الرمل.
تفريغ مزدوج في دورة MAJOR ≥ 1.
فرق تدريب على الإصدارات وتحديث كتب اللعب والأسئلة الشائعة.

18) الأخطاء المتكررة وكيفية تجنبها

منطقة زمنية غير صحيحة: دمج دائمًا في التوقيت العالمي المنسق، وقم بتخزين الموقع بشكل منفصل.
التقريب: استخدم قواعد التقريب المصرفية العشرية الموحدة.
عدم اتساق المعرفات: السجلات الفردية 'لعبة _ رمز'، 'طريقة _ رمز'، 'psp _ id'.
توطين الأرقام/التواريخ: فقط ISO-8601 والفترة كفاصل عشري.
PII واضح: فحص الأقنعة في الالتزام المسبق و CI.

19) التضمين في النظام البيئي

الاتصال بالأقسام: لوحة متابعة الامتثال، والإخطارات والمواعيد النهائية، وكتب تشغيل الحوادث، وإدارة الأزمات، وسجلات مراجعة الحسابات.
في روبوت الحادث: أمر '/تقرير <اختصاص> <report_id>' - احصل على المخطط والمواعيد النهائية.
يُضاف تصدير اللقطات على S1/S2 إلى حزمة القطع الأثرية.

20) خطة التنفيذ (30 يومًا)

الأسبوع 1

1. جرد جميع التقارير التنظيمية للترخيص.
2. إنشاء بطاقات (الفقرة 4) ورموز القواميس.
3. الموافقة على أشكال وقنوات الإرسال.

الأسبوع 2
4. بناء معارض DWH والنسب ؛ المصادقة الأولية.
5. توليد ملفات تجريبية (سوق/فئة واحدة).
6. إعداد التوقيع/التجزئة والأرشيف.

الأسبوع 3
7. التكامل مع بوابة sandbox/API/SFTP.
8. حالة لوحة القيادة والتنبيهات حسب المواعيد النهائية.
9. الإبلاغ عن تدريب العمليات وقوائم المراجعة.

الأسبوع 4
10. تقديم 2-3 تقارير تجريبية ؛ وجمع التغذية المرتدة.
11. CAPA لـ DQ/المصادقة ؛ تعديلات المخططات.
12. الإصدار v1. 0; وجدول زمني للتنقيح وموعد نهائي واحد.

الأبواب ذات الصلة:
الإخطارات بالانتهاكات والمواعيد النهائية للإبلاغ
لوحة متابعة الامتثال والرصد
كتب اللعب والنصوص الخاصة بالحوادث
إدارة الأزمات والاتصالات
خطة استمرارية تصريف الأعمال
سجلات مراجعة المعاملات