基于隐语框架，探索区域跨行账户风险联防联控。

嘉宾：厦门掌讯信息技术有限公司CTO 王艺团

大家下午好，我是来自厦门掌讯的王艺团，很感谢隐语社区和蚂蚁同学的信任，我今天分享的主题是“基于隐语框架探索区域跨行账户风险的联防联控”，主题关键词是探索，更准确一点说，应该是摸索。我其实在隐私计算领域是一个十足新人，自去年7月隐语开源之后，我才开始了解隐私计算，刚才演讲的嘉宾，我是看着他们的视频，学习隐私计算方面的内容的。

我之前主要是在监管、公共安全领域做数据仓库以及决策支持，最近几年一直在公共安全领域做数据共享与交换，包括跨部门信息共享交换，所以对于数据流通和数据安全之间的矛盾我是深有体会。我一直在想合适的方案，我们以前也有找过区块链，也找过联邦学习，但说实话，它们都是某种特定应用方案，而不是一种通用方案，直到碰到了隐私计算，碰到了隐语。我作为一个新人，为什么今天能勇敢地站在这里跟大家分享一些我的经历呢？因为我觉得这个也是隐语社区的意义，我在社区学习和汲取知识，也在里面成长，受社区的熏陶，我觉得很有必要把我这个新人在应用过程当中所碰到的问题以及收获，甚至包括一些困惑跟大家分享。当然我也有自己的一点小私心，想跟蚂蚁的同学喊话，快快更新吧！

我们主要在两个方面展开了探索，当然主要在功能性的验证这块，至于安全和性能我们打算直接交给社区的同学帮我们搞定。

一是应用开发的探索，我们做了联合查询、安全运算、安全统计以及安全学习的例子和场景，基本上也是覆盖了在线服务和离线任务。另外一个方面，因为我们是应用，程序写出来以后要上线实施，所以相当一部分是在运维工程这块的探索，包括部署、监控以及隐语本身提供的框架服务这块，基本上验证完的结论，有诸多方面的亮点。

特别强调一点在功能上的引擎和调度分离，可能有一些同学不是很清楚，如果了解SPU比较深的同学就知道，SPU实际上是可以独立部署，也就是说上层不用这个Ray Cluster，你可以自己构建这个调度。比如今天发布的SCQL，其实本质上可以视为一个调度框架实现。

整体结论是基本上非常符合我们预期，我认为隐语是极大简化隐私计算应用开发的门槛，甚至往高一点说我认为他是推动了隐私计算技术从学研到产用的转化，这是我自己的一个结论。

我的期望是隐语社区能够AI和BI齐飞，开发和工程并重，让我们应用开发者大量的场景能够真正落地。

我今天分享内容包括四个部分，首先介绍一下账户风险联防联控业务，以及我们在这个过程里面采用的工程方法，另外接下来会针对我们六个应用场景展开比较详细的介绍，会介绍运维探索以及我们一点点小扩展。最后我会介绍一下我们目前实际应用过程当中所了解到的行业趋势和收集到的需求，以及接下来再隐语社区的进一步探索和共建计划。

区域跨行账户风险联防联控的业务背景实际上来源于账户风险的源头治理，更大的背景就是去年通过并实施的反诈法。反诈法提出了1+3的治理框架，里面特别强调要注重源头治理，坚持齐抓共管和群防群治，落到金融治理具体领域里面，源头治理就是在开户的时候，开立银行账户和支付账户的时候要对客户进行尽职调查，要能够识别最终受益所有人，防范账户被用于电信网络诈骗，而且在开立账户的时候要符合有关规定的数量限制，为了做到这些事情，还提出要建立跨机构开户数量核验机制和风险信息共享机制，大家知道这都是隐私计算特别好的应用场景。

总的来说，落到具体的风险防控责任主体，也就是包括商业银行在内的金融机构上就是两点：一是有效管控增量，谁的客户谁负责，第二是切实排查存量，谁的账户谁负责。我们基于这个背景，结合隐私计算基础，提出了这个区域账户风险的联防联控，这个为什么使用这个隐私计算技术呢？

左边这个就是目前在银行以及监管机构等进行账户风险防控或者识别的架构，大家也看到在具体某一个地方，大家要知道现在大行和小行之间能力水平是非常不平衡的，而且银行之间某种程度是竞争对手，所以存在着各个孤岛。

