实现核心银行联机事务处理、多用户支持与高数据共享

“核心银行即银行核心业务处理系统”。这样的说法，能够得到国内银行业普遍的认同。但是核心银行具体包括了那些业务系统和功能，就不一定能够达成共识。通常情况下，核心银行（Core Banking）是指银行客户信息、存贷款、会计核算等应用集合。

经过近30年银行信息化建设的历程，国内各商业银行基本完成了能够满足自身日常经营活动所需要的银行信息化体系建设。但是由于受到所处系统建设历史时期不同、资源投入差异、IT技术发展变化等因素影响，在构建核心银行系统时，各商业银行选择了适合自身发展需要的架构模式。因此各行核心银行系统架构风格上呈现出多样化的特征。就架构设计模式而言，既有面向SOA的架构，也有面向EAI的集成架构；就系统集成度和功能范围而言，有大核心系统，也有小核心系统。

作为银行最核心、最基本的综合业务处理系统，一个好的核心银行系统，对各商业银行的重用性不言而喻。目前国内银行业不同核心银行系统具备哪些共性架构特征，哪些架构设计亮点值得参考和借鉴呢？

1.大核心与小核心

应用架构设计是对特定目标系统一种体系性通用解决方案。架构设计最终是对用户各类功能和非功能需求的权衡。一个好的应用架构，必然与银行业务发展战略高度契合，结构简洁、清晰，运行灵活、高效，系统维护方便快捷、易于扩展。核心银行系统建设，无论选择那种架构设计模式，同样也应该具备上述特点。大核心和小核心系统的出现，是商业银行在不同信息化发展阶段，面对不同业务规模、IT投入资源，权衡不同的功能和非功能需求后做出的不同选择。

大核心系统强调系统集成、安全与高效，除提供银行存贷结算、客户信息等基础产品和服务外，通常会把与之关联较为紧密的辅助业务功能和管理功能捆绑在一起实现。小核心系统也称为“瘦核心”系统，强调系统松耦合、组件化，通常是指剥离了大部分辅助和管理功能，只保留银行存贷款、支付结算等银行基础产品和服务的核心交易处理系统。

因此，大核心系统相对小核心系统而言，“大”在应用系统、功能组件之间关联性相对较高，涉及业务功能和业务流程的范围较为广泛。就应用架构设计要素而言，主要是选择的关注对象和侧重点不同。与所选择的架构设计模式和风格无必然联系。简而言之，无论是大核心还是小核心，都有可能选择了层次化、组件化设计原则，都有可能选择采用了面向服务的SOA架构，也可能选择了企业应用集成（EAI）架构。所以，核心银行系统是大核心还是小核心并不关键，重要的是所选择的架构设计方法和模式，是否契合了各商业银行业务和技术发展的实际需要。

同时，需要意识到，作为银行最重用的业务处理系统，与其他银行业务系统相比较，核心银行架构设计应重点突出稳定和高效。对于变化频繁的业务功能、流程，以及产品和服务，不适合在核心银行系统中实现。所以在架构设计上，核心银行与其他银行应用系统之间，应该是松耦合的架构关系，应该采取多层次、组件化的架构设计原则。

2.联机事务管理

全天24小时，核心银行系统都需要同时面对线上线下大量客户随机发起的交易服务申请，必须时刻保障客户交易及时完成。这意味着核心银行系统是典型的联机事务处理系统（OLTP），需要具备联机交易高并发处理能力，并保障联机交易的原子性、一致性、孤立性和持久性。联机事务处理系统，其基本特征是每一个联机交易服务申请在核心银行系统中都是以一个事务的方式实时运行，通过对特定银行业务数据的新增、查询、更新处理来完成客户的交易请求。

实现核心银行联机事务处理，通常采用两种模式实现。一种模式是使用业界成熟的中间件产品，或研发统一的联机事务处理框架，由该中间件产品系统协助核心银行完成业务交易处理，使银行核心系统在功能实现过程中无须关注这些与业务逻辑无关的，只与系统运行有关、具有共性的非功能需求。从而，整体上降低核心银行系统研发难度，提高系统功能的可维护性和扩展性。另一种模式则由核心银行系统自身实现联机事务处理，在实现业务流程处理的同时，通过编码实现对联机事务的管理。采用第二种模式，其研发和维护过程是复杂和昂贵的，同时也导致核心银行系统的可维护性和可扩展性相对较差。

