運營和合規→ iGaming市場監管卡

iGaming市場監管卡

1）為什麼需要監管卡

若幹市場的工作涉及要求的可比性和相關性。「地圖」是具有規範化字段的國家的單一目錄：許可證類型，KYC/AML要求，RG限制，廣告/關聯規則，支付方法，稅收模型，報告，提供商和當地的「紅線」。

目標是：

加快go/no-go和國家優先級。
簡化本地規範下的板載提供商、廣告和付款。
降低處罰/聲譽風險和合規成本。
給Ops/Compliance一個真相來源（SSOT）。

2）字段分類（每個國家/地區都有記錄）

基本元數據

國家/地區，市場狀況（監管/灰色/禁止），可用垂直線（賭場，現場，投註，撲克，樂托）。
登錄模式：本地許可證/.com受限制/與本地持有人合作。

許可和監督

調節器，許可證類型（B2C/B2B/子類別），本地存在要求。
審核程序（技術，財務，RNG）和周期性。

KYC/AML

基本檢查（身份、地址）、EDD觸發、RER/制裁檢查、數據保留時間。
資金來源，velocity限制和升級規則。

Responsible Gaming (RG)

年齡限制，存款/損失/時間限制，自我排斥，冷靜，本地註冊。

廣告和附屬公司

允許的頻道/時間段/內容字段，年齡標記，禁止「無風險」語言。
會員要求（合同，披露，真實UTM，實踐黑名單）。

付款和提供商

允許的方法（卡、銀行、錢包、憑證）、本地處理器、充電器/退款要求。
對B2B遊戲/支付提供商（許可證，報告，SLA）的要求。

數據/隱私和安全性

個人數據模式（類似GDPR的規範/本地）。
本地化/跨境傳輸、保留時間、數據主體權利。

稅收和報告

稅基（通常為GGR/turnover/付款費用），報告期，上載格式。
Finmonitoring，強制性RG/AML報告，事件報告。

限制和「紅線」

黑色/灰色營銷實踐，禁止獎勵機制，頭獎限制，夜間限制等。

3）數據模型（骨架）

yaml country: <ISO-2>
market_status: regulated    restricted    prohibited    grey verticals: [casino, live, betting, poker, lotto]
entry_model: local_license    partner. com_limited regulator:
name: <...>
site: <ref>
licenses:
b2c: [<type_a>, <type_b>]
b2b: [<rng>, <platform>, <payment_provider>]
kyc_aml:
base: [id, address, pep_sanctions]
edd_triggers: [amount_spike, multiple_methods, high_risk_geo]
retention_days: <int>
rg:
limits: {deposit: required    optional, loss: required    optional, time: optional}
self_exclusion: registry    internal    none ads_affiliates:
allowed_channels: [tv, ooh, digital, influencer]
disclaimers_required: true    false affiliate_rules: [kyb_required, utm_registry]
payments:
methods_allowed: [cards, bank_transfer, wallet, voucher, cash]
withdrawals_rule: source_to_source    required_checks privacy_security:
regime: gdpr_like    local data_localization: required    not_required tax_reporting:
tax_model: ggr    turnover    mixed reporting: {frequency: monthly    quarterly    realtime, formats: [csv, api]}
providers:
game_providers_requirements: [license, testing, rng]
payment_providers_requirements: [local_presence, settlement_rules]
red_lines: [no_risk_free_claims, minors_targeting_ban]
last_review: YYYY-MM-DD owner: compliance_team

4）風險圖和國家優先排序

評估軸是：

監管風險（剛性/不確定性/罰款）。
Go-To-Market Effort（許可證期限/本地化/集成）。
單位經濟學（稅收負擔/支付傭金/ARPPU預測）。
操作復雜性（RG限制/報告/供應商）。

得分（示例）：「得分=（經濟學-風險-復雜性）×準備就緒」，其中「準備就緒」是我們流程的成熟度（KYC/AML/RG/Reporting）在特定管轄範圍內。

優先級集群：A（啟動6-9個月）、B（準備）、C（研究）。

5）匹配矩陣（匹配地圖）

將我們的政策/控制與國家的要求相匹配：

國家要求	我們的政策/控制	狀態	Gap/計劃
通過國家登記冊進行自我排序	RG-POL-001 / CTRL:RG-EXC-002	一部分	與註冊表集成,ETA Q1
AML在N日的 SAR報告	AML-POL-003 / SOP:AML-SAR	對應	—
限制創意	ADS-POL-002	需要澄清	模板/渠道支票清單

6） Controls -/Policy-as-Code（片段）

RG限制控制（包括國家/地區）：

