GH GambleHub

1) Maqsad va qamrov

Barcha litsenziyalar va bozorlar bo’yicha tartibga solish hisobotlarini to’plash, shakllantirish va topshirish standartlashtirilsin. Hujjat quyidagilarni belgilaydi:
  • hisobotlar katalogi va jadvali;
  • ma’lumotlarning formatlari va sxemalari;
  • validatsiya va sifatni nazorat qilish qoidalari;
  • uzatish kanallari va qabul qilinganligini tasdiqlash;
  • rollari va RACI, artefaktlar va retensiya jurnali.
💡 Diskleymer: aniq maydonlar/muddatlar litsenziya shartlariga bog’liq. Yakuniy shakllar Legal/Compliance tomonidan tasdiqlanadi.

2) Rollar va RACI

Owner: Head of Compliance - versiyalar, ustuvorliklarni tasdiqlaydi (A).
Schema Steward (DWH Lead): sxemalar va mappinglarni qo’llab-quvvatlash (R).
Producers: AML/RG/Payments/Game Ops - ma’lumotlar manbalari (R).
QA/DQ: Data Quality Team - validatsiyalar, test to’plamlari (R).
Legal: normalarni talqin qilish, o’zgartirishlarni kelishish (C).
Security/DPO: PII/taxalluslashtirish, yetkazib berish kanallari (C).
Reporting Ops: tushirish, imzolash, jo’natish, tasdiqlash (R).

3) Hisobotlar katalogi (sinflar)

1. O’yin hisobotlari - stavkalar/yutuqlar/balanslar/sessiyalar, RTP, halollik.
2. Moliyaviy - depozit/olib qo’yish, ushlab qolish, soliqlar, GGR/NGR, chargebacks.
3. AML/CFT - shubhali operatsiyalar, RER/sanksiyalar, xavf agregatlari.
4. Mas’uliyatli o’yin (RG) - o’z-o’zini istisno qilish, limitlar, intervensiyalar.
5. Noxush - foydalanish imkoniyati, oqish, bildirishnomalar va muddatlar.
6. Marketing/affiliatlar - trafik manbalari, reklamani cheklash (agar litsenziya talab qilinsa).
7. Texnik - aptaym, RNG versiyasi, bild/konfiguratsiyalar xeshi, audit jurnali.

Har bir hisobot kartochka (§ 4) bilan tavsiflanadi.

4) Hisobot kartochkasi (shablon)


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

🚨 amlReport date="2025-10-31" operatorId="OP123" xmlns="urn:operator:aml:v1">
segment riskTier="HIGH" turnover="98500. 00" currency="EUR"/>
pepsMatches count="2"/>
sanctionsMatches count="0"/>
/amlReport>

14) Topshirishning operatsion jarayoni