银行交易的事务原子性是指交易服务申请执行要么完成，要么一点也不做。例如，银行转账处理，从A账号转100元到账户B，原子性操作要求对于账户A和账户B要么全部完成账户更新，要么全部都不更新。事务的一致性是指交易执行时要保持银行信息系统数据库的内在一致性，即交易执行完毕后，执行结果的数据总是处于用户可预见状态，交易可重现可回滚，数据不被破坏。事务的孤立性是指交易的执行是相互独立的，并发交易之间互不干涉。事务的持久性是指交易处理结果，将免于系统故障。即一旦交易已经提交，它的结果就被持久保持在存储介质中，并且在系统故障恢复后有方法可以找回。

核心银行系统作为典型的联机事务处理系统，其联机实时交易的处理过程需要支持多用户、多进程，并且支持高完整性的数据共享。根据不同商业银行核心银行实际物理部署情况，核心银行联机事务管理又可以分为本地事务处理和分布式事务处理两种模式。无论采用哪种模式，核心银行系统都需要具备OLTP系统的相应特性。但是，由于分布式事务处理需要协调完成多台物理机器上的多进程，要实现联机事务处理会较为复杂。因为，在实现联机事务管理过程中必须考虑当系统发生故障时，故障点可能发生在任何进程中。故障发生时，运行在不同机器上的进程都必须被撤销，回滚还未提交的联机交易已经被执行的所有操作。分布式事务处理如图3-11所示。

图3-11 分布式事务处理示意图

联机事务管理总体架构通常包括以下管理能力。全局事务管理，提供事务启动、事务回滚、事务提交等管理功能。事务恢复管理，负责在遇到事务失败或发生异常时，进行恢复和重启的能力，以保证资源的完整性和一致性。事务日志管理，负责系统日志、通用日志记录活动。安全管理，实现对程序和交易的安全控制。通过以上能力和管理机制，实现对核心银行系统交易的联机事务处理。联机事务管理活动中交易状态主要包括成功、失败、回滚失败等状态，如图3-12所示。

图3-12 交易状态示意图

3.以客户为中心

国内银行业信息系统在银行信息化建设初期，大多以专业条线为维度构建起银行各专业信息系统，采用的是竖井式应用架构，如图3-14所示。由于系统相互割裂，跨专业、跨机构之间信息共享存在壁垒，系统之间信息流转不能畅通无阻。割裂的系统架构，导致各专业系统因业务开办需要，在系统内部分别创建自己的客户信息管理模块，完成客户信息创建、修改、使用等业务处理。客户信息的分散存储和使用，导致银行对外难以实现统一的客户服务。常常造成不同专业条线的客户服务人员多次接触和联系同一客户、反复采集客户信息。客户烦不胜烦、体验差，无法认同这种分散的、无序的银行服务。降低了客户对银行的黏性。同时，不同专业对客户信息的采集内容不同、侧重点不同、审核不同、时间不同，采集到的客户信息必然存在差异。面对同一客户多份客户信息，当银行需要跨专业、跨机构使用时，难以判断那份客户信息更准确、更具有权威性。因此，对客户的统一服务、统一评价也就无从谈起，如图3-13所示。

以客户为中心，意味着需要打破专业和机构间的“壁垒”，通过企业级的客户信息整合，实现全行客户信息统一视图、统一评价，以及跨专业、跨机构的高效联动，进而能够不断推出新的产品，为客户提供全渠道一致性体验，提供更优质的金融服务，如图3-14所示。

（1）客户信息统一视图 建立客户信息统一视图首先需要构建企业级客户信息管理系统，确保同一客户在银行信息系统中持有逻辑上唯一的客户编码，并实现统一、全面、准确的客户信息视图管理和展现。其次，在此基础上构建侧重于数据统计分析的客户信息分析系统，以提高银行经营管理水平。当完成企业级客户信息系统建设时，银行才真正具备全渠道、全产品、全业务条线一致性服务能力，才真正具备差异化、个性化市场营销服务能力。

进入21世纪，我国银行业金融机构由分业经营转向综合化经营，已成为当前银行业发展的重要趋势。不同行业领域、专业条线对客户信息的使用要求不同。结合各专业领域的客户信息特点，企业级客户信息系统需要对客户信息分层管理，并按照客户信息概念模型对客户“共性信息”和“个性信息”进行抽象提炼，形成客户基本信息、客户关系信息、客户状态信息、客户偏好信息、客户分析预测信息等信息分类模型。共性信息主要用于全行层面共性需求的实现，个性信息主要用于不同行业、专业条线、分支机构个性化需求的实现。

