保险业的区块链应用实现路径

将区块链与保险业务结合,需要完成区块链与现有保险业务系统的融合。在技术层,通过密码学、数字签名、哈希、时间戳等技术手段实现用户身份验证、数据保存等问题;在业务层,通过智能合约实现更丰富灵活的跨系统业务逻辑,使多方合作业务更容易实现;而区块链的P2P通信、分布式数据存储架构技术能够实现系统多中心化计算和存储,从而在互联层和数据层上保障了系统数据的安全和可靠。

一个基于区块链的保险项目就是要通过区块链的技术特点,在数据层、互联层、业务层、技术层上提供有力的支持,保障保险相关的业务层各个系统正常运行。与中心化信息系统不同,区块链是一个多方参与的分布式系统,相对于传统的集中式信息系统,在同一条区块链上一般会有多个业务系统进行连接,并进行业务交互。在基于区块链技术的保险业务中,一般可以通过如下几个步骤来实现。

(1)确定各个参与方

一个基于区块链的保险系统,首先要确定参与的各个机构。如在寿险中,一般需要保险公司、医疗机构、银行等参与方加入区块链系统中来,共同参与区块链系统的建设。而在财险中,以车险为例,可能就需要保险公司、交管机构、银行等参与到区块链系统的建设中。甚至,可以将保险监管机构加入区块链中,成为其中的一个重要角色或者机构。区块链天然的共享账本特性,可以有效地提高监管的效率,从而提高区块链参与各方的公信力。

参与的各方往往是由业务决定。可能同一条区块链上,有多家医疗机构、多家银行、多家保险公司参与。有的同行业的参与方还存在着竞争关系,因此,如何协调上链的各个参与方关系往往成为系统建设的关键。一般在项目开始阶段,每个角色都只允许一个参与方加入到区块链上来,比如一家银行,一家医疗机构,一家保险公司,使业务逐步开展起来,后续如果有某个机构想参与进来,需要与已进入的机构进行沟通、协商,得到允许后就可以加入进来。参与保险业务区块链的各方,一般要遵照一定的行业规范,可设定一定的条款约束参与区块链的各方机构。参与方越多,区块链上的验证节点就会越多,就更容易形成多中心验证,从而实现去中介化,降低机构运营成本。从系统建设考虑,也要确定各个参与方的接入顺序。在保险行业应用场景中,保险机构管理模块和投保人管理模块处于核心地位,需要优先接入。而医疗机构和银行机构可在保险业务系统接入后进行接入联调。政府监管管理模块可根据需要再酌情考虑接入,这样能保证系统建设的有序稳妥。

(2)确定上链数据内容及格式

由于区块链连接了各个业务系统,而各业务系统往往都是已有的,并且由参与方自己建设完成。因此,就需要各参与方约定上链数据的内容及格式,从而实现通过链上数据的互联互通,达到信息共享的目的。因此,需要在数据层中,在投保人身份识别数据模块、保险机构业务处理数据模块、其他社会关联机构之间达成数据层面的共识,提炼共同认可的数据内容和格式。

数据内容的确定。确定上链数据的内容是整个区块链项目建设的重点,往往决定项目建设的难易程度以及项目建设的周期。而数据内容的确定一般又是由区块链上参与的多方角色一起制定商讨出来的,这个讨论过程又往往是艰难的。比如在保险公司、医疗机构、银行的三个参与角色中,参与的各方从自身利益角度出发,一定不会将自己全部数据都写入到区块链上。银行从信息安全的角度出发,不会发布用户的资产情况,一般只提供转账服务和一定的账户信息。医疗机构从保护病患信息角度出发,不会将患者的病史信息发布到区块链上,一般只会提供病人的自然信息以及医疗过程中的费用清单等相关信息。保险公司一般只会将保单中的部分信息写入到区块链上,而其后台的一些分析计算数据一般没有必要写入到区块链上。因此,对于上链数据的确认不是一蹴而就,而是需要参与各方多次讨论才能最终确定数据的内容。

