7.3 金融联合风控：反欺诈与反洗钱
7.3 金融联合风控：反欺诈与反洗钱
本节摘要：金融是 MPC 最成熟的付费场景：机构间既要联合识别风险、又被合规红线禁止交换客户明细。本节拆解联合反欺诈与反洗钱两个方案的骨架，给出"谁最终拿到什么"的完整清单与选型演算。
定位：本节解决什么
风控的本质是信息拼图：单一机构只看到自己的那块拼图，跨机构的资金流、名单、行为特征拼起来才能显出风险全貌。但金融机构恰好是合规最严的群体——客户信息出域的行政处罚远比错过一笔坏账严重。这个"既要用数据、又绝不能交换数据"的死结，正是 MPC 的定义性场景。本节把两个标杆应用拆到方案骨架层：一个偏布尔（规则比对，混淆电路友好），一个偏算术（评分聚合，SPDZ 友好）。
核心概念：两个标杆方案的骨架
联合反欺诈（布尔骨架）。 场景：多家机构各有高风险名单（欺诈账户、设备指纹、可疑收款方），想实时判断"本次交易对手是否出现在任一家的名单里"，名单本身绝不交换。方案骨架分三段：先做隐私求交确认重合身份（7.2 节技术），再用混淆电路跑阈值与规则比对（命中几家、风险等级判档），最后只输出"放行、拒绝、人工复核"的动作指令。计算量小、逻辑分支多、决策要快——布尔电路路线的各项特征全中。实时性要求高的场景把名单求交结果做成带 TTL 的缓存，交易时只跑轻量比较电路，毫秒级可达成。联合反洗钱（算术骨架）。 场景：跨行资金链路识别需要聚合各家观测到的交易特征（频次、金额分布、对手分散度），联合算一个风险评分。特征以定点数进 SPDZ 式加法分享，评分模型是线性组合加阈值——加法零通信、少量乘法、输出前 MAC 校验（恶意安全，金融机构的标配要求），单次评分在广域网的百毫秒到秒级。
图：金融风控两类任务的方案骨架
动手演练：联合评分的最小链路
K = 1 << 64 SCALE = 1 << 16 def share(x, P=1 << 64): from secrets import randbelow s = randbelow(P) return s, (x - s) % P # 两家银行各自的特征分（定点化 权重保密） f1, f2 = int(0.72 * SCALE), int(0.58 * SCALE) w = int(0.6 * SCALE) # 联合约定的权重（公开常数可数乘免费） s1 = share(f1); s2 = share(f2) # 各方本地数乘后求和：零通信完成线性评分 p1 = (w * s1[0] + w * s2[0]) % K p2 = (w * s1[1] + w * s2[1]) % K score = (p1 + p2) % K print(score / (SCALE * SCALE)) # 约 0.78 联合评分
会话输出联合评分约 0.78，两家特征全程未离开本地。真实系统在此之上叠加 MAC 校验、阈值比较（换布尔电路跑档位）与审计留痕。
工程实践要点
金融场景的三条实战经验。恶意安全是默认档：参与方是竞争关系，5.2 节的结论在这里兑现——SPDZ 系在线翻倍的开销完全可接受，而一旦查出作弊，检出记录就是处置依据。时效与缓存的艺术：名单求交结果有业务时效（欺诈团伙会换号），缓存周期要和对手的轮换速度赛跑；求交频率升高的成本要算进方案。对监管的翻译工作：向监管解释 MPC 方案时，最有说服力的不是协议名词，而是 7.1 节那张"谁拿到什么"的清单——写清楚、附上检出与日志机制，过审效率天差地别。
⚠️ 常见坑：把联合风控做成"求完交就完事"。没有后续评分、预警与处置动作闭环的求交，业务价值趋近于零；方案设计要从最终动作倒推每一步的技术选型。
本节要点：名单比对走布尔骨架、评分聚合走算术骨架；"谁拿到什么"清单是金融场景的通用评审语言；恶意安全在该行业是默认而非选配。下一节看数据敏感度更高的医疗与政务。
方案落地的组织准备
金融 MPC 项目的技术方案往往三个月能定，组织协调能拖一年。四项组织准备工作值得提前启动。牵头方与治理规则：多方项目必须有明确的牵头机构与治理章程——参数变更谁批准、作弊检出后怎么处置、成本怎么分摊，这些规则写进合作协议比写进代码更重要。合规预沟通：在方案定型前与监管条线做非正式沟通，把"谁拿到什么"清单提前过目——方向性认可拿到后再投入开发，返工风险大幅下降。应急预案：一方机构退出合作时数据与份额的处理流程、协议材料的销毁确认，都是要在协议层之外的书面文件里定死的。内部能力建设：至少两名工程师完整读过协议文档并能在目标框架上独立排障——纯外包的 MPC 项目在事故时刻的响应速度是灾难级的。
这四项没有一项涉及密码学，却决定项目的最终成败。MPC 改变的是机构间的信任技术，而项目成败取决于机构间的信任组织——这句绕口的话，做过跨机构项目的人都会懂。
从监管视角反推方案设计
金融 MPC 方案有个独特的优化方向：按监管的检查习惯反推设计。监管现场检查的三个高频动作，逐一预置应对。动作一：要数据流图。 检查人员会追着"这条字段从哪来到哪去"，方案文档里要备好逐字段的数据流图，密域段落用统一图例标注——事后补画的图在检查里可信度打折。动作二：抽日志对结果。 随机抽一次联合计算，核对协议日志（参与方身份、参数、时间线）与业务结果的一致性——这就是 5.2 节"检出记录即证据"的用武之地，日志的字段设计要按可抽查标准来。动作三：问异常场景。 "参与方破产了数据怎么办""对方内部人员作案怎么办"——每个异常场景对应预案文件，答案的完整度决定检查结论的成色。
三个动作背后是同一个换位思考：监管要的不是"你用了多先进的技术"，而是"出事时我能不能追责到人"。可追溯性设计因此在金融场景的权重高于性能与成本——这个排序与互联网场景恰好相反，跨行业搬方案时最容易翻车的地方就在这类排序差异上。
一个反欺诈方案的演进时间线
用一个典型的演进时间线收束金融场景的落地节奏。第一阶段（一至两月）：纯 PSI——两家机构先做黑名单重合度分析，技术闭环短、合规易过，快速拿到第一个业务结论。第二阶段（三至六月）：求交加阈值——在重合名单上叠加命中次数的布尔判断，混淆电路登场，产出"重点关注清单"。第三阶段（六至十二月）：联合评分——特征进 SPDZ 算术协议，输出风险分档，恶意安全全开。第四阶段（一年后）：常态化运营——增量求交、库存化预处理、检出记录接入审计，系统从项目变成设施。
时间线的价值在于节奏感：每一步都在上一步的安全与业务结论之上加码，没有一步跳跃。急着上第三步的项目（跳过 PSI 直接联合建模）大多卡在数据对齐与合规问答上，反而更慢——这个领域的落地节奏，慢即是快。