另外他们大量采用外部，主要通过API的方式提高行内账户风险识别的能力；另外目前虽然有存在EAST等报送系统，但监管机构更多的是监管单个银行，如果银行之间有互通的需求，目前主要通过监管机构的协调。我们结合隐私计算技术，提出了区域跨行联防联控，希望能够在监管指导下，在现有地方监管合规服务平台的基础上，把银行之间给连通起来，构建一个区域共享计算基础设施，同时结合现有的外部数据管理，能够改善和提高优化API方案，最终在区域之内形成共享核验以及进一步共享、进一步核验的循环，有效提高区域的整体治理水平。

我们结合隐语框架构建多参与方、多应用空间以及多应用三层的架构，这个架构里面核心就是SPU设备，我们在使用这个架构的时候，发现意料之外的收获。下面这个参与方很多时候在一家公司都是运营的同学负责，设备层因为涉及到网络，很多时候是运维的同学负责，最上层是开发的同学，所以这种三层分离架构有助于隐私计算项目开展过程当中可以进行一个分工以及工作开展的并行，这是一个意外之喜。

为了实现整体架构，我们采用了这么个工程方法，这个工程方法如果有做过大数据或者数据中心的同学很熟悉，基本上也是需求、设计、开发和部署运维四部曲，这个里面唯一比较大的差别是与常规MIS管理类消费类等偏流程交互类等应用系统分析设计不同，因为隐私计算毕竟是一个数据密集型的应用类型，所以在需求分析阶段特别在乎对数据的了解和把握，包括对于隐私诉求的识别。在方案设计，很关键的一点，明密文混合计算的流程设计，尤其是很多时候我们碰到项目过程当中，很多时候客户提出的数据流程不一定是合理和不一定是对的，我接下来跟大家讲为什么这个样子？

基于这个流程，我们也是结合JR0196多方安全计算金融应用技术规范，我们整理了我们需求采集项目，大概包括这些内容，我重点说一下这个里面，一是首先我们要了解有哪一些数据提供方以及这里面的数据结构。对于刚才发布的SCQL了解的同学，因为代码昨天已经开放了，这部分信息就是GRM的内容，如果我们在做需求采集的时候，把这部分工作做好，甚至这部分内容如果现有的客户那边肯定不是一穷二白，肯定有一些数据治理，尤其像数据目录这类的系统存在，其实这部分信息可能大部分都从这个里面提取出来。

接下来要把数据的流转了解清楚，我们使用刚才秉晟提到了理想世界模式，如果你在跟客户调研需求的时候，搀杂一些隐私计算和安全的东西是很难说清楚这个内容的，所以我们在做需求的时候，会假设这个里面有可信第三方，我们假设基于这个可信第三方了解说清楚这个流程应该是什么样的？中间有哪一些步骤？所以说一定要把输入输出说清楚，有时候你会发现输入输出一减，本身就泄露了一些信息或者本身就暴露了一些隐私，这个时候我们用隐私计算技术达到超越输出减去输入要求是完全不可行的，我们在实际项目或者实际探索过程当中的确经常出现这种情况。

隐私诉求这块，数据的可见性，要结合刚才上面数据结构到字段级别的数据可见性，而且可见性应该说清楚到底对谁可见？大家应该也很熟悉，这个其实就是刚才SCQL提到的CCL，字段访问控制这块的内容。

还有一点计算方，我们今天讲多方安全计算，我记得之前洪澄老师在OpenMPC有一篇文章，他说很多时候讲多方，我们其实是混合了数据方和计算方，尤其在SPU基于密文分享里面，其实密文分享里面数据方和计算方很多时候讲的很清楚，真正多方是计算方。

最后，我刚才有提到，很多时候这个流程并不一定是合理的，尤其是现在相当于一部分的隐私计算应用是存量场景升级优化，可能会涉及到原来旧的数据流的重建。

以上这个是我们采用隐私计算应用的需求采集和分析的一些步骤。

有这么一个过程下来之后，基本上隐私计算的应用类型、问题类型基本上已经确定了，接下来就开始做一个技术选型。

