银行信息系统架构中的数据应用

数据整合存储的目的是为了更好地支持数据应用，数据应用的目的是为了更好地支持商业银行经营决策管理，所以数据应用就是在数据产生、流转、整合的基础上发掘数据价值的过程。

在谈数据应用的时候，通常的分析逻辑如下：

依托于数据分析需要支持的业务能力，数据应用可以被分解为哪些业务领域？

商业银行需要数据发挥价值的业务领域是什么？

管理分析领域的应用规划对数据集市提出什么要求？

数据集市的建设方法是什么？

支持应用访问的主要的技术手段是什么？

同时为了把数据应用按照以上逻辑阐述清楚，需要列举几个典型的应用专题，按照应用规划需求进行集市建设的详细探讨。我们选择的专题包括两个：

1）商业银行基于监管要求，按照BaselⅢ的风险管理分析域。

2）商业银行满足不同监管机构要求的，外部监管合规分析域。

1.数据应用的数据架构分析过程

（1）商业银行的业务功能组件 管理快速增长的企业数据一直以来都是CIO面临的巨大挑战，据调查，尽管企业在信息管理项目上投入巨大，然而20%的管理层仍然抱怨：无法获得所需要的信息支持业务运营。为了实现战略信息管理，CIO必须关注那些能够创造企业竞争力的数据，即有价信息。因此，在银行信息系统架构规划过程中，必须坚持以“业务价值为信息规划驱动力”的指导原则。

为了让数据有效服务于银行价值创造，需要首先理解银行金融战略及发展方向，了解银行经营活动中所必须具备的各种业务能力。在一个以“业务价值为导向”的银行信息架构规划中，可以通过引入“通用银行业务功能组件”来规划银行数据服务需要支撑的全部业务价值领域。银行业务能力模型的构建目的是为了明确银行经营过程中所必须具备的能力模块，每一个能力模块的背后都应该有相应的组织架构、作业流程和IT技术支撑保障。

基于对国内银行业务的理解，以下是一个完整可参考的“通用银行业务功能组件”，如图4-9所示。

通用银行业务功能组件总共包括4个领域，从直接接触客户的最前端到银行内部管理的后端分别是：

1）客户接触域——银行与客户交互需要拥有的能力，包括品牌管理、渠道管理和客户关系管理（CRM）三个子领域。

2）业务协同域——衔接前端客户交互与银行内业务操作之间的作业协同，主要包括客户管理、产品和服务管理以及综合管理。

3）业务运营域——是银行业务能力的核心，与银行的业务范围密切相关，需要根据银行业务现状及发展目标进行适度裁剪。国内一般银行的业务范围包括基础存款及支付结算业务、信贷业务、投资理财业务、金融市场业务、金融同业业务、居间金融服务等。

图4-9 通用银行业务功能组件

4）业务管理与支持域——是银行后台运营管理的核心，同时也是银行数据服务最重要的价值领域，主要包括财务管理、资产负债管理、风险管理、合规管理、决策管理和公共支持6个子域。

银行数据的价值体现应该是将数据洞察的结果经由组织架构（人员）、业务流程和IT系统直接纳入整个银行业务能力模型的各个模块中，从而服务于银行收入提升、成本降低、风险规避和效率提升。

（2）业务功能组件推演的管理分析域划分 基于通用银行业务功能组件，我们不难定义一个完整的、覆盖全能力域的、数据服务的银行管理分析域，如图4-10所示。

下面简单定义每个管理分析域所要解决的业务问题，以及这个领域的基本应用规划：

1）客户营销与渠道管理。主要应用包括客户分析领域的客户细分，客户获取，客户全生命周期管理，客户交叉销售，客户风险识别以及渠道效率优化；业务价值是快速、准确识别客户需求，不断提升客户价值，降低客户风险，优化渠道绩效。

2）产品和服务管理。主要应用是面向快速变换的金融市场的产品服务创新，指导产品区别定价；业务价值是通过不断的金融服务创新满足不同细分客户群的产品定制化策略，能够更好地吸引客户，带来新的业务收入。

