浅谈银行数据仓库：金融主题层建设篇

FDM 金融主题层属于数据仓库的核心层级，在源数据与数据应用间起着承上启下的作用，关键是，金融主题应该划分成什么？每个金融主题的模型建设思路是怎样的？金融主题的数据模型该怎样维护？

前言

上一篇文章《浅谈银行数据仓库-分层架构》，描述银行数据仓库（下文简称“数仓”）分层架构至少包含 ODM 贴源层、SDM 标准层、FDM 主题层和 ADM 应用层。其中 FDM 层的核心诉求是把复杂的源数据化繁为简，按照业务逻辑划分出金融主题，把源数据进行拆分与整合到金融主题的模型中。关键是，金融主题应该划分成什么？每个金融主题的模型建设思路是怎样的？金融主题的数据模型该怎样维护？

在解答上述问题之前，首先要了解国外主流的金融主题划分方案是如何的，如何从国外的主流方案中取经。

国外主流的金融主题划分方案

Teradata 公司的 FS-LDM 十大金融主题模型

Teradata 公司作为全球最大的专注于大数据分析、数据仓库和整合营销管理解决方案的供应商，并提出一种先进的 FS-LDM 模型（Financial Services Logcial Data Model），把银行约 80%的业务数据囊括在该模型中。

Teradata FS-LDM 是一个成熟产品，在一个集成的模型内支持保险、银行及证券，包含十大主题：当事人、产品、协议、事件、资产、财务、机构、地域、营销、渠道。具体划分如下图所示：

IBM 公司的 BDWM 九大金融主题模型

IBM 公司作为数据仓库和数据分析的“元老级”企业，为了对抗 Teradata 公司的 FS-LDM 模型，提出了 BDWM（Banking Date Warehouse Model）九大金融主题模型，主题模型分为参与人、合约、条件、产品、地点、分类、业务方向、事件和资源项目。具体划分如下图所示：

金融主题层划分及建模思路

由上述的 FS-LDM 模型与 BDWM 模型，可以分析出以下共性：

1） 描述银行客户信息的主题；

2） 描述银行机构及员工信息的主题；

3） 描述银行产品信息的主题；

4） 描述银行与客户之间契约信息的主题；

5） 描述银行与客户资产信息的主题；

6） 描述客户使用银行服务时产生的行为信息的主题；

7） 描述银行与客户联系信息的主题。

由于 FS-LDM 模型偏向财务及营销方向，所以多出描述银行营销活动信息及财务风险信息的主题。而 BDWM 模型偏向银行环境及法规方向，所以多出描述银行环境信息及业务信息的主题。

结合上述两大金融模型及本地银行的数据环境，笔者建议以下优化点：

1）取消地域主题。地域主题来源于国外的邮寄销售业务，该业务是国外银行产品重要的引流及销售手段之一。但国内银行甚少开展邮寄销售业务，故地域主题重点描述的邮箱、电话、区域、地址等信息，都可以整合到客户主题内。

2）财务主题重点在总账数据。总账是银行的记账核心，总账数据一般存放在银行的核心系统或总账财务系统中。通过分析总账数据，可以分析出银行的经营状况、统计出银行的业务结构。同时通过汇总业务系统的账务数据，还可以进行以银行科目为维度的总分校验，保证余额信息的准确性。故财务主题的重点应为总账数据。

3）增加公共主题描述业务系统的码值与参数数据模型。业务系统的逻辑处理过程中，会产生大量的码值与参数，比如机构编码、状态编码、业务控制参数、节点配置参数等。这类数据对于识别数据的业务状态，及代码的中文含义，起到至关重要的作用，但这类数据跟已有的金融主题的关联性不强，故需单独增加公共主题进行建模管理。

最终，笔者认为 FDM 层的金融主题划分应划分为客户、产品、协议、事件、渠道、营销、银行、资产、财务、公共，具体如下图所示：

客户主题

