オペレーションとコンプライアンス→AMLポリシーとトランザクション管理

AMLポリシーとトランザクションコントロール

1）目的と範囲

AML政策の目的は、マネーロンダリングとテロ資金調達のためのプラットフォームの使用を防止し、偽陽性と運用負荷を最小限に抑えることです。このポリシーはプレイヤーのライフサイクル全体に適用されます： 登録→預金→ゲーム/送金→引き出し；アフィリエイト、プロバイダー、支払いパートナーだけでなく、

2）原則（リスクベース&エビデンス・バイ・デザイン）

1.リスクベースのアプローチ（RBA）：チェックとしきい値はリスクプロファイル（国、支払方法、行動、金額）に依存します。
2.レイヤードコントロール：CCM/制裁/PEP、行動分析、手動調査の組み合わせ。
3.エビデンス・バイ・デザイン：各ソリューションには、データソース、スクリーンショット、ログ、エクスポートされたレポートなどのアーティファクトがあります。
4.プライバシーファースト：個人データの最小化、マスキング、役割によるアクセス、管理された保持ポリシー。
5.説明可能性：ルールとモデルは解釈可能です。MLの場合-機能/重要性/ケース例。
6.継続的な改善：しきい値の設定、MLROからのフィードバック、ケースごとにレトロ。

3）役割と責任

MLRO（マネーロンダリング報告役員）：AMLプロセスの所有者、SAR/STRに関する最終決定、規制当局/銀行とのコミュニケーション。
AML Ops：調査、プレーヤー/銀行通信、SLAケースコントロール。
データ/BI&リスクアナリティクス：ルール/モデルサポート、検出品質監視。
支払い/Ops：制限の遵守と保留/逆方向の手続き、トランザクショントレーシング。
セキュリティ/DPO：データ保護、アクセス、プライバシーインシデント。

4）プレーヤーとセグメントのリスクモデル

• Geo/IP/Residency、 KYC Document and Method。
• 入出金方法、複数の支払い方法。
• 活動：量、頻度、vinrate/lossrate、夜間セッション、他の記述との相関。
• デバイス/指紋印刷、IP/デバイス/支払い詳細交差。

セグメント：低/中/高/禁止。
ルーティングエンジン：低い-簡略化された点検；高い-EDD/hold/restrictions。

5） KYC、制裁およびPEP

階層KYC： 'KYC1 （identity）→KYC2 （address）→EDD （additional documents/SoF）'。
制裁/REP：登録時の検証、預金/結論の大幅なしきい値、および詳細を変更するとき。
SoF/SoW：トリガー（ハイレベル、プロファイルの不一致、VIP）。
保持：管轄区域によって要求される文書の保持；vault/check-outコントロール経由でアクセスできます。

6）トランザクション制御（ルールとシグナル）

• 速度：速い沈殿物/出金のスパイク；一連の小さな預金→大きな引き出し。
• マルチインストゥルメント：短期間で多くの異なるカード/財布。
• Source/Destination mismatch： deposit from one instrument、 output to another。
• 循環：補充→最低料金/洗浄ボーナス→引き出し。
• 分割/構造化：しきい値の下で分割量。
• アフィリエイトの乱用：チャネルからの異常な流入+虐待の典型的なパターン。
• デバイス/IPリスク：デバイスの変更/プロキシ/高リスクASN。

• 低分散の非現実的な醸造、不満のある「コンテンツパートナー」への賭け、売上高のためのリスクを最小限に抑えるゲーム。

7）コントロールアズコード（フラグメント）

yaml control_id: AML-VELOCITY-DEP-01 scope: deposits risk_weight: 0. 8 trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3
OR count_unique(payment_method, 1h) >= 3
OR count(amount < threshold_structuring, 24h) >= 5 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- request: "KYC2_or_EDD"
evidence:
store: s3://evidence/aml/velocity/{player_id}/{ts}
fields: [amounts_1h, methods_1h, ip, device, kyc_level]
owner: mlro review_sla_days: 180

yaml control_id: AML-SRC-DST-02 scope: withdrawals trigger:
expr: payout_method!= last_successful_deposit_method actions:
- limit: withdrawals "require_same_source"
- notify: payments_team
- flag: aml_review exceptions:
- condition: method_type=="bank_transfer" AND policy. allow_bank_payouts==true evidence:
fields: [payout_method, last_deposit_method, policy_ref]

yaml control_id: AML-GAMING-PATTERN-03 scope: gameplay trigger:
expr: turnover_24h / deposits_24h > 10
AND avg_bet_risk_index < 0. 2
AND session_count_24h > 8 actions:
- flag: aml_review
- limit: bonuses "freeze"
- request: "source_of_funds"

yaml control_id: AML-RISK-SCORE inputs: [AML-VELOCITY-DEP-01, AML-SRC-DST-02, AML-GAMING-PATTERN-03, sanctions, pep]
score:
expr: w1velocity + w2srcdst + w3gaming + w4sanctions + w5pep thresholds:
- high: score>=0. 8 -> EDD + hold
- medium: score>=0. 5 -> review
- low: score<0. 5 -> auto_clear

8）モデルとルール： 共有

最初のルール（すばやく、わかりやすい）+優先順位付けのためのML（グラデーションブースト/ログレグ/抽出可能な機能）。
Champion/Challenger：現在のしきい値と日陰の新しいモデルの比較。
ドリフトモニタリング：機能のシフト制御、フラグ/ホールド、FPR/TPRの共有。
説明：SHAP/機能の重要性、参照例。

9） SOP（フラグメント）

SOP： AMLトリアージ

