<ანგარიშის ოფიციალური სახელი>

1) მიზანი და გაშუქება

• ანგარიშებისა და გრაფიკის კატალოგი;
• ფორმატები და მონაცემთა სქემები;
• ვალიდაციისა და ხარისხის კონტროლის წესები;
• გადაცემის არხები და დაშვების დადასტურება;
• როლები და RACI, არტეფაქტებისა და რეტენციების ჟურნალი.

2) როლები და RACI

Owner: Head of Compliance - ამტკიცებს ვერსიებს, პრიორიტეტებს (A).
Schema Steward (DWH Lead): სქემებისა და მაპინგების მხარდაჭერა (R).
Producters: AML/RG/Payments/Game Ops - მონაცემთა წყაროები (R).
QA/DQ: Data Quality Team - შესაბამისობა, ტესტის ნაკრები (R).
ლეგალი: ნორმების ინტერპრეტაცია, ცვლილებების კოორდინაცია (C).
უსაფრთხოება/DPO: PII/ფსევდონიზაცია, მიწოდების არხები (C).
Reporting Ops: გადმოტვირთვა, ხელმოწერა, გაგზავნა, დადასტურება (R).

3) ანგარიშების კატალოგი (კლასები)

1. თამაშის ანგარიშები - განაკვეთები/მოგება/ბალანსი/სესიები, RTP, პატიოსნება.
2. ფინანსური - ანაბარი/დასკვნა, შენახვა, გადასახადები, GGR/NGR, chargebacks.
3. AML/CFT - საეჭვო ოპერაციები, REP/სანქციები, რისკის ერთეულები.
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

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

14) ოპერაციული ექსპლუატაციის პროცესი

1. ფანჯრის მომზადება: უფასო, დანაყოფების გაანგარიშება, დაგვიანებული მოვლენების შევსება.
2. ვალიდაცია: schema + ბიზნეს წესები + რეკონსტრუქცია.
3. ფაილების გამომუშავება: სქემის ვერსია სახელწოდებით ('REP-GB-GAME-v1). 3_2025-10-31. csv`).
4. ხელმოწერა/ჰაში: PGP + SHA256.
5. ადგილზე მიტანა: პორტალი/API/SFTP; მიღების ლოგო (ID/ქვითარი).
6. არქივი: ორიგინალი + ხელმოწერა + ქვითარი ანგარიშების საცავში.
7. მონიტორინგი: Dashboard „Regulatory Reporting“ - სტატუსი „მზად/გაგზავნილი/მიღებული/შეცდომა“.
8. რეტრო: შეცდომების/გადახრების ანალიზი, CAPA.

15) ჩეკის ფურცლები

გაგზავნამდე

დადასტურებულია ფანჯრისა და ტაიმზონის თარიღი.
[] ყველა ვალიდაცია „მწვანეა“, საანგარიშო თანხები შემცირებულია GL/PSP- დან.
[] სქემის ვერსია შეესაბამება რეესტრს.
[] PII შენიღბულია/ფსევდონიმი.
[] ფაილი გაფორმებულია/გადამოწმებულია, დაფიქსირდა ჰაში.
[] რეგულატორის კონტაქტი აქტუალურია (პორტალი ხელმისაწვდომია).

გაგზავნის შემდეგ

[] მიიღო ქვითარი/ID, დაცულია არქივში.
[] სტატუსი განახლებულია დაშბორდში.
[] მიმღების შეცდომით აპდეიტის გეგმა შეთანხმებულია.

16) მეტრიკა და SLO

დრო: დროულად წარდგენილი ანგარიშების%.
First-Try Acceptance:% მიღებული კორექტირების გარეშე.
DQ Score: შეცდომების გარეშე ჩანაწერების წილი (schema/business).
Reconciliation Gap: GL/PSP- სთან შეუსაბამობის მთლიანი/პროცენტი.
Lead Time to Report: ფანჯრის დახურვის დრო დანებებამდე.
Change Failure Rate (ფორმატები): გამოტოვებული სქემების გამოშვების წილი.

17) მთავრობის ადმინისტრაცია

იურისდიქციის მოთხოვნების კვარტალური მიმოხილვა; დაუგეგმავად - რეგულატორების აპათიით.
RFC სქემების შეცვლისთვის: გავლენის ანალიზი, თავსებადობა, საპილოტე გამოცემა „ქვიშის ყუთში“.
ორმაგი გადმოტვირთვა MAJOR- ზე - 1 ციკლი.
განთავისუფლების გუნდების ტრენინგი, ფლეიბუკების განახლება და FAQ.

18) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

არასწორი დრო: ყოველთვის კონსოლიდაცია UTC- ში, ცალკე შენახვა.
დამრგვალება: გამოიყენეთ decimal, საბანკო დამრგვალების ერთიანი წესები.
იდენტიფიკატორების შეუსაბამობა: ერთიანი რეესტრები 'game _ code', 'method _ code', 'psp _ id'.
რიცხვების/თარიღების ლოკალიზაცია: მხოლოდ ISO-8601 და წერტილი, როგორც ათობითი გამყოფი.
PII ღია ფორმით: ნიღბების შემოწმება წინა კომიტსა და CI- ში.

19) ეკოსისტემაში ინტეგრაცია

კომუნიკაცია სექციებთან: დაშბორდის შესაბამისობა, შეტყობინებები და ვადები, ინციდენტის ფლეიბუკები, კრიზისების მენეჯმენტი, აუდიტის ჟურნალები.
ინციდენტის ბოტში: ბრძანება '/ანგარიში <jurisdiction> <report _ id> '- მიიღეთ სქემა და ვადები.
Snaphots- ის ექსპორტი S1/S2- ში ემატება არტეფაქტების პაკეტს.

20) განხორციელების გეგმა (30 დღე)

კვირა 1

1. ლიცენზიის ყველა მარეგულირებელი ანგარიშის ინვენტარიზაცია.
2. ბარათების (§ 4) და კოდების ლექსიკონის შექმნა.
3. ფორმატებისა და გადაცემის არხების დამტკიცება.

კვირა 2
4. DWH და ხაზის ფანჯრების მშენებლობა; პირველადი ვალიდაცია.
5. საპილოტე ფაილების წარმოება (თითო ბაზარი/კლასი).
6. ხელმოწერის/ჰაშის და არქივის კონფიგურაცია.

კვირა 3
7. ინტეგრაცია პორტალთან/API/SFTP „ქვიშის ყუთებთან“.
8. დაშბორდის სტატუსები და ალერტები ვადაზე.
9. ტრენინგი Reporting Ops და შემოწმების ფურცლები.

კვირა 4
10. საპილოტე გადაცემა 2-3 მოხსენება; ფიდბეკის კოლექცია.
11. CAPA DQ/validations; სქემების კორექტირება.
12. გამოშვება v1. 0; გადასინჯვების გრაფიკი და ვადების ერთიანი კალენდარი.

დაკავშირებული სექციები:
შეტყობინებები დარღვევებისა და ანგარიშგების ვადების შესახებ
Dashbord Complaence და მონიტორინგი
ინციდენტის ფლეიბუქები და სკრიპტები
კრიზისული მენეჯმენტი და კომუნიკაცია
ბიზნესის უწყვეტობის გეგმა (BCP )/DRP
ოპერაციების აუდიტის ჟურნალები