1. Oynani tayyorlash: freeze, agregatlarni hisoblash, kechiktirilgan voqealarni yuklash.
2. Validatsiyalar: schema + biznes qoidalari + reconciliation.
3. Fayllarni yaratish: sxemaning nomi (’REP-GB-GAME-v1. 3_2025-10-31. csv`).
4. Imzo/xesh: PGP + SHA256.
5. Yetkazib berish: portal/API/SFTP; qabul qilish jurnali (ID/kvitansiya).
6. Arxivlash: asli + imzo + hisobotlar omboridagi kvitansiya.
7. Monitoring: «Regulatory Reporting» dashbordi - «tayyor/jo’natilgan/qabul qilingan/xato» maqomi.
8. Retro: xato/ogʻishlar tahlili, CAPA.

15) Chek-varaqlar

Joʻnatishdan oldin

[] Oynaning sanasi va taymzon tasdiqlandi.
[] Barcha validatsiyalar «yashil», hisobot summalari GL/PSP bilan solishtirilgan.
[] Sxemaning versiyasi reyestrga mos keladi.
[] PII yashiringan/taxallus qilingan.
[] Fayl imzolangan/tekshirilgan, xesh oʻrnatilgan.
[] Regulyatordagi aloqa dolzarbdir (portal mavjud).

Joʻnatilgandan keyin

[] Kvitansiya/ID olingan, arxivda saqlangan.
[] Maqomi dashbordda yangilandi.
[] Validator xato qilganda yangilanish rejasi kelishilgan.

16) Metrika va SLO

Timeliness: o’z vaqtida topshirilgan hisobotlar%.
First-Try Acceptance:% qabul qilingan tuzatishlarsiz.
DQ Score: xatosiz yozuvlar ulushi (schema/business).
Reconciliation Gap: mutlaq/GL/PSP bilan tafovut foizi.
Lead Time to Report: Oynani yopishdan to topshirishgacha boʻlgan vaqt.
Change Failure Rate (formatlar): sxemalar relizlari ulushi.

17) O’zgartirishlarni boshqarish (governance)

Yurisdiksiyalar bo’yicha talablarni har chorakda ko’rib chiqish; rejadan tashqari - regulyatorlar yangilanganda.
Sxemalarni o’zgartirish uchun RFC: impakt-tahlil, moslashuvchanlik, «qum qutisiga» pilot chiqarish.
MAJOR ≥ 1 tsiklda ikki marta tushirish.
Relizlarda jamoalarni oʻqitish, pleybuklar va SSSni yangilash.

18) Tez - tez xatolar va ulardan qanday qochish mumkin

Notoʻgʻri taymzon: har doim UTC bilan birlashtirish, lokalni alohida saqlash.
Yaxlitlash: decimal, bankni yaxlitlashning yagona qoidalaridan foydalanish.
Identifikatorlarning nomuvofiqligi:’game _ code’,’method _ code’,’psp _ id’yagona reyestrlari.
Sonlar/sanalar lokalizatsiyasi: faqat ISO-8601 va nuqta oʻnli ajratuvchi sifatida.
Ochiq koʻrinishdagi PII: pre-comit va CI niqoblarini tekshirish.

19) Ekotizimga kiritish

Bo’limlar bilan aloqa: Dashbord komplayens, Bildirishnomalar va muddatlar, Noxush pleybuklar, Inqirozli boshqaruv, Audit jurnallari.
Hodisa botida: ’/report <jurisdiction> <report_id>' - sxema va muddatlarni olish.
Snapshotlar eksporti S1/S2 artefaktlar paketiga qo’shiladi.

20) Joriy etish rejasi (30 kun)

1 hafta

1. Litsenziyalar bo’yicha barcha tartibga solish hisobotlarini xatlovdan o’tkazish.
2. Kod kartochkalari (§ 4) va lug’atlarini yaratish.
3. Uzatish formatlari va kanallarini tasdiqlash.

2 hafta
4. DWH va lineage vitrinalarini qurish; birlamchi validatsiyalar.
5. Pilot fayllarni yaratish (bitta bozor/sinf bo’yicha).
6. Imzo/xesh va arxivni moslash.

3 hafta
7. / API/SFTP «qum qutisi» portali bilan integratsiya qilish.
8. Dashbord maqomlari va muddatlar bo’yicha alertlar.
9. Reporting Ops va chek varaqlarini oʻqish.

4-hafta
10. 2-3 ta hisobotni sinov tariqasida topshirish; fidbekni yig’ish.
11. DQ/validatsiyalar bo’yicha CAPA; sxemalarga tuzatishlar kiritish.
12. v1. 0; taftishlar jadvali va muddatlarning yagona taqvimi.

Bogʻlangan boʻlimlar:
Qoidabuzarliklar to’g "risidagi bildirishnomalar va hisobot muddatlari
Dashbord komplayens va monitoring
Noxush pleybuklar va ssenariylar
Inqirozli boshqaruv va kommunikatsiyalar
Biznes uzluksizligi rejasi (BCP )/DRP
Operatsiyalar auditi jurnallari
Contact

Biz bilan bog‘laning

Har qanday savol yoki yordam bo‘yicha bizga murojaat qiling.Doimo yordam berishga tayyormiz.

Telegram
@Gamble_GC
Integratsiyani boshlash

Email — majburiy. Telegram yoki WhatsApp — ixtiyoriy.

Ismingiz ixtiyoriy
Email ixtiyoriy
Mavzu ixtiyoriy
Xabar ixtiyoriy
Telegram ixtiyoriy
@
Agar Telegram qoldirilgan bo‘lsa — javob Email bilan birga o‘sha yerga ham yuboriladi.
WhatsApp ixtiyoriy
Format: mamlakat kodi va raqam (masalan, +998XXXXXXXX).

Yuborish orqali ma'lumotlaringiz qayta ishlanishiga rozilik bildirasiz.