操作和合規→ AML策略和事務控制

AML策略和事務控制

1）目的和範圍

AML政策的目的是通過最大程度地減少誤報和運營負荷來防止使用洗錢和資助恐怖主義的平臺。該政策適用於玩家的整個生命周期：註冊→存款→遊戲/轉移→輸出；以及附屬機構，提供商和支付合作夥伴。

2）原理（基於風險和事件設計）

1.基於風險的Approach （RBA）：檢查和閾值取決於風險概況（國家、支付方法、行為、金額）。
2.分層控制：CUS/制裁/RER，行為分析和手動調查的組合。
3.Evidence-by-Design：每個解決方案都有工件：數據源、截圖、日誌、導出報告。
4.Privacy-first： PDn最小化、掩蔽、角色訪問、受控重構策略。
5.可解釋性：可以解釋規則和模型；對於ML-fici/重要性/示例案例。
6.持續改進：設置閾值、MLRO反饋和復古案例。

3）角色和責任

MLRO （Money Laundering Reporting Officer）：AML流程的所有者，SAR/STR的最終決定，與監管機構/銀行的溝通。
AML行動：調查，與賭徒/銀行的溝通，對SLA案件的控制。
Data/BI&Risk Analytics：規則/模型支持,檢測質量監控。
Payments/Ops：遵守限額和保存/反向程序,交易跟蹤。
安全/DPO：數據保護、訪問、隱私事件。

4）玩家和細分市場風險模型

• 地理/IP駐留，文檔和KYC方法。
• 存款/收款方法，多種支付工具。
• 活動：金額，頻率，螺旋線/斜線，夜間會議，與其他帳戶的相關性。
• 設備/fingerprint，IP/設備/支付詳細信息的交叉點。

片段：低/中級/高/Prohibited。
路由引擎：Low-簡化檢查；High-EDD/保留/限制。

5）KYC，制裁和PEP

Tiered KYC：「KYC1（個性）→ KYC2（地址）→ EDD（補充文件/SoF）」。
制裁/反彈道導彈發射器：在登記、有意義的存款/結果門檻和修改細節時進行核查。
SoF/SoW：通過觸發器（高轉速，配置文件不匹配，VIP）。
重組：按照管轄權要求保存文件；通過vault/發行控制訪問。

6）交易控制（規則和信號）

• Velocity：快速存款/提款尖峰；一系列小額存款→重大收支。
• 多工具：短時間內有許多不同的卡/錢包。
• Source/Destination mismatch：從一個工具存入,從另一個工具存入。
• Circularity：充值→最低利率/洗錢獎金→退出。
• 分裂/結構：在閾值下粉碎金額。
• 附屬程序：來自運河的異常流量+濫用的類型模式。
• 設備/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。
Explainability： SHAP/feature importance,案例基準。

9） SOP（片段）

SOP： AML觸發Triage

1.檢查玩家的卡片（geo，KYC，風險刮擦，歷史）。
2.驗證數據源（付款/遊戲日誌、設備通信）。
3.決定：「clear/ request_info /hold/EDD/SAR」。
4.記錄案例系統中的活動並更新狀態。
5.與玩家的溝通（模板，響應時間）。
6.修改閾值/規則（如果有大量FPs）。

SOP： EDD/SoF查詢

1.文件查詢（提單/薪水/稅收）。
2.將總和/頻率/源映射到平臺上的行為。
3.更新風險配置文件,刪除/確認限制。
4.保存事件和解決方案（MLRO簽名）。

SOP： SAR/STR文件

1.收集事實（時間線、金額、鏈接、屏幕）。
2.檢查截止日期和管轄權/銀行格式。
3.提交SAR/STR,記錄ID/時間/鏈路。
4.更新帳戶的內部狀態和限制。
5.在監管機構/銀行關閉/指示之前進行失敗。

10）與玩家和合作夥伴的溝通