数据格式的确定。在数据内容确定的基础上,需要对上链数据的格式进行确定。由于区块链采用了创造性的块链式的数据结构,从而实现了不可篡改、可追溯等特性。但正因为采用块链式的数据结构,一般情况下,区块链上的数据不易过大,如视频、音频、图片这样的数据不适合写入到区块链上。如果业务系统需要处理音视频这样的大文件,一般采用将大文件进行哈希运算,将最终的哈希值保存到区块链上。其他的文本类信息可根据各业务系统的情况,以xml、json等各种流行的数据传输格式记录到区块链上。

(3)各业务系统的改造及与区块链对接

在参与方、上链数据的内容、上链数据的格式都确定后,就需要将区块链与参与各方的业务系统进行对接。一般业务系统是由参与方各自建设并维护的,要想与区块链进行对接,或多或少要对原有系统进行一些改造或升级。在这个过程中,需要区块链技术人员与各业务系统开发运维人员进行沟通。沟通的内容主要有两方面。(www.xing528.com)

原有业务开发人员对区块链技术和开发方法的学习和理解。因为区块链是一种新的技术解决方案,相对于传统的中心化信息系统存在着很大的不同。业务开发人员需要学习理解区块链的去中心化的理念,了解数据加密解密以及签名验证的概念,初步认识共识机制的原理和特点。除此之外,业务开发人员还要学习区块链的开发接口,只有充分了解了接口功能,才能有效发挥区块链技术的特点,完成业务逻辑的编码和测试。

区块链技术人员对保险行业业务和流程关系也需要学习和理解。保险行业是一个传统的金融行业,但也在不断地创新发展,采用区块链技术就是其重要的突破。这也要求区块链技术从业人员,要快速学习包括保险在内各种金融业务。区块链技术人员应该做到快速理解保险业务系统的逻辑关系,数据的存储方式,这样,才能有效地跟保险从业人员探讨业务设计,帮助保险业务开发人员完成产品需求及设计,并能够提出合理的基于区块链解决方案及建议,实现系统的快速构建。

(4)测试与验证

在以上步骤都完成后,还需要对基于区块链的保险应用的各系统进行测试和验证。由于区块链系统需要连接多个上链业务系统和机构,因此需要完善的测试和验证后才能够正式上线。测试和验证的重点主要围绕以下几个方向。

上链数据的完整性。也就是说,各业务系统写入的数据是否按照原有设计的内容和格式写入到区块链上需要充分验证。

保险业务的完整性。基于区块链技术的保险业务应该在不影响原有保险业务的情况下,提供更丰富的业务模式。因此,应该从保险业务模型角度,多做功能验证,保证原有保险业务逻辑不受影响。

上链数据的保密性。在区块链上有多个同业机构的情况下,为了防止数据被公开,数据一般都采用加密并且只有授权才能可见的方式。因此,数据保密性就特别关键。

上链数据的不可抵赖性。链上数据的每次操作都需要进行签名和验签,以保证写入的数据和操作是不可抵赖。因此,需要保证任何区块链的操作都要有用户的签名,任何数据的修改都需要验证用户的签名和权限,这样才能防止用户恶意篡改数据。

(5)其他

做完以上步骤后,往往一个区块链的项目就可以上线投产了。但在系统和业务的运行发展过程中,可能会有新的问题及新的需求。如:有新的机构要加入进来,有新的数据需要写入到区块链上等这样的问题。因此,就要求整个系统的设计者,在设计数据的内容和格式时,要有一定的前瞻性,要熟悉保险的业务场景,能够保证满足一定的业务扩展需要。这里也需要保险业务开发人员与区块链技术人员在系统设计初期多多沟通,互相学习,设计具有扩展性的方案,使新的需求能够更容易地实现,快速满足业务需求。