银行的客户信息会在多个业务系统中进行登记，比如网上银行、手机银行等渠道系统，理财系统、信贷系统、核心系统等，且多个业务系统中保存的客户信息还大概率的不一致。这时，在使用客户信息时就会出现疑惑：以哪个系统的客户信息为准？多个业务系统的个性化客户信息如何整合？所以，建设统一客户视图管理是银行数据工作的重点。

建设统一客户视图管理一般实践方式为建设 ECIF（客户信息管理）系统，由 ECIF 系统整合各个业务系统的客户信息形成统一视图，为全行提供客户信息查询服务。假如行内未建设 ECIF 系统，亦应在数仓上建设统一客户视图的客户信息主题，替代 ECIF 系统为全行提供客户信息查询服务。落地统一客户视图关键是与全行业务部门约定好客户信息整合的优先级及更新规则，因为客户信息整合很可能会影响到客户经理的绩效，从而影响业务部门的绩效。确定业务规则并获得全行支持后，通过 ETL 手段每日提取业务系统的增量客户信息整合处理即可。

银行客户主要分为个人客户、对公客户及同业客户。客户主题的建模应对这三类客户进行单独建模，原因如下：

1）数据分析时很少对所有客户进行统一分析，更多的情景是分析每类客户的情况；

2）单独建模可以避免单表的数据量过大，加快统一视图的数据整合效率；

3）相似数据进行“求同存异”的整合时，必定存在大量字段空值的情况，既影响数据的存储也影响表的查询速度。

故，客户主题的建模思路如下所示：

产品主题

金融产品是银行经营的核心，也是银行与客户建立关系的纽带。金融产品主要分为以下类别：

1）负债类产品。负债类产品一般为存款类产品和理财类产品，主要用于银行吸纳客户的合法资金，再运用该资金进行信贷或资管类产品投资。客户“借钱”给银行后，银行会按照约定的利率或者收益率，计提利息或收益并返回给客户，所以负债类产品的利率或收益率是银行向客户“借钱”的成本。

2）资产类产品。资产类产品主要是信贷融资类产品，主要用于银行“借钱”给客户，并向客户按约定的利率或费率收取客户的利息或费用，从而产生利润。信贷融资类产品又分为：

a）零售信贷，比如购房贷款、汽车贷款、教育贷款等；

b）对公信贷，比如经营贷款、购货贷款、小微企业贷款等；

c）政策信贷，比如涉农专项贷款、绿色贷款、联合平台贷款等；

d） 票据融资，比如承兑汇票贴现、转贴现等；

e） 国际贸易融资，比如信用证、福费廷等。

当客户购买银行的资产类产品后，需要按约定支付银行利息或者费用，作为客户向银行“借钱”的资金成本。故银行资产类产品的收益率与负债类产品的息率之间的利差，就是银行传统业务的利润手段。

3）资管类产品。这里专指银行自营的资管类产品，比如债券、基金、信托等。银行通过募集客户资金或运营客户委托的资金进行投资，在为客户赚取收益的同时，收取资管管理费和分润投资产生的超额收益进行收益。

4）中间收入类产品。中间收入类产品属于银行非资金运营业务，通过收取客户的服务费进行收益。中间收入类产品主要分为代理业务，比如第三方存管、代理资管类产品、保险产品、债券产品等；和部分重要空白凭证开立，比如汇票开立、信用证开立、保函开立等。

5）银行卡产品。银行卡产品主要分为借记卡、准贷记卡和贷记卡。

• 借记卡是指发卡银行向持卡人签发的，没有信用额度，持卡人先存款、后使用的银行卡。

• 准贷记卡是指持卡人须先按发卡银行要求交存一定金额的备用金，当备用金帐户余额不足支付时，可在发卡银行规定的信用额度内透支的信用卡，但透支的部分自透支当天起计收利息，不享受免息期。

