区块链在金融风险数据共享中的应用实践（上篇）

业务场景介绍

很多金融机构在开展 C 端业务的时候，时常需要甄别来自于 C 端用户的交易风险，身份伪造，营销欺诈等等。 简单举例：营销或者支付业务中，甄别某位个人用户是否有过欺诈行为就属于这一类风控识别措施。这些金融机构随着业务的开展，往往已经收集并沉淀积累了很多黑名单，黄名单，灰名单等。简单来说，金融机构通过使用这些名单数据，做一些用户过滤处理就能达到一定的业务风险控制的目标。

业务开展过程中，金融机构或许要面临一个显而易见的问题：已有的黑名单数据并不足以控制业务风险，时常需要借助其他机构的名单数据进行补充，才能达到一定的业务风控效果。而基于 C 端用户的风控数据，基本上都属于金融机构的核心数据，并不能无偿共享。这就衍生出了一个关于 C 端用户风控数据的买卖市场。传统的风控数据查询方式，往往通过卖方机构提供一个收费的数据查询接口的形式来实现。买方机构通过预付费或者后付费的方式向卖方机构支付数据查询的相关费用。而关于费用的计价维度多种多样，但相同之处是所有数据计价完全由数据卖方主导设定。

业务痛点如下：

• 基本上属于完全的卖方市场，数据的定价权和计价账单都由卖方来制定，对买方机构而言，并不足够公平。解决方案➔分布式账本

• 买方机构开展业务时一般需要对接多家卖方机构，每次接入都需要重新按照卖方的数据接口来开发对接，接入成本较高。解决方案➔联盟共识

• 买方机构查询获取的数据，可能会出现二次售卖的情况。解决方案➔隐私保护

• 缺乏公开公平公正的账户体系为数据的质量负责。解决方案➔智能合约

业务痛点主要来源于两个原因：

一、缺乏联盟性质的中介服务。

二、金融机构之间缺乏相互信任。

数据共享联盟目前已经有很多实践，但是大部分效果不佳，原因还是金融机构之间缺乏信任和共识。如果采用技术的手段，建立数据共享细分领域的行业共识，将能够极大地促进行业的发展，提高整体行业的业务风控水平。

区块链技术中的联盟链恰好适用于当前这样的业务场景，能够在联盟参与方之间通过技术的手段达成业务共识。换言之，各家金融机构加入联盟之后，并不需要信任联盟组织方，也不需要信任其他联盟参与方，只需要信任来自于底层的区块链技术以及技术之上的行业约定即可。联盟链的几个重要组成部分：分布式账本，共识机制，智能合约和隐私保护，可以为联盟业务开展提供坚实的技术基础。

基于区块链的设计方案-1.0 版本

区块链中的分布式共识，是来源于整体技术架构的，而宝贵的业务共识一旦达成，需要量化和固化下来，才能清晰地表征业务状态以及促进业务发展。通证的设定可以有效的量化共识，而分布式账户体系可以达到固化共识的目标。通证，即区块链中通用的凭证，需要一个具体的单位来描述，这里暂且使用“积分”作为这个通证单位。

1.0 版设计方案的主体思路：将数据分类后制定价格并与“积分”关联，建立基于合约的账户体系，所有数据的买卖都由共识下通证“积分”流转来实现。

• 数据上传阶段：各家参与机构把希望共享的数据上传，在各个共识节点的监督下，根据上传数据量发放通证“积分”，并记录在分布式账本中。

• 数据下载阶段：各家参与机构使用自己的通证“积分”余额，在各个共识节点的审查下，查询目标数据，并支付扣减通证“积分”。

经过一段时间的试验与论证，逐渐发现 1.0 版设计方案中存在一些问题：

1. 数据安全方面：共享数据仍然物理上存储于各个参与机构的共识节点上，尽管可能采用了加密存储的方式，仍然会导致参与机构的数据报送意愿不足。

2. 数据质量方面：在报送数据没有经过业务实时验证的前提下，对应的通证积分已经记入参与方的账户余额，报送数据质量没有得到有效保证。

3. 交易效率方面：所有参与机构的报送数据统一集中管理后，在联盟共识的基础下完成数据查询，交易效率偏低。

4. 通证流转方面：目前国家的政策法规还不允许，基于区块链发行的通证，在二级市场进行买卖。导致某些参与机构可能只是数据卖方，积累了大量通证积分而无法变现；某些参与机构可能只是数据买方，账户余额中没有通证积分，无法进行数据查询。

基于区块链的设计方案-2.0 版本

首先分析 1.0 版设计方案的组成要素，可以逐渐明确 2.0 版设计方案的改进措施：

✔ 联盟链去中心化的设计方案，使得参与机构信任主体变成底层技术。

✔ 基于联盟链形成分布式账户体系，并使用积分作为通证单位来计量数据。

✖ 数据采用报送的方式收集，换取通证积分，花销通证积分查询数据。

可见，1.0 版设计方案最主要的问题来源在于“使用报送的方式收集数据”。各家参与机构的核心数据不会以报送的方式被获取，即使能够换取联盟的通证积分，也很难促进联盟参与机构的数据报送意愿。因此，2.0 版设计方案最大的改进之处在于，各家参与机构不再需要将核心数据进行报送，风控原始数据并不会汇集到区块链的节点上。换言之，各家参与机构依然可以按照原有的方式保护自己的核心数据，参与到联盟中的金融机构也间接地形成了一个核心数据的分布式存储架构。基于如上的分析，联盟链需要解决的核心问题有两个：