图4-10 商业银行的管理分析域划分

3）财务与绩效管理。主要应用是财务成本及收益综合分析评估，包括确立内部资金价格，管理会计计算，通过引入合理的成本分摊法则，针对机构、产品、客户进行综合的收入、成本和盈利分析；财务与绩效分析虽然不直接贡献于业务价值的提升，但是可以协助企业通过数据分析提升其精细化运营能力。

4）资产负债管理。主要通过对不同期限的资金进行规模、头寸、敞口的计量，有效地防范商业银行可能存在的资产与负债不同期限的错配或者不足的问题，帮助商业银行控制资金成本，提升资金应用效率的能力，同时为利率风险和流动性风险管理提供数据基础。

5）风险管理。满足《商业银行资本管理办法》中对金融风险的计量要求，通过对信用风险、操作风险、市场风险等基本风险领域的计量，以及通过RWA，经济资本计量、风险压力测试、组合风险管理等整合风险管理策略的实施，满足监管部门对银行资本充足率的要求，并在企业内逐步形成风险管控意识和成本节约意识；通过降低银行经营风险，有效运用资金，从而贡献于银行业务价值提升。

6）合规管理。包括内部合规和外部合规两大领域，外部合规主要是满足外部三大监管部门对银行业务运营的监管要求，及时准确对外报送经营报表，满足监管当局的数据要求，同时达到提高报送效率、降低报送成本的目的。内部合规则主要是服务于商业银行的审计、稽核、内控、合规等部门的管理需求而建设的应用体系。

7）运营管理支撑。伴随着企业数据分析深度的不断扩展，数据分析结果的运用层面势必逐步走向支持业务协同和客户接触的运营流程，实现数据分析结果与业务流程的实时或准实时嵌入，数据价值直接服务于业务价值创造。

8）战略决策支持。数据服务于银行管理层的战略决策，通过组合的动态监控指标来实现。

以上只是针对管理分析域的一种划分方式，不同的商业银行按照自身中、后台管理的模式差异性，可以按照自己的方式进行区分。但是最终都要达到针对管理分析需求的全覆盖。管理分析域的应用需求，直接就决定了这个领域的数据集市的建设策略。从而影响数据应用环节的数据架构设计。

（3）管理分析应用影响数据集市的因素 在不同的管理分析域，都有多个应用的部署，而不同的应用对数据整合、数据共性加工、数据个性化加工的需求都有差异性。

而我们区分管理分析域的目的是把具备相同数据源基础，具备更多共性加工逻辑，以及应用之间有数据相互的输入、输出依赖的应用耦合在一起，当然这种耦合性也势必反映它们在业务分析决策支持过程中的应用功能的耦合性。这样耦合在一起的应用可以有两层的数据集市对它进行支撑。

第一层：本领域内共享的数据集市，主要目的是支持领域内的明细数据组织，领域内的共享加工逻辑，领域内的共享结果的整合性存储。从这种角度看，某领域的共享数据集市和数据仓库有很多类似的地方，当然也有差异性，至少数据服务的目标范围是不一样的。这种共享数据集市是我们在集市建设阶段讨论的重点，包括的设计方法和思路，以及和数据仓库的差异性。

第二层：单一应用独享的数据集市，该数据集市只服务于单一应用，其数据的存储、处理、保留完全按照单一应用要求实现，更加需求驱动，而且没有共享性需求。这种集市随需求差异性很大，我们不作为数据架构重点讨论的内容。

（4）数据集市的设计方法 按照上面所述，从数据架构的角度讨论，我们重点关注某管理分析域共享数据集市的建设方法。

和企业级数据仓库整合平台一样，共享数据集市也可以进行内部的数据层次区分，一个典型的划分为：基础明细层、共享加工层、结果数据回流存储、对外服务接口等多个层次。但是共享数据集市的构建方法与数据仓库的建设方法还是略有区别，这种区别主要体现在：

