一种面向银行风险控制的金融图谱构建与分析方法与流程

本发明属于金融大数据分析领域，尤其涉及金融图谱的数据建模和如何通过金融图谱发现海量银行数据中可能存在的风险。

背景技术：

银行业是一个数据驱动的行业，数据也一直是银行信息化发展的主题词。银行业每天都要都要产生海量的交易数据。有研究统计，经过多年的发展与积累，国内商业银行的数据量已经达到100tb以上级别，并且正在以更快的速度增长。

如此庞大的数据也给银行及其监管机构的数据分析部门带来了巨大的挑战。当数据分析任务的复杂性比较高时，海量数据的计算会导致难以承受的开销。以担保环为例，担保环是指多家企业通过互相担保或连环担保而产生的特殊利益体。在经济平稳增长时期，担保环确实在一定程度上降低了中小企业的融资难度，促进了民营经济的发展。但是如果经济逐步下行，担保环的负面影响将逐步显露，加剧了信贷风险的暴露，如果处理不当，容易引发系统性金融风险。然而，目前银行所使用的传统关系型数据库管理系统（rdbms）在处理大量连接操作时效率不高，在检测担保环时的时间开销非常巨大，无法满足实际工作的需求。

因此，如何对海量金融数据进行建模存储，并对其进行分析，从而达到发现和规避金融风险的目的，是一个目前亟待解决的技术问题。

技术实现要素：

针对当前海量金融数据分析效率低的现状，本发明提供了一种金融图谱的构建与分析方法，能够实现海量金融数据的快速模式分析。具体分为两个模块：金融图谱构建模块和金融图谱分析模块。所述金融图谱构建模块主要用于将银行的关系型数据建模为图谱数据，并存入新型的图数据库，如neo4j等；所述金融图谱分析模块主要用于对金融图谱进行查找分析，包括担保环查询、消费贷款违规进入房地产行业查询等方面。

所述金融图谱构建模块方案如下：

金融图谱，就是以知识图谱为基础，把银行海量的金融数据连接在一起而得到的一个金融关系网络。在一个存放金融数据的关系数据库中，存放的信息类型主要可以归纳为客户的基础信息、客户的所有的存款账户信息，银行的基础信息和所有的业务信息这四大类。由此，本发明提出了一种通用的以图为结构的银行数据模型。并以该模型为基础进行金融图谱的构建。

该模型可表示为：。其中，是节点的集合，对于中的每一个节点，都有一个标签和若干个属性，标签表示该节点所属类型，属性包括属性名和属性值，表示该节点所包含的各种信息。是一个有向边集合，对于中的每一条边，都有一个标签和若干属性，标签表示该边所代表的关系类型，属性包括属性名和属性值，表示该边所包含的各种信息。是节点标签的集合，是边标签的集合。是节点属性的集合，是边属性的集合。

而在银行的关系数据库中，金融数据都是以表的形式进行存储。所以在构建金融图谱时需要建立从银行关系数据库模式到金融图谱数据模式的映射关系，并根据映射关系进行数据转换，得到对应的金融图谱实例。

所述金融图谱分析模块方案如下：

在金融图谱分析模块，我们可以根据银行具体的业务需要建立相应的分析模型，然后借助于图数据库在模式匹配方面的优势，采用适当的方法在金融图谱中进行查找。银行海量的金融数据给银行以及银行监管机构的数据分析部门带来了巨大的挑战，而借助于金融图谱分析模块，我们可以全面而有效的分析查找出金融数据中存在的金融风险，从而更好的服务于银行的风险防范工作和银行监管部门的宏观决策。

对于具体的银行业务，在分析过程中的思路是：将业务中所涉及的实体抽象为图中的节点，实体之间的关系抽象为图中的边，然后根据业务需要，对节点和边添加一定的约束条件。然后可以采取图查询或图遍历的方式在整个金融图谱中进行模式匹配，查找出包含该模式的所有实例，并进行可视化展示。

金融图谱分析模块可通过以下几个步骤来实现：

步骤1：了解银行业务，分析其所需查找的分析模型。

步骤2：根据步骤1中的分析结果，将分析模型中的各个部分与图数据模型建立映射。

步骤3：根据步骤2中的映射，建立图数据库中的逻辑模式。

步骤4：根据步骤3中的逻辑模式，采用适当的查询方式或者设计合适的算法进行查找。

