本文详细介绍了我国银行更换核心系统的银行原因，以及新核心建设的核心五大模式与其特点对比。希望内容能够帮助银行科技从业者建立起对银行核心系统的系统整体认知，提供一定积极的建设指导作用与借鉴意义，从而引发思考并促进行业交流与探讨，模式共同为我国的银行银行科技蓬勃发展贡献自己的智慧与经验。

一、核心银行核心系统更换的系统原因分析

介绍完我国银行核心系统的发展历程，银行可以结合现有系统的建设使用情况以及产品和服务革新需求、转型急迫性等方面，模式全面掌握自身所处的银行状况并结合当前基础设施、市场动态、核心客户需求和组织能力等方面，系统决定银行核心系统的建设实施路径。

例如，模式观望（不作为）、升级（涉及较小的应用程序功能或技术变更）、重构（主机下移或转Java等提升系统的现代化）、增强（部署一个并行的核心系统运行一系列的差异化服务）、更换（以现代化的解决方案替换现有核心系统，即建设新一代核心系统）。

针对更换核心系统的原因，站在银行的角度进行分析，主要从以下维度进行思考：

功能：系统技术非市场主流，与主流技术对接产生障碍；因为银行的合并，现存的任何一个核心系统无法对应不同文化的银行多样应用系统整合的需求；

风险：每一代的银行面对的社会经济活动不同，对系统的架构与应用要求产生结构性的影响，必须以重建的思维从根本解决；业务规模（业务量、经营范围）扩大，旧系统无法应对；

运维：旧系统厂商退出市场（硬件、软件）；因为希望合并迅速整合完成，急急忙忙的系统整合，导致旧系统降低服务水平，缩短原系统寿命；核心系统生命周期，因为科技与社会经济活动改变而逐渐缩短；

成本：旧系统的应用系统时间久了打满补丁，新的需求开发费时费力；旧核心系统成本贡献比逐渐升高，特别是主机型系统用户；

收益：核心系统经营管理模式随着科技与应用的改变，产生多样的核心系统经营方式可供银行依据自身条件（规模、人力、成本、效益）选择（自建、购买、托管）；

组织：旧系统开发、维护人才逐渐凋零，借着新系统的开发培养下一代的接班技术人才。

二、银行核心系统建设的五类原则

银行的金融交易涉及到客户资金运转，在国民经济发展中处于特殊重要地位。所以银行的业务特性决定了银行对交易和数据的及时性与一致性要求非常高，必须准确、不可丢失，安全性、可用性、可追溯，更是互联网金融企业无法比拟的。

例如，对于外汇业务，利率的实施变化决定了相关业务要实时相应，如果时效性、准确性达不到要求，就会给客户或银行带来损失。再如，在证券行情实时变化时，银证转账如果不能满足要求，可能会给客户带来巨额损失；一些大额的转账或汇兑如无法满足时效性及一致性，可能给客户的资金使用带来风险。当然，互联网企业的优势（如海量服务能力、注重客户体验、大数据服务能力等）也是传统商业银行转型必须具备的。

及时性：是指要及时响应客户的交易行为，避免可能带来的损失。因为银行系统的处理能力与银行规模和科技投入有关，所以主要从银行核心系统的几个关键指标来了解自身发展情况和目标，如响应时长、每秒事务处理数、每秒请求数等。

响应时长（RT）：从发出请求到得到响应的耗时，即从前端界面按交易提交键、到处理结果并反显全部信息到前端界面之间的时间间隔。一般可以采用毫秒单位来表示，而对一些RT比较敏感的业务场景下，可以使用精度更高的微秒来表示。每秒事务处理数（TPS）：每秒能够处理的事务数，其中T（Transactions）可以定义不同的含义，它可以是完整的一笔业务，也可以是单个的接口请求。每秒请求数（RPS）：也可以叫做QPS，但它与TPS有所不同，前者注重请求能力，后者注重处理能力。不过，若所有请求都在得到响应后再次发起，那么RPS基本等于TPS。数据库性能：指的是有关数据库的指标，比如资源超时、资源死锁、数据库连接、内存泄漏等。