目前我们分成三类，分别是安全查询、包括PSI。后面看我具体应用探索就会发现，我基本上先用SPU，我对SPU比较偏爱。另外一个是数据分析，可能最好的方案就是今天开放的MPC SCQL，SPU Jax基本上满足这个要求，除了在文本类型上目前是比较难受，但是后面我也会解释为什么。

机器学习目前就是MPC FL、ML或者SL这一块，像前面PSI等组件官方的文档都还算是比较完整，而且是比较详细的。ML这块其实也有，但是我要吐个槽，如果大家去看Secretflow源码，ML目录下有一个readme文件，要求大家如果增加一个算法实现的时候，必须说清楚采用什么算法，数据的划分类型是什么？以及采用安全的技术是什么？蚂蚁同学自己写的有时候不按这个来，他里面有讲到如果这个算法，业界大家都很熟悉的，直接用这个算法名称，但是我建议都按这个改掉。为什么呢？因为从应用者的角度来说，我们一定是先弄清楚我们的数据划分类型，我们想要的安全级别，我们才去选这个算法。因为可能你们很熟悉那个算法名字，但对我们来说很陌生，这是我们提的一点小意见。

好的，到现在我基本上把我这里面采用的、探索出来的工程方法以及需求分析等跟大家介绍完。

接下来针对具体的应用场景展开一个比较详细的介绍。

首先一个场景是开户核验时的实名核验，我左边这个信息基本上按照前面的信息采集表稍微说明一下。首先输入来自于信源那边提供一个要素的名单，银行这边提供一个待核验的要素，希望输出银行能够得到一个核验的结果，通常可能表示是否一致。诉求很简单，不希望外泄核验要素，因为这些要素很多时候反馈银行这边的客户信息。这个问题大家也看出来是很简单的问题类型，就是匿踪查询，或者更准确一点是安全判定，我们直接用JNP，一行代码搞定的事情，接下来很多时候可以看到我们很多场景一行代码或者两行代码搞定，这导致我写出这个PPT的时候还跟担心，这个会不会写的太简单？导致没有什么价值，真的是一行代码能够搞定这个事情。

因为底层是基于SPU秘密分享的，性能的确就像张秉晟老师刚才提到的性能还是不太咋的，但是我们有试过，如果用这个协议基本上在十万，甚至快到百万的时候，如果你带宽足够OK完全没有什么问题的，就是通信这个复杂度的问题，真的太难解决了。

因为PSI本质只是one element keyword psi，所以我们也用隐语SPU里头包装的apsi，但很不幸，目前只要c++ api，上周星河杯技术分享会，张磊老师还加班写了examples，我们这边等不及，所以我们自己请我们的同学做了一个pybind，自己写一个PirServer，里面也把这个insertOrAssign方法开放出来，这样可以作为一个运行的时候动态增加发送方数据进去。做这些都很简单，我碰到几个问题或者挑战。

首先，我们在做实名核验的时候很多是多要素的，比如我是手机号加身份证号加姓名，这个长度是比较长的。在上周张老师的分享当中提到就是hash，把它映射到FM64域上；关于PIR还有一个很大的困惑，就是他的并发性能怎么上来？让我想起了之前洪澄在基于全同态加密的匿踪查询有提到，他说业界要多关注一下PIR应用场景，但是说实话目前实际效果来看，他的性价比不是那么OK，所以我也能够理解为什么隐语里面对PIR的API关注度不是特别够，我也能够理解。

接下来场景同样也是开户核验，但这时候是辖区内银行共同提供开户记录，其他银行开户的时候去验证当前要开户的客户是否有短期频繁开户，这个专业的说法叫做多头核验。辖区的银行大家都不能暴露自己的开户信息，开户银行自己也不想泄露核验的要素，我们一开始是把这个问题简单理解为他是一个匿踪查询加上汇总，所以我们当时做了一个方案，发起方开户行作为同态密钥持有者，中间找一个比较诚信的，比如说清算组织，由他来发起多个PIR请求，把请求的结果进行一个汇总，执行某一个规则执行结果再反馈回来，说实话在实际应用的时候要求可能会比较高，因为存在诚信代理的要求，所以我们对PIR一个疑问，我们产生了一个困惑，银行之间有时候泄露核验要素真的这么重要呢？