1）建设目标上的差异：数据仓库的建设目标一般是支持全行数据分析应用；而数据集市的建设目标往往是服务于某一个或某类特定的业务领域的数据分析应用（例如风险管理），因此数据集市的建设更强调“需求驱动”。

2）数据范围上的差异：数据仓库注重收集整合全部有业务意义及分析价值的数据；而数据集市往往只关注于特定分析范围下的有意义数据（例如风险数据集市只关注资产类明细数据，不关注纯中间业务数据）

3）数据模型上的差异：数据仓库的模型注重稳定性、扩展性，能够整合行内各种数据，因此，从模型设计语义上有适度的业务抽象性，往往不易被一般业务人员理解和使用；而数据集市的模型更关注业务一致性，面向特定应用的分析计算需要，对数据进行预加工，预关联，从而保证上层应用使用的基础数据具有共同的预处理逻辑，数据集市的模型更偏重于业务使用需求，因此更具业务可读性，但是也会因应用的针对性而失去一定的稳定性。

另外，数据集市的部署策略也有多种选择，主要包括四种模式：

1）纯数据仓库仓内集市部署策略，如ACRM，可以作为完整的仓内集市建设，和仓外的OCRM体系从使用角度分离。

2）仓库大集市和仓外小集市部署策略，如管理会计，无论是分摊前的明细准备还是分摊后的结果共享存储都回归数据仓库，但是会将分摊规则的引擎部署在仓外。

3）仓内小集市和仓外大集市部署策略，如市场风险计量，因为仓外有专业的计算引擎，因此仓库只承担原始接口数据加工。

4）纯仓外集市部署策略，如征信、反洗钱等不依赖数据仓库的明细类监管报送应用大都采用这种架构。

在实际应用过程中，大部分的数据集市都属于第二种或者第三种模式，而第一种和第四种是少量的。

（5）综合数据服务体系 打造数据综合服务体系，是把数据应用计算结果传出去的手段。按照当前商业智能领域的主流技术和商业银行的实践，主要包括四种技术手段的应用以及一个商业智能门户的建设。

主流的四种数据访问手段如下：

1）报表和查询体系：包括报表、查询、多维立方体展示、指标库展示、管理驾驶舱等多种报表以及查询服务体系。

2）基于专业引擎的数据计算访问体系：依托于专有计算引擎计算，而且直接进行计算结果展示的应用展示体系，如测算，计量，估值等。

3）数据分析服务体系：指针对临时性、探索性、不确定性数据分析需求的交互式数据访问和数据分析服务体系。

4）数据挖掘体系：基于数据挖掘工具构建的模型试验室体系。用于营销、风险管理等领域的计量模型的探索。

一个好的数据综合服务体系，应该涵盖以上多种的数据分析服务手段，才能搭建出数据应用价值到最终用户的合理的传导机制。

2.数据应用专题分析

（1）专题一：风险应用与风险数据集市

1）金融机构面临的风险。金融机构管理的主要目标之一是增加其股东的收益，然而这个目标实现的同时往往会带来一些风险，现代金融机构面临的风险包括：

①利率风险。金融机构资产和负债的期限不匹配时面临的风险。

②市场风险。当利率、汇率和其他价格发生变化时，金融机构交易账户中的资产和负债面临的风险。

③信用风险。金融机构无法完整地获得其贷款和证券所承诺的现金流。

④表外风险。金融机构资产负债表外的或有资产和或有负债业务所带来的风险。

⑤营运风险。现有的技术、审计、监控和其他支持系统有可能失灵或崩溃。

⑥外汇风险。汇率变化会对金融机构以外币所表示的资产和负债的价值产生影响。

⑦国家或主权风险。外国政府的限制和干预措施有可能使向国外债权人或投资者的还款中断。

⑧流动性风险。突然大规模的挤兑有可能迫使金融机构在很短的时间内低价（低于市场公平价）出售资产。

⑨破产风险。金融机构可能没有足够的资本来弥补其资产价值的突然下降。

