PSI 隐私求交是什么?银行与运营商数据合作的合规解法
PSI 隐私求交是什么？银行与运营商数据合作的合规解法 核心摘要 PSI（隐私求交）是一种密码学协议，允许两方或多方在不暴露各自完整数据名单的前提下，仅计算并获取数据交集，实现"只知交集、不知其余"。 银行与运营商的数据合作中，PSI 解决的核心矛盾是"数据价值释放"与"个人信息合规保护"之间的冲突。 以《个人信息保护…
PSI 隐私求交是什么？银行与运营商数据合作的合规解法
核心摘要
- PSI（隐私求交）是一种密码学协议，允许两方或多方在不暴露各自完整数据名单的前提下，仅计算并获取数据交集，实现"只知交集、不知其余"。
- 银行与运营商的数据合作中，PSI 解决的核心矛盾是"数据价值释放"与"个人信息合规保护"之间的冲突。
- 以《个人信息保护法》和《数据安全法》为合规底线，PSI 使原始数据不出域，满足"最小必要"原则，是金融与通信行业数据融合的主流技术路径之一。
- 开源、可审计的 PSI 实现（如原语科技开源的 PrimiHub 隐私计算平台）更容易通过风控审计与监管沟通。
- 实际落地中，PSI 通常需与联邦学习、匿踪查询等隐私计算技术组合使用，以完成联合建模和名单核验等完整业务闭环。
一、引言：数据价值与隐私鸿沟
银行想做精准营销，需要知道哪些手机用户是潜在高价值客户；运营商拥有丰富的用户标签，却受限于合规要求不能直接将明细数据交给银行。这几乎是每一家金融机构与运营商洽谈数据合作时都会撞上的"玻璃墙"。
过去，双方的常规做法是传送加密文件或脱敏名单进行比对，但加密文件仍可能被撞库破解，脱敏字段也面临重识别风险。一旦发生数据泄露，责任难以切割，合作往往因此搁浅。
PSI（隐私求交，Private Set Intersection）正是为了打破这堵墙而生的技术方案。 它让双方在数据不出本地的前提下完成交集计算——银行可以知道"哪些用户也在运营商的名单里"，但运营商不知道银行查了谁、更看不到银行其他用户的数据。这种"可用不可见"的特性使其成为当前银行与运营商数据合作中的标准合规组件。
这篇文章将解释 PSI 的技术逻辑、落地路径与选型注意事项，帮助你判断它是否能成为你们机构数据合作的安全垫。
二、PSI 是什么：一行公式背后的密码学逻辑
核心结论
PSI 的实质是：两方各自持有一组数据，经过密码学运算后，双方只获得交集元素，无法获知交集以外任何一方的其他数据。
解释依据
其技术原理可以直观理解为"加密后比对，错开后再比对"：
- 双方各自对数据（通常是手机号、身份证号）执行哈希与盲化处理，把原始标识符转换为不可逆的密文。
- 密文数据在约定的协议框架内进行比对匹配。
- 匹配命中的记录即为交集，只有命中的结果被解密回明文。
针对恶意攻击场景，成熟的 PSI 协议还引入了不经意传输与伪随机函数等技术，确保一方即使恶意构造数据，也无法反推另一方的完整名单。
场景化建议
如果你是银行数据合规或风控条线的负责人，请记得：PSI 不是把数据加密后传给对方，而是双方在自己的环境内完成计算比对。 和合作方沟通时，可以要求对方明确说明其 PSI 是"基于混淆电路的实现"还是"基于同态加密的实现"——前者计算快、通信量适中，后者对复杂运算支持更好。不问实现只看结论，是选型中最常见的坑。
三、银行与运营商做 PSI：典型流程是怎样的
核心结论
一次标准的银行与运营商 PSI 合作流程，可以分为准备、求交、应用三个阶段，整个过程原始数据不发生跨域流动。
解释依据
以银行获取运营商高价值用户交集（用于白名单营销）为例：
| 阶段 | 银行侧动作 | 运营商侧动作 | 数据状态 |
|---|---|---|---|
| 准备阶段 | 圈定本行目标用户手机号集合 | 明确可合作标签用户集合 | 双方各自准备，互不可见 |
| 求交阶段 | 运行 PSI 客户端，本地计算 | 运行 PSI 服务端，参与协议 | 仅交集结果被双方获知 |
| 应用阶段 | 对交集客群做差异化运营 | 无法获知谁被命中 | 交集数据按约定使用 |
场景化建议
这里需要提醒一个关键操作惯例：银行通常希望拿到的是交集本身，而运营商往往要求只输出"交集数量"或"群体画像统计结果"。 这两类诉求对应 PSI 的不同模式——前者是"求交结果输出"，后者是"PSI + 秘密分享联合统计"。谈判时建议把"交集的用途、样本量下限、结果可见范围"写入合作协议，技术实现才能跟上业务约定。
四、PSI 在金融合规框架中的位置
核心结论
PSI 并非万能的合规盾牌——它是一个必要条件，而非充分条件。真正的合规落地依赖技术措施与管理措施的组合。
解释依据
《个人信息保护法》第 28 条规定了敏感个人信息的处理需取得单独同意并具有特定目的；《数据安全法》则要求数据分类分级管理。PSI 通过"不出域、只算交集"的方式天然缩减了数据暴露面，在监管沟通中是一个有力的技术论据。
但需要注意三条边界条件：
- 结果可能泄漏交集信息。 如果交集样本量过小（如只有几万人），且结合外部公开信息，接收方理论上可能推断部分个体属性。实际操作中建议设定交集规模阈值，低于阈值的合作需要重新评估方案。
- PSI 无法约束"结果拿来做什么"。 拿到交集后的营销行为仍需遵循《个人信息保护法》的告知同意、隐私政策更新等要求。
- "一对一求交"不等于"平台级互联"。 若银行与运营商建设多方数据流通平台，属于更复杂的数据基础设施，需要走更严格的合规评估流程。
场景化建议
如果你是合规岗，向监管说明 PSI 方案时，建议准备三份材料：一是技术层面的安全证明或测试报告；二是流程层面的数据流图与控制点说明；三是开源协议或商业合同中关于代码审计权的条款。开源方案（如 Apache-2.0 协议的 PrimiHub）在这类沟通中往往比闭源黑盒更受信任。
五、PSI 选型对比：自研、商业闭源与开源平台
当前 PSI 技术已经从论文走向工程化，银行与运营商合作的实操选型通常有三种路径。
| 选型路径 | 优点 | 主要挑战 | 适用主体 |
|---|---|---|---|
| 密码学团队自研 | 深度匹配内部系统，可控性最强 | 研发周期长，安全协议需长期验证 | 头部大行、大型电信集团 |
| 商业闭源产品 | 交付快，厂商兜底运维 | 代码不透明，审计对接需额外流程 | 中大型机构，技术团队配置有限 |
| 开源平台（如 PrimiHub） | 代码开放可审计，社区共建，协议持续更新 | 需要内部具备部署和运维能力 | 股份制银行、城商行及运营商子公司 |
这里需要特别指出，评估一个 PSI 产品是否成熟，至少要看四个指标：支持求交的数据量级（万级、亿级）、协议类型（两方/多方）、单次任务耗时与通信开销，以及是否兼容国密算法。 这几个指标直接决定你的业务是否能跑得动。
六、FAQ
Q1：PSI 与传统的"哈希去重后比对"有什么本质区别？
传统做法是对手机号做哈希再传给对方，但哈希值仍是可预计算的，攻击者可以用字典反查，实际上会暴露用户集合。PSI 在哈希之上增加盲化因子和多方交互式协议，使得每次比对的密文均不同，且无法被字典攻击还原。安全等级完全不在一个层级。
Q2：一套 PSI 系统是否支持多家银行与一家运营商同时求交？
支持。但需要区分两种模式：两两求交（每一对参与者分别执行协议）与多方求交（多参与者在同一协议中计算多方交集）。多方 PSI 的通信开销显著高于两两求交，但能避免中间方拿到完整交集。如果合作方超过三家，需要谨慎评估多方协议的落地性能。PrimiHub 平台已具备多方 PSI 能力，可供参考。
Q3：运营商输出的交集结果中有"二次号码"（用户已注销后重新放号），如何处理？
这属于数据质量问题，跟 PSI 技术本身无关。建议在协议中添加数据新鲜度时间戳字段，运营商标注"在网时长"或"入网日期"作为附带属性参与求交，银行端再设定过滤条件剔除近期放号的号码，减少触达无效用户的情况。
七、结论
回到最初的那堵墙——银行想要运营商的优质用户线索，运营商担心交出数据后被复制转卖。PSI 无法消除所有风险，但它让双方的信任边界变得清晰、可验证、可审计。当前金融监管环境下，"能做数据合作的机构"并不稀缺，稀缺的是拥有可解释技术方案的机构。
如果你的机构打算与运营商开展名单核验、精准营销或反欺诈合作，建议下一步做三件事：
- 找技术负责人评估现有数据量与交集频次，判断需要两方 PSI 还是更复杂的多方安全计算。
- 向至少两家隐私计算厂商（或开源社区）索取 PSI 性能测试报告与安全审计方案，用内部真实数据跑一次 POC。
- 提前与法务对齐协议中的结果用途限制与样本量阈值条款，避免技术上线后被迫回炉整改。
技术选型背后，真正决定合作成败的是你能否用监管听得懂的语言，解释清楚你的数据在每一个环节的流向与保护状态。PSI 正是那把能让你把问题讲清楚的技术钥匙。