金窝窝是怎样利用区块链技术解决大数据风控问题的

区块链风控的意思是

我国的供应链金融实践已经有10年以上的时间。银行作为资金端的主力，风控逻辑主要依赖核心企业的信用背书，在风险规避的策略下，质押担保是主要的授信策略，如存货质押、应收账款融资、预付款融资等。而购买债权的保理业务占比较低，贸易融资的自偿性特性没有得到充分利用。这与银行的信用创新技术和风控方法有着密切联系，银行对于交易真实性的判断与票据审查，仍然具有诸多技术上的困难。

区块链架构提供“穿透”多层交易结构的信用技术，使得银行可以对远离核心企业的节点进行授信。现有的供应链金融，核心企业的信用杠杆一般只能传递给一级供应商或一级经销商，而对于二级以上的供应商与经销商，由于缺少与核心企业的直接交易关系，银行因核心企业无法进行信用背书而不能提供融资服务。在区块链架构下，可以构建多节点参与的交易关系，依据ERP构建连续的合同关系，再结合云仓库、VMI等库存管理模式，使得全链都可以获得核心企业的信用支持。

区块链架构可以打通银行急需解决的信用瓶颈。虚拟系统对于供应链金融的最佳支持，是对于全链所有节点交易的可视化，不仅包括线上的交易链（商流），而且包括交易的各类支持流程，如线下的物流、单证流、价值交换的真实证据等，只有当银行认为已经获得足够、充分的信息时，才能排除质押品风险，充分的授信服务才可能实现。

1.从虚拟到平行、交互

快速发展的电子商务、科技金融、虚拟现实和其他众多的智能技术，已经根本性地改变了现代商业的采购、生产、营销、消费等模式，形成了现实物理世界与虚拟网络空间紧密耦合、虚实互动、协同演化的平行世界。

可靠的数据是虚拟世界存在的基础。基于区块链架构构建的虚拟系统，在“双工交互”模式下，能实现与真实系统同构的方式反映交易历史，实际上虚拟系统已经具有客观实在性，因为虚拟系统不再是原来可以任意删改的信息系统，而是与真实系统相对应的平行系统，现实系统与虚拟系统具有相同的真实性，所以虚拟系统的信用也是真实可信的，这对于以“真实性”为本的金融业务的开展具有极大的支撑作用。

区块链架构下的虚拟系统是平行于真实系统的。或者说，在区块链架构下，人可以理解的系统分为两个世界（由两个世界组成），这两个世界都是真实的，互为补充、交互执行。

2 政府节点的重要性

政府各相关部门具有丰富、高质量的信用信息资源，如工商、税务、公安、海关、检验检疫等部门。这些部门的信息获取具有严格的要求并受国家法规的保护，是建立在自身业务范围基础之上的，但是缺乏统一标准。

政府部门的信息一般对内交流，不与社会商业系统进行互通交换、资源共享。而在现有供应链金融的平台中，信用信息资源分散、透明度低、获取信息的难度大、成本高，较大地制约了信用创新及信用评级业务本身。政府部门大量有价值的信息资源处于闲置和浪费的状态中，这甚至是商业信用创新的一个“瓶颈”问题。

以外贸为例，有运输服务、港口及空港物流园区（保税）、海关及电子平台、检验检疫、综合服务平台（如一达通）及大量功能性服务机构。在管理及效率的驱动下，近年来各类机构及平台不断创新服务模式，在效率上取得较大的进步。但在实践中，贸易便利性问题仍然没有得到很好地解决。目前，主要问题是海关、港口、物流园区的服务功能并不以“贸易”本身为中心来构建，这就给平台的金融服务创新造成极大的困难。

参考国外的先进模式，商业平台的构建以“贸易”为中心，是整合各政府服务部门、职能部门、运作实体的大服务平台。以贸易为中心，是把以“商流”为中心的交易网作为最高层次的平台，其他平台、实体、职能机构围绕交易平台来展开和对接服务、衔接流程，最终的目标是实现“贸易便利化”。这种模式将为供应链金融服务的导入和创新提供巨大的空间，便利化的结果是交易成本的快速下降。这也是我国发展实体经济的重要策略之一。

未来，大型平台中的供应链金融必然要将政府节点的引入作为区块链架构的关键之一。政府节点加入后，高质量的信用信息可以增强系统整体信用，也将促进参与交易的各方守信并增加动力，为金融服务的创新和融资范围的扩大提供有利的条件。

区块链架构并不是去中心化，而是减少传统的信用中介成本，政府节点的加入并不会导致中心化模式的出现，政府节点与其他节点处于平等的地位，政府节点并不实施控制权，而是在公开环境下实施行政职能。资料整理自网络，更多干货关注e票通！