步骤5：根据步骤4中的结果，在后台进行处理，用于前端可视化展示，并进行保存，以供重复利用和分析。

本发明具有以下优点和积极效果：

（1）提出了一种通用的以图为结构的银行数据模型，并以该模型为基础在图数据库中进行金融图谱的构建。借助于构建的金融图谱，可以大大提高分析效率。

（2）在查找担保环时，提出了一种基于深度优先搜索的图遍历算法，缩小了遍历范围，大大提高了担保环的查找效率。

附图说明

图1为本发明所述的一种关系数据库中存储的金融数据模型图

图2为本发明提出的一种通用的以图为结构的银行数据模型

图3为本发明所述的从关系数据库中提取数据到图数据库中建模的流程图。

图4为本发明所述的消费贷款违章进入房地产行业模型的流程图。

图5为本发明所述的担保环查找算法的流程图。

具体实施方式

所谓金融图谱，就是以知识图谱为基础，把银行海量的金融数据连接在一起而得到的一个金融关系网络。借助于金融图谱，我们可以从“关系”的角度去分析问题，从而实现金融数据的快速模式分析。在这一部分里，我们将对金融图谱的构建以及金融图谱的分析进行详尽的阐述。

1、金融图谱构建模块

下文将结合现实中银行的金融数据详细介绍金融图谱构建模块的具体实施方式。

1.1理论基础

传统的关系型数据库中，对于数据之间内在关系的表示都是基于表格和表格之间的连接操作。由于表格和表格之间的连接操作是非常耗时的。所以在应用关系型数据库对海量的金融数据进行查找分析时，往往存在查询效率低下，时间开销大等问题。举一个简单的例子，在如图1所示的金融数据模型图中，当我们要查询与客户a发生过交易关系的客户时，需要先根据客户的证件号码在存款账户表ck中获取客户a的存款账号，然后根据存款账号在交易信息表中jy中获取交易对手的账号。接下来根据交易对手账号在ck表中获取证件号码，最后通过证件号码在客户信息表n中获取客户的详细信息。这只是一种简单的情况。当数据分析任务的复杂性比较高，比如查询一笔贷款资金的流向时，则会涉及到更多次表连接操作，从而导致难以承受的开销。由此可以看出，在需要描述大量关系时，传统的关系型数据库已经不堪重负。它所能承担的是实体较多但实体间关系相对简单的情况。而对于银行金融数据这种实体间关系非常复杂，需要在关系之中记录数据，且大部分数据操作都与关系有关的数据，原生支持了关系的图数据库才是正确的选择。它不仅可以使查询分析的效率得以提高，更可以提高开发效率，减少维护成本。

下面对图数据库进行简单介绍：

图数据库是基于图论的思想和算法而实现的高效处理复杂关系网络的新型数据库系统。它善于高效处理大量的、复杂的、互连的、多变的数据。由于其数据的存储基础就是基于点和点之间的关系而设计的，所以更适合基于数据关系的查询和遍历。

图数据库包含的4种基本元素如下：

（1）节点（node）：图数据库中，每个节点代表一个独立的实体，实体的属性被存放在节点上，且每个节点都有唯一标识。

（2）关系（relationship）：关系是定向的，它连接两个存在联系的节点，联系的属性也存放在关系上。

（3）属性（property）：图数据库中，属性用来描述一个具体的对象，节点和关系都可以拥有属性。

（4）标签（label）：标签用于将节点和关系进行分类区分，方便进行查询。

1.2图数据库模型的建立

基于以上分析和介绍，本发明提出了一种通用的以图为结构的银行数据模型，如图2所示。该模型由三类节点和五类关系组成。其中，银行节点是现实中银行的抽象，代表着银行实体，由银行机构代码、银行机构名称等属性组成。客户节点包括对公客户和个人客户两种，代表现实中的企业和个人，由机构代码、客户名称、证件号码、客户姓名等属性组成。存款账户节点代表账户实体，是客户之间、客户与银行之间进行业务往来的载体，由存款账号、证件号码、账户余额等属性组成。对应关系存在于客户节点与存款账户节点之间，是客户实体与其所拥有的存款账户实体之间的一种映射关系，对应关系没有属性。交易关系存在于客户节点所对应的存款账户节点之间，表示客户之间发生了资金往来，由交易账号、对方账号、交易金额、交易时间、银行机构代码等属性组成。担保关系存在于客户节点之间，是指客户实体向银行申请贷款时，另一客户实体为其进行担保，担保关系由担保人证件号码、贷款人证件号码、担保金额、银行机构代码等属性组成。贷款关系存在于银行节点和客户节点所对应的存款账户节点之间，表示客户实体与银行实体之间发生了借款行为，且客户需要在一定期限内归还，贷款关系主要由银行机构代码、证件号码、贷款入账账户、贷款金额、贷款类型、贷款实际发放日期等属性组成。控制关系存在于客户节点之间，表示客户实体之间存在从属关系，控制关系由控制类型这一属性组成。

