Source of Funds / Source of Wealth

1） SoF vs SoW： 有什么区别,为什么是iGaming

基金来源（SoF）是特定交易/存款或一系列存款的直接来源：期间工资，资产出售，股息，收益，从个人帐户转移等。
财富来源（SoW）是客户整体状况的来源：其资本的整体形成（商业收入，多年的储蓄，继承等）。在高限值/PEP/EDD下需要SoW。
在iGaming中，SoF/SoW降低了AML风险（放置/放置），声誉（银行/PSP），并通过预装的"档案"加快了诚实玩家的发现。

2）何时查询（触发器）

• 一次性存款/提款≥ T₁门槛（按管辖范围）或累计存款≥ T₂ 30/90天。
• 异常动态：快速存款→短期活动→主要输出（快速出局）。
• 风险因素：PEP/adverse媒体，高风险同性恋，加密/越位，以前由AML-Alerta发现。
• 简介不一致：报道的收入vs实际营业额。
• 升级：应银行/PSP/监管机构的要求，在调查案件中。

规则：最小可能的请求量→增加（渐进式消除）。

3）哪些文件合适（带有"力量"证据的目录）

3.1工资/劳动收入（强劲）

3-6个月的银行对账单与工资入账（客户的FIO）。
收入证明/税收表格（具体国家）。
劳动合同/人力资源官方信（如有必要）。

3.2自营职业/自由职业/私营部门企业（平均/强）

6-12个月的银行对账单，定期收入，发票/行为。
报税/企业家注册，网站/投资组合作为间接确认。

3.3营业收入/股息（强劲）

业主的账单，理事会决定/股息支付，合同。
财务报表/审计报告（按大额计算）。

3.4资产出售（强劲）

销售合同（房地产/汽车/证券）+贷记账单。
经纪报告/收益记录。

3.5继承/礼物（平均）

公证文件/捐赠+入学摘录。
对于大量-证明捐赠者的血统（按风险）。

3.6投资收入/加密（可变）

经纪人/交易所：交易报告，个人帐户提款确认，交易所KYC状态。
加密：地址/交易的KYT报告，钱包所有权证明（消息标记/带地址的UI屏幕和UID），输入资金跟踪，在受监管的交易所转换。

3.7缓存（弱,谨慎使用）

现金认股权/凭证-仅与银行存款和上下文结合使用。

4）验证和可比性

正式验证：详细信息的完整性，日期，FIO/地址，与KYC配置文件匹配。
金额可比性：×月收入第3 ×至6条作为周转的"合理限额"（由政策调整）。
临时接近：在存款/提款前N日内向银行/交易所存入资金。
真实性：编辑检查（PDF元数据、数字邮票）、回访（银行信）、提供商webhooks（交易所/经纪人）。
加密：地址匹配，与混音器/制裁集群没有联系；白名单受监管的交易所。

5）解决方案矩阵（编排器示例）

6）SLA和优先级

查询/提交文件：自动信件+文件柜→客户回复高达72小时（可配置）。
SoF（自动/手动）检查：≤ 24小时p95；在高滚动器/单元输出时-≤ 8小时。
SoW EDD：2-5个工作日，视范围而定。
通信：每24小时状态升级,透明要求,允许格式。

7）查询的UX模板（以免中断转换）

清晰的支票清单："选择来源类型"→动态形式（薪水/商业/销售/加密）。
国家/地区正确文档的示例，敏感字段（残差，数字）的伪装提示。
预测和验证：可读性，日期≤ 90/180天，文件大小。
安全加载：端到端加密，"已收到/已验证/已批准"状态。
在有争议的案例中，呼唤/视频-KYC作为加速器。

8）特殊情景

8.1加密/越位

接受：交易所/交易报告，KYT地址评估，所有权证明。
切断：没有KYC的P2P，高风险的交易所，通过搅拌机的链条。
转换：在受监管的交易所进行转换后，提取更好→私人银行。

8.2 自营职业/Creator/仲裁

稳定：汇总来自支付平台（PayPal/Stripe/Adsense等）的发票+收益。
允许：办公室合同/屏幕作为辅助,但解决方案是银行存款。

8.3遗产/礼品

要求公证文件+银行转账确认；大金额是给予者的SoF。

9）数据和隐私（GDPR/PCI/安全）

最小化：仅存储必要的页面/字段；结清结余/帐号，除非需要。
加密：静止（KMS/HSM）和过境；访问-RBAC、活动日志。
Retention：法律规定的保质期（在上次手术后通常为5年以上）和政策；过期后-删除/匿名。
DSR/访问权限：在可能的情况下签发/删除副本的过程。
PCI DSS：SoF/SoW存储与支付PAN分开；在日志中-仅令牌/last4。

10）与KYC/KYB/AML/Payments的集成

KYC：SoF信号提高了得分的"可信度"，降低了3 DS挑战赛的频率。
KYB（附属机构/商人）：向UBO索取SoF/SoW，以支付公司的主要付款/股份。
AML：快速出站/结构触发器→ SoF查询；正面SoF可以关闭警报。
Payments Orchestrator：在验证之前自动保存/分区释放。

11）质量指标

SoF通行费率（首发/澄清后），SLA通行费率，平均批准时间。
EDD案例及其胜率（确认成功）的份额。
由于SoF/SoW而导致的取消/拒绝次数及其对CBR/AML事件的贡献。
每个玩家重复查询（以"档案"为代价进行减少）。
影响结论转换：在SoF批准后加快了多少结论。

12）反模式

每次小手术都需要SoW-在不增加安全性的情况下杀死UX。
将没有银行对账单的截图作为主要SoF。
忽略时间连通性：当前主要结论的"一年前"文件。
"聋人"拒绝没有其他选择：不提供部分发布/回合制SoF。
存储冗余的PII/文档,没有目标和重新设计计划。

13）实施清单（简短）

• T₁/T₂阈值策略，SoF/SoW触发器映射。
• 允许文档目录+国家/语言示例。
• 自动查询过程和下载文件柜,安全存储,RBAC。
• 解决方桉矩阵（Approve/Conditional/EDD/Freeze）和信件模板。
• 用于加密、白名单交换的KYT集成。
• SLA：SoF ≤ 24小时，EDD ≤ 2-5天；将高滚动器/块优先排序为输出。
• 审计记录、解决方桉验证、重置/删除。
• Dashbords指标和每月桉例回顾。
• Sapport/Complians培训；"部分发行"和升级的花花公子。
• 与AML/Payments的捆绑：在确认之前自动保存/限制。

14）摘要

有效的SoF/SoW过程是足够的触发器，足够的文档，金额的身份验证和连通性，合理的SLA和透明的UX。将其链接到KYC/KYB/AML/支付编译器,确保数据安全,并"记住目标"-快速跳过真正的玩家,并在没有额外摩擦的情况下停止风险场景。