全球化银行信息系统设计

1.体系架构

体系架构一般依据不同业务的应用特性与硬件平台特性的匹配，硬件平台、数据库、开发运营等方面的投入与经营效益比值，以及银行自身IT治理的要求符合制订相关的建设原则。一般地，面向基础客户交易的应用系统需要满足高稳定性、高效的处理能力。理财等衍生产品的应用系统需要扩展性灵活，交易渠道需要兼容性强、友好性佳，后线统计分析则要求大规模数据集中处理能力强。

每个银行体系架构的处置策略也不尽相同，不同应用平台的厂商支持能力、社会上配套专业资源、每年运行维护成本、支撑灾备等安全级别的能力可能都是考量因素。

举例来说，国内某全球发展的银行制订的体系架构策略是所有客户服务相关的应用系统均采用IBM主机平台，使用DB2数据库，公共信息在数据库层面实现共享，统计分析类系统使用开放平台、Oracle数据库。这种体系下，在系统的运维支持等方面的开销是巨大的，且应用灵活性差，但这种方式数据底层模式、业务系统间的交互会相对简单，应用处置容易，可以统一地进行数据备份处理。

而另一家银行制订的体系架构策略是，仅客户信息、存款、贷款、支付等核心应用构建在主机上，其他所有业务产品均架构在开放平台，这种瘦核心、松耦合的体系，使得每个业务应用进行独立变更时灵活性较好，但由于是异构系统互联，在交互接口、数据转换、数据统一的备份恢复方面复杂度大大提升。体系架构对比如图4-1所示。

图4-1 体系架构对比

2.应用架构

应用架构是根据拟开办的业务对应用功能进行切分组合，形成不同的应用服务单元（系统）。切分的视角依据商业银行的管理模式不同而不同，一般分为两类视角。一种从银行经营的业务视角进行划分，分为客户管理、渠道、产品服务、风险控制、账务管理、决策分析等业务大类。在产品服务中继续细分成核心业务、投资理财、国际结算业务、资金业务、清算业务金融衍生品等，在应用构建上可以采用建设综合业务系统集成各个产品应用，也可以将各个业务应用独立成单独的系统。第二种视角是按照客户属性进行划分，由于对公业务一般使用电子渠道较少，整体账户数、业务量相对对私业务少之又少，但对公业务要求交易的信息量和时效性更高，不仅要求交易来源、交易对手等信息，对于动户通知、实时账单、动态定价也有更多的要求，对银行的价值更大。所以从信道服务角度说，对私业务往往并发笔数多、单笔金额小、交易信息实时归总要求不高，而对公业务则并发笔数少、单笔金额巨大、信息实时归总的要求高，所以对对公对私业务应用进行分别构建，分配不同的资源配置也是一种应用架构构建的模式。特别在自主建设的设行模式下，如采用统一应用版本的模式，在每个应用系统设计中还需要考虑分国家的处置策略，以应对不同国家的应用差异。这种处置策略上，一般可采用参数化定制和关键公共处理中留出分行特色Route接口两种方式进行，其应用架构对比如图4-2所示。

图4-2 应用架构对比

另外，全球化建设对于应用的设计层级需要做重新规划，一般会划分“基础标准应用”和“特色服务应用”。其中，“基础标准应用”是标准的基础标准功能，其逻辑、流程、定义相对固定，“特色服务应用”是指满足各国差异而设置的应用模式，向下细分还可以划分为“区域应用”和“本地应用”。区域应用是针对区域内共性的内容进行标准化设计，一般按照大洲划分，如欧洲的IBAN清算，本地应用一般按照国家划分，如某国的消费税系统。

根据应用结构的划分，一般银行应用体系区分为接入渠道、公共信息及定价管理、客户信息、业务应用、会计总账及决策分析、风险管控、监管报送等应用环节。

（1）接入渠道

接入渠道指对客的服务渠道，一般包括柜面、网银、自助终端、ATM、微信银行、电话银行等，电子渠道主要是客户柜面服务的延伸，除了业务流程、客户体验保持统一外，电子渠道还承担了银行通知通告的发布、营销信息推介等职能，所以渠道端既要在界面配色、语言显示、输入习惯等方面综合考虑支持地域差异，又要在版本一致性上要制订全球发布的策略。

（2）公共信息及定价管理

这主要包括网点、柜员、货币、行业分类、企业性质等公共信息的定义，以及利率、费率、汇率、税率等基础定价。在进行全球化建设时，网点、柜员作为银行组织结构的一部分，一般进行统筹规划，定价一般从客户（账户）、产品、业务（交易）、渠道四个视角进行定义，每个视角又都可以划分为基础定价、浮动定价两个维度。

