图计算引发银行资产负债管理变革

孙宇熙 Ultipa Graph创始人&CEO

一、商业银行流动性风险管理与算力要求

（一）商业银行流动性风险管理要求

首先从商业银行的流动性风险管理切入。下图是银保监会2018年5月份的颁布的文件，文件提到要压实五方责任（5个部门），构建九大管理程序，19个监管监测指标（包括5个流动性识别计量，5个监测指标，以及9个市场流动性指标），管理信息系统7个要求。这是一个相对比较庞大的体系。

（二）算力水平的作用

在这个体系当中，有很多指标需要计量，算力将发挥非常关键的作用。

前面提到中国银保监会与央行的要求。另一方面，欧盟和英国，例如EBA和英格兰银行 PRA部门都在寻求比流动性覆盖率更严苛的指标。例如EBA致力于定义高质量的流动资产和不同类型存款之间的动态平衡，PRA考虑是否要求额外的流动性作为系统性的补偿LCR。如果这是一张比较完整的算力图，从最上面监管的指标向下发展，例如从Basel II开始的流动性风险的监测工具，到日间的流动性管理的要素，以及部分监测指标的管理。最下层是应急的预案压力的测试。

（三）数据穿透对算法的要求

对于银行，特别是资产负债管理作为综合规划协调的部门，一方面有外部监管的压力，另一方面有内部增效的内动力。我们把资产负债中指标的计量按照不同的算力的需求，分成了点、线、面、体四方面。但有6个维度是确定的、需要做到的，即快、稳、准、深、多、溯。

指标的计量要足够快，在有限资源的情况下做到实时性更佳。在数据治理的基础上的计算可靠精准显然是有重大意义的。指标的计量当中，怎么做归因分析，多维的数据之间怎么深度下钻、穿透才能完成深度、实时的追溯，对上述问题的研究也是有重大意义的。以存款余额为例，传统的深度分析是对于离散的、不同类型的存款账户层层追溯。在资产负债层面上汇总到对公存款、零售储蓄存款等作为第一步，在存款的余额再下钻，按照分行、支行、团队的维度，客群按照客户经理的维度，拆分到更明细的数据，这是线性的计算方式。如更复杂的指标，涉及到复杂的网络化多层嵌套关系，例如像RAROC，可以有效帮助商业银行衡量营业的状况，例如营业收入，利息的净收入、非净息收入等。但实际上数据的内容是多维关联的。而LCR的计算几乎涉及商业银行的所有数据，从零售到对公、同业，计算量非常巨大，我们称之为高维计算，在多维和下钻的基础之上，包括其他时间和空间，例如LCR计量中未来30天现金的净流出。从点线面体，即从个体到线性的关联到网络化的关联，直至多维的，包括时空信息的高度关联的4步，这4个步骤对于算力的需求实际上是逐级增加的。

二、图数据库的原理与作用

（一）传统数据库的局限

在数据分析过程中，传统的数据库，或IT的框架难以解决指标计量当中的快、准、稳、深、多、溯的问题。例如传统的数据库当中用二维的表关联作为典型的表连接，但表的关联十分复杂，多表之间的关联不可避免的会造成计算性能的指数级下降与时耗的剧烈增长。因此，我们提出改变的方式是从图计算、图数据库的角度看，把数据建模成图。

如下图黑框当中，将不同的传统数据库二维表当中的实体和关系抽离，再构造新型的数据之间的关联网络，例如账户、卡、交易、设备与不同的实体类型，以及它们之间同构或者异构的实体之间的关联关系，这是一种构图的方式，但不是唯一的。传统的数据库中只要做多表关联（table-join）就可能会出现笛卡尔集的数学上面的算法复杂度高企的问题，这也会导致效率成为巨大的门槛。在实验中，如MySQL跟实时图数据库间在面对同样数据量级、硬件基础的条件下，性能比较可以发现：从2个table-join到5个table-join时，随着计算与查询深度的增加，两套数据库系统间的性能差异出现指数级增加。深度为1时，两者并没有本质的区别，但从深度2（2-table-join）开始，性能出现十几倍到上千倍，甚至在深度为5层时超过万倍的差异。如果将计算结果进行直观的对比,Y轴是计算的时耗，实时图数据库用时几乎是完全平稳的，是亚线性的；而关系型数据库随着查询的深度（维度）的增加，时耗以指数级方式剧烈增长，直到不可承受为止，这就是银行业中有大量批处理操作的原因。基于传统的数据库和数仓基础上，任何复杂的操作几乎都是T+1甚至T+N的。在复杂、大量的数据情况下，MySQL类的关系型型数据库无法高效完成计算。银行业，尤其是资产负债部门，在通过SQL存储进程对各类指标计算很缓慢的时候，也很难变得稳定，甚至很难做到准确。

（二）数据库发展变革