一致性：在分布式银行核心系统中，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致性的状态下执行更新操作后，应保证系统的数据仍然处于一致。提到一致性就离不开分布式事务、缓存等，就不逐一展开了。

安全性：是指通过信息安全建设和管理，有效控制和防范信息安全风险，确保企业与客户的信息及资金安全。主要包括机房、网络、数据、系统、制度等安全方面进行保障。

高可用：是指系统提供的服务必须一直处于可用的状态，所有处理环节避免单点故障，当故障发生时可以快速恢复，如果在故障发生时具备故障隔离或备灾备容错能力，如多活并行处理、两地三中心等，RPO（Recovery Point Objective，恢复点目标）、RTO（Recovery Time Objective，恢复时间目标）等指标无限趋近于零。

如下表：

可用水平（%），通常都包含了信息系统计划停机的时间，即为了系统维护、新版本投产等原因，人为主动的让系统停止对外提供服务。因此，要提高可用水平，需要减少系统的计划停机时间。

可追溯：是指金融交易的所有业务操作都要保留日志数据，做到信息流的可查、可追溯、可审计，也是监管的要求。

三、银行核心系统建设的五大模式

在银行IT系统中，银行核心系统建设是整体支出占比最大、最为复杂，对于技术要求最高的工程，需要持续投入非常多的资金与人力资源，而且还涉及到全行各关联系统的配合或同步改造，项目建设周期往往少则一年，多则两三年。

采取什么样的模式来建设新核心系统，如何在本行能够承受的前提下投入财力和人力，使系统建设既能对标同业又要符合实际发展情况，并能够满足未来银行业务快速发展的需要，一直是一个困扰许多银行决策层的难点问题。

银行新核心系统的建设模式大致可分为五种，分别是外购或外包产品、完全自主研发、主导研发、项目研发外包和应用系统托管。对于采取哪种研发模式，需要综合考虑诸多因素择优选择，切不能一概而论。在规划中要提前明确和定位建设模式、合作伙伴以及维护方式等。

通常是银行自身IT有强大的技术能力的大行，研发团队越成熟，越应该走自主研发的道路。反之，中小型银行的自身IT规划能力及建设能力不太强，并要支持下一步的业务创新及快速实现业务需求有一定难度，采取外购外包模式，与合作伙伴共同实施核心系统建设是一个更好的选择。不仅银行可以用更低的成本获得更好的技术和服务，并可以使自身在人员缺乏的情况下，将更多精力集中在需求分析设计、项目规划与服务监控上，从而更好的推进核心项目的建设。

另外，银行核心系统产品从纵向解剖，自底而上通常可以分解为基础设施、技术平台、应用模块三大部分，越是基础的越能通用，越靠近应用越要定制，否则做出来效果不好，并且结合外包、自主研发多维度统筹考虑。

1、外购或外包产品对于科技力量薄弱、自身研发能力不足，业务规模在一两年内甚至几年内预估不会爆发增长的小银行，采取外购或外包产品的模式更加合适。它们没有多少IT人员，忙于日常如协助各个部门查数据、打印报表或结单、分析生产问题，或承接以运维类、报表类等低价值开发工作为主，没有多少剩余时间进行研发与创新、甚至是学习或吃透其服务商产品的做法或优点。

除了外购产品更成熟或先进之外，银行核心系统上线或更换速度更快，比如偏互联网银行基本保持在半年内，主要还是相关项目由于是新做，没有负担，所以周期短。

还见过银行直接外购整个银行IT系统，拆除科技部，直接将信息科技的运维都外包给相关的机构，也是一种更经济的可选择的方式，或者一种过渡的方式。

当然，有利必有弊，该模式需认真分析以下三点：

