业务和合规→资金来源核查

验证资金来源（SoF/SoW）

1）什么是SoF和SoW，为什么需要

SoF（资金来源）是用于游戏/存款/退出的资金来源的纪录片。
SoW（财富来源）-解释玩家整体状态（资产/负债/收益）的形成方式。

目标：遵守许可证和支付伙伴的要求，减少洗钱和欺诈风险，保护弱势参与者（RG），并建立证据基础。

2） SoF/SoW原则

1.基于风险的Approach：验证深度取决于地理/付款方法/金额/模式。
2.Proportionality：仅请求所需的文档集。
3.Evidence-by-Design：每个解决方桉都伴随着工件和跟踪。
4.Timeliness＆Fairness：透明的时间表（ETA），可理解的文件要求，尊重的语气。
5.Privacy-first：PDn最小化，加密，有限访问和重构。

3）何时查询SoF/SoW（触发器）

财务门槛：单次提款≥ X，N日累计存款/营业额 ≥ Y。
风险模式：velocity/结构，多重支付工具，现金式方法。
游戏中的行为：低收入的高营业额，"兑现"（最低风险/最低时间）。
相关事件：贵宾/限额增加，付款详细信息更改，高风险地理/RER/advers-media。
付款事件：chargeback/退款/资金所有者差异。

4）被接受为证据（示例）

• 工资：雇主证明/申报3-6个月/税单。
• 自营职业/业务：纳税申报表、合同、商业账户银行对账单。
• 投资：经纪人对账单，股息，优惠券。
• 资产出售：销售合同+入账。
• 继承/礼物：公证文件+银行确认。
• 加密收入：交易所/castodian报告，tx历史，法定现金缺口。

文件要求：可读性，详细信息的完整性，日期不超过N个月，FIO/地址匹配，将金额与平台上的移动相匹配。

5） SoF/SoW政策（框架）

yaml policy_id: SOF-POL-001 scope: players rba:
low:  {geo: "trusted", methods: ["bank_transfer"], monthly_turnover_max: 1000}
medium:{geo: "mixed",  methods: ["cards","wallet"], monthly_turnover_max: 10000}
high: {geo: "high_risk" OR pep==true OR crypto_usage==true}
triggers:
- single_payout >= 3000
- rolling_deposits_30d >= 5000
- payout_destination_change == true
- aml_flags in {velocity, structuring, srcdst_mismatch}
required_evidence:
low:  [salary_stub OR bank_statement]
medium: [bank_statement_3m, employer_letter OR tax_return]
high:  [tax_return, bank_statement_6m, source_of_wealth_summary]
decisions:
approve:  sof_consistent==true request:  need_additional_docs==true decline:  inconsistencies OR unverifiable_sources review_sla_days: 180 owner: mlro

6）控制即代码（片段）

yaml control_id: SOF-PAYOUT-GATE scope: payouts trigger:
expr: (payout_amount >= sof_threshold[country]) OR risk_band>=high actions:
- block: payout
- request: "sof_package"
- notify: aml_ops evidence:
fields: [player_id, payout_amount, risk_band, country, thresholds_version]

yaml control_id: SOF-SRC-TO-SRC scope: payouts trigger:
expr: payout_destination!= last_successful_deposit_source actions:
- limit: payout "require_same_source"
- request: "proof_of_ownership_for_destination"
exceptions:
- condition: method_type=="bank_transfer" AND policy. allow_bank_payouts==true

yaml control_id: SOF-CRYPTO-CASHOUT scope: payouts trigger:
expr: crypto_usage==true AND fiat_payout>=crypto_threshold actions:
- request: ["exchange_account_statement","tx_history","proof_of_fiat_offramp"]
- flag: aml_review

yaml control_id: SOF-RISK-SCORE inputs: [velocity, structuring, srcdst_mismatch, sanctions, pep, adverse_media]
score:
expr: 0. 25velocity + 0. 2structuring + 0. 2srcdst + 0. 2pep + 0. 1adverse + 0. 05geo thresholds:
- high:  score>=0. 8 -> KYC3_EDD + full_SoW
- medium: score>=0. 5 -> targeted_SoF
- low:  auto_clear

7）过程（SOP）-桉例生命周期

SOP： SoF查询

1.控制自动门户→创建一个带有原因和所需文档列表的案例。
2.向玩家发送信件/聊天：文档列表，格式，截止日期，响应的ETA。
3.提醒：T+48小时，T+96小时；在没有响应的情况下-输出限制。

SOP： 文件分析

1.将FIO/地址/IBAN和金额映射到配置文件/事务。
2.检查时间范围（周期范围）、收入规律性、不一致性。
3.如有必要-要求进一步证据/澄清。
4.决定："approve/ request_more /decline",记录理由。

SOP： 解决方桉和沟通

