<отчеттун расмий аталышы>

1) Максаты жана камтуу

• отчеттордун каталогу жана графиги;
• берилиштердин форматтары жана схемалары;
• валидация жана сапатты контролдоо эрежелери;
• берүү каналдары жана кабыл алууну ырастоо;
• ролдору жана RACI, артефакттар жана ретенция журналы.

2) Ролдору жана RACI

Owner: Head of Compliance - версияларды, артыкчылыктарды (A) ырастайт.
Schema Steward (DWH жол): схемалар жана mapping колдоо (R).
Producers: AML/RG/Payments/Game Ops - маалымат булактары (R).
QA/DQ: Data Quality Team - валидациялар, тесттик топтомдор (R).
Юридикалык: ченемдерди чечмелөө, өзгөртүүлөрдү макулдашуу (C).
Коопсуздук/DPO: PII/псевдоним, жеткирүү каналдары (C).
Отчет Ops: чыгаруу, кол коюу, жөнөтүү, ырастоо (R).

3) Отчеттор каталогу (класстар)

1. Оюн отчеттору - коюмдар/утуштар/баланстар/сессиялар, RTP, чынчылдык.
2. Каржылык - аманат/чегерүү, чегерүү, салыктар, GGR/NGR, chargebacks.
3. AML/CFT - шектүү операциялар, РР/санкциялар, тобокелдик агрегаттары.
4. Жоопкерчиликтүү оюн (RG) - өзүн-өзү четтетүү, лимиттер, интервенциялар.
5. Инциденттик - жеткиликтүүлүк, агып кетүү, билдирүүлөр жана мөөнөттөр.
6. Маркетинг/аффилиаттар - трафиктин булактары, жарнаманы чектөө (эгерде лицензия талап кылынса).
7. Техникалык - aptime, 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. Терезени даярдоо: freeze, агрегаттарды эсептөө, кеч окуяларды жүктөө.
2. Валидация: схема + бизнес эрежелери + reconciliation.
3. Файлдарды түзүү: аталыштагы схеманын версиясы ('REP-GB-GAME-v1. 3_2025-10-31. csv`).
4. Кол/хеш: PGP + SHA256.
5. Жеткирүү: Portal/API/SFTP; кабыл алуу журналы (ID/квитанция).
6. Архивация: оригинал + кол + отчет сактоочу жайдагы квитанция.
7. Мониторинг: "Regulatory Reporting" дашборд - "даяр/жөнөтүлгөн/кабыл алынган/ката" статусу.
8. Retro: каталарды/четтөөлөрдү талдоо, CAPA.

15) Чек баракчалары

Жөнөтүү алдында

[] Терезенин жана таймзондун датасы тастыкталды.
[] Бардык валидациялар "жашыл", отчеттук суммалар GL/PSP менен салыштырылган.
[] Схеманын версиясы реестрге туура келет.
[] PII жашыруун/псевдоним.
[] файл кол коюлган/текшерилген, хеш жазылган.
[] Жөнгө салуучу менен байланыш актуалдуу (портал жеткиликтүү).

Жөнөткөндөн кийин

[] дүмүрчөк/ID алынган, архивде сакталган.
[] Статус dashboard өзгөртүлгөн.
[] validator ката жаңылыштык планы макулдашылган.

16) Метрика жана SLO

Timeliness: өз убагында берилген отчеттордун%.
First-Try Acceptance:% туура кабыл алынган.
DQ Score: катасыз жазуулардын үлүшү (схема/бизнес).
Reconciliation Gap: абсолюттук/GL/PSP менен айырмачылык пайызы.
Lead Time to Report: Терезенин жабылышынан тартып жеткирүүгө чейинки убакыт.
Change Failure Rate (форматтар): ыргытуу схемаларынын релиздеринин үлүшү.

17) Өзгөрүүлөрдү башкаруу (governance)

Юрисдикциялар боюнча талаптарды чейрек сайын карап чыгуу; пландан тышкаркы - жөнгө салуучу такталганда.
схемаларды өзгөртүү боюнча RFC: импакт-талдоо, шайкештик, "кум" пилоттук чыгаруу.
MAJOR ≥ 1 айлампасы менен кош түшүрүү.
Чыгарылганда командаларды окутуу, playbook жана FAQ жаңылоо.

18) Көп каталар жана аларды алдын алуу үчүн кантип

Туура эмес убакыт: ар дайым UTC консолидация, өзүнчө жергиликтүү сактоо.
Тегеректөө: decimal, банктык тегеректөөнүн бирдиктүү эрежелерин колдонуу.
Идентификаторлордун дал келбегендиги: бирдиктүү реестрлер 'game _ code', 'method _ code', 'psp _ id'.
Сандарды/күндөрдү локалдаштыруу: ISO-8601 жана чекит гана ондук бөлгүч катары.
PII ачык: алдын-ала жана CI-жылы маска текшерүү.

19) Экосистемага киргизүү

Бөлүмдөр менен байланыш: Дашборд комплаенс, Билдирүүлөр жана мөөнөттөр, Инциденттик плейбуктар, Кризистик башкаруу, Аудит журналдары.
Окуя-ботто: команда '/report <jurisdiction> <report_id>' - схема жана мөөнөт алуу.
S1/S2 учурунда снапшотторду экспорттоо артефакттардын пакетине кошулат.

20) Ишке ашыруу планы (30 күн)

1-жума

1. Лицензиялар боюнча бардык регулятивдик отчетторду инвентаризациялоо.
2. Карточкаларды (§ 4) жана коддордун сөздүктөрүн түзүү.
3. Берүү форматтарын жана каналдарын бекитүү.

Жума 2
4. DWH жана сызык терезелерди куруу; баштапкы валидациялар.
5. Пилоттук файлдарды түзүү (бир рынок/класс боюнча).
6. Кол тамганы/хэштерди жана архивди тууралоо.

Жума 3
7. Portal/API/SFTP "Sandbox" менен бириктирүү.
8. Dashbord статусу жана мөөнөтү боюнча алерта.
9. Отчет Ops жана чек баракчаларын окутуу.

4-жума
10. 2-3 отчетторду пилоттук тапшыруу; фидбек чогултуу.
11. DQ/валидация боюнча CAPA; схемаларды тууралоо.
12. Релиз v1. 0; текшерүү графиги жана бир календар.

Байланыштуу бөлүмдөр:
Бузуулар жөнүндө билдирүүлөр жана отчеттуулук мөөнөттөрү
Дашборд комплаенс жана мониторинг
Окуя ойнотмо жана скрипттер
Кризистик башкаруу жана коммуникациялар
Бизнес үзгүлтүксүздүгү планы (BCP )/DRP
Операцияларды текшерүү журналдары