就是在PIR这个场景的时候，我提供的核验要素如果对方也有，这个时候其实不太存在是否泄露的问题，所以如果我们把这条隐私诉求给去掉，实际上会变成一个联合统计加运算的问题类型，这个时候我们采用明密文混合计算的方式，当然我们是在PYU里头包了个SQL，基本上可以理解为简易版的MPC SQL。

当然我们对外提供的不是SQL，只不过要我们手动的把整个逻辑拆成在本地执行的SQL，哪一些是在SPU执行的计算。

大概效果是这样的，一个频繁开户的信息反馈回来。

接下来存量账户的排查，其实很简单，就是一句话，是jnp有一个in1d，也是一行就可以搞定这个事情，如果专用协议就是Labeled PSI，在用的时候发现一个问题，因为我在用这些方法都是jax numpy里面叫做set routines下面一堆的API，这个也理解，这是集合操作。

这个时候我又联想到一个事情，其实除了PSI，还有PSM、PSU，大家可以看一下GMR21论文里面，就会把这个归为一类，所以我就在想既然jax numpy里面都提供这个方法，他这实现的时候，我们底层SPU有优化，能不能把这些API统一，以及在优化实现的时候能够把通用专用协议的优化的措施给引用进来，给集成进来，这是我自己个人的一些想法，我自己也说出来，希望蚂蚁同学考虑一下，并且同样一个问题类型有多种API提供出来，我有时候觉得也是怪怪的，对于我们应用来说，我们希望只有一套API，当然底层能自动选择最好，没有的话，开一些参数出来，我们自己来控制也是没有问题的。

接下来一个应用是比较特殊，这个应用叫做客户结构，它是基于开户数量的客户结构。怎么理解？他就是要在辖区内所有银行开户记录，union之后，基于id，统计出来一个，这个统计的维度是按客户开户银行数，他这种结果就像人口结构，按年龄的人口结构，他某种程度上可以反映我们这个区域内账户整体的风险水平。比如说我们这个区域内大家开的户头都非常多，可想而知肯定会有那么一点点情况存在。一开始这个问题我们把他归为叫做基于集合联合之上的安全计算，这个在业界也有一些专用说法，比如google的Private Join and Compute，但是这些具体的应用目前都没有看到特别好的，所以我们一开始也是直接找jnp，这个里面有一个方法我们可以直接用，叫做unique，但是很不幸，我们碰到SPU上面有一个大坑，明文索引的问题，大家可以看issue 116、117。这个方式不行。我们就想能不能用最简单、最直接的来直接循环，排序之后再循环，我们一般的编程人员出身能够想到的方法，结果又碰到一个问题，这个我最后会讲到，因为这个里面有一个要求，如果用jax循环控制流的API的时候，他要求输入输出必须是一致的，为什么要一致呢？涉及到这个jax里面控制流跟传统我们理解的循环控制流有一个很大的差异，这个里面本质是递归，而不是循环。

最后，我们迫不得已采用一个明密文混合的方式，银行本身提取id并sort，在SPU里面append+sort+diff.astype，得到一个这个sort里面分组之间的边界，因为在这个diff会做相减，如果同一个id相同相减是0，如果不是0的时候就出现分组的边界，我们拿着结果的时候再到监管PYU提取出来所有边界位置，然后再做一个bitcount，直接出统计的结果。

应用五：区域态势感知，就是风控排名及风险趋势。也是基于辖区银行开户信息，可能大家都在做账户风险的治理，但是不知道自己做的怎么样。所以想知道自己治理水平在辖区内大概是什么样的水平，但是又不想把自己的实际数据暴露出来，大家可以在这个联盟里面排一下名。这里面有一些专用协议，private set sorting或者ranking，基本上都有相应的内容，我们采用类似于刚才方法，PYU里面包一个SQL，再用SPU做安全的运算或者排序，最终达到一个效果。