是否适合国情、行情：银行核心系统是一家银行的引擎、发动机，也是一家银行科技实力的重要体现，同时也服务于银行的战略、业务和组织架构、以及监管政策和法律法规。而不同国家、不同银行有非常不同的目标、形式和历史原因。例如，国内外的核心系统差异巨大，直接拿来使用可能会水土不服。

差异化开发及维护成本：外购的产品通常要适合本行特色业务，从而进行差异化开发或修改，差异化需求越大越多，修改和测试的工作量就越大，可能会影响上线期限。当系统上线进入了维护阶段，服务商会有半年到一年的免费维保期，但对新增需求的分析、设计、开发等方面要单独算费用，因为过渡依赖存在不确定风险，故议价能力很弱。基本上是，维护成本占了系统建设整个生命周期所需费用的大头。

系统间整合：指的是系统之间没有统一的数据标准，使得银行的数据信息零乱分布，既有冗余又有缺失，或数据更新不同步，数据一致性无保障。比如有些银行将核心系统进行拆分，单独外购贷款系统或分散外购，不同的厂商框架或标准不一样，若没有统一标准或长远规划，不可能提供高质量的信息服务。

该模式适用的银行范围有：部分中小城商/农商、民营银行、外资银行，而且部分银行会要求产品能简单部署在云平台上，在自主可控方面陆续要求集成国产数据库。当然，有相当研发能力的金融机构也不是绝对不能外购。

2、项目研发外包项目研发外包模式使用较多，是指“外购产品+改造实施”的方式建设新核心，也可称为项目外包，即在服务商的业务与技术人员入场前，确定好外包范围和外包金额，银行方不再太关注外包公司实际投入资源，而是重点关注项目质量和进度。

在项目实施过程中，银行会根据里程碑计划的执行情况和行内自主掌控要求，选派不同程度的人员参与需求分析和设计及评审或部分开发工作，具体的研发还是以服务商为主。

服务商目标和责任明确，银行方投入精力小，有利于银行拥有自主知识产权或者是共有知识产权。缺点是立项采购拉长了项目实施周期、银行自有研发规范较难落实、项目质量受制于服务商实施团队的能力，多家外包伙伴时沟通成本较大。

随着银行规模增大，可能还会衍生出多家服务商合作外包的方式做项目，降低对单个服务商的依赖，将可能造成的损失降到最低。

在项目前期，通常还会增加咨询公司对本行的业务进行梳理和优化。银行对自身业务把握清晰，但对未来发展和业界的领先实践无法与咨询公司相提并论，只有通过专业的理念和服务将业务分析透彻，才能很好指导后期的系统设计与开发工作。

其次，核心系统项目建设牵涉到银行很多部门和组织，难免会有利益冲突与工作的协调配合，借助第三方专业的视角和可观的角度能更高效的协调和解决问题。

该模式适用的银行范围有：部分中大小城商/农商，其主要述求是替代掉原有的老旧核心系统，建立起产品的业务模型和架构建设，在自主可控方面部分银行会要求集成国产数据库。

3、自主研发对于大型金融机构来说，银行IT在逐步去外包化，尽管还存在外购系统的情况，但更多的是希望能掌控系统从而解决外购系统的重重束缚，或是完全自主研发代替外购或外包产品。为积极响应国家对金融核心领域技术自主可控的要求，银行IT走自主研发的道路是必经之路。

不仅能完全使用本行的战略、业务和组织架构，而且国内金融IT厂商技术力量相对薄弱，很多高水平毕业生不做外包，当行里研发队伍的规模和素质达到一定程度，系统上线周期会快于外购系统。

算上研发人力费用、固定资产折旧、办公费用、系统维护成本等，从整个产品生命周期看，自主研发总成本通常要低于外购产品。

该模式适用的银行范围有：国有大行、股份制、大农信、部分中大城商/农商行，大多数原有核心采用AS400或大机的银行希望采用重构的方式完成核心下移，部分银行会要求基于云平台进行核心系统重构，在重构的规划或过程中强调自主控。