由于不同行业领域专业性强、客户需求多样、监管要求各异，与传统商业银行存在较大差别。因此，构建客户信息统一视图时，需要同步建立一套完善的访问权限分层控制机制。实现不同法人机构之间，以及同一机构不同专业领域之间客户信息的隐私保护。表3-2中对客户信息访问采用了三层权限控制机制。

图3-13 银行信息化建设初期客户信息处理架构

图3-14 企业级的客户信息整合示意

表3-2 客户信息三层权限控制机制

（2）客户统一评价 建立以资产、负债、中间业务等指标为主体的综合评价体系。并依托客户统一评价，将客户在银行中的各类业务交易信息进行提炼与整合，形成可以反映客户全貌的客户统一视图。

客户统一评价按照客户信息“统一采集标准、统一采集路径、统一评价计量方法”构建，形成一个跨专业、跨渠道、跨产品、全流程，动态反映客户实际情况，层次清晰、互相配合的综合评价体系，如图3-15所示。客户统一评价体系的建立，将使得客户在银行不同机构不同专业的评价标准得到统一，可以更加准确地获取客户对银行实际贡献情况。有利于建立以客户为中心的营销和销售体系，促进机构、部门间信息共享与联动营销，提升客户对银行服务满意度；有利于各级营销人员通过统一评价结果挖掘客户价值、提高产品渗透率，提高营销成功率和收益率。通过客户统一评价在信贷管理业务的应用，可以及时发现客户交叉违约风险，减少因客户风险所带来的行内利益潜在损失。

建立客户统一评价体系，首先，需要每日各渠道交易系统提供海量交易明细数据到数据仓库，数据仓库对数据分类并根据客户评价模型进行评级计算。考虑到个人客户、法人客户业务差异，个人客户和法人客户可以根据实际需要选择不同的评价模型。例如，法人客户个人客户，可以考虑采取经济界流行的EVA/RAROC企业贡献评价模型，该模型以客户效益评价为主导，辅以风险评价、营销评价和客户关系评价。

其次，需要建立客户统一评价动态管理机制，按评价周期对客户评级结果进行动态管理。对于评价提升客户，当期自动调整客户评级，对评价下降客户，可考虑采取“递延调整客户评价”的方式，缓冲客户因各种原因造成的临时性评价下降。(www.xing528.com)

最后，基于客户统一评级结果，将客户识别引导、接触营销、关系维护等流程纳入渠道服务集成。实现全渠道客户服务信息共享，以及高低柜、线上线下无缝链接，从而进一步提高银行精准营销能力。并根据客户评价模型，动态监测各分支机构客户结构组成变化、跟踪维护全行/各分行重点客户等。

图3-15 客户统一评价架构示意图

4.独立设计的会计核算系统

银行核算职能是指对银行经营活动的表述和价值数量上的确定，以货币为主要计量单位，对银行一定时期的经济活动进行真实、准确、完整和及时的记录、计算和报告，为管理经济活动提供所需的会计信息。核算系统的处理逻辑依托于会计准则，对于一个会计准则适用范围内的核算处理规则相同。而产品是银行为客户提供金融服务的载体，产品系统的处理规则会因为不同的服务要求存在较大的差异。所以银行会计核算与银行产品服务，虽然存在关联性，但在业务架构中属于银行不同业务领域。

对业务稳定性进行分析。银行会计核算功能相对稳定。而银行产品服务需要面对日益激烈的市场竞争，产品创新步伐快，产品变化频繁。根据架构设计中可变性管理和分离关注点原则。会计核算与产品系统在架构上应尽可能松耦合。因此，两者之间适合采用分层架构设计思想，将银行不同产品系统中，具有系统处理共性的会计核算功能剥离出来，在核心银行系统中建立一个相对独立、统一、集中、标准、共用的核算平台，作为银行对外服务的后台基础业务系统，支持灵活和多层次的会计核算服务。通过对账户核算信息的提炼和分析，从逻辑上把核算信息、产品信息区分开来。从而实现核心银行系统会计核算与产品应用的分离和解耦，以提高整个银行核心系统的核算灵活度。

出于系统性能考虑，核算和产品分层原则为逻辑分离，即逻辑上核算和产品信息分属于不同的应用层级，如图3-16所示。但在架构落地实施过程中，需在系统性能与系统易用性、可维护性等方面找到平衡点。因此，在物理结构上，可以根据实际需要，即可以物理分离，也可采同用一套应用节点，甚至同一数据库实例。但在代码实现层面，核算信息、产品信息应由使用不同的功能组件完成信息的更新处理。