1.プレイヤーのカード（地理、KYC、リスク率、履歴）を確認します。
2.データソース（決済ログ/ゲーム、デバイス接続）を確認します。
3.「クリア/request_info/hold/EDD/SAR'」を決定します。
4.ケースシステムでアクションを記録し、ステータスを更新します。
5.プレイヤーとのコミュニケーション（テンプレート、応答時間）。
6.しきい値/ルールリビジョン（多くのFPの場合）。

SOP： EDD/SoFリクエスト

1.書類請求（明細書・給与・税金）

2.合計/周波数/ソースをプラットフォームの動作にマップします。
3.リスクプロファイルを更新し、制限を削除/確認します。
4.証拠と解決策（MLRO署名）を保存します。

SOP： SAR/STRフィード

1.ファクトロジー（タイムライン、金額、リンク、スクリーンショット）を収集します。
2.管轄/銀行の期限とフォーマットを確認してください。
3.SAR/STRを送信し、識別子/時刻/チャネルを修正します。
4.内部ステータスとアカウントの制限を更新します。
5.閉鎖/規制/銀行の指示へのフォローアップ。

10）プレイヤーやパートナーとのコミュニケーション

トーン：中立的で事実上、内部ルール/モデルの開示はありません。
締め切り：応答、リマインダー、チケットの固定のための明確なETA。
決済パートナー：ホールド/リバース同期、ケースID交換、単一のAMLチャネル。

11）統合とデータ

支払ゲートウェイ：トランザクションのステータス、メソッドと詳細、リターン、チャージバック。
ゲームプラットフォーム：転換/酢/セッション/分散、異常。
デバイスグラフ：指紋/デバイス/セッション/IP通信。
KYC/PEP/制裁：イベントとスケジュールスクリーニングプロバイダー。
ケース管理：ステータス、SLA、意思決定ログ、SAR/STRパッキング。

12）品質指標（KPI/OKR）

• 確認された場合のTPR/リコール、 FPR （false flags）： QoQ。
• 高精度高リスク>X％；オートクリアレート（Low-risk> Y％）。
• Case Prioritization Accuracy（上部N％は検索のM％を与えます）。

• トリアージ時間（P95）、 EDDターンアラウンド、ホールド時間（中央値）。
• SAR/STR SLA （≤締め切りの提出）、AML対策後の返品/チャージバックの確認※
• モデル/ルールのドリフト-許容できる廊下内。

• 詐欺による損失・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
• プレーヤーの経験：AMLプロセス、正直なプレーヤーのNPSについての苦情。

13）ガバナンスと安全

アクセスポリシー：AML/MLROのみが機密フィールドを表示します。監査を読んでください。
保存期間：ケース/ドキュメントの保存期間；自動クリーニング。
ロギング：ケースおよびルール/モデル編集のすべてのアクション。
デュアルコントロール：重要なルール/しきい値の変更には2つの確認が必要です。
CIのテスト：ルール構文、しきい値の競合、回帰シナリオ。

14）チェックリスト

• トランザクション/ゲーム/デバイスデータを確認しました。
• 入出金方法がマップされます。
• 制裁/PEP/geoが検証されました。
• 正しいソリューションタイプを選択（'clear/hold/EDD/SAR'）。
• 記録されたETAおよびプレーヤーのコミュニケーション。

• 完全なタイムラインと金額、他のアカウントとの接続。
• アーティファクトをサポート（スクリーンショット/ログ/ステートメント）。
• フォーマットおよびチャネルは条件を満たします。
• 内部のステータスと制限が更新されました。
• その後の指示を監視します。

• しきい値/タイムウィンドウが正当化されました。
• FP/TP評価、ビジネス効果があります。
• ドリフトとオートテストモニタリングが設定されています。
• プレイブックのトリアージを更新しました。
• MLRO/コンプライアンスレビュー実施。

15）アンチパターン

RBAなしの「すべての国のための」普遍的なしきい値。
ETA/コミュニケーションなしで握り「、掛かる」場合。
説明可能性とバージョン履歴のないMLモデル。
証拠テンプレートと日付管理のない手動アップロード/SAR。
depozit↔vyvodコミュニケーションの欠如、支払いとの統合が不十分です。
偽陽性には通常のレトロはありません。

16） 30/60/90-実装計画

• AMLポリシー、ロール（MLRO/AML Ops）、 RBA行列を承認します。
• 基本的なControls-as-Code（速度、src/dstの不一致、ゲームパターン）を実行します。
• KYC階層+制裁/PEPを有効にし、SOPテンプレート（トリアージ/EDD/SAR）を作成します。
• 証拠保管および保存ポリシーを入力します。

• リスクアグリゲータ、自動ルーティングケース、SLAレポートを接続します。
• しきい値とML優先順位付けアシスタントのチャンピオン/チャレンジャーを起動します。
• 支払い/ゲーム/デバイスグラフをシングルプレイヤープロファイルに統合します。
• Trainコマンド、debug communication templates、 enable rule autotests。

• リコールの損失なしでFPR ≥ 20％を減らして下さい；トリアージまでの時間を30％ ≥短縮します。
• SLAのSAR/STR=100％を時間通りに達成して下さい；すべての「古い」ケースを閉じます。
• 管理の設計と有効性の内部監査を実施する。次の四半期のOKRを記録します。

17） FAQ

Q：保証およびUXのバランスをとる方法か？
A： RBAルーティング：低リスクの自動クリーニング、中程度の簡単なリクエスト、高EDD/ホールドの場合。透明なETAと通信。

Q： VIPと高い制限についてどうすればいいですか？
A：必須EDD、定期的なSoF/行動レビュー、ソースからソースへの追加制限。

Q：いつ銀行/規制当局にエスカレートするのですか？
A：管轄期限に従って確認された赤い旗/疑惑を使って；MLROの協議と証拠の固定後。