2）监管要求。针对以上风险，国际组织巴塞尔委员会作为全球监管当局交流监管技术，讨论监管准则的平台，形成了一系列监管框架。中国自2009年加入巴塞尔银行监管委员会后，充分借鉴和吸收了国际银行业的风险监管经验，出台了一系列金融监管办法和监管指标体系。

2012年6月银监会颁布的《商业银行资本管理办法（试行）》（以下简称“办法”），自2013年1月1日起执行，要求中华人民共和国境内所有商业银行须满足办法中规定的资本充足率监管要求。依据办法要求，银监会对国内所有商业银行风险监管的目标体现在以下三个方面：

①满足风险加权资产（RWA）计量资本充足率的要求。

②满足银监会非现场监管资本充足率的报表需求。

③满足办法中规定的信息披露需求。

办法中规定的RWA计量要求和资本定义要求完全满足了巴Ⅲ的要求，并在17个附件中规定了三大风险不同计量方法下的计算规则及指标。

同时办法中明确提出，商业银行应当建立数据仓库，并在数据仓库的基础上建立风险数据集市，以获取、清洗、转换和存储满足风险计量模型的开发、优化、校准和验证，以及风险指标计算所要求的内部和外部数据，既应包括单个客户，单笔债项的详细数据，也要涵盖行业、区域、产品等资产组合以及宏观层面的数据等，并且数据仓库及风险集市应作为计量结果的返回存储系统。

3）银行建立风险应用体系。鉴于金融风险应用领域的需求十分庞大、复杂且互相交织，金融风险应用的构建远不是一个应用项目就可以实施完成的，一般而言，商业银行都会逐步按照以下风险应用框架体系之要求，启动一系列相关的风险应用项目群，如图4-11所示。(www.xing528.com)

其中包括单一风险计量应用和综合风险应用两大领域：

①单一风险应用领域的应用主要包括：

a.零售信用风险，主要建设内容包括零售客户评分卡模型，零售客户分池模型等。

b.非零售信用风险，主要建设内容包括非零售内评初级法，非零售内评高级法等。

c.市场风险，主要包括权重法，高级计量法。

d.操作风险，主要包括风险与控制自评估，关键风险指标，损失数据收集，操作风险资本计量等。

②综合风险应用领域的应用主要包括：

a.风险加权资产计量。

b.贷款定价管理。

c.限额管理。

d.经济资本管理。

e.资产负债及流动性管理。

f.风险监控及预警。

图4-11 风险管理领域的应用规划

g.全面风险报告。

4）银行建立风险数据集市。根据风险应用的特征要求，分析支持风险应用领域的共享数据集市应该包括以下的数据内容：

①基础数据明细层：按照仓库基础数据模型的主题划分，对于风险计量需要的原始明细结果进行存储，可以采用适度降低范式的策略，保证业务取用的效率。

②风险计量层：

a.存放初步加工的债项、敞口、头寸、限额等信息。

b.存放单一应用计量的结果。

c.存放RWA和经济资本计算等组合风险管理应用的计量结果。

d.风险压力测试场景数据。

e.风险压力测试结果数据。

③应用接口层：

a.支持单一风险计量引擎计算的接口导出层。

b.支持组合风险计量引擎计算的接口导出层。

c.支持基于整合风险管理的风险报表结果数据的导出层。

④模型计算数据集：当前支持模型计算，以及应用于模型监控、验证的原始变量和计量中间结果以及计量最终结果的变量保留的数据集。

⑤模型研究数据集：模型训练过程中使用的变量集。

针对风险管理域的风险数据集市在整体企业数据架构中的部署如图4-12所示。

图4-12 风险数据集市整体架构设计图

（2）专题二：监管报送应用与监管报送数据集市

1）监管要求。要分析监管报送领域的数据集市建设，先要从监管的业务要求推导出监管应用的需求。

金融监管机构是出于对维护一个稳定、健全、高效的金融体系的要求而建立的。回顾中国银行业的发展过程，在银监会成立之前，我国银行业经历过混业监管，分业监管阶段，金融机构经历了乱投资、乱拆借到合理规划、控制风险的发展过程。2003年银监会成立之后，中国“一行三会”的金融监管格局正式形成，监管体系逐步成型完善，监管理念、方法、手段不断改进。我国现阶段金融监管的具体目标可以概括为：

