| 编辑推荐: |
| 本文来自于51CTO，文章以信贷业务为例，基于联盟链的架构，设计实施了金融风险数据共享的解决方案。 |
|
金融机构或者企业在开展各类风控相关业务的过程中，需要收集风控数据，构建风控体系，并最终服务于相关业务场景。以信贷业务为例，基于风控数据的黑名单机制，是比较常见的一类风控措施。在开展此类业务的过程中，各家金融机构或者企业往往会产生数据共享的需求，用以提高相应的风控能力。目前金融风险数据共享的主要方式，一般通过接口查询的方式实施，被查询方根据查询流量进行计价收费。
本文将讨论基于区块链技术，搭建金融风险数据共享联盟，为联盟中各个金融机构或者企业提供一个公正平等的数据互查平台，并且推动联盟中数据整体质量得到提高，使得联盟成员去伪存真，优胜劣汰。最终目标是结合区块链技术对通证的生成和验证等特性，为金融风险数据共享提供公平有效的计价和评价体系，并促进整体联盟不断迭代增值。
业务场景介绍：
很多金融机构在开展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业务系统；
如上所述，数据查询的过程已经结束，其中主要有两点疑问：
第一，为什么要添加服务系统作为数据中转？
综合来看，服务系统的设立有以下几个目的：
1.作为业务系统接入区块链节点的桥梁，联盟统一定制，可以降低接入成本；
2.与区块链节点共同协作完成分布式数据查询的路由转发；
3.为后端的业务系统提供屏蔽，保护其数据查询接口不被公开；
4.通过流经服务系统的查询请求与查询结果数据，进行基于区块链的事后记账；
第二，A向B查询数据的过程并未关联区块链？
基于区块链的分布式记账交易需要考虑时效性，完备性，准确性等等因素。A向B查询数据完成之后，记账交易是通过事后记账的形式完成的。设计成事后来完成记账交易，主要是考虑了风控数据的时效性，即交易效率的考量。区块链是异步确认交易的过程，如果等待异步确认交易完成后，再返回查询结果，将会大幅降低交易效率。此外，事后记账交易由被查询方来完成（即上述示例中的参与机构B），这样设计的目的是为了保证记账交易的完备性。从博弈的角度来看，被查询方B输出查询结果从而获得通证积分，具备发起记账的自发性和主动性。B记录账目的准确性，则是通过记账完成之后的事后审计来控制。对于A查询B并由B记录账目这个事件，唯一可能对账目存在异议的只能是交易对手方A。A可以在账目记录完成后发起事后审计，以保证记账交易的准确性。本文下篇会详述事后记账与事后审计的相关内容。
前文提到鉴于国家政策法规的限制，区块链项目中产生的通证，并不允许在二级市场进行自由买卖。目前没有国家背书的法定数字货币正式推出，尚无法关联区块链通证并实时结算。这种情况下，添加一个具备监管属性的运营参与方到联盟链中，是解决通证结算问题的最优方案。通过合约中限制监管运营方的交易操作，仍然能够保证区块链分布式去中心的相关特性，使得监管运营方只作为业务流程中某些特殊环节的辅助参与机构，并非作为中心化的权力机构。
基于以上设计思路，监管运营方在联盟链中，主要承担如下几个主要任务：
1.建立健全分布式数据查询的机制，并维护机制的正常运转，提供联盟运营和运维的相关服务；
2.提供事后审计服务，本文下篇将详述其审计服务的必要性；
3.基于区块链上的记账信息，主持进行链外的资金清结算工作；（备注：监管运营方无法直接干预区块链原始记账信息；）
总结对照2.0版设计方案的改进之处：
数据安全方面：各家机构无需报送数据，仍然保留数据的访问控制权，数据安全得到保证。
数据质量方面：被查询的数据会经过业务流程的实时验证，数据质量通过反馈机制可以得到有效控制。
交易效率方面：由于采用了事后记账与事后审计的机制，数据查询的效率并没有被分布式架构所影响。
通证流转方面：积分采用透支的方式获取，固定期限后进行积分轧差清零，参与机构可以及时变现。
2.0版本系统架构设计
区块链底层框架，仍然沿用了金融机构目前广泛接受的超级账本开源项目HyperLedger Fabric。如前文所述，智能合约中主要包括两部分内容：分布式数据互查机制和公开公平公正的数据计价体系。
BS-F（区块链服务系统）作为参与机构接入区块链节点的桥梁，在提供数据写入与数据读取基本功能的同时，还会将区块链数据按照区块和交易的维度进行缓存备查。
BU-F（区块链工具系统）包含了运营系统来作为监管运营方接入联盟，此外，还包括一些运维角度的区块链底层配置管理，比如节点管理，证书管理等等。
2.0版本部署架构设计
HyperLedger Fabric将节点分为排序节点和背书节点，排序节点用于维护组网配置和生成区块，几乎不支持动态变更；背书节点分别从属于不同的参与机构，用来在业务层面达成共识，并且支持动态变更。运营系统作为监管角色，直接接入区块链节点，而参与机构的业务系统都是通过服务系统中转接入区块链节点。
非对称信息博弈的最优契约-事后记账与事后审计
如本文上篇所述，事后记账由被查询方来完成，那么记录的账目信息中都包含哪些内容呢？ 简单来说，可以描述成，谁查询了谁，查询了哪些数据，这些数据会导致通证积分余额产生什么样的变化。
详细来说，账目信息会以键值对的方式记录到区块链节点中。
Key值包括查询方与被查询方，以及查询方拟定的唯一序列号组成（由查询方拟定序列号，主要考虑到被查询方记录账目以及双方存在博弈关系）。此外，记账信息Key值中还包含了分期信息，后文将详述分期信息的必要性。
Value值中主要包括查询请求与查询结果，还有根据查询请求和查询结果生成的通证积分结转信息。查询请求和查询结果信息并不能直接作为账目信息发往区块链的背书节点。
本文上篇的部署架构中明确了背书节点分别从属于不同的参与机构，如果直接发送原始数据，会有数据安全的隐患存在。Fabric1.2版本中添加了节点私有数据库sideDB，用于处理此类隐私数据的安全隐患问题，但仍然存在一些交易效率的相关问题。所以实施方案中，会把原始数据的摘要信息以及对摘要信息的签名作为记录账目的组成部分。摘要信息证明了原始数据的存在，而签名则证明了原始数据的来源。这两项数据可以有效证明查询请求与查询结果的合法性，并且原始数据不会以任何形式暴露给背书节点。
记账信息通过交易的形式发往区块链背书节点，背书节点通过合约校验记账交易的合法性，包括签名是否正确，积分结转是否合理等等。唯一无法校验的环节在于，原始数据与摘要数据的一致性。对于查询方来说，对于被查询方的记账交易，唯一需要质疑的内容，也是原始数据与摘要数据的一致性问题。原始数据基于安全性考虑，无法传递到区块链背书节点，公布给所有参与机构见证。
但是，查询方对于账目信息存在疑虑的时候，可以在链外向监管运营系统发起审计操作。
事后审计是监管运营系统自动执行的相关业务流程，不需要人工干预。系统会读取原始数据与链上数据，按照固定的处理流程进行对比，最终裁定该笔审计操作是否被认可。一旦查询方获取到监管运营系统给予的审计背书（包含监管运营系统的签名），就可以发起一笔冲正交易，将对应的记账信息置为无效。这个过程也就是记账交易完成之后的审计流程，简称事后审计。需要特别指出的是，并不是每笔记账交易都需要进行事后审计，只有那些查询方质疑的交易才会由查询方发起审计校验，而审计校验的成本是向监管运营系统公布原始数据。
基于区块链的通证积分清结算体系
探讨通证积分清结算体系之前，简要介绍一些预先设定，联盟链参与机构的初始积分都是零，使用透支的方式来花销积分，并设置积分透支的软上限。透支软上限的监测以及调控，都是通过监管运营系统来统一管理。所有参与机构的积分余额，在固定期限（比如一个月），由监管运营系统根据链上的快照数据来进行链外的资金结算。举例来说，链上的每家机构的积分余额，可能为正也可能为负，在链下进行资金兑付后，积分余额将被清零。
深入探讨积分清结算体系内的几类交易：
积分记账交易：由参与机构发起交易。由于区块链是异步确认交易的过程，每个区块中包含的交易会在区块生成后进行再次校验。同一个区块中的多笔交易可能改变了同样的读写集合，就会导致交易无效的发生。如下图，区块0中，A查B，B查C，如果两笔交易都读取了B的余额，至少会造成B查C交易无效。为了提高交易的有效性，所有的记账交易并不会读取并改变每家机构的积分余额，只是记录账目的发生（谁查询了谁，查询数据是什么，待清算积分是多少）。
积分冲正交易：由参与机构发起交易。冲正交易来源于事后审计，但是需要考虑时限性问题。如果记账交易已经完成链下的资金结算，将无法回滚交易并执行冲正操作。所以，冲正交易发起时限为当期积分快照交易完成前。
积分清算交易：由监管运营系统发起交易。主要有两个功能，首先是汇总记账交易产生的积分余额变更，其次是监管运营系统监测联盟参与机构的透支额度是否已经被突破。积分清算交易同样面临交易有效性问题，如果该交易不是某个区块的最后一笔交易，则一定会造成交易无效。因为积分清算交易依赖于积分记账交易，在积分清算交易提交后再次发生积分记账交易，一定会导致积分清算交易无效。为了解决这个问题，适时引入了积分改期交易。
积分改期交易：由监管运营系统发起交易。将所有的记账交易，分为若干记账周期。例如，每日零点发起积分改期交易，开启一个新的记账周期。这样使得积分记账交易依赖于积分改期交易，而积分改期交易一定是有效交易。积分改期交易完成之后，积分清算交易无论何时进行，同样也变成有效交易了。
积分快照交易：由监管运营系统发起交易。积分快照交易将汇总多个积分清算交易产生的积分余额变更，为链外资金结算提供链上积分快照数据参照。积分清算交易周期可以被监管运营系统灵活调整，但积分快照交易周期则需要与链外资金结算周期保持同步。
项目可扩展性-机构接入成本
联盟链项目的机构接入成本主要体现在组网配置中，本文暂不讨论此类问题。从业务开展角度来看，新机构加入联盟链，需要首先进行接口改造，主要包括数据查询与数据提供两个接口；然后部署区块链服务系统，服务系统将由联盟提供统一定制蓝本；最后部署从属于该机构的区块链背书节点，承载智能合约，校验各类交易的有效性。
根据联盟整体运行性能要求，服务系统的部署环境会有最低配置要求，而参与机构的业务系统接口也需要达到一定的最低并发要求。此外，为了提高节点运行性能，参与机构背书节点可以采用读写分离的部署策略等等，不再逐一详述。新机构接入流程，首先在测试环境进行演练，之后将移植到生产环境。
总结与展望
综合前文所述，基于联盟链的架构，设计实施了金融风险数据共享的解决方案。目前该方案仅提供了数据的计价能力，仍然欠缺数据的评价能力。完善数据的评价能力可以通过使用权益积分来实现，仍处于探索阶段。
区块链从问世之初，就不仅仅是一种分布式数据库，不应该只被用来完成上链记账操作。或者说，区块链不仅仅是一项技术，而是结合了经济学，社会学，密码学，博弈论等等内容的综合体。在一个熵增（不确定性逐步增长）的环境下达成共识，形成制度博弈，最终优胜劣汰，良币驱逐劣币，达到某个细分领域内的行业自治才是区块链能够带来的最终改变。
|
