<공식 보고서 이름>

1) 목적과 범위

모든 라이센스 및 시장에 대한 규제 보고서의 수집, 생성 및 제출을 표준화하십시오. 문서는 다음을 정의합니다

보고서 카탈로그 및 일정

데이터 형식 및 스키마

검증 및 품질 관리 규칙;

전송 및 승인 채널;

역할 및 RACI, 아티팩트 로그 및 보존.

2) 역할 및 RACI

소유자: 준수 책임자-버전, 우선 순위 (A) 를 승인합니다.
Schema Steward (DWH Lead) - 스키마 및 매핑 (R) 지원.
프로듀서: AML/RG/Payments/Game Ops-데이터 소스 (R).
QA/DQ: 데이터 품질 팀-유효성 검사, 테스트 키트 (R).
법적: 규범 해석, 변경 승인 (C).
보안/DPO: PII/Aliasing, 배달 채널 (C).
Ops보고: 업로드, 서명, 전송, 확인 (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 _ 코드, 통화, 지분, 승리, round _ id, sesion _ 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 ('day', ts _ utc) AS report _ date,

게임 _ 코드,

통화,

SUM (스테이크) AS 스테이크 _ sum,

SUM (승리) AS win _ sum,

SAFE _ DIVIDE (SUM (승리), NULLIF (SUM (스테이크), 0)) AS rtp

fact _ game _ rounds에서

• GROUP BY 1,2,3;

Payments (deposits/withdrawals/fees):

sql

셀렉트

DATE _ TRUNC ('day', ts _ utc) AS report _ date,

메소드 _ 코드, psp _ id, 통화,

SUM (CASE 언제 유형 = 'DEPOSIT' THEN 금액 ELSE 0 END) AS 예금,

SUM (CASE 언제 유형 = 'WITHDRAWAL' THEN 양 ELSE 0 END) AS 인출,

SUM (수수료) AS 수수료

사실 _ 지불에서

장소 _ TWEEN: AND에서: 에서

GROUP BY 1,2,3,4;

13) Sample files

13. 1 Gaming Unit (CSV)

report _ day, operator _ id, game _ 코드, 통화, 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", "chimes _ day": 180, "ts _ utc": "2025-10-31T09: 11: 02Z"}

{"report _ date": "2025-10-31", "player _ id _ hash": "c01a"..., "rg _ event": "LIMIT _ BREACH", "limate _ Type": "LOSS _ DAILY", "amount": 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. ').
4. 시그니처/해시: PGP + ș256.
5. 배송: 포털/API/SFT; 수신 로그 (ID/영수증).
6. 보관: 보고서 저장소의 원본 + 서명 + 영수증.
7. 모니터링: 대시 보드 "규제보고" - 상태 "준비/전송/허용/오류".
8. 복고풍: 오류/편차 분석, CAPA.

15) 점검표

보내기 전에

[] 창 및 시간대 날짜가 확인되었습니다.
[] 모든 유효성 검사는 녹색이며보고 된 금액은 GL/PSP와 조정됩니다.
[] 스키마 버전은 레지스트리와 일치
[] PII 마스크/앨리어스.
[] 파일 서명/확인, 해시 커밋.
[] 규제 기관의 연락처가 최신 상태입니다 (포털을 사용할 수 있음).

전송 후

[] 수령/ID가 수신, 보관되었습니다.
[] 대시 보드에서 상태가 업데이트되었습니다
[] 유효성 검사기 오류가 발생할 경우 업데이트 계획이 합의됩니다.

16) 측정 및 SLO

시간: 보고서의% 가 정시에 제출되었습니다.
첫 번째 시도 수락: 수정없이% 허용됩니다.
DQ 점수: 오류가없는 항목의 백분율 (스키마/비즈니스).
조정 갭: GL/PSP와의 절대/백분율 불일치.
보고 리드 시간: 창을 닫는 것부터 제출까지의 시간.
실패율 변경 (형식): 롤백과 스키마 릴리스 공유.

17) 거버넌스

관할권 별 청구에 대한 분기 별 검토; 예정되지 않은 - 규제 기관 업데이트 중.
스키마 변경을위한 RFC: 충격 분석, 상호 운용성, 샌드 박스 파일럿.
MAJOR주기에서 이중 언로드
릴리스, 플레이 북 및 FAQ 업데이트에 대한 교육 팀.

18) 빈번한 실수와 피하는 방법

잘못된 시간대: 항상 UTC로 통합하고 로케일을 별도로 저장하십시오.
반올림: 10 진수의 균일 한 은행 반올림 규칙을 사용하십시오.
식별자의 일관성이 없음: 단일 레지스터 'game _ code', 'method _ code', 'psp _ id'.
숫자/날짜의 현지화: ISO-8601 및 10 진수 구분 기간 만.
명확한 PII: 사전 커밋 및 CI에서 마스크 확인.

19) 생태계에 포함

섹션과의 통신: 준수 대시 보드, 알림 및 마감일, 사건 플레이 북, 위기 관리, 감사 로그.
사건 봇에서 명령 '/보고 <관할권> <report _ id> '-계획과 마감일을 얻으십시오.
S1/S2에서 스냅 샷 수출이 아티팩트 패키지에 추가됩니다.

20) 시행 계획 (30 일)

1 주차

1. 모든 라이센스 규제 보고서의 목록.
2. 카드 작성 (§ 4) 및 코드 사전.
3. 전송 형식 및 채널 승인.

둘째 주
4. 건물 DWH 및 계보 쇼케이스; 주요 검증.
5. 파일럿 파일 생성 (하나의 시장/클래스).
6. 서명/해시 및 아카이브 구성.

셋째 주
7. 샌드 박스 포털/API/SFTP와 통합
8. 대시 보드 상태 및 마감일 별 경고.
9. Ops 교육 및 점검표를보고합니다.

넷째 주
10. 2-3 보고서의 파일럿 전달; 피드백 수집.
11. DQ/유효성 검사를위한 CAPA; 계획 조정.
12. 릴리즈 v1. 0; 개정 일정 및 단일 마감일 일정.

관련 섹션:
위반 및보고 마감일 통지
준수 대시 보드 및 모니터링
인시던트 플레이 북 및 스크립트
위기 관리 및 커뮤니케이
비즈니스 연속성 계획 (BCP )/DRP
거래 감사 로그