オペレーションとコンプライアンス→iGaming Marketsの規制マップ

iGaming市場の規制マップ

1）規制マップが必要な理由

いくつかの市場での作業は、要件の比較可能性と関連性にかかっています。「マップ」は、ライセンスタイプ、KYC/AML要件、RG制限、広告/アフィリエイトルール、支払い方法、税金モデル、レポート、プロバイダー、およびローカル赤線など、正規化されたフィールドを持つ国の単一のディレクトリです。

目的：

国ごと/行かないことおよび国の優先順位付けを加速して下さい。
オンボーディングプロバイダ、広告、ローカル決済を簡素化します。
ペナルティ/評判リスクとコンプライアンス・コストの削減。
Ops/Complianceに単一の真実源（SSOT）を与える。

2）フィールドの分類（各国の修正内容）

基本的なメタデータ

国/地域、市場状況（規制/灰色/禁止）、利用可能な垂直（カジノ、ライブ、賭け、ポーカー、ロット）。
ログインモデル：ローカルライセンス/。com限定/ローカルホルダーとのパートナーシップ。

ライセンスと監督

レギュレータ、ライセンスの種類（B2C/B2B/サブカテゴリ）、ローカルプレゼンス要件。
監査手順（技術、財務、RNG）と頻度。

KYC/AML

基本的な検証（身元、住所）、EDDトリガー、POP/制裁チェック、データ保存期間。
ソース、ベロシティ、エスカレーションのルール。

責任あるゲーム（RG）

年齢制限、預金/損失/時間制限、自己排除、クーリングオフ、ローカルレジストリ。

広告・アフィリエイト

許可されたチャンネル/タイムスロット/コンテンツwikids、年齢マーカー、「リスクのない」言葉遣いの禁止。
アフィリエイトの要件（契約、開示、実際のUTM、練習のブラックリスト）。

支払いとプロバイダー

許可された方法（カード、銀行、財布、バウチャー）、ローカルプロセッサ、チャージバック/払い戻しの要件。
B2Bゲーム/決済プロバイダ（ライセンス、レポート、SLA）の要件。

データ/プライバシーとセキュリティ

パーソナルデータモード（GDPRのような規範/ローカル）。
ローカリゼーション/クロスボーダー転送、保持期間、データ主体権。

税務・報告

税金ベース（多くの場合、GGR/売上高/支払手数料）、レポート期間、ダウンロードフォーマット。
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）適合地図

私達は国の条件と私達の方針/制御を比較します：

国の要件	私たちのポリシー/コントロール	［ステータス］	ギャップ/プラン
州のレジスタを介した自己排除	/	部分的に	レジストリ統合、ETA Q1
N日間のSARによるAMLレポート	AML-POL-003/SOP： AML-SAR	対応しています	—
クリエイティブの制限	ADS-POL-002	明確にするために	チャンネル別テンプレート/チェックリスト

6）制御-/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>}

マーケティングの免責事項のルール：

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）規制マップのダッシュボード（表示するもの）

市場準備：国によるライセンス/統合/ポリシーのステータス。
コンプライアンスヒートマップ：KYC/AML/RG/広告/プライバシー-緑/黄/赤。
証拠カバレッジ：正しく収集された証拠との取引のシェア。
Reporting SLA：アップロードの適時性/スキーム/検証のエラー。
リスクレジスタ：国によるトップリスク、緩和計画、ETA。

8）プロセスとRACI

SOP： 国の追加または更新

1.法的評価と要件マッピング→カントリーカード。
2.Policy/Controls-as-CodeとReportingを設定します。
3.プロバイダ/支払い：デューデリジェンスとテスト。
4.ステージでの戦闘テスト→トラフィックのパイロット1-5％。
5.KPIと規制アラートの試運転+監視。

RACI（断片）：

アクティビティ	R （R）	A （A）	C （C）	私は、
カントリーモデル/カード	コンプライアンスアナリスト	コンプライアンス責任者	法律、セキュリティ	Ops（オプス）
コントロールの設定	SRE/プラットフォーム	Opsのヘッド	コンプライアンス	［ドメイン］
レポート作成	データ/BI	コンプライアンス責任者	Legal（リーガル）	ファイナンス
広告/アフィリエイト	マーケティングコンプライアンス	CMOについて	リーガル/ブランド	ファイナンス

9）デューデリジェンスチェックリスト

新しい国

スライダーとライセンスタイプ、頂点が許可されています。
コントロールのKYC/AML/RGマッピングとオーバーライド。
広告/アフィリエイト免責事項ルールとテンプレート。
プライバシー/データのローカライズ、保存期間。
支払い：利用可能なメソッド、返品/出力ルール。
レポート：フォーマット、輸送、周波数；荷を下すことをテストして下さい。
プロバイダ：要件と監査。
ヘアライン/赤線が固定されています。

新しいアフィリエイト/チャンネル

KYB、契約、UTMレジストリ、クリエイティブライブラリ。
ターゲティング制限（年齢/地理）。
クレームと禁止言語のポリシー。
違反の場合の交通停止のメカニズム。

10）アンチパターン

「真実の2つのバージョン」：Excelテーブルは本番コントロールから分離します。
法的な確認なしに現地で検証されていない解釈。
国の優先なしの普遍的な広告規則。
証拠保管とSLAレポートの欠如。
所有者と定期的な改訂なしのカード。

11）成熟度の指標

国のカバレッジ：フィールドがいっぱいの国のカード≥ 90％。
Control Alignment： 95％を≥すべきcountry-overridesを持つコントロールの割合。
SLAの報告：アップロードの適時性≥ 98％。

証拠の完全性≥ 98％

監査結果TTR：コメントの締め切り≤ 90日です。
インシデントリーク：マーケティング/RG違反のシェア→減少傾向。

12）統合

Docs-/Policy-/Controls-as-Code：レビュー/CI-lintを持つ単一のリポジトリ。
CRM/Payments/DWH：国を意識したルール、店舗を報告する。
Observability：コンプライアンスドリフトへのアラート（制御が機能しませんでしたが、レポートは消えませんでした）。
AIコンプライアンスアシスタント：カントリーカードで検索し、ヒントを上書きし、レポートを作成します。

13） 30/60/90-実施計画

30日（基礎）：

フィールドタクソノミとカントリーカードテンプレートを承認します。
「reg-map/」リポジトリ（docs/policies/controls/reports）を展開します。
現在のポートフォリオに5-7の主要国を追加し、基本的なオーバーライドを設定します。
Coverage/Heatmap/Reporting SLAダッシュボードを上げる。

60日（スケーリング）：

支払い/広告/プロバイダのレジスタとバンドルを追加します。
RG/AML/広告のエビデンスストレージを有効にします。
レポートおよび検証スキームのテストエクスポートを自動化します。
規制「ドリフト」に関するアラートを作成します。

90日（固定）：

対象国の90％ ≥カバーし、管理設計の内部監査を実施します。
規制カードKPIをOKR（報告SLA、証拠、監査TTR）にリンクします。
国とプロセスカードの定期的な四半期ごとの更新。

14） FAQ

Q：マップはどのように関連していますか？
A： 90〜180日ごとのカードの改訂、'last_review'のCIリマインダー、レポート/コントロールの不整合のアラート。

Q：国の規範に矛盾がある場合はどうすればいいですか？
A：より厳密な規範を適用するか、または個々のオーバーライドで地理的に製品フローを分割します。

Q：カードを製品にリンクするにはどうすればよいですか？
A： Through Controls-as-Code：ルールは'country'/'brand'/'vertical'によって有効になり、レポートショーケースは自動的に必要なフィールドを収集します。