操作和合规→ 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咨询和固定事件之后。