①经营安全性：保护存款人和其他债权人的合法权，规范金融机构的行为，提高信贷资产质量。

②竞争公平性：通过中央银行的监管，创造一个平等合作、有序竞争的金融环境，保证金融机构之间的适度竞争。

③政策一致性：通过监管，使金融机构的经营行为与中央银行的货币政策目标保持一致。

通过金融监管防范和化解金融风险，维护金融体系的稳定与安全，保护公平竞争和金融效率的提高，保证中国金融业的稳健运行和货币政策的有效实施。

监管当局目前对国内政策性银行、商业银行等实施监管的重要手段之一，便是采取了定期的监管报送体制。目前已发布实施的各种监管报送制度见表4-2。

表4-2 监管报送制度

2）银行建立监管报送应用体系。正是由于上述监管报送体制的不断更新变革，各家银行传统的报送方式（一制度一项目报送）已经越来越不适应现代监管报送制度要求。规划和构建新型监管报送应用体系时，需要满足的建设要求总结有以下几个方面：

①统一数据来源，统一共性数据加工。

②逐步构建统一监管报送平台信息门户，集中管理各报送体系。

③逐步统一技术架构和开发规范，实现快速响应。

④建立统一的监管报送数据质量管理体系。

⑤实现跨报送体系数据的交叉稽核校验。

⑥逐步建立监管报送报表指标的多维分析功能。

总之，在新型监管报送制度之下，建立集中统一的监管报送应用体系，实现快速响应将是一个必然的趋势。

满足上述建设要求构建的监管报送应用完整体系架构示例，如图4-13所示。

3）银行建立监管报送数据集市。

①监管报送数据集市的功能主要包括：

a.为各类监管体系提供了统一的基础明细数据来源。

图4-13 监管报送领域数据架构示意图

b.数据共性加工，实现数据共享，以及体系个性化需求加工。

c.确保上报数据一致性，统一数据统计口径。

d.提供按需裁剪后的预加工、预计算数及指标数据，为监管报送提供初始成表数据。

e.数据加工计算规则可配置。

f.设置质量检核规则，进行数据质量监控，提升数据质量，满足监管上报数据质量要求。

g.建立元数据管理机制，实现数据血缘分析及影响分析，同时方便元数据变更、维护与查询。

②监管报送集市平台满足的应用功能包括：

a.实现监管报送成表报送服务，包含但不限于分解表填报，成表生成，计算及校验规则配置，手工填报等。

b.报送体系集中管理，包含报表设计，制度规范升级与变更等。

c.各体系用户、角色、权限定义和统一身份认证管理。

d.监管体系数据补录管理。

e.上报结果数据通过规则配置实现跨体系间数据校验。

f.满足各业务条线的用户多维分析需求，提高数据的应用，发挥监管信息的价值。

g.业务人员在调整试算过程中全面了解对其他报表的影响程度。

（3）专题总结 在此，我们以两个数据应用专题为例，从业务出发点驱动、到应用架构以及数据集市架构进行了讨论。可以看出，集市与仓库有类似的地方，又有明显的差异化分工。总结如下：

1）数据集市可以有自己的基础明细、整合加工、汇总加工，也可以有明确的数据层次划分。

2）但是从大的数据架构而言，集市的数据整合与明细存储更多局限在支持某一个领域的应用为目标，而数据仓库是面向企业级的目标。

按照之前探讨的原则：即使可以包括明细数据，但是为了不让大量的明细数据进行搬迁和冗余存储，尽量在集市中通过逻辑映射的方法共享数据仓库的基础层以及共性加工层的信息。这样，既保证了集市针对某一个业务领域的理解的完整性，又不违背企业级整体的数据架构规划。而在现实系统建设过程中，还是更多的数据搬迁和冗余存储。一般把它理解为架构管控以及不同部门之间利益冲突的问题。