• 贷记卡即信用卡，是由商业银行或信用卡公司对信用合格的消费者发行的信用证明，持卡人可在发卡组织规定的信用额度内透支资金，且透支资金享有免息期。站在客户的角度，信用卡是一款可透支的支付工具；站在银行的角度，信用卡更像是一个客户运营的平台。虽然信用卡具备免息期，但是客户在使用信用卡进行提前消费的分期业务或者取现时，就是银行通过信用卡这个平台产生收益的时候。

产品主题应按同类产品进行单独建模，建模思路如下：

协议主题

协议主题是银行与客户之间针对某种特定产品或服务而签立的契约关系。当银行与客户之间针对某种产品或服务的条款和条件达成协议时，一个协议就会被开立，因此协议是客户和银行往来的重要载体。由于协议的类型繁多，如存款账户、贷款账户，如手机银行签约合同、贷款合同，如存折、银承汇票，都属于银行与客户间的协议，所以协议主题也是银行主题模型中最重要和复杂的一个主题。

协议信息主要分为三类：

a）银行账户，比如存款账户、贷款账户、理财账户等;

b）签约信息，比如网银签约、手机银行签约、贷款合同、担保合同等;

c）凭证，比如银行承兑汇票、支票、存折、存单等。

协议主题应按同类协议进行单独建模，建模思路如下所示：

事件主题

客户享受银行金融服务的过程中，会与银行产生大量的互动行为，这类互动行为就是客户与银行间的事件。事件按是否涉及钱财分为金融事件与非金融事件。

1）金融事件主要为客户与银行间发生的涉及资金的行为，包括存款、消费、取现、转账、批量代发，水电费用代缴等；

2）非金融事件主要为客户与银行间发生的无资金涉及的行为，包括账户余额查询、签约状态变更、操作日志等。

除了客户与银行间的事件，还有银行与银行间的资金清算事件，这一类事件就是支付结算流水。

故，事件主题具体建模思路如下所示：

渠道主题

当客户想要跟银行接触、购买产品、使用服务，互动交流时，必须通过一个触点来进行，这个触点就是平常所说的渠道。渠道除了是银行业务入口，也是银行客户的流量入口，所以经营好银行渠道是业务增长其中一个关键点。

银行渠道主要分为三类：

1）电子渠道，比如网银、手机银行、微信公众号。

2）设备渠道，比如 ATM、POS、自动终端。

3）人工渠道，比如网点、柜台、分理处。

要注意的是，渠道既然是一个对外放开的接口，肯定也会有相应的限制规则作为门槛，避免渠道被乱用、滥用。

故，渠道主题具体建模思路如下：

营销主题

为了促进金融产品的销售，银行的市场部门会制定营销活动推送给客户，并根据营销活动实际产生的效果，不断调整活动细节直到达到营销目标的循环往复的过程。为了实现营销活动自动化配置及推送，银行会建设营销管理系统或 CRM（客户关系管理）系统来策划与管理营销活动，所以营销主题的数据来源就是营销管理系统或 CRM 系统。

营销主题的数据主要分为三类：

1）商机发现，主要为客户调研数据、同业调研数据和潜在客户数据。

2）营销活动，主要为活动信息及规则。

3）权益体系，主要为对应营销活动的权益信息及规则。

故，营销主题具体建模思路如下：

银行主题

银行主题主要是描述银行内部的信息，内部信息主要分为三类：

1）内部组织架构，比如总行、分行、支行、营业厅等机构信息。除了机构信息之外，还关注组织架构的层级关系。

2）内部人员，比如员工基本信息、薪酬信息、关系人信息、奖惩记录等。

3）内部账户，这里专指银行机构内部清算、银行对他行清算、银行对商户清算的虚拟账户。

所以银行主题具体建模思路如下：

资产主题

无论是银行还是银行客户，系统内都存储着大量的资产数据（负债属于从别的对象“借”过来的资产，所以可以理解为“负”的资产）。

对于银行来说，资产主要分为四部分：

1）同业拆借。同业拆借是金融机构之间进行短期、临时性头寸调剂的行为。银行向同业贷出款项，称为资金拆出，属于资产；银行向同业借入款项，称为资金拆入，属于负债。