• 建立基于分布式存储数据的互查机制，或者说，在黑名单数据互查这个业务场景下，实现安全多方计算（SMC）。

• 借助区块链分布式共识的特性，建立公开公平公正的数据计价体系。

2.0 版设计方案的总体设计思路：联盟参与机构的核心数据并不需要报送，通过添加一层“服务系统”来协助智能合约完成安全多方计算，合约中添加账户体系来为每次数据查询进行计价服务。在数据查询与计价服务实现的基础上，同时考虑数据安全，数据质量，交易效率与通证记账完备性问题等等。

在整体架构设计中，首先需要简单介绍一下数据查询的应用示例。例如，金融机构 A 查询金融机构 B 提供的风控数据，通过如下的流程来完成：

1. A 业务系统向 A 服务系统发起查询请求，该请求接口兼容批量查询，同时支持一对多的查询。

2. A 服务系统与区块链节点同步机构路由地址等信息，进行查询转发，向 B 服务系统发起查询。

3. B 服务系统与区块链节点同步机构状态等信息，经过审核校验后，向 B 业务系统转发查询请求。

4. B 业务系统查询后端数据后，返回查询结果给 B 服务系统。

5. B 服务系统返回查询结果给 A 服务系统。

6. A 服务系统收集查询结果，（如果是一对多的查询），使用消息队列异步返回查询结果给 A 业务系统。

如上所述，数据查询的过程已经结束，其中主要有两点疑问：

第一，为什么要添加服务系统作为数据中转？

综合来看，服务系统的设立有以下几个目的：

• 作为业务系统接入区块链节点的桥梁，联盟统一定制，可以降低接入成本。

• 与区块链节点共同协作完成分布式数据查询的路由转发。

• 为后端的业务系统提供屏蔽，保护其数据查询接口不被公开。

• 通过流经服务系统的查询请求与查询结果数据，进行基于区块链的事后记账。

第二，A 向 B 查询数据的过程并未关联区块链？

基于区块链的分布式记账交易需要考虑时效性，完备性，准确性等等因素。A 向 B 查询数据完成之后，记账交易是通过事后记账的形式完成的。设计成事后来完成记账交易，主要是考虑了风控数据的时效性，即交易效率的考量。区块链是异步确认交易的过程，如果等待异步确认交易完成后，再返回查询结果，将会大幅降低交易效率。此外，事后记账交易由被查询方来完成（即上述示例中的参与机构 B），这样设计的目的是为了保证记账交易的完备性。

从博弈的角度来看，被查询方 B 输出查询结果从而获得通证积分，具备发起记账的自发性和主动性。B 记录账目的准确性，则是通过记账完成之后的事后审计来控制。对于 A 查询 B 并由 B 记录账目这个事件，唯一可能对账目存在异议的只能是交易对手方 A。A 可以在账目记录完成后发起事后审计，以保证记账交易的准确性。本文下篇会详述事后记账与事后审计的相关内容。

前文提到鉴于国家政策法规的限制，区块链项目中产生的通证，并不允许在二级市场进行自由买卖。目前没有国家背书的法定数字货币正式推出，尚无法关联区块链通证并实时结算。这种情况下，添加一个具备监管属性的运营参与方到联盟链中，是解决通证结算问题的最优方案。通过合约中限制监管运营方的交易操作，仍然能够保证区块链分布式去中心的相关特性，使得监管运营方只作为业务流程中某些特殊环节的辅助参与机构，并非作为中心化的权力机构。

基于以上设计思路，监管运营方在联盟链中，主要承担如下几个主要任务：

• 建立健全分布式数据查询的机制，并维护机制的正常运转，提供联盟运营和运维的相关服务。

• 提供事后审计服务，本文下篇将详述其审计服务的必要性。

• 基于区块链上的记账信息，主持进行链外的资金清结算工作。（备注：监管运营方无法直接干预区块链原始记账信息）

总结对照 2.0 版设计方案的改进之处：

1. 数据安全方面：各家机构无需报送数据，仍然保留数据的访问控制权，数据安全得到保证。

2. 数据质量方面：被查询的数据会经过业务流程的实时验证，数据质量通过反馈机制可以得到有效控制。

3. 交易效率方面：由于采用了事后记账与事后审计的机制，数据查询的效率并没有被分布式架构所影响。

4. 通证流转方面：积分采用透支的方式获取，固定期限后进行积分轧差清零，参与机构可以及时变现。

2.0 版本系统架构设计

区块链底层框架，仍然沿用了金融机构目前广泛接受的超级账本开源项目 HyperLedger Fabric。如前文所述，智能合约中主要包括两部分内容：分布式数据互查机制和公开公平公正的数据计价体系。

• BS-F（区块链服务系统）作为参与机构接入区块链节点的桥梁，在提供数据写入与数据读取基本功能的同时，还会将区块链数据按照区块和交易的维度进行缓存备查。

• BU-F（区块链工具系统）包含了运营系统来作为监管运营方接入联盟，此外，还包括一些运维角度的区块链底层配置管理，比如节点管理，证书管理等等。

2.0 版本部署架构设计

HyperLedger Fabric 将节点分为排序节点和背书节点，排序节点用于维护组网配置和生成区块，几乎不支持动态变更；背书节点分别从属于不同的参与机构，用来在业务层面达成共识，并且支持动态变更。运营系统作为监管角色，直接接入区块链节点，而参与机构的业务系统都是通过服务系统中转接入区块链节点。