图3-16 核算与产品分层逻辑关系示图

基于层次化、组件化设计理念，会计核算系统内部同样也可考虑采用分层架构设计，如图3-17所示。将影响会计分录的会计事件，按产品、分户账等重要信息进行归纳抽象，构建核算引擎用于核算解析。当产品账户发生交易时，核算引擎能够根据产品交易事件信息，确定具体的产品，自动提取与会计核算相关的信息，并根据预先设定的核算规则，自动将采集的数据转化为会计分录，完成账务处理。核算规则发生变化时，只需调整核算引擎中的参数化转化规则，而不需要对产品层进行调整。反之，当产品层发生变化，如新增产品时，只需要在核算引擎中定义相应的转化规则，核算层即可据此完成对此产品的核算处理。

图3-17 产品层和核算层分层架构示意图

5.分层设计的核心交易公共服务

介质是客户获取银行服务的媒介，它是客户访问标识（AccessID）的载体，任何客户要与银行打交道时，必须首先向银行提供他的访问标识（AccessID）。银行通过对访问标识（AccessID）及相关认证信息的鉴定，确定来者是谁，能替他提供什么的服务。介质包括实物介质（卡、存折、存单）和虚拟介质（虚拟卡、登录ID等）。

协议包括产品协议、客户服务协议。本文所述的协议主要是指产品协议。产品协议是产品的实例，明定其中一方自另一方取得产品使用权。一个产品可对应零到多个产品协议，一个产品协议只可对应一个产品。介质与协议关系如图3-18所示。

账户是用于监控货币及非货币数量变化的储存分类，代表经济业务发生后引起资金或非资金运动数量的变化。

存贷结算等银行传统金融服务，在开办之初产品结构和办理渠道单一，介质与账户结合紧密、一一对应。因此，银行在信息化系统建设过程中，往往将介质和账户统一设计、功能统一实现、数据统一存储。这样的设计模式，在银行信息化建设初期，因业务需求较为简单，系统研发和运行效率高。但是，随着我国改革开发的深入，金融服务逐渐呈现多样化、个性化特征。所有涉及介质信息、介质协议信息的产品创新需求，都需要同步修改银行账户体系和核心账务交易。这样的设计和研发模式，大大增加了项目研发难度和风险，如图3-19所示。

图3-18 介质与协议关系

图3-19 介质与账户耦合示意

根据业务使用场景分析，客户要获取银行服务，直接面对的是银行各种渠道，并通过介质与银行之间建立联系。介质作为客户获取银行服务的媒介，与客户信息、使用渠道、银行协议同时存在关联关系。因此，要避免相互影响，只有采用松耦合设计思想，将介质作为公共服务单独抽离出来，才能避免因为渠道访问权限、客户访问权限、客户个性化服务、新产品等业务创新，同时频繁修改渠道信息、介质信息、协议和账户信息，如图3-20所示。

图3-20 介质与渠道分离示意图

介质、协议、账户三者分离，将降低应用系统耦合度，使业务逻辑更加清晰。核心银行采用分层设计，建立介质层、协议层和账户层。将介质、介协关系从银行账户体系结构中抽离出来，在介质层、协议层和账户层分别抽取形成介质、协议、账户公共服务。在介质、协议未分离的情况下，介质与协议关系固定，限制某些与介协相关的产品创新业务功能的实现。分离后，介质与协议之间松耦合，可以根据业务创新需要，实现一对多、多对一和多对多灵活的介协关系。将介质信息、协议信息从银行账户体系中抽离出来，可以保证账户结构和功能的稳定，从而保证核心账务处理构件和服务的稳定。同时，介质与协议的分离，可以理顺介质、协议和账户在业务架构中的作用和位置，有利于服务的识别、规约和暴露。

介质、协议分离后，在介质层可以建立介质权限统一视图管理。实现对银行介质服务权限和客户个性化权限的统一管理模式。例如，采用“产品服务+客户个性化定制”模式，分别实现银行服务和客户个性化定制。按照不同产品服务，定义客户介质下的一个或多个账户的操作权限；客户个性化定制模式，在不同产品服务基础上，客户定义介质对具体账户的操作限额、交易默认账户等管理信息。

套餐定义示例见表3-3。

表3-3 套餐定义示例

客户个性化定制示例见表3-4。

表3-4 客户个性化定制示例