第一：风险管理排的是“雷区”，这是从合规审查的角度来讲。

第二：风险管理防的是“万一”。这是从风险判断的角度来讲。

第三：风险管理守的是“底线”。这是从风险缓释的角度来讲。

第四：风险管理敲的是“警钟”。这是从风险预警的角度来讲。

第五：风险管理做的是“善后”。这是从风险化解的角度来讲。

在正确认识风险管理作用的基础上，要真正做好风险管理，还要构建相对科学的风险管理体系，才能真正取得风险管理的实效。

前期准备

拿到足够多的数据做支撑

做足够灵活的分析平台去分析数据

产出风险事件进行阻拦风险

量化风险拦截的价值和不断分析案例进行策略优化

风控技术评估研究

日志选择：以增量日志方式记录存储，hadoop或spark做分析，集群同步到客户端机器上，做同步策略，不同纬度的数据做统计加工计算。

实时监控：监控在每一个环节的交易量和高风险操作，做阀值报警，以默认的规则做处理。

dns防范：防止http对dns的拦截，手动纪录中断被拦截掉的交易流，转向存储中心系统做处理给予用户提示。

报警提醒：在发生重大灾难的同时需要有一套完善的体系提醒风控人员近入作战，以短信或电话的形式发起通知给用户。

数据灾难：数据的历史纪录应该有完整的备库纪录，这种操作不是必须的但是必要的，防止管理员因为误操作导致的数据灾难不容小视，启东应急方案进行恢复。

日志选择：需要在原有基础上做集群数据分析后，统一有一个入口的分析平台做汇总，对不同维度的计算规则做排重，这里我们可以使用elk的方式把数据清洗完成后，做相关的分析调研，实时读库的方式不可取，增量数据库只保留历史的数据，可以对时间做相关的约定，查询的平台统一做相关的调控。

方案的选择和实施

针对现在的数据规则，需要对现有的各方数据做分析指标，做数据仓库，从不同的数据中计算对应的需要风控形成各种渠道的报表数据。如何通过查询海量的历史数据来支撑规则的运算，从分析的角度来看，又是一个IO密集型的应用；利用OLTP（online transaction processing ）和OLAP（online analytical processing）做相关的维度计算，主要针对用户、功能、数据片、存储空间、DB设计来做维度计算和方案的优化调整。

大到用hadoop做数据集群算法分析，也可以用spark、storm来做。

简而言之就是分布式框架，那么什么是分布式框架？

分布式计算框架实现了什么？简而言之，基于分布式计算框架的应用，就是一个分布式的应用；那么分布式的应用解决了什么问题？简而言之，就是将请求处理的业务逻辑和所需资源合理地分布到N台服务器上，这里就不在过多介绍。

基于C/S模式的原理，从client到server端的应用，采集需要的数据。Server之间通讯是有开销的，只不过这个开销是MS级的。系统在定位也是基于百万级的应用。

以分层的概念，针对每部的风控模块，需要在特定的时间做调整。缓存的应用：如果是历史级别的数据，可以采用redis、cache来做，防止减少对于I/O的读写操作，减少存储压力的开销。基于款时间的维度对应的风控系统计算，需要我们在处理的同时考虑数据的节点，分批次处理。对于变化多端的数据，建议利用高可用性能存储设计，基于DB设计即可，数据结构要基于范式(NF)设计，不可有冗余免得频繁返工。

数据分离的优先选择

数据库读写分离机制：在初期，风控系统一般都极为简单，此时侯一般通过数据库主从复制/读写分离/Sharding（或slave进行）等机制来保证交易系统的数据库和风控系统数据的同步及读写分离。风控系统对所需要的客户/账户数据、交易数据一般都只进行读操作。

缓存/内存数据库机制：不管是交易系统还是风控系统，高效的缓存系统是提升性能的大杀器，一般会把频繁使用的数据存放到Redis等缓存系统中。例如对风控系统，包括诸如风控规则、风控案例库、中间结果集、黑白名单、预处理结果等数据；对交易系统而言，包括诸如交易参数、计费模板、清结算规则、分润规则、银行路由策略等。对一些高频交易中，基于性能考虑，会采用内存数据库（一般会结合SSD硬盘）。

RPC/SOA架构：要降低交易系统和风控系统的耦合度，在初期系统服务较少的情况下，一般直接采用RabbitMQ/ActiveMQ之类的消息中间件或RPC方式来实现系统间服务的调用。如果系统服务较多，存在服务治理问题，会采用Dubbo之类的SOA中间件来实现系统服务调用，这个期间我们需要支持用异步消息完成rabbitMQ的消息的push/pull处理机制来处理违规数据和异常数据提取。