4、主导研发除了大型商业银行，其他银行规模相对比较大，研发团队有较强的研发能力，但不具备完全的自主研发能力。那么，可以采取介于完全外购外包与自主研发之间的近自主研发的系统建设模式。

主导研发包括自主定义系统的架构、数据标准、接口标准、数据交换规范，以及系统设计、数据库设计、流程设计等，项目与技术经理要由银行研发人员担当，便于日后能主导所有系统维护工作。

银行进行外包采购的是“人力外包（俗称买人头）”。人力外包是以人力劳动时间为主要目标的外包方式。一般以开发工时为结算依据，银行负责选人、分派任务、结果验收。

其优点是项目可快速进入实施阶段、使用人工灵活，有利于自主掌控，研发规范管理更好，知识传承和连续性保障较好。缺点是银行的管理难度高，外包人员流动性较大、缺乏对团队的归属感和认同感。此外，如何客观评价外包人员的劳动效率也是一个难题。

在人力外包的情况下，衍生出了新的形式用于严格规范对人力外包的管理，防止外包人力工作量不饱和。

比如以任务单的形式实施小微型项目外包，便于对人力外包的事前控制，要求从外包资源池中申请外包人力时，必须提出具体的工作内容和预估工作时长，并形成研发任务单。同时，管理难度有增加，需要明确评估每一个任务的工作量。

5、应用系统托管上述提到的四种核心系统建设模式，基本都是一个银行拥有一个自己的系统。还有一种模式是“应用系统托管”，可以理解为多法人机构共享的核心系统。

对于中小型金融机构或新成立的银行，要新建一个仅供自己银行使用的核心系统并进行日常的运维不容易，所谓麻雀虽小，五脏俱全，总体投入成本较大。

因此，2009年左右出现了银行间共享合作平台，各参与行共同建设，从调研论证、项目立项、需求分析、开发、测试到上线后的运维，成员行公共参与并实践，因此减少了研发过程中的重复开发，节省掉研发费用后均摊成本，将用户利益做到最大化，最终为金融机构提供各种所谓金融服务。

随着涉及金融云服务的快速发展，云服务企业已成熟，如山东城商行联盟、兴业银银平台、神码金融云等，其应用系统托管的模式帮助中小城商行、民营银行解决了发展过程中各种各样的难题。

结束语

关于我国银行核心系统定义、边界与位置，我国银行核心系统整个发展历程、更换核心系统的原因和原则，以及新核心的建设五大模式就介绍完了。

相信对于初学者来说，已经逐渐建立起了对银行核心系统领域的整体认知、搭建起了属于自己的第一层级知识树。对行业同仁来说，对目前银行核心系统发展到分布式微服务的模式有了更深的理解，当然很多实现的模式所带来的问题与机会需要继续思考，也包括业内各大服务商正研发的云原生核心系统等，都还需要在实践与使用的过程中不断研究与探索，从而更好的权衡利弊、更进一步的追寻方案最优解。

最后，谢谢您的耐心阅读。也欢迎分享自己的见解或想法，写作过程中很多时候是在讨论、学习与思考过程中形成的观点，文章的内容会根据反馈做适当调整，定期也会更新。如果觉得有所收获的话，请转发评论点“在看”，分享一下朋友圈吧~

参考书籍与报告：

1．梁礼方．《银行信息科技》，2015年

2．吴军．《商业银行外部研发资源管理探讨》，2016年

3．牛新庄．《商业银行分布式架构实践》，2019年

4．德勤．《数字化时代下的核心银行转型》，2019年

5．网商银行技术编委会．《金融级IT架构》，2021年

6．雷小寒．《银行核心系统建设再提速》，2021年

7．阿里云．《“核”聚变—核心系统转型之路》，2022年

（来源：文章来源于小代嘚吧嘚，作者代堂鸣）