yaml control_id: RG-LIM-DAILY judgments: [""] # defaults, redefined in trigger country: loss_today> limit_loss_daily actions:
- block: betting
- notify: player_template_rg_7 overrides:
- when: country==<ISO>
set: {limit_loss_daily: <local_rule>, cool_off_hours: <N>}

營銷條款（disclaimer規則）：

yaml policy_id: ADS-DISCL-001 require:
- on_all_creatives: age_restriction
- on_bonus: wagering_conditions ban:
- wording: ["risk-free", "guaranteed win"]
overrides:
- country: <ISO>
additions: {time_window: "22:00-06:00 ban TV"}

報告（格式/頻率）：

yaml reporting:
frequency: monthly exports: [revenue_by_vertical, rg_cases, aml_sar]
transport: sftp    api overrides:
- country: <ISO>
frequency: realtime exports: [bet_level, session_level]

7）監管卡的標記（顯示的內容）

市場準備：按國家分列的許可/整合/政策狀況。
Compliance Heatmap：KYC/AML/RG/Ads/Privacy-「綠色/黃色/紅色」。
Evidence Coverage：具有正確收集的證據的操作比例。
報告SLA：上載/電路錯誤/驗證的及時性。
風險註冊：按國家/地區劃分的最高風險，緩解計劃，ETA。

8）流程和RACI

SOP： 添加或更新國家/地區

1.對國家的要求進行青少年評估和模擬→卡。
2.設置Policy -/Controls-as-Code和報告。
3.供應商/付款：盡職調查和測試。
4.牛排上的戰鬥測試→飛行員流量的1-5％。
5.調試+監視KPI和調節差速器。

RACI（片段）：

活動	R	A	C	I
國家模型/卡片	Compliance Analyst	Head of Compliance	Legal, Security	Ops
設置控制	SRE/Platform	Head of Ops	Compliance	Domains
A.報告	Data/BI	Head of Compliance	Legal	Finance
廣告/附屬機構	Marketing Compliance	CMO	Legal/Brand	Finance

9）支票單盡職調查

新國家

監管機構和許可證類型，允許垂直。
控制中的KYC/AML/RG映射和覆蓋。
Ads/Affiliates保留規則和模板。
隱私/數據本地化,保留時間。
付款：可用的方法，退貨/退貨規則。
報告：格式、傳輸、頻率；測試卸載。
提供商：要求和審計。
風險/紅線記錄。

新會員/頻道

KYB，合同，UTM註冊表，創意庫。
目標限制（年齡/地理）。
claim和禁止使用的語言政策。
交通中斷暫停機制。

10）反模式

「兩個版本的真相」：Excel表與程序控制分開。
未經修飾的局部解釋而無需進行法律確認。
無鄉村廣告的通用規則。
缺乏事件存儲和SLA報告。
沒有所有者和定期修訂的地圖。

11）成熟度量

覆蓋國家：填滿田地的國家卡≥ 90%。
控制對準：需要≥ 95％的國家-overrides控制份額。
報告SLA：上載的及時性≥ 98％。
證據完整性：證據總量≥ 98%。
Audit Findings TTR：結束評論≤ 90天。
事件泄漏：市場營銷/RG違規份額→下降趨勢。

12）整合

Docs -/Policy -/Controls-as-Code：一個具有評論/CI的存儲庫。
CRM/Payments/DWH：country-aware規則，報告展示。
觀察力：異物漂移（控制不起作用，報告沒有消失）。
AI助理編譯器：搜索國家/地區的卡片，覆蓋線索和報告草稿。

13）30/60/90-實施計劃

30天（基礎）：

批準字段分類法和國家卡模板。
展開「reg-map/」存儲庫（docs/policies/controls/reports）。
將5-7個關鍵國家/地區納入當前投資組合，建立基本覆蓋範圍。
提高Coverage/Heatmap/Reporting SLA的行車記錄板。

60天（縮放）：

添加付款/廣告/提供商註冊表和捆綁包。
啟用RG/AML/Ads的事件存儲。
自動執行計劃報告和驗證的測試輸出。
將Alerta嵌入調節「漂移」。

90天（固定）：

覆蓋≥ 90%的目標國家，對控制設計進行內部審計。
將監管卡KPI鏈接到OKR（報告SLA, Evidence, Audit TTR）。
定期季度更新國家和流程卡。

14) FAQ

問：如何保持地圖的相關性？
A：每次90至180天對卡進行一次審計，通過「last_review」進行CI提醒，以解決報告/控制不一致的問題。

問：如果國家規範之間的矛盾，該怎麼辦？
答：適用更嚴格的規範，或將雜貨店的雜貨店與單獨的雜貨店隔開。

Q：如何將卡與產品關聯?

答：通過Controls-as-Code：通過「國家」/「品牌」/「垂直」啟用規則,報告店面自動收集所需的字段。