业务场景介绍很多金融机构在开展 C 端业务的时候,时常需要甄别来自于 C 端用户的交易风险,身份伪造,营销欺诈等等。 简单举例:营销或者支付业务中,甄别某位个人用户是否有过欺诈行为就属于这一类风控识别措施。这些金融机构随着业务的开展,往往已经收集并沉淀积累了很多黑名单,黄名单,灰名单等。简单来说,金融机构通过使用这些名单数据,做一些用户过滤处理就能达到一定的业务风险控制的目标。
业务开展过程中,金融机构或许要面临一个显而易见的问题:已有的黑名单数据并不足以控制业务风险,时常需要借助其他机构的名单数据进行补充,才能达到一定的业务风控效果。而基于 C 端用户的风控数据,基本上都属于金融机构的核心数据,并不能无偿共享。这就衍生出了一个关于 C 端用户风控数据的买卖市场。传统的风控数据查询方式,往往通过卖方机构提供一个收费的数据查询接口的形式来实现。买方机构通过预付费或者后付费的方式向卖方机构支付数据查询的相关费用。而关于费用的计价维度多种多样,但相同之处是所有数据计价完全由数据卖方主导设定。
image 2.0 版设计方案的总体设计思路:联盟参与机构的核心数据并不需要报送,通过添加一层“服务系统”来协助智能合约完成安全多方计算,合约中添加账户体系来为每次数据查询进行计价服务。在数据查询与计价服务实现的基础上,同时考虑数据安全,数据质量,交易效率与通证记账完备性问题等等。
在整体架构设计中,首先需要简单介绍一下数据查询的应用示例。例如,金融机构 A 查询金融机构 B 提供的风控数据,通过如下的流程来完成:
第二,A 向 B 查询数据的过程并未关联区块链?
基于区块链的分布式记账交易需要考虑时效性,完备性,准确性等等因素。A 向 B 查询数据完成之后,记账交易是通过事后记账的形式完成的。设计成事后来完成记账交易,主要是考虑了风控数据的时效性,即交易效率的考量。区块链是异步确认交易的过程,如果等待异步确认交易完成后,再返回查询结果,将会大幅降低交易效率。此外,事后记账交易由被查询方来完成(即上述示例中的参与机构 B),这样设计的目的是为了保证记账交易的完备性。
从博弈的角度来看,被查询方 B 输出查询结果从而获得通证积分,具备发起记账的自发性和主动性。B 记录账目的准确性,则是通过记账完成之后的事后审计来控制。对于 A 查询 B 并由 B 记录账目这个事件,唯一可能对账目存在异议的只能是交易对手方 A。A 可以在账目记录完成后发起事后审计,以保证记账交易的准确性。本文下篇会详述事后记账与事后审计的相关内容。
积分记账交易:由参与机构发起交易。由于区块链是异步确认交易的过程,每个区块中包含的交易会在区块生成后进行再次校验。同一个区块中的多笔交易可能改变了同样的读写集合,就会导致交易无效的发生。如下图,区块 0 中,A 查 B,B 查 C,如果两笔交易都读取了 B 的余额,至少会造成 B 查 C 交易无效。为了提高交易的有效性,所有的记账交易并不会读取并改变每家机构的积分余额,只是记录账目的发生(谁查询了谁,查询数据是什么,待清算积分是多少)。