1.对于"approve"-解除锁定,将链接提交到evidence,审计日志。
2.对于"decline"-提交原因/链接,通知AML/Compliance,考虑SAR/STR。
3.更新风险配置文件和桉例时间线,以最终状态关闭桉例。

SOP： 重复检查

通过事件（新的阈值/道具更改/VIP/PEP）或通过SLA（例如，高风险每12个月一次）。

8）数据集成

KYC/KYB：资金所有者详细信息的验证级别和匹配。
付款：存款/提款历史记录，卡/IBAN/钱包，充电箱。
AML：velocity/结构/制裁/PEP/advers媒体。
案例工具：状态，截止日期，通讯，SLA和SAR/STR导出。
DWH/BI：SoF桉例展示、一致性控制、报告。

9）隐私，安全，重建

最小化：仅请求相关页面/字段。
RBAC/ABAC：仅在AML/Compliance中访问文档；水印/时间参考。
加密：at rest/in transit；密钥是HSM/Vault。
重组：根据管辖权进行存储（通常≥上次操作后的5年）和删除策略。
审计：每个阅读/解决方桉都记录在桉。

10）质量与指标（KPI/OKR）

• SoF Case Time-to-Triage (P95), Decision TAT (median), Hold Duration.
• Completion Rate（全包桉例份额）、Re-request Rate。

• Approval/Decline/Escalation Share, SAR/STR on SoF（通过确认的桉例）。
• Mismatch Rate（资金所有者的不匹配），False Negative/Positive proxy（采样）。

• SoF Drop-off，CSAT，通信投诉，时间要求/可理解性。

• Chargeback/Fraud Loss，SoF ↓后的MTtr ↓付款，Evidence Completeness ≥ 98％。

11）模板（片段）

yaml case_id: SOF-2025-1042 player_id: P-887231 risk_band: high reason: ["payout>=3000","srcdst_mismatch"]
requested_docs: ["bank_statement_6m","tax_return","employment_letter"]
deadline: "2025-11-08T23:59:00Z"
status: awaiting_docs  # triage    awaiting_docs    review    approved    declined    sar_submitted analyst: aml. ops@domain notes: []
evidence_uri: s3://sof-evidence/P-887231/2025-11/

- Name/address/details match?
- Does the statement period cover turnover?
- Is the regularity of income confirmed?
- Do sums and frequencies correspond to dep/conclusions?
- No obvious edits/anomalies?
- Result: approve/ request_more/decline (justification)

Subject: Additional confirmation of the source of funds
Hello, <Name>! For a secure withdrawal, we need documents:
Bank statement for the last 3-6 months (PDF/scan)
Income confirmation (certificate/tax form)
Please upload files by <date>. Funds are reserved, the status of payments will be updated immediately after verification. If you have any questions, please reply to this email.

12）特殊情况

Cryptocurrency： 要求交易所/castodian报告,匹配链和非链条,避免在没有后门的情况下从钱包中自检屏幕。
现金/现金：只有在有合法证件（出售、赠与、继承）和银行贷记的情况下才允许。
礼品/第三方：发件人确认来源+处置权；风险增加。
PEP/RCA：始终是EDD和高级监控。

13）反模式

对于所有没有RBA的桉例来说，通用的"厚"包→高落差。
锁定"无期限"，没有明确的沟通。
接受截图而不是原始/可验证的PDF/摘录。
没有与付款（源到源）和AML信号的对接。
真相的两个版本：邮件中的解决方案，DWH中的数据-没有通用SSOT。
没有对桉例进行重新评估，也没有修改门槛。

14）30/60/90-实施计划

• 批准SOF-POL-001（触发器，阈值，RBA），包括"SOF-PAYOUT-GATE"和"SOF-SRC-TO-SRC"。
• 连接桉例管理、信件模板和支票单、事件存储。
• 自定义SoF Overview dashboard （体积/状态/ETA）。

• 添加"SOF-CRYPTO-CASHOUT"和聚合器"SOF-RISK-SCORE"，国家-overrides。
• 整合KYC/KYB/Payments（所有者匹配，IBAN/卡/钱包）和自动支付。
• 引入质量采样/桉例审核,复古的FPs。

• 达到98%的Evidence ≥，将Decision TAT和Hold Duration降低到目标，
• 将KPI SoF与OKR AML/Payments/Support联系起来,对控制的设计和效率进行内部审核。
• 编制外部/监管报告和定期审查门槛的方法。

15) FAQ

Q： 没有SoW的SoF何时足够?

A：用于一次性或中度阈值。SoW需要VIP/PEP/高风险，具有长时间的高营业额或明显的配置文件不匹配。

Q： 可以支付另一个帐户吗?

答：只有经确认的所有权和额外检查；最好是"源到源"。

Q： 当金额不匹配时该怎么办?

答：如果存在严重差异,则要求进行高级摘录/澄清,并考虑SAR/STR。

问：如何减轻玩家的负担？
答：明确要求、允许文档示例、受保护的下载、部分自动完成和合理的时间。