2）央行准备金。为了确保商业银行在遇到突然大量提取存款时，能有相当充足的清偿能力，央行要求商业银行的库存现金按一定比例存放在央行的存款，称为央行准备金，属于资产。

3）固定资产。这里指银行所拥有的固定物资，比如银行名下的房产、办公楼、固定设备、汽车等。

4）无形资产。比如银行的品牌、专利权、著作权、信誉等。

对于银行客户来说，资产主要分为四类部分：

1）固定资产。这里指客户所拥有的固定物资，比如个人/公司名下的房产、汽车、货物、地皮等。

2）本行金融资产。在本行购买的存款产品、贷款产品、理财产品、资管产品。还有贷款时的担保物与抵质押物也属于客户的资产。

3）他行金融资产。在他行购买的存款产品、贷款产品、理财产品、资管产品、在本行购买的代理第三方的金融产品。

4）无形资产。比如客户的品牌、专利权、著作权、信誉等。

通过资产数据，可以分析银行/银行客户的经济实力，从而对银行/银行客户进行营销评级或风险评级。

由于银行资产数据结构与客户资产数据结构差异较大，且不同资产的数据结构同样差异较大，故资产主题需对每一类的资产进行单独建模，建模思路如下：

财务主题

财务主题主要分为总账数据与风险管理数据两部分：

1）总账数据。总账全称为会计总分类账薄（General Ledger），是根据总分类科目开设账户，用来登记全部经济业务，进行总分类核算，提供总括核算资料的分类账薄。故总账数据登记的是银行按会计科目记录的经济业务的数据。通过分析总账数据，即可得出银行的经营情况及业务结构。

除此之外，通过把总行数据与账务明细数据按科目进行余额核对（也称总分校验），可以检查出会计登记数据与实际业务发生数据是否一致，是银行经营数据校验的关键一环。

2）风险管理数据。存放银行的风险敞口与贷款减值准备的分账信息。

故，财务主题具体建模思路如下：

公共主题

业务系统的运营过程中，会产生大量的码值与参数，比如机构编码、状态编码、业务控制参数、节点配置参数等。虽然码值与参数非业务数据，却是使用业务数据的重要一环，因为该类数据是为了识别业务数据的状态与码值的中文含义。

故，建设公共主题是为了把整个数据布局补上最后一块重要的拼图，具体建模思路如下：

总结

FDM 层对源数据的化繁为简后，整个银行数据的脉络就清晰展现在面前，为 ADM 层和数据分析提供数据基础。然而，是否建设好 FDM 层模型就可以一劳永逸呢？很明显答案是否的。原因有以下两点：

1）银行业务在不停地发生变化，而 FDM 层是按照业务脉络进行建模的，所以 FDM 层模型必须跟随着业务的变化而变化，才能符合及容纳当前实际的业务情况。

2）银行的数据量日渐增大，由于数据库技术的限制，原有模型的管理效率会越来越低。为了解决效率问题，可以通过更新数据库技术来解决，但更新技术意味着整个数仓要进行重构，成本非常大。故除非绕不开技术的瓶颈，否则通过拆解模型来解决。

拆解模型指把原来粗粒度的模型拆分成细粒度的模型，比如支付结算模型，可拆解为大额支付模型、小额支付模型、超级网银支付模型、票据清算模型等。模型的拆解，虽然会增加数据统计或分析的复杂度，但可低成本地解决效率问题，且不至于对数仓伤筋动骨。

FDM 层对源数据化繁为简后，已经具备数据分析的数据基础。那是否代表业务人员就可以直接使用 FDM 层的数据进行数据分析呢？假如业务人员具备丰富的业务知识与数据库技术，是可行的，但实际上大部分的业务人员的知识储备并没有那么丰富，然而他们希望能够自行进行数据探索，解决自身的小需求。如何才能降低数据分析的门槛，让大部分普通的业务人员也能享受这个科技红利呢？这个问题留到下一篇文章再进行讨论。