应用六：疑似电诈风险联合评分，基本上发卡行、运营商等三家的联合评级，这个案例跟刚才石老师介绍的案例差不多，我们基本上也是用现成MPC学习的方式直接解决掉了这个问题。刚好当时PSI提供三方PSI，我们先用了。这里有一个问题，因为像联邦学习这种方式本质是各方之间是一个完整的训练，他把中间权重参数提交上去汇总再往下更新，但是MPC不是，用MPC方式得到的训练参数是份额存在各家这边的，所以在社区里面也有同学提到这一点，目前MPC ML等各个模型是没有提供save model方法的，是没有办法给持久化保存在本地的，这个目前应该已经排上计划的。为什么我们碰到这个问题呢？跟我们后面工程实践的时候碰到的问题有关系。

结合刚才这几个应用，我最后简单总结一下我们用隐语API的经验。

大家有看到这边最低层也是分类，但是跟官网分类不一样，我实际上是按多方，还是本地的，还是单方的，为什么？因为在我们应用的时候，我们除了关注明密文混合之外，其实我们更在乎在设计的时候弄清楚哪一件事情需要多方？哪一件是本地能够实现的，我们自己调整了一下。

下面这个我推荐给大家，如果要充分使用隐语API的话，可以进行参考。一是最好的参考方式除了官网文档，就是隐语提供的这些单测这些用例都可以看一下，基本上你想要这里面都有相应的实现。包括在隐语里面数据集，也有经典数据集的API以及包括快速构建API。

重点说一下JAX，为什么说有坑？它号称自己纯函数编程，这里面如果从大数据那边过来同学特别注意一下，这个函数编程跟我们在spark、flink上的函数编程还是不太一样的。最典型的我刚才说的控制流那些内容。为什么？因为JAX，大家知道隐语里面用JAX最终一定要经过JIT优化，这个编译有一个要求，他的输入输出等等数据形状、类型在编译时是必须确定的，因为他这样才能做足够的优化。也就是说，大家看到编译的时候必须提供example数据，才能正常的编译通过。在这点上面我们摔了无数的跟头，所以推荐大家如果要用SPU的一定把这几篇文章看一下，要保持对官网Jax Numpy Operators状态的跟踪。

这个是在应用开发这侧，我们的一些探索和总结。

接下来运维探索与扩展。为什么做运维的探索呢？因为也是隐语惹的祸，因为现在官方的所有示例里面都是集中编程和交互编程的，这对学习来说是非常有用的，但是对于我们生产怎么办？

所以我们跟社区同学沟通的时候发现绝大部分的同学会把notebook里头的代码拷贝出来写成一个脚本然后python执行，这样才能提交到后台，但这也有问题，因为我们现在文件或者脚本本身是一个Driver文件，里面包含了隐语环境的初始化，包含了SPU的构建，包括很多环境配置的信息，还有你的业务逻辑的代码以及业务代码的执行控制，你把多方信息合在一起的，难道说我们所有每一个作业都要重复做一遍这个事情呢？其实这个是不太合理的。

第二个集中编程，但是我们在多方的时候，尤其在多机构的时候，现在rayfed有一点不太好的地方，同一份代码两边都要同时执行一遍，有时候对运维的同学他脑筋会转不过来，他觉得好奇怪。还有刚才提到的我们现在的环境跟推理环境线上环境是分开的，我怎么把这个模型迁移过去。

我们的做法很简单，给它加一层，我们之前直接在Driver这边跟Ray进行交互，我们给加一层，把Driver这边做成一个long time service，我们把环境管理、设备管理，甚至算法模型管理、数据管理等等这些服务都拆出来，具体怎么拆？

如果把这些方法都拆掉，这些代码还是Driver代码，我们把他拆开，我们可以在数据方、计算方上面加一层控制层的东西，能够进行算法发布、作业的管理以及数据的读写，当然这个数据的读写是在数据提供方或者数据接收方这一侧，Driver是部署在这一侧的，这是我们做了一点扩展，基本上就是用Python的rest api一些框架把Driver包了一下，把相应方法给分拆出来。

我简单介绍一下我们隐语在运维、工程提供的API。

首先，现在隐语可以说托管在Ray上面的，所以可观测性基本上通过Ray提供出来的，包括日志、指标等等。

设备管理，目前实际上应该还没有这个管理的意识，这边我也再吐槽一下SPU，我们现在生产环境里面用现有的SPU这种模式不合适，为什么？因为我们每一个SPU都要绑定一套端口，生产环境下大家想想本来跨机构申请一个端口是不容易的，我能申请这么多端口吗？不可能，看有没有办法，或者把rayfed代理功能做的更强大一点。