（3）客户信息

客户信息一方面要满足本地对客户的识别，还要满足集团（总行）进行客户识别的需要。与公共信息一致，客户信息也需要建立行标信息、本地信息两类标准。对于应用的构建需要先将客户信息划分为登记展示信息和业务依赖信息，其中登记展现信息仅仅是在客户信息输出时进行展现，与业务逻辑、定价无关，此类信息可以选择最兼容的数据定义，直接进行存储即可；如果信息的普适性不强（如此类信息不会给本国以外的地方提供），甚至可将此类信息作为本地应用进行部署。业务依赖信息则是客户信息要参与业务逻辑的分支或者客户定价的变化（如VIP类型、企业性质等），此类信息就必须进行全行标准化管理，并且作为业务逻辑参数、定价参数引用的维度使用。

（4）业务应用

业务应用指支撑银行对客或自营的各项业务。根据银行在该国家的发展规划，以及硬件资源、运维人员等投入预算，一般业务应用有“综合性业务系统”和“插件式业务系统”两类，综合性业务系统使用统一的平台和数据存储，应用结构相对紧耦合，系统间数据交互和交易交互较少，运维人员和硬件资源投入较少，但应用系统综合、复杂，版本升级关联影响较大。而插件式业务系统则将业务系统分散化，应用松耦合，应用独立，硬件资源可使用分区技术共享。这种模式在业务应用版本升级时相互关联影响较小，但体系执行流程复杂，硬件和运维人员投入较多，系统间存在大量数据交互和交易交互。

（5）会计总账及决策分析

会计总账和决策分析，一般是基于总行集团视角的数据统计分析，用于总行的决策分析和经营监控，一般保持全辖的统一建设，与产品系统之间是数据接口关系。

（6）监管报送

监管报送包含两部分内容，一方面是银行集团向自身所在国监管机构进行报表报送，另一方面是开设分行面向当地监管机构进行的报表报送：集团所在国报送一般统一口径、统一建设；分行所在国监管报送，一般建设在分行，以满足其个性化需求。

3.数据架构

数据架构设计是匹配全球化建设模式和应用架构的设计。数据架构的设计不仅要考虑应用划分要求，考虑差异化支持，还要考虑数据传输的要求。一般来说全球化数据架构的设计重点应考虑以下几方面内容：

（1）公共信息、基础信息的信息标准设立

数据信息标准是应用处理的基础，面对全球化的应用场景，各个国家执行的均是各国自己的行业标准（如我国执行的GB标准），在公共信息定义维度、取值范围方面需要考虑对各国差异的兼容。

一般地，如果公共信息项仅仅是表述项，在数据模型设计时需要对全球可能存在的差异情况进行分析，数据栏位设计上取其最大的长度定义，栏位可以放开自由输入（输入端的输入法需要予以保证）。如果公共信息作为业务逻辑的控制项，则需要进行数据栏位的行标设计，即建立一个银行内的统一标准和定义，能够与各个国家的栏位取值一一映射，并在数据设计时提供冗余，保存本地标准的栏位取值。举例说，客户信息中的“行业类型”，如果该栏位参与了客户的业务定价，则需要制订行内标准，统筹定义所有开办行业的类型。

（2）数据分层管理

数据分层管理主要是权衡管理力度、业务影响、执行性能等对数据分布设计的影响。

一方面，集中的数据会对银行及时进行资金运用监控、经营风险防范起到良好的作用，但另一方面，在全球化的模式下，数据集中意味着数据的操控端和业务应用端将远离数据本身，对执行性能提出挑战。从各国分行的视角来看待这个问题，交易终端和监管报送一定是部署在当地的，如果业务数据都是集中部署在一个国家，一定涉及交易时跨国实时数据交互和大量数据传输，这对网络传输能力、数据使用时效性都会带来考验。所以既满足业务时效性要求又满足集中管理需要是一个需要权衡的命题。(www.xing528.com)

如图4-3中的两种方式是比较常见的数据层次规划方式。

图4-3 数据层次规划方式

（3）应用信息的数据模型设计

应用信息模型设计主要是考虑数据的应用划分。

公共信息一般指机构、货币、行业、风险类别等公共信息的定义，这类信息一般需要全行执行统一的标准，由总行统一发布，所以公共信息一般为集中的数据集，各个国家的各个应用系统可下载保存其副本。