語氣：中立和事實，沒有內部規則/模型的披露。
時機：明確的ETA響應,提醒,固定在tiket。
支付合作夥伴：保存/反向同步,case-ID交換,單個AML通道。

11）集成和數據

Payments Gateway：交易狀態、方法和詳細信息、退款、充電板。
遊戲平臺：周轉/旋轉/會話/分散，異常。
設備圖：fingerprint/設備/會話通信/IP。
KYC/PEP/Sanctions：事件和時間表篩選提供商。
案例管理：狀態，SLA，解決方案日誌，SAR/STR包裝。

12）質量指標（KPI/OKR）

• TPR/Recall通過確認的案例，FPR（假標誌）↓ QoQ。
• Precision по High-risk > X%;Auto-clear Rate для Low-risk > Y%.
• 案例優先化Accuracy（前N％給出M％的發現）。

• 時間到三元組（P95），EDD Turnaround，Hold Duration（中位）。
• SAR/STR SLA（提交≤截止日期），AML措施後的退款/充電↓。
• 模型/規則漂移-在允許的走廊內。

• 因貨運/洗↓而蒙受的損失、手表/案件↓。
• 玩家體驗：對AML流程的投訴，對誠實玩家的NPS。

13） Howernance和安全

訪問策略：只有AML/MLRO可以看到敏感字段；閱讀審核。
重組：案件/文檔的保留時間；自動清洗。
日誌：所有案例操作和規則/模型編輯。
雙重控制：嚴格的規則/閾值更改需要2次確認。
CI中的測試：規則語法，閾值沖突性，回歸方案。

14）支票單

• 已驗證交易/遊戲/設備數據。
• 已比較存款/提款方法。
• 核實制裁/RER/地質。
• 選擇正確的解決方案類型（「clear/hold/EDD/SAR」）。
• 記錄了ETA和對玩家的溝通。

• 完整的時間線和金額，與其他帳戶的鏈接。
• 確認文物（屏幕/標誌/摘錄）。
• 格式和頻道符合要求。
• 內部狀態和限制已更新。
• 後續指示的監測。

• 閾值/時間窗口是合理的。
• 有FP/TP分數，業務效果。
• 設置了漂移和自動測試監視。
• 已更新三重奏劇本。
• 由MLRO/Compliance進行評論。

15）反模式

沒有RBA的「所有國家」的普遍門檻。
在沒有ETA/通信的情況下，「掛起」案例。
無可解釋的ML模型和版本日誌。
手動卸載/SAR沒有事件模板和時間控制。
缺乏溝通depozit↔vyvod，與付款的整合較弱。
沒有關於假陽性的常規復古。

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

• 批準AML策略，角色（MLRO/AML作品）和RBA矩陣。
• 運行基本的Controls-as-Code （velocity, src/dst mismatch, gaming pattern）。
• 啟用KYC tiers+制裁/RER，創建SOP模板（triage/EDD/SAR）。
• 引入事件存儲和恢復策略。

• 連接風險分散聚合器、自動案例路由和SLA報告。
• 運行閾值和優先級ML助手的冠軍/挑戰者。
• 將payments/game/device圖集成到單個玩家配置文件中。
• 訓練命令，調試通信模板，啟用規則自動測試。

• 將FPR降低≥ 20％而不損失Recall；將Time-to-Triage減少≥ 30%。
• 按時達到SLA SAR/STR=100％；關閉所有「沈積」的案例。
• 對控制的設計和效率進行內部審計；為下一季度記錄OKR。

17) FAQ

Q： 如何平衡安全和UX?

A： RBA路由：對於低風險自動清洗,對於中等要求,對於高水平的EDD/hold。透明的ETA和通信。

問：貴賓和高限額怎麼辦？
答：強制性EDD，定期修訂SoF/行為，強制鏈接輸出（源到源），附加限制。

問：何時升級到銀行/監管機構？
答：根據管轄期限確認紅旗/懷疑；在MLRO咨詢和固定事件之後。