回顾过去近40年的时间，如果从IT基础架构的底层看，数据库系统体系架构经历了从关系型数据库到大数据，再到快数据，直至深数据（图数据）的演变。今天金融行业个业务部门的需求，从技术应答的角度上讲，应该归纳为深数据和图数据的挑战，也是刚才讲到的从由点及线及面最终到体的挑战。点是离散的，线能完成一些简单的收入分解构成分析，但是到了更复杂的面计算、体计算，例如流动性覆盖率，复杂的缺口分析，压力测试、收入模拟等工作，应该是由新型图计算等技术来更好地回应业务挑战。在过去十几年的发展中，趋势是从静态时点的计算道动态的、面向未来的计算方式，也代表底层数据库架构大型变革的时代的到来。

（三）图计算引发流动性风险管理变革

在这里分享一下我们在招商银行进行的流动性风险管理图中台项目，是基于图计算引擎与图数据库实现的。在今年7月，招行获得了《亚洲银行家》颁发的流动性风险管理成就奖。下面这张示意图是3D可视化的业务人员实时交互的界面，其功能十分强大。例如LCR指标，传统的基于Oracle的现金流引擎的做法是T+1的计算模式，我们把它做成了实时反馈。

原来Oracle进行全量的LCR数据计算中，大概需要3-4个小时左右，我们一般情况下一秒钟就可以出结果，也可以为资债管理的三性（流动性、盈利性与安全性）的目标提供非常精准的数据支撑。

在其他方面，例如LCR的贡献度变化的归因分析，我们有多个维度的归因分析，客户维度，包含客户每个账户下的每一笔交易，每一笔交易当中的每一分钱，都可以精准的计量。另外包括行业的维度，分行的维度，包括LCR的144个子项的维度，以及总期限、总结构变化的实时化归因分析。

在反向追溯的时候，我们可以知道LCR变化是由哪个客户的哪个账户，哪一笔交易，途经了哪个分行，哪些LCR的子项，最终汇总到流动性覆盖率指标。例如LCR变化贡献度中的正向50、负向50的客户排名。这样的计算规模与复杂度，用传统的Oracle数据库是做不到的，因为这要对全行所有的数据，无论是零售、对公还是同业，进行综合排序和反向追溯。如果LCR指标的计算需要3-4个小时，进行刚才描述的贡献度变化的归因分析大概可能需要至少10倍以上的时间，传统数据库中这可能是T+2也无法完成的工作。但通过实时图计算是秒级完成的，最终结果是以高度可视化的、可交互的形式展示的，并且在整个操作过程当中是白盒化的方式呈现的。我们认为这是对于流动性风险管理，以及更加全面的资债的核心指标管理和风险管理是一种创新模式。

（四）图计算在资产负债管理的实际应用

通过实时图计算解决的痛点和难题有6个。第一是实时化的计算的能力，另外一方面是图算法可追溯、可解释、可审计，这对于银行来说是十分重要的，包括如何去防范模型的风险，对白盒化的需求以及归因分析，变化贡献度分析，追溯到每笔的逐笔交易的追溯与计量等。这种实时化、深度穿透的计算能力可以为银行的核心指标计量、分析、报告提供底层支撑。包括怎么压测，怎么进行情景模拟。例如在流动性当中监管定义了15个场景，但将LCR拆成144个子项以及多个维度进行组合后，形成的压测场景可以是百万级以上的。3D可视化的方式也让整个分析变得更加直观，带着上下文的分析也是更有意义的。在实现这些的基础之上，最有趣的是从IT运维角度上讲，用非常小的集群，与传统动成百上千台机器的大集群模式是非常不同的，实时图计算所需硬件的规模只有原来的10%~20%，那也意味着我们运维的成本可以大幅降低70%以上。

最后，图计算赋能资产负债管理核心指标的计量及全面风险管理。在下图中自下而上总共分为5层，涉及到流动性风险管理到资产的负债管理，到信用风险管理，包括财务与管理会计、综合管理等方面。

从基础信息开始，如何进行信息分类，怎么进行计量与测算，到如何测算与模拟，有一些指标如何模拟分配等问题都可以得到解决。例如RAROC、EVA、CAR、ECR都是非常典型的指标。

最终如何分配和控制，例如内部产品的定价，客户经理绩效的考核，这些事情在商业化银行当中，都是资产负债管理比较重要的工作。我们的系统的主要工作是完成上述指标的快速准确计量后，如何赋能业务、更好帮助业务部门对整个银行的内部管理提效，这是图计算带来的非常典型的，有颠覆性的效果。

对于银行业来说，实时图（计算）的性能有非常明显的优势，不仅仅是时效性与深度下钻等维度性能，还包括白盒化、可解释，以及可以用更小的集群的部署规模来带来更高效的计算，这显然也具有碳中和的意义。

撰稿人：白峻赫

责任编辑：李瑞钊

来源：TGES2021（第十七届）中国金融风险经理年度总论坛：

资产负债管理与流动性风险管理（12月）