模型可形式化表示为。其中，是节点的集合，对于中的每一个节点，都有一个标签和若干个属性，标签表示该节点所属类型，属性包括属性名和属性值，表示该节点所包含的各种信息。是一个有向边集合，对于中的每一条边，都有一个标签和若干属性，标签表示该边所代表的关系类型，属性包括属性名和属性值，表示该边所包含的各种信息。是节点标签的集合，是边标签的集合。是节点属性的集合，是边属性的集合。

以下对上述各集合进行形式化的描述：

注：表示标签为a的节点的集合，示标签为b的边的集合，表示标签为a的节点属性的集合，表示标签为b的边属性的集合。

1.3数据迁移的设计与实现

由于银行的金融数据是存放在关系数据库中的，所以为了借助图数据库对银行金融数据进行分析，在建立好数据模型后，需要将关系数据库的数据向图数据库进行迁移。在这个过程中，需要建立从银行关系数据库模式到金融图谱数据模式的映射关系，并根据映射关系进行数据转换，得到对应的金融图谱实例。数据转换的流程图如图3所示，具体步骤如下：

步骤1：从银行关系数据库中抽取相应数据，生成6张中间关系表，如图1所示，包括银行信息表，客户信息表，存款账户表，贷款信息表，交易信息表和担保信息表。

步骤2：将银行信息表、客户信息表和存款账户表中的每一条记录作为一个节点，为每个节点加上一个相应的标签，即银行、客户或存款账户，并将记录的属性值作为相应节点的属性值，即得到金融图谱中的节点数据。

步骤3：将贷款信息表、交易信息表、担保信息表中的每一条记录作为一条边，连接相应的节点，为每条边加上一个相应的标签，即贷款、交易或担保，并将记录的属性值作为相应边的属性值，即得到金融图谱中的贷款关系、交易关系和担保关系的边数据。

步骤4：将客户信息表与存款账户表做自然连接，得到表示客户与其存款账户之间对应关系的中间表。将中间表中的每一条记录作为一条边，连接相应的客户和存款账户节点，为每一条边加上“对应”这一标签，即得到金融图谱中对应关系的边数据。

步骤5：选择客户信息表中的证件号码、控制人证件号码、控制类型等属性，得到表示客户之间控制关系的中间表。将中间表中的每一条记录作为一条边，连接相应的客户节点，为每条边加上“控制”这一标签，并将记录的控制类型属性值作为相应边的属性值，即得到金融图谱中控制关系的边数据。

步骤6：将上述节点数据和边数据导入图数据库。

至此我们完成了金融图谱的构建，用户可以通过金融图谱对金融数据进行分析。

下文将结合现实中的两个金融分析模型来详尽介绍金融图谱分析模块。

2、金融图谱分析模块

在金融图谱分析模块，我们可以根据银行具体的业务需要建立相应的分析模型，然后借助于图数据库在模式匹配方面的优势，采用适当的算法在金融图谱中进行查找。银行海量的金融数据给银行以及银行监管机构的数据分析部门带来了巨大的挑战，而借助于金融图谱分析模块，我们可以全面而有效的分析查找出金融数据中存在的金融风险，从而更好的服务于银行的风险防范工作和银行监管部门的宏观决策。

2.1、分析模型的设计与实现

对于具体的银行业务，在分析过程中的思路是：将业务中所涉及的实体抽象为图中的节点，实体之间的关系抽象为图中的边，然后根据业务需要，对节点和边添加一定的约束条件。以查询两个账户之间交易金额大于某个数值的交易为例，该实例可以抽象为（节点:账户a）-[关系:交易]->(节点:账户b)这样一种模式，然后添加对交易金额的限制。对于其它更加复杂的业务，最终也可以抽象成类似的模式。然后可以采取图查询或图遍历的方式在整个金融图谱中进行模式匹配，查找出包含该模式的所有实例，并进行可视化展示。