数据、算法模拟等等这块有相应的API提供，作业这块比较尴尬一点，目前我们只能通过PYU或者SPU等Device提交代码之后，拿到作业的状态，但是如果要停掉作业呢？好象目前没有看到相应的API，只能把Driver关掉。我们希望后面隐语能进一步的补充好。

以上是我们在隐私计算应用开发以及工程运维这方面的探索和总结。

下一步计划和打算。目前我们了解到的，我们自己本身没有能力做这个调研，我们主要看权威机构的研发，目前最新主要金融信息化研究所的《隐私计算应用白皮书》，3月份刚出来的，艾瑞咨询也出了《中国金融科技行业洞察报告》，以及隐私计算联盟出的《隐私计算白皮书》，大抵可以看出来目前的这个趋势是什么样子呢？大部分还是处于敏捷探索的阶段，可能在营销或者风控有少量的精益实践，只能说前途光明，但是困难还是挺大的。

这里面的关注点，比如说包括互联互通、安全性前面各位老师也都有讲到，我们说一点点不太一样的，比较贴近地气的。

一是大家都看到，现在隐私计算绝大多数案例讲的都是机器学习，但是告诉大家一个事情，刚才王磊老师也有讲过，可能80%的或者接近80%的场景里面用不着，或者还到不了那个地步。我们实际上碰到的一些新技术、新场景都是冷启动的，哪来的那些负样本？根本找不到，尤其是反诈的，基本上很难拿掉。现在都是先解决数据能够流通，基于这些数据，我们先业务定一些规则去执行，能够支持业务策略快速验证和应用，我们收到绝大部分的需求是这块的需求。

另外安全性这块，我也跟客户沟通过，客户说为什么安全？他觉得这个好神奇，我们当然也可以拿现在的测评报告，但是说实话绝大部分还都是团标，可能含金量还是不太够。

另外，合规或者隐私度量，我前面讲到一个案例，我们把其中一条隐私诉求删掉了，他还是否合适呢？有的时候也是跟着需求走，但是我们还是希望有一种能够量化隐私度量的方式，能够比较可靠去评价当前到底安全达到什么样的程度？

从工程的角度，大家知道隐私计算不是孤立的全新的应用，他一定是在现有各参与方本身内部数据治理已经达到一定的水平，数据质量已经达到OK的情况下我们才会做隐私计算应用。有很多现成的，比如说刚才提到数据目录，甚至包括数据治理工具，我们现在明密文混合编程里面PYU那部分执行的事情，有时候是是现有的数据中台或者大数据平台里面有现成的组件或者现成的作业，我们可能要做的是用PYU给包装起来。

还有一个我们现在真正并不是创新场景，而是现在存量的场景。比如刚才提到的基于外部现有的API核验，他是现在就有的，只不过我们用隐私计算技术来增强和优化，这个时候我们可能会得到一个需求，隐语有说到我们用的开发方式，用的语言跟明文的是一样的，但是我们这个时候想更进一步提高要求，我们这里面有一个现成的算法和现成的模型，你能不能直接给我转化，直接迁移到上面？毕竟改造我也是一个成本。

像探索训练分离也是如此，虽然说我前面提到隐语有一个好处是一站式，但是真正实际项目在做的时候很多东西已经准备好的，他都是分离的。

结合我们了解到趋势和关注点，我们下一步的计划是进一步做应用探索，尤其是今天开放了SCQL，因为隐语里面太多东西跟Ray和Jax有关系，下一步我们也会积极探索这块的内容。

另外一方面，我们在这个行业里面刚才也讲到了，我们打算包装一个DevOps平台，在上面承载跟大家刚才分享的工程方法，能够把监控部署的工具，包括数据治理，甚至我们想把现在一些评测机构所提供的测评方法看能不能给固化到平台里面，因为平台或者产品的东西可以评测没有问题，但是项目不太好拿去评测，但是客户又想看到这个东西，怎么办？得提供一个方法让他看到这个内容。我们最终的目标希望能够回馈这个社区，希望说后面有机会能够在应用开发和运维这块为社区做出贡献，我的介绍到这里，谢谢大家！