1) Amaç ve kapsam

• Rapor kataloğu ve programı
• Veri formatları ve şemalar
• Doğrulama ve kalite kontrol kuralları;
• iletim ve bilgilendirme kanalları;
• Roller ve RACI, eser kaydı ve elde tutma.

2) Roller ve RACI

Sahibi: Uyum Başkanı - sürümleri, öncelikleri (A) onaylar.
Schema Steward (DWH Lead) - şemalar ve eşlemeler için destek (R).
Üreticiler: AML/RG/Payments/Game Ops - veri kaynakları (R).
QA/DQ: Veri Kalitesi Ekibi - doğrulamalar, test kitleri (R).
Yasal: normların yorumlanması, değişikliklerin onaylanması (C).
Güvenlik/DPO: PII/Aliasing, Teslimat Kanalları (C).
Raporlama Operasyonları: yükleme, imzalama, gönderme, onaylama (R).

3) Rapor kataloğu (sınıflar)

1. Oyun raporları - bahisler/kazançlar/dengeler/oturumlar, RTP, dürüstlük.
2. Finansal - para yatırma/çekme, kesintiler, vergiler, GGR/NGR, ters ibrazlar.
3. AML/CFT - şüpheli işlemler, PEP/yaptırımlar, risk toplamları.
4. Sorumlu oyun (RG) - kendini dışlama, sınırlar, müdahaleler.
5. Olay - kullanılabilirlik, sızıntılar, bildirimler ve son tarihler.
6. Pazarlama/bağlı kuruluşlar - trafik kaynakları, reklam kısıtlamaları (lisans gerektiriyorsa).
7. Teknik - çalışma süresi, RNG sürümleri, yapı/yapılandırma karmaları, denetim günlüğü.

Her rapor bir kartla tanımlanır (§ 4).

4) Rapor kartı (şablon)

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

SEÇ

DATE_TRUNC ('gün', ts_utc) AS report_date,

game_code,

Para birimi,

SUM (stake) AS stake_sum,

SUM (win) AS win_sum,

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

fact_game_rounds'dan

WHERE ts_utc> =: from AND ts_utc <: to

GRUP 1,2,3;

Payments (deposits/withdrawals/fees):

sql

SEÇ

DATE_TRUNC ('gün', ts_utc) AS report_date,

method_code, psp_id, para birimi,

SUM (CASE WHEN TYPE = 'DEPOSIT' THEN amount ELSE 0 END) AS mevduat olarak,

SUM (CASE WHEN TYPE = 'WITHDRAW' THEN AMOUNT ELSE 0 END) Para çekme olarak,

SUM (ücret) AS ücretleri

fact_payments'dan

WHERE ts_utc BETWEEN: FROM AND: TO

GRUP 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) Operasyonel ciro süreci

1. Pencere hazırlama: donma, agregaların hesaplanması, geç olayların yeniden yüklenmesi.
2. Doğrulamalar: şema + iş kuralları + uzlaşma.
3. Dosya oluşturma: adında şema sürümü ('REP-GB-GAME-v1. 3_2025-10-31. csv ').
4. İmza/karma: PGP + SHA256.
5. Teslimat: Portal/API/SFTP; Kabul günlüğü (kimlik/makbuz).
6. Arşivleme: rapor deposunda orijinal + imza + makbuz.
7. İzleme: kontrol paneli "Düzenleyici Raporlama" - durum "hazır/gönderilen/kabul edilen/hata".
8. Retro: hata/sapma analizi, CAPA.

15) Kontrol listeleri

Göndermeden önce

[] Pencere ve saat dilimi tarihi onaylandı.
[] Tüm validasyonlar yeşildir, rapor edilen miktarlar GL/PSP ile uzlaştırılır.
[] Şema sürümü kayıt defteriyle eşleşir.
[] PII maskelenmiş/aliased.
[] Dosya imzalandı/kontrol edildi, hash işlendi.
[] Düzenleyicinin bağlantısı günceldir (portal mevcuttur).

Gönderdikten sonra

[] Makbuz/kimlik alındı, arşivlendi.
[] Durum kontrol panelinde güncellendi.
[] Doğrulayıcı hatası durumunda güncelleme planı kabul edildi.

16) Metrikler ve SLO

Zamanlama: Zamanında gönderilen raporların %'si.
İlk Deneme Kabulü: % düzeltme olmadan kabul edildi.
DQ Puanı: Hatasız girişlerin yüzdesi (şema/iş).
Uzlaşma Boşluğu: GL/PSP ile mutlak/yüzde tutarsızlık.
Rapor Verme Süresi: Pencerenin kapatılmasından gönderime kadar geçen süre.
Hata Oranını Değiştir (formatlar): Geri dönüşlü şema sürümlerinin paylaşımı.

17) Yönetişim

Yargı yetkisine göre taleplerin üç ayda bir gözden geçirilmesi; Planlanmamış - regülatör güncellemeleri sırasında.
Şema değişiklikleri için RFC: etki analizi, birlikte çalışabilirlik, sandbox pilot.
MAJOR ≥ 1 döngüsünde çift boşaltma.
Yayınlarla ilgili eğitim ekipleri, oyun kitaplarının ve SSS'lerin güncellenmesi.

18) Sık yapılan hatalar ve bunlardan nasıl kaçınılacağı

Yanlış saat dilimi: her zaman UTC'de birleştirin, yerel ayarı ayrı olarak saklayın.
Yuvarlama: ondalık, tek tip banka yuvarlama kurallarını kullanın.
Tanımlayıcıların tutarsızlığı: tek kayıtlar 'game _ code', 'method _ code', 'psp _ id'.
Sayıların/tarihlerin yerelleştirilmesi: yalnızca ondalık ayırıcı olarak ISO-8601 ve nokta.
Açık PII: Ön taahhüt ve CI'da maskeleri kontrol etmek.

19) Ekosisteme gömülme

Bölümlerle iletişim: Uyumluluk panosu, Bildirimler ve son tarihler, Olay oyun kitapları, Kriz yönetimi, Denetim günlükleri.
Olay botunda: command'/report <jurisdiction> <report_id>' - düzeni ve son tarihleri alın.
S1/S2 üzerindeki anlık görüntüleri dışa aktarma, nesne paketine eklenir.

20) Uygulama planı (30 gün)

Hafta 1

1. Tüm lisans düzenleme raporlarının envanteri.
2. Kartlar (§ 4) ve kod sözlükleri oluşturun.
3. İletim formatlarının ve kanallarının onaylanması.

2. hafta
4. Bina DWH ve soy vitrinleri; Birincil doğrulamalar.
5. Pilot dosyaların oluşturulması (bir pazar/sınıf).
6. İmza/karma ve arşiv yapılandırılıyor.

3. hafta
7. Sandbox portalı/API/SFTP ile entegrasyon.
8. Pano durumları ve son teslim tarihlerine göre uyarılar.
9. Raporlama Ops eğitim ve kontrol listeleri.

4. hafta
10. 2-3 raporun pilot teslimatı; Geri bildirim toplama.
11. DQ/doğrulamalar için CAPA; şemaların ayarlanması.
12. V1'i serbest bırakın. 0; Revizyon programı ve tek bir son tarih takvimi.

İlgili bölümler:
İhlal Bildirimleri ve Raporlama Süreleri
Uyumluluk panosu ve izleme
Olay oyun kitapları ve komut dosyaları
Kriz yönetimi ve iletişim
İş Sürekliliği Planı (BCP )/DRP
İşlem denetim günlükleri