笔者曾经写过一篇《金融机构如何选择隐私计算技术和公司》（公号：高声谈，进门左转）的文章，主要从隐私计算技术的特长出发讲不同场景下的优选问题，同时也罗列了一些隐私计算公司的判断维度和测试方法。此次，我们从更深一个层面探讨金融机构如何设计隐私计算平台和技术框架。

隐私计算的另一种分类

我们常见的分类是按照需求场景分类，可分为：单向查询类、联合统计类、风控建模类、精准营销类等；还有一些分类是按照技术路径、流派分类，如按照解决思路的不同将隐私计算分为多方安全计算（MPC）、联邦学习（FL）和可信执行环境（TEE）；也有按照最底层的密码协议分类为同态加密、秘密分享、零知识证明、混淆电路、不经意传输等。

我们从金融机构的具体需求出发，将隐私计算需求场景分为两大类：涉及数据外采类场景、不涉及数据外采类场景。

不涉及数据外采的场景是指金融机构之间具备数据和应用场景的情况，例如集团内子公司之间的联合统计、多家机构间黑名单共享反欺诈、地方政务平台和银行联合建模用于中小微企业贷款风控等。这类场景具备数据，同时需求明确，缺少的只是隐私计算技术，因此一拍即合。去年落地的隐私计算项目基本上都属于该种情况（具体名单见《金融机构如何选择隐私计算技术和公司》）。

另一类场景是涉及数据外采的场景，需要从不确定的数据源厂商引入大量外部数据，主要是 to C贷款时引入外部数据源进行反欺诈、A卡、B卡建模，或是引入外部数据源对存量客户进行精准识别与营销。在以往的明文建模时期，上述场景需要从不止一家数据源厂商中引入大量外部数据，丰富入模入参数据维度，或互补形成覆盖度更高的黑灰名单库。

《个人信息保护法》生效后，很多数据源厂商获取数据以及转售卖的合法性存疑，同时需要投入资源部署隐私计算产品，多数数据源厂商纷纷停止或暂停输出数据，导致当前市场上基本没有合规、优质的三方数据用于反欺诈、A卡、B卡和联合营销建模，现有模型效果大打折扣，金融机构痛点需求愈发阻滞。

这也是当前隐私计算行业普遍存在的问题：隐私计算厂商往往只具备隐私计算产品，但并未对接合规数据源，因此只能满足不涉及数据外采的场景需求，无法解决当前反欺诈、A卡、B卡和联合营销建模需求。而在金融机构量化分析场景中，后者需求最为迫切，数据采购金额占绝大部分。

我们了解到，很多头部隐私计算公司正在全力拓展数据源厂商，然而并不是所有数据源均能够通过隐私计算实现对外输出。对于拓展何种数据源、如何进行合规化改造，笔者在文章《金融业外采数据法律隐患与改造建议》（公号：高声谈，进门右转）中有详细阐述，在此摘录主要结论如下：

• 最好为一手数据源，看数据源厂商通过服务在获取个人信息时的告知和授权内容及范围，是否包含可以对外输出的部分；
• 结合此次数据输出服务内容和范围，是否可以包含进上述告知和授权范围之中；
• 数据需求方在进行告知和获取授权时，应明确数据来源、使用数据的内容、范围和目的；
• 更合规的方式是，数据源厂商应在需求方告知和获取授权时，在其获取的个人信息范围内，对客户进行二次告知并取得授权，并明确告知需求方（接收方）的名称、联系方式、处理目的、处理方式和信息种类。

基于上述分析，结合数据源厂商意愿，当前数据质量较好、且对隐私计算接受度较高的厂商主要有：银联、移动通讯运营商、蚂蚁腾讯等头部互联网公司。然而，由于隐私计算的商用化落地从去年才刚刚开始，基于实际需求、实际应用的隐私计算项目尚未大规模开展。

隐私计算是应用级的解决方案，不宜纳入公司基础技术框架

2021年被称为隐私计算元年，出现了大量的实验试点项目，其中以金融行业头部机构为主（不完全统计全年落地项目二十余个）。但是从实际结果看，隐私计算解决方案距离大规模商用化尚有诸多问题需要解决：

• 解决问题个性化强，实施过程缺少标准，操作可信度、真实效用待验证；
• 隐私保护程度以及产品安全性有待进一步验证，需要更具权威性的认证；
• 普遍存在计算开销大、性能损耗大、建模效果有损失、对恶意攻击防范性不强等问题；
• 产品之间兼容性、通用性不强，使用不同隐私计算产品会形成新的“数据鸿沟”。

