联系我们
如您对参会报名、网站使用、内容发布有任何疑问或改进意见，请随时与我们进行沟通！
客服企业微信
期待您的宝贵意见
刘学锋，中国银行司库高级经理
本次与大家分享的是《商业银行资产负债领域数据模型的设计与实现》，重点是数据模型，专注于资产负债业务领域。这里的模型，不是Model，而是 Module，即数据模型，在系统建设上通常称为“组件”。Module可以中译为“组件”，即数据组件。这里讲的是专门为资产负债管理设计的数据组件或数据模型。
内容按以下顺序来讲，先讲概念模型，然后是业务逻辑模型和领域数据模型，最后是物理模型。模型讲的再好，或者设计的再好，最后都要实打实的设计出来。可以把模型想象成一个魔方，把数据变成数据魔方，可以随意旋转、透视。
既然讲资产负债领域的数据模型，那么概念模型是什么？概念模型实际上就是资产负债管理。资产负债管理，是综合平衡量、价、险三要素，实现安全、流动、效益三性统一。量、价、险三要素中的价格，包含了成本和利润，是本利和，所以通过调节量、价、险三要素，即可达到资产负债管理的目标。
英文ALM是资产负债管理的缩写，BSM是资产负债表管理Balance Sheet Management的缩写。资产负债管理的目标和措施手段要通过资产负债表去实现。比如增加一笔贷款或者吸收一笔存款，最后会体现在资产负债表上。再比如市场做了一笔融资或投资，最后都会在资产负债表上体现出来。既然都在资产负债表上体现出来，那么就可以通过业务交易，去实现资产负债表的扩表（扩张）或者缩表。
概念模型，主要通过量、价、险三要素去实现资产负债管理的目标。
量和价的概念通常比较清晰，比如各种财务报表，特别是财务概念的资产负债表，一边是资产，一边是负债和所有的权益，另外还有表外产品，有量也有价，本、利都会在财务报表上体现出来。
下面主要讲一下商业银行资产负债业务中的风险。关于风险，财务概念上的资产负债表是看不出来的，所以需要扩展一下去看风险。商业银行资产负债业务中的风险，可以分成两大类：信用风险和错配风险。
首先是信用风险，做交易首先需要有客户即交易对手，所以信用风险是首先要面对的一类风险（包括交易对手风险和集中度风险）。选择和谁做交易、不和谁做交易，这是交易对手风险。叙做的交易是不是过分集中于某一个交易对手，或者某个产品、某个期限、某个货币上，属于集中度风险。
其次是错配风险，是由于错配所引发的各种风险。错配风险分为三类：
一是货币错配。指资产端和负债端使用了不同的货币，比如只有人民币存款，却发放了美元贷款，这属于货币错配。
二是利率错配。指资产端和负债端分别使用了浮动利率和固定利率，或者使用了不同的利率基准。比如用三个月浮动利率融入的资金，去支持一年期的贷款，属于用浮动利率支持固定利率的交易，这是利率错配。
三是期限错配。是指资产端和负债端交易的时间期限不一致，包括原始期限错配、剩余期限错配和重定价期限错配。
原始期限是原始状态的期限，比如客户今天存了一笔钱到明年的今天，这是一年的时间，那么原始期限就是一年。银行用客户这一年期的存款去支持十年期的贷款，这是原始期限错配。
剩余期限，是指年初已经做的交易，从今天（报告日）看，它距离到期日还有多少天，也叫“到期期限”，或者“流动性期限”。
重定价期限。浮动利率和固定利率的交易都涉及重新定价，比如和客户做一笔交易时，下一个利率变动日的利率是多少，需要和客户事先做协议确定价格，特别是浮动利率存款和浮动利率贷款，很明显涉及到重新定价期。重新定价期是指从报告日开始算，还有多久利率有可能变动。到了重定价日，不管利率变与没变，都需要刷新（更新）一次利率。
货币错配会产生外汇风险敞口，利率错配和重定价期限错配会产生利率风险敞口，这两类风险敞口来自市场价格变动，因此称为市场风险。
原始期限、剩余期限错配会产生流动性资金缺口（包括日间头寸缺口和未来到期资金流缺口），形成流动性风险。
比如一笔资金到期了，资产端和负债端不匹配了，资金多了会出现资金淤积，资金少了会出现资金短缺，我们把它称为流动性风险。通常认为客户大量提款会造成资金短缺，其实资金太多了淤在手里，没有利息收入而一直有利息支出，这也是一种流动性风险。资金淤积和资金短缺这两种状态，都属于流动性风险。
资产负债管理活动贯穿于资产负债表内和表外，既追求绩效（KPI），又关注风险（KRI）；资产负债管理需要控制信用风险，规避市场风险，保障资金流动性，再此基础上实现盈利目标。
这就是资产负债领域中的概念模型，既要看到量，又要看到价，还要看清风险。
下面要延展到数据层面，我们从顶层的概念往下拆解，量和价比较清晰，关键在于险。后续在数据获取和展开的时候，会有更多的说明。
我们实际上是通过资产负债表去实现资产负债管理，这既是业务的逻辑，也是数据透视的逻辑。
上图是资产负债表中的资产负债、业务集中度、资金储备之间的业务逻辑。我们需要盯住资金缺口，关注集中度，做好资金储备。
首先要盯住资金缺口。如果把每笔资产都视同一辆车在路上行驶，按行驶里程供油，油可以理解成负债。假如这辆车行驶500公里，油箱一次性加满500公里的油，相当于固定期限匹配了。如果油箱比较小，每100公里加一次油，就是以短养长，会出现资金缺口，需要及时弥补。
其次要关注集中度。一是交易对手集中度，二是产品集中度。比如资产端是否过度集中在某些贷款、某些债券上，负债来源端是否过度依赖某个存款大户（某个企业的存款）、央行的资金，或者过度依赖市场，都是非常危险的。集中度相当于车上的温度表，温度太高会影响行车安全。
最后要关注资金储备。商业银行司库，即商业银行的资金部，负责资金供应（储备油量），银行这辆车行能行驶多久多远，与资金密切相关。
这张图把银行比喻成一辆车，司机需要随时关注里程表、温度表、油量表。
在数据处理上，要计算出资产、负债的业务缺口，还要计算出大宗交易的缺口。业务缺口是资产减去负债，资产大于负债是正缺口，资产小于负债是负缺口。
作为油库的司库（即资金部），需要有足够的资金，对资产负债业务到期时所产生的资金缺口要及时弥补。资金多的时候要及时运用出去，或者在资产负债表扩张的时候为新增业务提供资金。如果通过普通负债（如存款）获取的资金不足，就需要及时从货币和资本市场中融资。
图中最左端这一列，是总行的视角，境内、境外机构尽收眼底。
资产负债表需要从量、价、险几个方面去看，有四个观察维度。
传统财务视角看到的资产负债表是两个维度：产品维度和货币维度。
资产负债表内的资产、负债（如存款、贷款、投资），所有者权益，以及表外衍生品，都属于产品维度。
货币维度，国内商业银行主要是人民币，如果是全球化的商业银行，会有很多外币，如美元、英镑、欧元、日元等。国内规模较小的商业银行，如果不做外币业务，资产负债表是单货币的，就不需要货币维度。但是多数银行需要货币维度。
从管理会计视角看，还会有一个期限维度。前面讲资产负债错配的时候讲到了三种期限，包括原始期限、定价期限和到期期限。如果资产负债表中看不到期限维度，就看不见错配，看不见错配（即所谓的不匹配），就看不到风险。因此资产负债管理当中的量、价、险，如果只能看到“量”和“价”，而看不到“险”，这在资产负债管理的框架下，就不是“资产负债管理”，而是“财务管理”。
完整的资产负债管理还要考虑另外一个维度：风险资本维度。众所周知，资产负债表受资本约束，核心资本是8%，以及更多的资本要求（国内商业银行资本充足率多数超过10%）。风险资本维度比较偏重信用风险（约束的是资产端）。
这四个维度，构成了领域数据模型的数据维度框架（如图），我把它称作“4 Dimension Data Module for ALM”。
这四个维度可以两两组合。产品维度和货币维度组合，是从财务会计的视角看资产负债；如果把期限维度加进去，就是管理会计视角的，一共三个维度；再把风险资本维度加进去，就是全视角的资产负债管理，实际是一个四维度的数据全景图。
这张图承载了很多内容。资产负债管理（ALM）包括了融资、定价、资本与市场风险管理。资产负债表（BS）则承载了价格数据和金额数据。价格数据包括买价、卖价，主要是利率、汇率，还有一个看不到的费率（费率信息通常会在资产负债表中通过手续费的收支体现出来）。至于金额数据，可以分成余额和发生额，包括基期数据和报告期数据。当前这一期叫报告期，前一期叫基期，在两期数据相比较时，需要这方面的数据。
需要特别提示一下产品维度。现在的FTP绩效考核，将产品分客户、分部门、分条线，其实都是在细分产品维度。理论上讲，一笔银行存款或贷款，可以视同是某个机构、某个部门、某个客户的存款或贷款，都应该归类于产品维度项下。否则，在搭建资产负债数据模型时，会出现数据维度混乱。比如，会有日期、货币、机构、部门、客户维度，还有买家、卖家维度，以及利率、汇率等等维度。
这些细分维度，每一个都相当于数据库的一个字段或者Excel表的某一列。
资产负债领域的这些细分数据完全可以归类于图中的四大维度。四大维度是围绕量、价、险的，指向资产负债管理的目标（安全性、流动性和效益性的三性统一）。
维度与视角的总结：
商业银行的资产负债业务数据可以归纳并划分为货币、产品、期限、风险四个维度。货币维度包含本币及各种外币；产品维度包含资产项目、负债项目、所有者权益及表外项目（机构、部门、客户通常是产品的持有者和所有者，因此归入产品维度下）；期限维度包含原始期限（起息日至到期日之间的天数）、到期期限（报告日至到期日之间的天数）、重定价期限（报告日至下一利率重订日之间的天数）；风险维度包括信用评级、交易对手等。
管理商业银行的资产负债表，有三种不同的视角。即，财务会计视角、管理会计视角、风险资本视角。视角不同，管理难度也不同。在传统财务会计视角下，仅会从货币和产品两个维度去管理资产负债表，不考虑期限和风险维度，难度不大。在管理会计视角下，则会从货币、产品、期限三个维度去管理资产负债表。由于增加了期限维度，管理难度加大。如何管理期限错配、利率错配、货币错配，规避市场风险，考验管理者智慧。风险资本视角下的资产负债表管理，是四维度的。除了货币、产品、期限三个维度外，需要从风险维度去考量。如，贷款质量，债券评级，交易对手等。由于增加了风险维度，资产负债表开始承受资本约束。如何在资本约束下管理资产负债表，既考验管理者智慧，也考验监管者智慧。
用资本约束资产端，就能约束规模扩张。这是因为资产负债表的平衡等式是“资产 = 负债 + 所有者权益”，只要约束住了资产端，就能约束住另一端。所以风险管理比较侧重于资产端的信用风险管理。
构建方法是基于四维度的数据模型进行的。有了模型和清晰的数据，把数据按照四个维度归集好之后，只需要找到一个比较好的工具去落地实施。
挑选了一下市场上比较好的工具。最初最看好的是Tableau，非常棒的工具。但是在国内，购买有一定的困难，所以将需求降级，改为自主开发。提交了需求之后，发现做出来的东西更像是一个报表，索性把开发出来的东西变成了ETL工具，用来完成领域数据模型的数据抽取、转换，然后将数据上载到微软的Excel，在EXCLE上最终实现。
鉴于Tableau和Power BI的市场领先地位，两个工具都是可以采用的。但考虑到购买成本和用户的使用习惯（学习成本），最后还是回归到Excel。从Excel’2010版本开始，EXCEL的数据透视表（Pivot Table）提供了切片器功能，切片器是传统筛选器的一种升级和替代。有了切片器之后，Pivot Table变成了很好用的分析工具。最终基于微软的数据透视表Pivot Table构建了领域模型。但目前为止，由于数据源的原因，只实现了产品、货币和期限三个维度的模型，随着数据的丰富和可获取，可以把四个维度的数据全部纳入。
思路归纳：首先，模型应能够像魔方一样，可以旋转看全景，也可以透视看细节。其次，对用户来讲，最重要的是要高效，数据的获取、查看、计算可以自助完成。再次，模型要易用、易展。易用，指拖、拉、拽就能完成，不需要去开发程序（低代码、零编程）；易展，指一旦有新数据或者新想法，就可以全自动地在模型上展现出来。例如已经有了三个维度的数据源，当第四个维度的数据源纳入之后，模型不需要改变，就能自动看到。模型应该是一个数据魔方，能够任意切片、旋转、透视，数据即时呈现。
为了实现上面的数据模型，把商业银行的业务系统做了框架性的归纳，按照业务流程和业务逻辑，形成下图。
先看一下商业银行的业务流程（业务逻辑）。当客户到商业银行之后，首先会登记客户信息CIF（Customer Information Facility/File，Facility指的是业务系统，File指的是形成的客户信息文件）,然后通过柜台（或者互联网客户端）叙做交易（TIF），银行的后台则会做相应的账务处理（AIF）。这样，逻辑上讲，一笔交易就完成（结束）了。但是从银行的管理视角来看，成千上万的客户做了N多笔交易，需要知道哪一笔交易赚钱，哪一笔交易不赚钱。如何获取这些信息，并做归纳、分析和透视，这是很重要的。因此在管理层面还要有管理信息，即管理驾驶舱。把这一部分称为MIF,其中的M，指的是管理（Management）。需要形成领域数据模型，为管理驾驶舱服务。
因此，支撑商业银行业务运营的IT系统通常包括：1. 存储并提供客户信息的客户服务系统。2. 处理各类业务交易（存款、贷款、汇款、资金交易等）的交易处理系统。3. 负责资金清算与会计核算的账务处理系统。4. 负责业务报表和数据分析的管理信息系统。在集中的一体化IT业务系统中，以上各类系统则做为一体化系统的子模块存在。
依据商业银行的业务系统（模块）分类，商业银行的业务数据包括：1. 客户信息（CIF），如个人客户、公司客户、机构客户、其它客户。2. 交易信息（TIF），包括日期、产品、货币、期限、金额、价格等。3. 账务信息（AIF），包括会计核算及总账科目信息。4. 管理信息（MIF），包括规模、结构、KPI、KRI等。
这张图，很像汽车的方向盘。它是CIF、TIF、AIF、MIF在业务（B）、信息（I）和系统（T）三个层面的深度融合。这个构架，我称其为“BIT构架”，即BIT Architecture for Data-Driven Banking。
现在大家都在讲银行数字化转型。那么，什么是数字化转型？目前为止，并没有统一的定义或者说法。我的理解是，只要实现了数据驱动，能够通过数据去驱动银行的经营和决策，就实现了数字化（转型）。
从上面的BIT构架图，可以看到一个业务交易流程（B）、一个数据信息流程（I），以及相应的底层系统（T）分布。其中的数据信息（I），主要服务驾驶舱，客户信息、账户信息和交易信息都要反映出来。
BIT是BI和IT的组合，“I”在其中有两个。BIT在这里解释成“Business + BI + IT System”，即“业务 + BI + IT系统”。BI中的“I（Intelligence）”主要用来发现数据价值，是数据价值链中的“I”。IT中的“I（Information）”，提供数据信息服务，是数据供应链中的“I”。因此，负责数据供应链的IT，与负责数据价值链的BI，通过数据去驱动业务运营（B）,就是数字化（BIT）。
这就是我理解的数字化的商业银行运营，契合了Bit（比特）的初始含义。
比特（Bit）是对数字化的初始技术描述，是指把所有的信息都变成比特（Bit）存储起来。在万物互联的物联网时代，数字化已经是（技术层面的）自动化、（数据层面的）信息化、（业务层面的）智能化的三合一。
这个BIT构架，涉及的前三类数据信息（客户信息、交易信息、账务信息），通常都会有所体现。第四类MIF信息，往往会被忽略。在设计系统构架的时候，一定要考虑这四类信息（包括CIF、TIF、AIF和MIF）。如果没有MIF(管理信息),系统建设就会缺少龙头，就很难去把其它三类信息（CIF、TIF、AIF）集成在一起。
获取数据之后的数据信息处理，涉及到数据口径。
商业银行的业务数据透视分析应基统一的业务数据标准。业务数据标准（即数据的业务标准）是企业数据标准的一个关键子集，是指业务数据的分类聚合标准，也称业务数据口径。业务数据标准是商业银行管理信息系统（MIS）的通用语言。没有业务数据标准，会出现数据沟通理解、数据ETL和数据聚合困难，产生数据孤岛和数据垃圾。
获取一批数据之后，首先需要做分类聚合，在数据处理上做编码。比如为了便于计算机处理，对于一笔存款或贷款，通常并不使用汉字记录，而是做编码，因为存款、贷款也分很多种。比如，存款分为定期存款、活期存款，对公存款、对私存款，有金融机构的存款，也有行政事业单位的存款，都需要做不同分类。
总体来讲，分类是林林总总、千千万万的，行业编码也好，内部统计编码也好，按照大类分，主要包括以下几种：
1.客户码：用于区分不同的客户。客户码最简单的是客户的身份证号，也可以在身份证号基础上再增加其他不同的标识和分类特征。客户有内部客户、外部客户，还有企业客户和个人客户。企业客户的编码和个人客户身份证是完全不一样的。
2.交易码：用于区分不同的交易。第一笔交易和第二笔交易之间应该有区分，否则在数据钻取或抽取的时候就无法追溯，对于已经汇总的数据，则无法向下细分。
3.产品码：用于区分不同的产品。资产负债表内、外的所有产品，比如资产类产品、负债类产品、权益类产品、衍生类产品等。
4.账务码：包括核算码和科目码，用于记录账务信息。账务处理通常分两级，一级是总账，二级是核算码，即总账科目码和会计核算码。会计核算码更细一点，总账码在核算码之上，相当于 N个核算码的汇总（变成总账科目码的一个值）。
5.统计码：用于区分不同的统计项目，记录不同的统计项目口径（也称统计项目归属）。在资产负债管理层面，最常使用统计码，实际上所有的指标都属于统计口径的指标。统计码是按照不同的目的去做聚合分类，所以是按照统计目的做聚合分类的。账务码、产品码、交易码、客户码基本上是不会去按照统计的目的随意分类的，而要严格尊重账务事实去做，只有统计码才可以各取所需，根据不同需要去做不同的归类，也称为不同的口径。
关于“口径”，比如监管的口径、信息披露的口径，还有央行（人民银行）的口径，或者内部管理的口径等，通常是不同的，在编码分类时需要有一定的注意和讲究，特别是不能交叉汇总、交叉分类，除非是统计层面才可以，底层不可以。
业务编码要遵循业务逻辑，采用总、分结构，逐级向上体现子、母之间的多对一汇总关系，避免一对多或多对多的交叉关系。另外，编码新旧不能混合使用，旧编码废弃之后不可再恢复使用。
实际业务中，比如经过多年之后，历史上的一批编码被忘记，新增设的新编码进入电脑系统和旧编码混合在一起，并且系统设计没有做一致性的核对和比对，新旧编码代表不同的账务内容和业务内容会导致数据混乱。
业务数据标准在商业银行业务处理和分析中非常重要。数据口径定义不清晰，新旧数据口径混合使用等，都会导致数据不一致、不可比，进而影响企业级的数据汇总、挖掘和分析应用。
口径标准最主要的是统计标准，统计标准是按照数据流程来分类的。从图中可以看到数据流向。从一个客户进入银行做一笔交易，这笔交易一定会涉及到某个产品，比如存款、贷款，然后到后台账务再到统计，编码同样是按照这个流程。
至于统计，也是随着这几大类去做的，比如机构或客户是一类，还有交易类别、产品类别、会计科目、统计指标。
最后，为了统计和旋转透视，需要做切片筛选。按照用户的需要，比如日期、期限、货币、机构客户等，都是针对前面讲的四个维度的数据做切片。如果把数据模型理解成魔方，那么就是按需做切片。
目前在商业银行里，大家都比较注重报表。其实，报表只是数据魔方的一个“切片”。至于各种统计指标，往往是零散的，因为统计指标通常是基于某一张报表中的数据计算而来的。
数据才是最集中的。切片之后变成的报表就分散了，基于报表之上做出的指标则更零散。报表是碎片化的，各种指标则更加碎片化。
所以，统一的数据思维还要回归到数据模型。只有对魔方中的数据心中有数，才能在需要报表和指标时，即时搞定。
前面讲的维度，最后要落实到物理实施。关于物理实施，可以从以下这张数据表看到数据模型需要的数据，也可以看作是数据结构（Data Structure）。
从表中可以看到数据分成几列，每一列相当于物理数据表的字段。比如对应产品维度的项目，包括资产类、负债类、权益类、表外类。还有期限维度，包括原始期限、到期期限和定价期限。货币维度，包括原币和折币。价格，包括利率、汇率、费率。金额，包括本金和利息。这些就是“量、价、险”。“险”主要体现在期限和货币上。
表中的货币维度，按照统计习惯，既看每个货币的原币，也看折币，折币最常用的是各货币折人民币、折美元，各外币折美元（不含人民币），以及各货币折本位币。本位币是汇率风险管理中会用到的概念，指的是无风险计价货币（某些情况下可以是本国货币）。在汇率风险管理中，本位币是指该货币没有汇率风险。例如人民币可以是中国的本位币，美元是美国的本位币。对于某些亚、非、拉国家货币，在汇率风险管理中，通常使用美元作为本位币。因为全世界的计价货币是美元，美元理论上讲没有外汇风险敞口，因为所有的货币都向美元平盘，它是最终的无风险货币。
前面讲的四个维度和量、价、险，全部通过这张物理表去实现数据呈现。
可以看到期限和价格列有灰色文字，是设计这张表时还不具备的数据。这张物理表最早为流动性目的设计，首先实现了到期期限，也是最重要的一个期限。
另外，关于交易对手维度，由于使用的是Excel去实现的这个模型，受Excel数据表100万条记录的阈值限制，底层交易对手数据的集成和聚合有难度，数据量太大。
除了交易对手这一部分，目前100万条记录的数据表对于统计项目层数据来说，足够用了。除了个别没有上线IT系统的机构，数据模型每天可以看到全球的数据。现在是T+2每天提供数据，即今天能看到前天的全球汇总数据。由于全球24小时的时差，T+2目前是模型数据服务时限的极限，一般很难突破，境内行或者部分海外行倒是可以实现T+1。
想要做到全球24小时覆盖，服务时限做到T+0，需要考虑内嵌到实时的生产系统上。即使是内嵌到实时生产系统上，也可能会有限制。除非是基于集中的全球一体化业务系统，否则，如果是某个时区的机器关机了，也会查不到数据。所以在系统设计时，对资产负债管理而言，T+2基本够用了。
数据透视或者数据展示，是通过微软的Excel实现的，使用EXCEL做模型是免费的。我把模型称为BSM³，英文是Balance Sheet Modeling，Monitoring & Management。
投产的数据模型（BSM³）从规模和结构两个方面呈现商业银行资产负债业务全景，从产品、期限、货币三个维度逐日（T+2）监测资金来源与资金应用。数据模型遵循业务逻辑，由可以灵活旋转的同源多组数据透视表组合而成。主要包括：
1.资产负债分期限业务缺口表（全景表n张，结构表n张）
2.司库大宗资金来源与运用表（分类主题表n张）
3.司库头寸与资金储备缺口表（T日头寸表，储备缺口表）
数据模型（BSM³）从资金运营的角度展现商业银行各分支机构的资金来源与资金运用，揭示资金来源与资金运用的互动和依存关系，动态监测两者之间的匹配情况，关注资金安排的集中度，为商业银行资金运营、流动性管理以及资产负债表管理提供及时有效的信息支持。
资产负债表的设计、日常监控和管理，都集中在上面的图表（Picture）中。目前包括三大类：资产负债业务（里程）表、资金集中度（温度）表和资金储备（油量）表。
资产负债业务（里程）类。涉及业务规模和业务结构。产品结构，资产负债表内外都属于产品，例如存款、贷款、投资、融资、衍生品等都属于产品。期限结构，包括原始期限、到期期限和重定价期限，他们的结构是不一样的。货币结构，能够看到全球汇总之后共多少种货币，境内的货币是多少，海外各个分支机构的货币分布情况，都在表中，一目了然。
资金集中度（温度）类。主要呈现投资、融资是否过度集中。比如，是否过度依赖央行资金、线下同业。这几年国内市场融资（特别是升杠杆、降杠杆过程中的业务），同业的大额票据等，都属于线下同业的交易。同业负债不是直接负债，通过其他金融机构的间接负债是不稳定的，成本也比较高，所以都要考虑集中度的问题。
资金储备（油量）类。主要考虑流动性资金缺口。流动性管理需要去“削峰平谷”，即资金不足时要及时补充进来，资金充裕时要及时运用出去。这里既要关注当日头寸，也要关注司库储备，以应对资产负债业务未来到期时可能出现的资金流缺口。司库储备应能弥补到期资金缺口，避免到期后临时市场融资可能因市场资金紧张而付出昂贵的流动性成本。
资产负债表模型之所以叫Picture，是因为除了目前所列的这些透视角度或者透视表之外，用户可以根据需要，随时通过拖拉拽去任意涂画，自行添加。
上图是模型所展示出的数据。内含切片器，所点即所得。例如需要看某个产品、某个机构、某种货币的数据，直接点击就可以秒级响应，没有任何时滞。因为数据没有超过100万条，效率非常高。目前能够逐日监测数据。保存到模型里的数据通常是月末数据，因为如果Excel表的容量太大（比如超过几百兆）就无法打开。这种情况下，通常需要借助Tableau才可以打开，而且是秒开。
在产品设计的时候，很多IT人员质疑 Excel的效率，说它做不到实时呈现。
其实是能够做到的。为什么呢？
我们在模型设计时，只需要对数据做一下分层即可，让统计项目层数据模型，只针对统计项目做旋转和透视。
一旦要向下一层（比如会计的科目码层、核算码层）或者再向下面的更深层（产品层和交易对手层）钻取数据，可以单起一支程序，挂载在数据模型下面，由这支程序负责下钻。在统计项目层，下钻程序并不常用。一旦触发了下钻程序，它会跳出模型去单独运转，完毕之后把数据返回到统计项目层的数据透视表中即可。下钻程序通常需要耗费大量时间（比如面对的是几十亿、几百亿条记录），除非机器或者计算能力足够强大。集中计算也好，分布计算也好，只要计算能力足够强大，就可以做到。
这里的数据模型，对于普通的中小商业银行已经足够用了。即使是四大行这种数据量，对于统计项目层数据，Excel就能搞定。
设计透视模型的时候，原型是在Tableau上实现的。由于购买Tableau有一定难度，才下移到 Excel。也曾考虑到Power BI，发现Excel本身内嵌的Power BI的能力和透视表功能差不多，所以也放弃了。最终通过Excel的 Pivot Table功能实现。
这个模型的ETL程序，是自主开发的，需要一定的数据和科技支持。
理想的状态，是将实现的领域数据模型作为管理驾驶舱的一个控制面板（All-in-One Board），通过逻辑分层，实现从“数据”到“信息”再到“价值发现”的完整过程。
这里的 “Data → Information → Insight → Value”, 借用了《Becoming a Data-Driven Organisation - Unlock the Value of Data, 2019》这本书里面的概念和逻辑。
书中的两幅图，值得参考：
这是关于“数据供应链“的一张示意图。
在一个企业里，如果有Data Office部门的话（Data Office目前国内还没有对应的比较恰当的部门），这个部门应该负责数据供应链。例如ETL的过程，就需要这个部门负责。
这是书中关于“数据价值链”的一张示意图。
底层是Data，由Data Office负责。Data Office也负责提供Information。再向上，Data Office与Business（业务部门）合作，洞察并发现数据的价值。
左侧是我的标注：下半部分是IT（Information Tchnology），上半部分是BI，需要业务部门与信息部门合作。这里的“ I”有两层含义（Intelligence & Information）。“I”是“BI”与“IT”的合作。
图中，最底层是Data Source（数据），上一层是Information（信息），再上面是Business（业务）和Management（管理）。业务层和管理层需要的是Insight（洞见/洞察）和 Value（价值）。银行内部的业务部门（对公、对私、金融市场等）和管理部门（资产负债、财务、风险等）通常都在Business和Management这两层。其中的Management，往往层级更高，是决策层。
这里的Insight层，契合了大数据时代的需求：基于给定的数据，发现其中的模式、关系和异常，据此形成业务建议或者管理报告。
贵阳银行风险管理部田仁礼提问：前端数据质量管控如何保障和实现？
刘学锋回答：前端数据质量管控更多的要管好入口。我们在上一代业务系统设计时，曾经遇到过一个问题，就是系统的数据里没有重新定价日，所以在2008年首次提出加入重新定价日字段。
还有系统设计，在IT设计时，就要考虑系统本身去控制。比如系统窗口前端录入的数据，假设设计的每一个字段的数据类型都是文本，那么无论是什么数据，都可以进入了。所以在前端数据类型上要做控制，在数据库物理层上要做设计。
另外，操作手册上要有要求，比较优秀的系统对前端不该录入的数据会自动提示或拒绝。
个人认为数据质量管控问题，更多的要在物理层的系统上去控制。
关于数据，数据系统设计应该有过滤，一旦数据是异常值立马报警，不能让数据悄无声息地进入到后台结算，造成重大的事故和风险。这种技术风险需要在技术环节避免。金融科技在智能化层面要把好第一道关。
个人认为，在技术层面首先要消灭掉99%的问题，顶多留1%给业务人员。因为业务人员这一层面不好控制，虽然有各种各样的操作手册,而技术层面控制可以降低成本。目前各行都在做数据质量控制，要么在技术层面做，要么在前端录入的时候把住入口，而在中间环节无法控制。
另外需要关注参数码表。系统的参数码表非常重要，参数码表往往是由银行业务主管部门控制，运营部门录入时都会实时征求业务主管部门的意见。比如银行名称的缩写，特别是有些外资银行的名称缩写，如果不同的柜员使用不同的缩写就很麻烦。所以在后台参数定义的时候都要统一，很多时候由于各种码表的数值不规范，会造成了很多监管问题而遭遇罚款，这是业务主管部门的责任，需要在技术层面管好系统的参数码表。
前中后要守土有责。前端是柜员，中台是业务主管部门。参数码表要管理好，中台实时监控限额，最后是后台技术要跟上。
商业银行资产负债管理的主题是量、价、险，技术方向是实现BIT。B要管好入口，I要管好信息和参数码表，T设计的系统要足够智能化。
“量、价、险”和“B、I、T”，是商业银行经营中永远的六字主题。
用户提问：数据上存在一定的跨平台等待和数据丢失的问题，是否能够用Python工具来解决？
刘学锋回答：Python是可以解决的。但是如果去实施的话，个人认为数据丢失要通过不同系统之间的协同合作或者系统之间的校验去实现。Python只是工具，是技术处理层面的。我更觉得应该考虑系统性的解决这种问题的方法。方式方法正确了，技术实现就比较容易了。
关于多平台之间的数据校验之前也遇到过。对于非一体化的业务系统，系统是分散的，与后台的会计系统是分离的，业务系统把数据传给会计系统的时候，就有可能丢数据或者重复传送和记录。这种问题经常发生，造成大量错账，不能及时出出账，特别是年终结算的时候，会非常麻烦。
所以解决上下游接口，会更有效率。
祝世虎补充回答：第一个关于数仓和数据质量的问题。刚才从管理角度讲得非常好，我从技术角度再讲一下个人观点。
银行从原来的IOE到后来TDGP的数据仓库，再到现在各个银行都在建仓库一体的数据仓库，建好之后，就可以发挥大数据平台的能力，尽量弱化一些前台录入准确性的问题。比如以前的数据仓库，很多数据都是单一来源的，如果原系统的原数据错了，那么数据仓库的数据就错了。并且原来的TDGP的数据仓库并不具备很丰富的算力，所以校验能力比较差。一旦是原系统的数据错了，那么传到数据仓库错的概率就非常大。但是进入Hadoop之后，大数据时代到了，Hadoop数据仓库具有丰富的算力，能够突破原来单一来源数仓的三点限制：
第一点，能够对多元数据做到一元数据的智能匹配和同源数据的智能拉链，降低了数据准确性对原系统数据准确性的依赖。
第二点，大数据仓库有丰富的算力，可以加很多复杂的校验环节来进行第二次的数据质量的治理，并且可以将数据治理的结果反哺到前端的语言系统内，这样在语言系统就不需要大量数据校验人员。
第三点，Hadoop的数据仓库能够直接处理非结构化的数据，可以在合同中通过OCR和NLP的方式提取最原始的数据，和原系统的数据进行校验。
所以，仓库一体的数仓设计，实际上弱化了数据仓库对原系统数据来源准确度的依赖。
第二个问题是传输数据丢了怎么办？首先,如果是基于Hadoop数舱，用准实时的伏定的船的话，丢了就没有了，唯一的办法是当天晚上T+1跑批的时候再找回来，这是一个纯技术的问题。
责任编辑：李瑞钊
来源：2022 TGES前沿讲座：NO.12 资产负债管理与资金转移定价（FTP）（3月）