金融图谱分析模块可通过以下几个步骤来实现：

步骤1：了解银行业务，分析其所需查找的分析模型。

步骤2：根据步骤1中的分析结果，将分析模型中的各个部分与图数据模型建立映射。

步骤3：根据步骤2中的映射，建立图数据库中的逻辑模式。

步骤4：根据步骤3中的逻辑模式，采用适当的查询方式或者设计合适的算法进行查找。

步骤5：根据步骤4中的结果，在后台进行处理，用于前端可视化展示，并进行保存，以供重复利用和分析。

2.2、具体实例

接下来结合两个具体的金融分析模型来阐述在进行金融图谱分析时所采用的两种不同的方式。

2.2.1采用图查询的方式实现消费贷款违章进入房地产行业模型

在这一分析模型中，我们采用图数据库的声明式查询语言来进行查询，具体流程图如图4所示。具体地，为方便进行说明，以neo4j这一通用的图数据库所支持的查询语言cypher来进行描述。如若使用其它图数据库，可采用相应图数据库所支持的声明式查询语言来进行查询。

该模型的具体实施方式如下：

步骤1：了解银行业务，分析其所需查找的模型。对于“消费贷款违章进入房地产行业”这一模型，它在银行的业务中反映的是，银行向个人客户以消费贷款的形式发放贷款，个人客户在进行一笔或多笔交易后，将这笔贷款资金用于购买房产，也即消费贷款资金流入了房地产企业的账户中。

步骤2：根据步骤1中的分析，将分析模型中的各个部分与图数据模型建立映射。在“消费贷款违章进入房地产行业”这一分析模型中，主要涉及有银行、客户、存款账户三类实体和贷款、交易、对应三类关系，分别对应于图数据库中的三类节点和三种关系。而且在这一模型中，企业只能是房地产企业，交易的金额和时间相对于贷款的金额和时间都有一定的约束条件。

步骤3：根据步骤2中的映射，对于“消费贷款违章进入房地产行业”这一模型，在图数据库中可建立如下模式:

（节点:银行）-[关系:贷款]->(节点:账户a)-[关系:交易]->(节点:账户b)<-[关系:对应]-(节点:企业)

在进行查询时，还需要对该模式添加一些约束，例如在交易金额上，交易的金额不得大于贷款金额的1.2倍，不得小于贷款金额的0.8倍。在交易时间上，交易时间必须在贷款发放后的一周以内。而且，企业节点的名称中需要包含“房地产”字样。

步骤4：根据步骤3中设计的逻辑模式，采用图数据库neo4j的cypher语言来进行查询。具体的查询语句如下:

matchp=(:银行)-[dk:贷款{贷款类型:“消费贷”}]->(ckzh:存款账户)-[jy:交易]->(:存款账户)<-[:对应]-(c:客户)

wherejy.交易金额>=dk.贷款金额*0.8andjy.交易金额<=dk.贷款金额*1.2

andjy.交易日期-dk.贷款实际发放日期<7andjy.交易日期-dk.贷款实际发放日期>0

andc.客户名称contains“房地产”

returnp

在neo4j中执行这一语句，即可得到金融图谱中消费贷款违规进入房地产行业这一模型的具体实例。

步骤5：根据步骤4中得到的结果，对数据进行处理，用于前端可视化的展示。并将该模型的所有实例以字符串的形式存储到关系数据库中，以供重复利用和分析。

采用声明式查询语言进行查询，其优势在于：声明式查询语言的设计简便，直观，特别是对于结构较复杂的模型，只需要以图数据库能执行的方式设计出来对应的模式即可。对于其中的具体实现细节不需要开发者去了解，图数据库都会自动完成。缺点是在数据量十分庞大的时候，这种透明的查询方式的效率会大打折扣。

2.2.2设计图遍历算法实现担保环模型

对于担保环模型，重中之重在于担保环的查找。我们同样可以采用4.1中所述的图查询的方式进行查找。具体实施方式如下：

步骤1：了解银行业务，分析其所需查找的模型。对于担保环来说，在银行的业务中反映的是企业之间相互担保或连环担保而产生的特殊利益体。

步骤2：根据步骤1中的分析，将分析模型中的各个部分与图数据模型建立映射。在担保环中涉及的主要有客户这一实体和担保这一关系，其对应于图数据模型中的客户节点和担保关系，且要求担保链上的起点和终点一致形成一个担保环。并且业务中关注的是这个担保环的长度和担保环上所有担保关系的总担保金额，所以需要提取担保关系中的担保金额。