定价需要考量各国的定价惯例，匹配各国定价维度的要求。一方面，全面梳理出影响定价的要素。一般说，地域、年龄、账龄、平均余额、信用等级、VIP类型、累积业务笔数、金额等信息都是影响定价的要素。另一方面，对各国定价的惯例也需要进行梳理设计，主要包括定价的分层（余额分层、差额分层、时间分层等）、计算方法（比率法、指数法）、减免及优惠方式（以费抵息、比率优惠、定额优惠等），所以在数据模型设计上要容许最大的灵活性。定价信息数据模型的设计需要看总行的管理意愿，如果定价是分国家、分业务条线分别管理，则定价信息会分散到各个业务系统中自行定义；如果总行对于分产品、分业务条线、分客户的定价统筹管理，则需要有产品定价平台，数据也集中在总行。

客户账户信息是银行服务客户的基础信息，一方面信息要完整，不仅包含客户的基础识别信息，银行自身用于差异化业务定价、客户分类评级等信息，还要包含适应各国监管所需的客户识别信息、报送信息。同时，由于客户账户信息又是业务应用中使用最多的信息，所以客户信息、账户信息的构建需要使用分类分层的原则，形成客户信息的数据集。如果存在全球客户（如跨国集团），则需要构建全球客户平台，勾连各国的同一客户信息。

业务信息数据架构主要匹配业务流程对信息流转的要求，既要保证业务的及时性、完整性，又要保障业务的准确性。业务流转需要跨多个业务系统时，需要将业务信息进行分拆和冗余设计。

一般来说统计分析信息需要构建一个信息量大的面向分析的数据模型，但在全球化建设中，需要考量的是将各国的差异化定义做标准化的映射，以便一份数据服务多个应用。例如：一笔转账信息，在后线分析中需要扩充网点名称、客户名称、客户类型、客户地址、货币名称、客户所属网点、账户所属网点等多项信息，而对于客户类型，则需要既记录本地标识，又记录全行统一标识。

风控信息主要体现在事中和事后的控制，由于各国差异性的要求，一般事中风控作为单独的应用进行建设，结合各国不同的风控要求，在业务过程中设置触发条件启动授权、交易禁止、登记的风控处理。

4.执行架构

执行架构中主要包括两部分内容：一方面是执行流程、交互的控制；另一方面是执行流程中容错措施和安全控制。综合来看，执行架构需要考量以下几个因素：

（1）保障总行和各国分行业务需要

由于各国时区不同，经营时间不一，业务系统的截止时间不同，执行架构上需要制订公共信息和定价信息的发布流程、业务应用系统间前承和后继的分银行管理的执行流程，以及对后线汇总数据进行加工的时机等方面进行规划，满足各个国家当地的正常营业要求和总行后线数据使用要求。尤其在每个应用的批处理执行上，是采用分国家执行、按区域执行，还是全球一并执行，与上下游应用的关联影响，都需要在执行架构层面做深入的设计。

（2）满足数据备份，灾备热备启动时间窗口要求

执行架构的设计还需要考虑为数据镜像备份，在发生灾难事件时为数据恢复留出运行的时间窗口，以满足应急需要。

（3）满足应用平台和数据库升级重组的时间窗口要求

需要由厂商评估不同层级的升级、数据重组所需的时间，并以此时间窗口作为区域划分的依据。

如图4-4所示，以某全球化发展银行为例，其最高层（实例、国家层面）的执行架构设计将全球划分为三个实例区域，每个实例中对于营业时间、批处理时间、升级窗口都做了明确的规划。

图4-4 系统升级时间窗口

5.系统部署

系统部署是综合权衡有关事宜，一般需要考量部署地点的社会稳定因素、自然灾害情况、监管许可、网络情况、用工资源、硬件厂商支持能力、资金投入等多方面的因素。

1）分散部署：运行性能会较好，网络传输数据量较小，但硬件成本投入较高（含灾备硬件资源），运维人员、技术保障人员（含厂商）支持程度分散，甚至会受到厂商硬件供应商全球分配不均的影响，平台版本或应用版本升级时协同复杂。

2）集中部署：由于存在终端—应用的跨国数据传输，运行性能会受到影响，网络压力大，但硬件成本相对较低，各种资源可相对集中，升级时管理调度相对容易。

同时，系统部署还要考量各国监管对于信息系统部署的硬性要求。比如，马来西亚、巴西、俄罗斯等地都要求金融行业的信息系统必须部署在当地。例如，某商业银行进行海外应用系统建设的部署分析见表4-2。

表4-2 某商业银行进行海外应用系统建设的部署分析

（续）