由于当前的隐私计算技术尚未成熟，大规模商用化还未到来，因此不宜将隐私计算作为公司或技术平台的底层技术，而纳入基础技术框架。当前的隐私计算产品只是解决数据交互过程中的去标识化问题，一定程度上解决个人隐私保护，做不到完全的匿名化，无法帮助企业规避信息处理诸多义务以及必要的客户告知，应定位于一种轻量级、应用型解决方案，用于数据交互时点对点的信息加密和防泄露保护。

鉴于上述情况，建议金融机构在采购隐私计算产品时，秉持“一切以需求驱动和实用性为主”和“解决实际问题”的务实思路，对各家公司产品进行对比分析。这一趋势在今年的落地案例中体现愈发明显：如招商银行“慧点隐私计算平台”项目，最终由上海富数、洞见智慧、同盾科技和平安科技4家隐私计算公司联合中标，分别从产品兼容性、稀有数据源、建模经验和性能保证等方面，确保了项目的高度实用性。

随着越来越多的金融机构和数据源厂商落地不同的隐私计算产品，产品兼容性不足会导致数据需求方和供给方必须采用同一隐私计算产品，现实操作中往往弱势一方妥协，这就为之前的隐私计算招投标采购埋下“隐患”，进而再次重复建设。同时，由于隐私计算产品标准化不足、对比评价缺少依据，招投标采购很难准确地选中合适的产品，去年金融行业的很多隐私计算项目进行到一半无疾而终便很好地说明了这一问题。

因此，金融机构应高度重视兼容性和通用性问题，同时鉴于隐私计算产品之间加密协议的打通需要一事一议并产生额外成本，因此，笔者一直以来主张采取“一体化硬件底座”来解决产品兼容性问题。这里的“一体化硬件底座”能够兼容当前市面所有隐私计算软、硬件产品，当遇到隐私计算产品冲突时，便采取“按照数据逐笔收费”的方式实现隐私计算产品的轻量级替换，减轻采购时因决策失误造成的潜在隐患和重复建设成本。

对风控流程的改变和技术框架设计

现实中由于因数据性状和业务流程等因素的不同，不同机构的建模流程不尽相同。笔者仅以自身实操案例讲解隐私计算产品对建模和技术框架流程造成的重构。

笔者所在金融机构在明文状态下的建模和技术框架流程如下：先搭建了“统一数据对接平台”实现外部数据的统一采集，“统一数据对接平台”可植入路由策略，以实现诸如黑名单数据源轮询方式实现外部黑名单并集等操作；“统一数据对接平台”与企业自身数据中台共同接入“决策引擎”，实现多维数据同时入模入参，并形成策略后输出。

决策引擎中的模型和策略是通过事前、离线地反复训练得来，主要是将企业自身数据中台中的客户样本、特征值和坏样本，与外部样本撞库后，通过反复建模调优得来。模型和策略一经验证定性便植入“决策引擎”中用于生产执行。当然，具体实施时还要遵循“AB-test”方法逐步上线。

使用隐私计算产品后，由于金融机构的离线建模和训练策略的过程，与生产环境下实时跑批生成决策的过程，完全一致且全部置于隐私计算产品环境之中，同时，金融机构无法掌握模型全貌而将完整模型部署在“决策引擎”之中，因此会导致建模技术实现流程的较大改变。

此时的建模技术流程为：将企业自身数据中台和隐私计算产品平台对接，以实现进件数据和外部数据实时、线上入模入参并形成策略，策略仅通过“决策引擎”的组合、并行、串行、分流等策略调度模块实现落地。注意，此时的“决策引擎”失去了部署模型和跑批结果的功能，仅保留策略调度功能；“统一数据对接平台”失去作用，被隐私计算产品替代（若涉及隐私计算下的多方数据建模，则可能还会发挥作用，但目前多数隐私产品不支持多方建模）。

合规数据源的减少、建模技术流程的调整、暂不支持多方联合建模均是企业面临的调整成本，是为更加符合个人信息保密所必须付出的成本。既然付出了高昂成本，请务必高度重视品的测试工作，以“实事求是”的思路推动产品的优化与成长，在帮助企业“解决实际问题”的同时，推动隐私计算行业快速、健康发展。

———————————————————

笔者个人公众号：高声谈，Inter-FinanceCow

邮箱：gaoshengtan2021@yeah.net

欢迎读者多交流！