步骤3：根据步骤2中的映射，对于担保环模型，可在图数据库中建立如下模式：

（节点:客户a）-[关系:担保]->(节点:客户)-[关系:担保]->...->(节点:客户a)

在进行查询时，为了使担保链形成一个环，还需要添加约束，具体为担保链上的起点和终点应一致且其它节点应互不相同。

步骤4：根据步骤3中设计的逻辑模式，采用图数据库neo4j的cypher语言来进行查询。为行文方便，这里给出三个节点担保环的cypher查询语句（更多节点的担保环的查询语句可参考该语句写出，这里不再赘述）：

matchcircle=(s:客户)-[:担保]->(n1:客户)-[:担保]->(n2:客户)-[:担保]->(e:客户)

wheres=eands<>n1ands<>n2andn1<>n2returncircle

步骤5：根据步骤4中得到的结果，对数据进行处理，用于前端可视化的展示。并将该模型的所有实例以字符串的形式存储到关系数据库中，以供重复利用和分析。

但是，在担保环模型中，采用图数据库支持的声明式查询语言进行查询的方式也有这极大的弊端：

（1）查询方式不灵活，对于每一种长度的担保环，在查找时都需要编写一个查询语句。

（2）当担保环超过一定长度时，其查询语句会变得愈加繁琐，并且图数据库对查询语句的长度也有一定的限制，超过一定长度则无法执行。

（3）最重要的是，在使用查询语句查找担保环时，对于每一个环，环中每一个节点的遍历都会得到这个环。以3个节点的环abc为例，在查找过程中会被遍历三次，分别为：abc，bca，cab。这就造成了大量的冗余计算，从而使查询效率大大降低。

所以在查询担保环模型时，我们设计了如下图遍历算法，算法的流程图如图5所示，具体步骤如下：

步骤1：调用图数据库提供的api根据具体的标签得到所需遍历的全部节点；

步骤2：对步骤1中得到的所有节点逐个进行遍历；

步骤3：针对步骤2中遍历的每一个节点，进行以下操作：

步骤3.1:将此节点id进行保存，得到一个遍历过的节点的id的集合；

步骤3.2:将此节点作为遍历的起始节点，调用图数据库的api得到起始节点的入度和出度，判断其中之一是否为0，若为0则退出这个节点的遍历，因为不会有包含这个节点的担保环。

步骤3.3：比较起始节点的入度和出度，若起始节点的出度比入度大，则将起始节点作为担保环遍历的第一条边的尾节点，且担保关系按入边的方式，即以当前结点为尾节点不断沿着担保关系的反方向遍历；若起始节点的出度比入度小，则将起始节点作为担保环遍历的第一条边的头结点，且担保关系按出边的方式，即以当前结点为头结点不断沿着担保关系的方向遍历。

步骤3.4:将每个节点遍历得到的担保环加入最终的结果集。

其中，对于步骤3，遍历的规则设置如下：

(1)采用深度优先搜索策略；

(2)根据步骤3.2中的结果，设置关系的遍历规则，即担保关系遍历的方向采用入边或是出边；

(3)为防止节点的重复遍历造成的冗余计算，设置遍历的唯一性规则为节点不会出现在之前路径出现过的地方；

(4)查询的担保环的长度由用户输入；

(5)对于一个环，对环中每个节点遍历时都会遍历得到这个环，这会浪费大量资源和时间。对此我们自定义一个剪枝规则，在遍历时，当遍历的节点是在步骤2中进行保存的遍历过的节点时，我们就退出遍历回溯到上一个节点再继续遍历；

(6)遍历的终止条件为遍历的路径终点是路径的起点。

这种方式的优势在于，对于每一种模型，我们可以灵活的设计其遍历方式，从而减少对不必要节点的遍历，极大地提高效率。但也存在不直观，相较声明式查询语言更复杂的缺点。

至此我们对数据库中的所有担保环数据进行了全局查找。银行以及银行监管部门可以对担保环进行逐个分析，以查找出其中可能隐藏的金融风险。

以上实施例仅供说明本发明之用，而非对本发明的限制，有关技术领域的技术人员，在不脱离本发明的精神和范围的情况下，还可以作出各种变换或变型，因此所有等同的技术方案，都在本发明的保护范围之内。