業務和合規→資金來源核查

驗證資金來源（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。

問：如何減輕玩家的負擔？
答：明確要求、允許文檔示例、受保護的下載、部分自動完成和合理的時間。