分布式重构、交易核算分离与AI落地的真实边界

周二·核心银行系统深研

研究类型：周二《银行业务·组织·Core·银行IT Deep Dive》 日期：2026-09-29 研究对象/领域：核心银行系统（Core Banking System）及其中国落地 核心问题：核心系统如何运转、为何必须分布式与国产化重构、AI 在哪些环节是真价值而非叙事 证据口径：截至 2026-09-29，政府/监管/央行、上市公司年报、银行官方披露、IDC/赛迪/IBSi 等第三方、权威媒体与行业研究；关键数字标注置信度标签

---

一、研究锚点

核心银行系统（Core Banking System，下文称"核心系统"）是商业银行最底层、最不可中断的 IT 系统，承载存款、贷款、支付清算、总账、客户信息等"记账心脏"职能。它不直接面向客户做营销，却决定每一笔钱能不能记对、能不能实时到账、能不能在监管口径下对平账目。

本报告的切入点是：在 2027 年底前央企信息化系统信创替代的硬约束下，六大行与全国性股份行已用数年时间把运行了二十年的集中式主机核心，逐步替换为分布式、国产化、单元化的新核心。这场重构的真实动机、技术代价、失败案例与 AI 能真正改写的环节，比"去 IOE"叙事本身更值得解剖。

二、执行摘要

[[墨青:核心系统的本质是一家银行"能否把账记对、记快、记稳"的底线能力，它的重构不是技术赶时髦，而是零售化高并发、主机授权成本、信创合规与业务敏捷四股力量共同挤压的结果。]]【已确认】

中国银行业 IT 投资 2024 年达 1693.15 亿元，预计 2028 年达 2662.27 亿元；银行业 IT 解决方案市场 2024 年 713.05 亿元，预计 2029 年达 1039.39 亿元，五年复合增长率 7.8%。[[金棕:713.05→1039.39 亿元，CAGR 7.8%]]【计算·高】这笔钱的一个核心流向，就是对运行二十余年的 IBM 主机 + Oracle/DB2 数据库 + COBOL 程序的核心系统做分布式与国产化替换。

工商银行 ECOS 工程历时六年，把超 10 亿借记卡账户与客户信息、会计核算、账户体系从主机下移；邮储银行新个人核心峰值 TPS 67000、联机 65 毫秒、日终 197 分钟、结息 25 分钟，较旧系统分别改善 30%、28%、82%。[[金棕:峰值 TPS 67000、结息 -82%]]【已确认】建设银行 2024 年 7 月完成境内外核心系统全部分布式下移。

读者向解读：上述数字说明一件事——核心系统重构是真实发生的工程，不是 PPT 概念。但数字背后要分清"性能改善"和"风险消除"是两件不同的事：邮储的结息时间从 140 分钟降到 25 分钟，是分布式架构的红利；而 TSB 银行 2018 年一次核心迁移失败，导致 13 亿条客户记录出错、赔偿约 29 亿元人民币、监管罚款 4865 万英镑，说明核心系统的"稳"远比"快"难。本报告后续会反复回到这个张力：重构能带来敏捷与自主可控，却也把银行置于数据迁移与双轨并行的生死博弈中。

三、研究对象基本面画像

3.1 领域定义与边界

[[定义:核心银行系统]]是银行处理"客户账户与账务"的中枢系统，覆盖存款、贷款、支付清算、总账、客户信息（CI）五大基础职能。它的边界是：凡是涉及"钱从哪个账户、以什么科目、记多少、记到哪本账"的操作，最终都要落在这套系统里。周边系统（信贷系统、网银、手机银行、支付网关、理财）产生的交易，最终都要把"记账指令"送回核心系统完成落账。

核心系统不等于"银行全部 IT"。它刻意保持"瘦核心"：只管账户与账务，把产品创新、渠道交互、风控决策放到外围。邮储银行新核心明确以"瘦核心"为建设目标，正是这一边界划分的产物。

3.2 市场规模与玩家格局

中国银行业 IT 投资 2024 年 1693.15 亿元，较 2023 年增长 3.6%，预计 2028 年 2662.27 亿元；IT 解决方案市场 2024 年 713.05 亿元，同比增长 2.9%，预计 2029 年 1039.39 亿元。[[金棕:IT 投资 1693→2662 亿元（2024→2028）]]【计算·高】

全球核心银行软件市场 2025 年约 131 亿美元，预计 2030 年近 300 亿美元。[[金棕:全球核心软件 131 亿美元→300 亿美元（2025→2030）]]【计算·高】主要玩家：Temenos（连续 20 年 IBSi 核心银行销量第一，2025 年营收约 11.5 亿美元、份额约 8.8%）、Oracle FLEXCUBE（全球约 10% 份额、600+ 客户、140 国、客户留存率 >95%）、Infosys Finacle、FIS、Finastra、TCS BaNCS，以及中国厂商长亮科技、神州信息、宇信科技、中电金信、科蓝软件、恒生电子。

3.3 技术架构演进主线

核心系统的架构演进分四代：纯手工记账 → 会计电算化（交易驱动核算）→ 交易与核算紧耦合的集中式主机 → 交易与核算分离的企业级分布式核心。当前六大行与头部股份行正处于第四代建设期，中小银行多在第二、三代之间。技术底座从"IBM 大机 + Oracle/DB2 + COBOL"转向"通用服务器 + 国产/开源分布式数据库 + 微服务/单元化 + 云原生"。

3.4 监管与合规要求

监管对核心系统有两条硬线。一是连续性底线：核心系统要求 7×24 小时、可用性目标 99.999%（全年停机不超过 5.26 分钟）。二是自主可控硬约束：国资委 79 号文要求 2027 年底前实现央企信息化系统安全可靠替代，金融信创从外围应用向核心应用加速渗透；人民银行 JR/T 0204-2020《分布式数据库技术金融应用规范》从技术架构、安全、容灾三方面给出金融级标准。等保三级、商用密码应用安全性评估、数据分类分级贯穿选型全过程。

3.5 竞争位置与主要替代方案

核心系统的"替代方案"有两层含义。一是技术路线替代：集中式（电科金仓、达梦，与 Oracle 高兼容）vs 分布式（OceanBase、GoldenDB、TDSQL）vs 云原生（PolarDB、TDSQL、GaussDB）。二是厂商替代：国际厂商（Temenos、Oracle、Infosys）与国产厂商（长亮、神州信息、宇信、中电金信）在不同客群各有占位。国产厂商在中小银行与信创场景占优，国际厂商在跨国银行、多币种、复杂合规场景仍具深度。

3.6 关键经营/技术指标一览表（3–5 年）

主体	指标	数值	口径/时点
中国银行业 IT 投资	规模	1693.15 亿元（2024）→ 2662.27 亿元（2028E）	IDC，CAGR≈12%
银行业 IT 解决方案	规模	713.05 亿元（2024）→ 1039.39 亿元（2029E）	IDC，CAGR 7.8%
邮储新个人核心	峰值 TPS / 联机耗时 / 日终 / 结息	67000 / 65ms / 197min / 25min	2022 投产，对比旧系统
工商银行 ECOS	节点/容器/日均调用/对公 TPS	26 万节点/60 万容器/200 亿次/20 万 TPS	2025 云平台
长亮科技	营收/净利/合同/海外占比	17.36 亿/-9.46%、净利 1858.6 万/-42.18%、合同 22.9 亿/+16%、海外 20%	2024 年报
神州信息	营收/金融科技/金融软服	100.03 亿/-17.03%、金融科技 49.12 亿、金融软服 36.80 亿	2024 年报
Temenos	营收/份额/客户	11.5 亿美元/8.8%/3000+ 客户	2025 估算
Oracle FLEXCUBE	份额/客户/留存/毛利率	10%/600+ 客户/95%/>32% 净利率	2025

四、关键术语与概念底座

[[定义:核心银行系统（Core Banking）]]：银行处理账户与账务的中枢，负责存款、贷款、支付清算、总账、客户信息的最底层记账，是"账记在哪、记多少、记到哪本账"的最终落点。

[[定义:瘦核心]]：刻意把核心系统收窄到只管账户与账务，把产品、渠道、风控放到外围系统的设计原则，目的是让核心稳定、让外围敏捷。

[[定义:交易与核算分离]]：把"与客户发生的业务动作"（交易系统）和"按规则生成会计分录"（会计引擎/总账）拆成两套系统，交易系统只管业务，会计引擎统一出账。

[[定义:会计核算引擎]]：一套参数化配置的规则系统，把交易系统送来的业务事件映射成会计分录，再传给总账，使产品创新和准则调整不再牵动核心代码。

[[定义:单元化（Unitization）]]：把客户按维度（如客户号哈希）切分到多个结构相同的"部署单元"，每个单元独立承载一部分流量，扩容量只需复制单元，是分布式核心横向扩展的基石。

[[定义:去 IOE]]：摆脱 IBM 小型机、Oracle 数据库、EMC 存储的技术依赖，改用通用服务器与国产/开源替代，是核心系统自主可控的前提动作。

[[定义:双轨并行]]：新旧核心在迁移期同时运行、数据实时或准实时同步，一旦新系统异常可秒级切回旧系统，是核心迁移的"逃生舱"。

[[定义:主机下移（MIPS→开放平台）]]：把原本跑在 IBM 大型机上的账户、核算等核心功能，逐步迁移到基于 x86/ARM 的分布式开放平台，降低主机授权与运维成本。

[[定义:日终批处理]]：银行白天做联机交易，夜间集中跑结息、计提、总分核对、报表等批量作业，是核心系统最吃算力的时段。

[[定义:冲正/回滚]]：一笔交易因异常需要撤销或回退到之前状态的操作，是账务一致性的最后兜底机制。

[[定义:热点账户]]：某些高频账户（如红包入账、清算过渡户）被海量并发读写，是分布式架构下最易击穿一致性的典型痛点。

[[定义:强一致性 vs 最终一致性]]：强一致性要求每笔读写都读到最新已提交数据（金融记账的底线）；最终一致性允许短暂不一致、事后对齐（多用于非账务场景）。

[[定义:信创（信息技术应用创新）]]：以国产芯片、OS、数据库、中间件替换国外产品的国家自主可控战略，金融是推进最快的关键行业。

[[定义:CAP 定理]]：分布式系统在网络分区发生时，只能在一致性（C）与可用性（A）之间取舍，核心系统通常优先保一致性。

[[定义:影子系统]]：在测试环境构建与生产一致的系统镜像，用真实流量回放提前暴露 SQL 差异与性能瓶颈，降低上线风险。

[[定义:LLM/大模型幻觉]]：大模型基于概率生成内容，在缺乏确定数据或语义混乱时可能"一本正经地胡说"，在容错率为零的金融核心场景是致命缺陷。

五、业务模式与价值链条（零背景读者可独立读懂）

假设你完全不懂银行 IT，这一章让你十五分钟读懂这门生意。

这门生意卖什么：核心系统不是银行给客户用的 App，而是银行自己内部那套"记账总账房"。你到银行存钱、借钱、转账，背后都有一套系统替你把"谁、在哪个账户、进出多少钱、记到哪本账"逐笔算清楚。核心系统就是这套账房。银行要么自己养几百上千人开发维护（六大行多自研），要么花钱请长亮、神州信息、宇信这类厂商帮它建一套（中小银行多外购）。

谁掏钱、为什么掏钱：掏钱的是银行（甲方），底层推力是三个——第一，老账房（IBM 大机）每年授权费上亿，用国产替代能省下这笔钱；第二，国家在推信创，要求 2027 年前关键系统自主可控，不换有合规风险；第三，零售业务爆发，老账房应付不了"双十一"级别的高并发。三者叠加，银行才肯拿出几亿甚至十几亿做这套替换。

一笔生意怎么流转：厂商先跟银行签合同（长亮 2024 年合同额 22.9 亿元，同比 +16%），派几百人进场做业务建模、写代码、搭分布式底座；银行提供真实环境与数据；两者联合调试数月到数年；上线后厂商还要做几年运维。钱分几笔收：签约预付款、里程碑付款、上线款、多年运维费。

卡在产业链哪环：核心系统处在银行 IT 的"地基"位置，上面叠着信贷、网银、风控、理财等几十套外围系统，下面压着数据库（OceanBase/TDSQL/GaussDB）、服务器、操作系统。离了它，银行一天都开不了门；它坏了，全行交易中断。所以它是"不可中断的地基"，迁移极度慎重。

和对手差在哪：国产厂商（长亮、神州信息）的优势是懂国内监管、交付快、成本低、能陪银行做长期定制；国际厂商（Temenos、Oracle）的优势是产品成熟、覆盖多国多币种合规、全球化银行认。对一家城商行，长亮可能比 Temenos 更合适；对一家做跨境业务的银行，Oracle FLEXCUBE 的 3000+ API 与多国合规包更有吸引力。差异不在"谁更先进"，而在"谁的账本规则与你的客群、监管、预算更贴"。

六、核心问题与分析边界

本报告聚焦三个问题：第一，核心系统内部"账怎么记对"的机制，以及交易与核算分离为何成为架构升级的枢纽；第二，从集中式主机到分布式单元的重构，真实解决了什么问题、付出了什么代价；第三，AI 在核心系统与周边风控中，哪些是真落地、哪些仍是叙事。

边界声明：本报告不覆盖银行全部 IT 架构（如数据中台、信贷系统细节单独成题），不评判单一厂商股价，不对尚未公开的核心迁移内部故障做归因。涉及海外厂商的数据以公开年报与第三方榜单为准，部分全球份额为估算值，标注【推断·中】。

七、核心机制：账务核算引擎与交易核算分离

7.1 现象

传统核心系统是"交易与核算紧耦合"：一笔存款交易发生时，系统同时完成对客服务与生成会计分录，两套职责绑在一起。结果是新产品上线要改核心代码，海外分行用不同会计准则要另购系统，2018 年新金融工具准则（四分类变三分类）时，耦合系统要逐个业务系统改核算规则。[[暖红:紧耦合使核心系统同时承担对客与核算双重职责，产品创新与准则调整都被核心代码锁死。]]【已确认】

7.2 因果链

银行业的"以客户为中心"转型要求前台极速响应、产品快速上线，而紧耦合让每次产品创新都变成核心改造工程，开发测试周期被拉长。同时集团化、国际化要求一套交易数据在不同会计准则下出不同账，紧耦合架构无法低成本满足。这两股力量把"解耦"从优化项逼成必选项。

7.3 证据

农业银行、工商银行、建设银行、浦发银行已采用企业级独立会计核算引擎；中国银行、中信银行分别通过核心内核算模块完成分离；邮储新核心以"瘦核心 + 会计引擎 + 大总账"为设计；昆山农商银行 2021 年 8 月新核心同步上线会计引擎，核心查询交易响应降到 100 毫秒内、季度结息约 17 分钟、日终批量从 3 小时缩至 10 分钟。[[金棕:昆山农商日终 3 小时→10 分钟]]【已确认】

7.4 反证与边界

M 银行是国内首家实现企业级重构与交易核算彻底分离的案例，但实施周期过长，说明彻底分离代价高昂，多数银行采取"渐进分离"而非一步到位。部分国外采购软件代码不开放，剥离核算功能成本大于收益，只能保留原模式用会计分录对接引擎。[[暖红:交易核算分离不是越彻底越好，实施周期与改造成本是硬约束，渐进式更现实。]]【推断·中】

7.5 结论与读者向解读

交易核算分离的本质，是把"业务动作"和"记账规则"拆开：交易系统只管业务，会计引擎用参数配置把业务事件变成分录，准则变了只改引擎不改业务。这意味着银行上新产品、海外设机构、准则调整，都不再牵动核心代码。对读者而言，这一机制解释了为什么六大行能把"上新业务"从数月缩到数天——不是科技变魔法，而是把记账职责从核心里抽出来、集中到一套可配置引擎，让核心回归"稳"，让外围回归"快"。

7.6 一个记账实例：存款开户如何不出分录

客户存入 1 万元现金，交易系统记录"现金收讫、活期存款 +1 万"，但不自己写会计分录；它把"业务事件（存款、金额、科目要素）"传给会计引擎，引擎按预先配置的规则生成分录：借：库存现金 1 万 / 贷：单位（或个人）活期存款 1 万，再送总账过账。若监管要求新增"存款保险标识"维度，只需在引擎改参数，交易系统零改动。[[墨青:交易系统只产生'发生了什么'，会计引擎决定'按什么规则记'，两者通过'核算要素'这一薄接口解耦，是分离架构可落地的最小技术契约。]]【推断·中】

八、典型场景复原（E2E 多流同步）：一笔对公贷款

下面复原一笔对公流动资金贷款从开户到回款的全链路，展示实物流、商流、资金流、单据流、会计流、数据流如何同步。

触发：某制造企业（借款人）向银行对公客户经理提出 1000 万元流动资金贷款需求，用于采购原材料。

参与者：借款人、对公客户经理、授信审批官、风险官、核心系统、信贷系统、会计引擎、总账、人行征信/中登登记系统、放款中心。

获客与准入：客户经理收集营业执照、财报、征信授权，信贷系统发起准入，调用人行征信与司法数据做初筛。单据流：申请书、财报、征信授权书；数据流：征信查询落库。

授信审批（多流同步）：风险官基于财报与押品做评级，信贷系统生成授信方案，会计流尚未发生；资金流未发生；核心系统冻结授信额度。此环节通常仍由人终审，AI 仅做材料解析与预警辅助。

合同签订：双方签借款合同与抵质押合同，中登系统登记押品（单据流 + 数据流外发）。

放款：借款人提款，信贷系统向核心系统发"放款记账指令"，核心系统记贷款发放（借：贷款—本金，贷：单位活期存款），会计引擎生成分录、总账过账。资金流：银行活期存款增加 1000 万（负债），贷款资产增加 1000 万（资产）。单据流：放款通知书、借据。

计息与存续：核心系统按日计提利息（会计流：借：应收利息，贷：利息收入），按月结息。存续期间风控系统持续监测借款人经营指标，触发预警则人工介入。

还款：借款人按期还本付息，核心系统记账（借：单位活期存款，贷：贷款—本金 / 应收利息 / 利息收入），资金流回流银行。

异常与补偿：若借款人违约，触发减值（IFRS9 预期信用损失 ECL 计提），会计流记信用减值损失；若放款指令异常，核心系统冲正回退到放款前状态。

控制闸门：授信额度冻结、放款前押品登记校验、核心记账与会计引擎总分核对（日终批处理做总分户对账，不平则挂账待查）。

映射到三张表：放款使资产负债表"贷款 +1000 万、存款 +1000 万"同步扩张；计息使利润表确认利息收入；还款改善现金流。一笔贷款从申请到回款，至少跨越信贷、核心、会计引擎、总账、征信、中登六套系统，任何一套对账不平都会被日终批处理捕捉。

8.6 组织职责映射：谁对核心系统的哪一段负责

核心系统不是科技部门一家的事，它把银行前中后台的职责重新切了一遍，这正是周二模式要求建立"业务→组织职责→产品/流程→风险会计→数据→领域系统→Core→IT 架构→数字化/AI"闭环的原因。

• 业务部门（对公/零售条线）：定义产品与交易规则，是交易系统的需求方；在交易核算分离后，不再写会计分录，只提"产品要怎么算"。
• 运营部门（营运条线）：负责网点与线上的交易操作，分离后只做业务操作与凭证核对，不再承担会计分录准确性。
• 财会部门（总行核算规则岗）：集中配置会计引擎的核算规则与科目，分支行的业务会计执行被总行引擎替代，这是职责上收的典型。
• 风险部门：在授信、放款前做准入与押品校验，是 E2E 中的"控制闸门"owner；风控模型与核心记账解耦，但风险事件要回流核心做减值计提。
• 科技部门（核心系统 owner）：负责核心、会计引擎、总账的架构、开发、运维；在分布式核心下还要管单元化路由、双轨并行与日终批处理。
• 数据治理与合规部门：管数据口径与监管报送，是 AI 落地的前置责任方。

[[墨青:交易核算分离在组织上等价于把"记账权"从分支行与业务部门上收到总行财会核算规则岗，配合科技部门集中维护会计引擎，这是核心系统重构最容易被忽视、却最决定落地速度的组织变革。]]【推断·中】

8.7 流程地图 L0→L4：核心业务的分层拆解

• L0 价值流：客户发起银行业务 → 银行完成记账与清算 → 监管与经营数据闭环。
• L1 业务域：存款、贷款、支付清算、总账、客户信息（CI）五大基础域。
• L2 流程组：以贷款域为例，分为授信、放款、计息、还款、减值、核销六组。
• L3 流程：放款流程 = 指令生成（信贷）→ 记账指令（核心）→ 会计分录（会计引擎）→ 过账（总账）→ 对账（日终）。
• L4 活动：记账指令含借：贷款—本金 / 贷：单位活期存款；会计引擎按参数匹配科目；总账做总分核对；日终批处理捕捉不平。

这张地图的意义在于：任何一次核心改造，都要先在这一层确认"改的是 L3 哪一段、是否牵动 L4 的记账分录与对账"，否则就会出现北富银式的 ESB 参数错误——核心与周边系统边界没划清，导致 CPU 资源用不足、线上交易超时。

九、架构演进 Deep Dive：从集中式主机到分布式单元化

9.1 工行 ECOS：六年主机下移的工艺

工商银行 2015 年启动 IT 架构转型，2017 年启动 ECOS 工程，2020 年完成超 10 亿借记卡账户主机下移，2024 年 3 月实现对公业务板块切换至分布式单轨运行。核心工艺是"主机下移六步实施工艺"：按应用分步推进，先外围后核心、先只读后交易，避免一次性整体迁移的研发与实施风险集中。[[金棕:10 亿+ 借记卡账户下移、六步工艺]]【已确认】截至 2025 年，工行云平台纳管超 26 万节点、60 万容器，分布式核心承载应用节点超 15.9 万、容器超 30 万，支持超 20 万 TPS，日均服务调用超 200 亿次，对公业务使用中兴 GoldenDB。

9.2 邮储新核心：单元化 + 国产数据库

邮储 2019 年 3 月启动预研，确定分布式单元化架构；2020 年 11 月确定 openGauss 为关系型数据库；2021 年 4 月分布式技术平台投产；2022 年 4 月个人核心全面投产；2022 年 11 月完成 6.5 亿客户无感在线迁移；2024 年 1 月公司核心全面投产、10 月完成全量迁移。新核心峰值 TPS 67000、联机 65 毫秒（较旧系统 -30%）、日终 197 分钟（-28%）、结息 25 分钟（-82%），公司核心效率提升 10 倍以上。[[金棕:6.5 亿客户无感迁移、效率 10 倍+]]【已确认】

9.3 建行与中行：分批次、混部署

建设银行 2019 年启动多技术栈核心建设，37 家一级分行分三批完成境内对私核心下移，2022 年 12 月信用卡核心全部切换至全栈自主可控系统，2024 年 7 月境内外核心全部完成分布式下移。中国银行按"横向银行划分 + 纵向业务领域划分"构建数据与服务单元，采用 TDSQL + 中标麒麟 + 鲲鹏，是国内首次实现 x86 与国芯混部署的核心系统。[[金棕:中行首例 x86+国芯混部署]]【已确认】

9.4 读者向解读

三家大行的路径揭示一个共性：没有一家是"一夜切换"，全部是数年、分批、双轨、按应用逐步下移。原因在核心系统的连续性底线——它不是能停机的业务系统，而是银行的心跳。把 10 亿账户从运行二十年的主机搬到分布式平台，工程上等于给飞行中的飞机换发动机。因此"单元化 + 六步工艺 + 双轨并行"不是银行业的保守，而是金融级系统重构的唯一稳妥路径。对读者而言，理解了这点，就能识别那些"一键上云替换核心"的厂商话术——核心迁移从没有捷径。

9.5 中小银行与互联网银行的差异化路径

大行走"数年、分批、自研底座"的负重路线，中小银行与互联网银行走的是另一条更激进的路——直接在新建系统上用国产/开源分布式数据库，没有历史主机包袱。

• 张家港农商行（2019）：国内传统商业银行核心业务系统首次用分布式国产数据库替代国外数据库落地，是中小行"换心"的破冰案例。
• 微众银行（2015）：核心系统上线即用 TDSQL 承载数百个核心系统与全行所有 OLTP 业务，是银行核心首个国产数据库大规模落地。
• 网商银行（2017）：全面采用 OceanBase，成为率先 100% 去 IOE、自主可控的银行机构，验证"无历史包袱即可一步到位"。
• 北京银行：网联支付清算、银联无卡快捷等平台用 TiDB，两地三中心部署、主从多活。
• 金华银行"星辉工程"（2023-06）：新一代核心用长亮 V8 + OceanBase，依托高 Oracle 兼容性实现应用基本零改造，从"小型机 + Oracle 集中式 + 高端存储"迁移到"PC 机 + OceanBase 分布式 + 普通磁盘"，成本缩减约 75%、分析型加工能力提升约 300%。[[金棕:金华银行核心成本 -75%、分析 +300%]]【计算·高】

9.6 读者向解读

这条路径揭示一个反直觉事实：核心系统重构的难易，与银行规模不是正相关，与"历史包袱"才是。六大行最难，不是因为技术差，而是因为 10 亿账户、二十年 COBOL 程序、跨时区多准则的存量要平移；网商银行最易，是因为它生来就在分布式上、没有要迁的旧账。对读者而言，这解释了为什么"互联网银行 IT 更先进"是误读——它们只是起跑线不同。真正考验工程能力的，是给飞行中的飞机换发动机，而不是造一架新飞机。

9.7 重构的共性成本结构

核心迁移的总拥有成本（TCO）中，初期采购成本只占 20%—30%，后续 3—5 年的迁移部署、应用适配、人员培训、日常运维与升级占绝大部分。[[金棕:TCO 采购占 20%—30%]]【推断·中】这意味着"买系统"只是开始，"迁数据、改应用、养团队、双轨并行"才是成本主体。绍兴银行为保 0 故障构建"主库 + 异构备库 + 异步流复制"的双轨架构，直接拉高 TCO，是这一结构的现实注脚。对银行甲方而言，评估核心重构预算时，若只算 License 与实施费，会系统性低估真实投入。

十、国产数据库与去 IOE：选型决策

10.1 六类主流银行的数据库落点

工商银行对公用 GoldenDB、信贷等 130+ 系统用 GaussDB；农业银行核心用 TDSQL 实现全栈信创；中国银行核心全链路用 TDSQL（x86+国芯混部署）；建设银行信用卡核心用 GaussDB；交通银行贷记卡核心用 OceanBase（国内首个贷记卡核心大机下移）；中信银行核心用 GoldenDB；北京银行网联/银联平台用 TiDB。[[金棕:中信核心 GoldenDB、交行贷记卡 OceanBase]]【已确认】

10.2 选型的两条底线

第一条底线是"不能出错、不能中断、不能被攻破"，可用性目标 99.999%。第二条是"数据一致性不能有丝毫妥协"：银行交易系统没有"最终一致"的空间，每一笔资金变动必须实时准确。这把部分只解决"可用"、在一致性上让步的 NoSQL 挡在核心门外。

10.3 三类技术路线与代价

集中式（电科金仓、达梦）与 Oracle 语法兼容度高（金仓 PL/SQL 兼容 >95%），适合迁移成本敏感、传统核心场景，平滑过渡。分布式（OceanBase、GoldenDB、TDSQL）扩展性好、并发强，代价是架构复杂、运维要求高，需要 DBA 具备内核级定位能力。云原生（PolarDB、TDSQL、GaussDB）弹性好，但要警惕"云时代再绑定"——下云或跨云改造代价极高。

10.4 读者向解读

去 IOE 的真实难点不在"买不买国产数据库"，而在"老账本的数据与规则怎么平移"。一家城商行的核心账务系统里有数百个 Oracle 特有存储过程，金仓以高兼容 + 双轨并行 + 一键回退完成"换心手术"；富滇银行基于多年真实运行数据才决定继续选用 OceanBase。这说明数据库选型是工程能力与工具链完备性的较量，不是榜单排名的较量。对银行而言，核心数据库不是买来展示的，是要跑"开门红"高峰的，真实高峰下的底线承载能力才是唯一裁判。

十一、财务与市场穿透（3–5 年）

11.1 银行业 IT 支出盘子

2024 年中国银行业 IT 投资 1693.15 亿元（同比 +3.6%），预计 2028 年 2662.27 亿元；IT 解决方案市场 713.05 亿元（+2.9%），预计 2029 年 1039.39 亿元（CAGR 7.8%）。[[金棕:IT 投资 CAGR≈12%、解决方案 CAGR 7.8%]]【计算·高】六大行 2024 年金融科技投入合计 1254.59 亿元（+2.15%），是核心重构的主资金来源。按 IDC 轨迹，银行业 IT 投资从 2023 年 1633.98 亿元增至 2024 年 1693.15 亿元，2028 年预计 2662.27 亿元，四年增量约 969 亿元，其中信创与分布式改造是核心去向之一。[[金棕:2023→2028 增量约 969 亿]]【计算·高】

11.2 厂商财务穿透

长亮科技 2024 年营收 17.36 亿元（-9.46%）、归母净利 1858.6 万元（-42.18%）、合同额 22.9 亿元（+16%）、经营性现金流 1.22 亿元、海外合同占比从 6% 跃升至 20%、签下泰国汇商银行 4960 万美元（约 3.3 亿元人民币）核心大单。[[金棕:长亮海外占比 6%→20%、单笔 3.3 亿]]【计算·高】神州信息 2024 年营收 100.03 亿元（-17.03%）、金融科技 49.12 亿元、金融软服收入 36.80 亿元（+1.13%）、国有大行金融软服收入 +18.80%，在银行核心、渠道管理、开放银行细分市场连续多年第一。

11.3 全球厂商对照

Temenos 2025 年营收约 11.5 亿美元、核心银行份额约 8.8%、3000+ 客户、150 国，连续 20 年 IBSi 核心银行销量第一；Oracle FLEXCUBE 全球约 10% 份额、600+ 客户、140 国、客户留存 >95%、净利率 >32%、经营利润率约 45%。[[金棕:FLEXCUBE 净利率 >32%、留存 >95%]]【已确认】

11.4 有解释价值的计算

• 邮储新核心结息效率：140 分钟 → 25 分钟，节省 115 分钟，改善 82.1%（给定 -82%）。[[金棕:结息 -82%]]【计算·高】
• TSB 迁移成本对照：为省每年约 8.9 亿元人民币（1 亿英镑）主机许可费启动迁移，结果 13 亿条记录出错、赔偿约 29 亿元人民币、罚款 4865 万英镑，成本与风险完全倒挂。[[金棕:省 8.9 亿 vs 赔 29 亿]]【计算·高】
• 长亮海外跃迁：海外合同占比从 6% 到 20%，单笔 3.3 亿大单约占其 2024 年营收 17.36 亿的 19%，说明单笔海外订单已能显著改善收入结构。[[金棕:单笔海外单 ≈ 营收 19%]]【计算·高】
• 信创替代窗口：国资委 79 号文要求 2027 年底前央企信息化系统安全可靠替代，倒推 2024—2027 约四年是核心替换的集中投放期。[[金棕:2024→2027 四年窗口]]【计算·高】

11.5 厂商盈利质量对照

厂商	营收（2024/2025）	净利率/经营利润率	关键结构特征
长亮科技	17.36 亿元（2024，-9.46%）	净利 1858.6 万（-42.18%）	合同 +16%、海外占比 20%、现金流 1.22 亿
神州信息	100.03 亿元（2024，-17.03%）	金融科技 49.12 亿、金融软服 36.80 亿	核心/渠道/开放银行市占第一，但商誉减值致亏损 5.24 亿
Temenos	约 11.5 亿美元（2025）	经营利润率约 45%（参考 Oracle 同业）	核心银行 20 年销量第一、3000+ 客户
Oracle FLEXCUBE	约 8.15 亿美元（2024）	净利率 >32%、经营利润率约 45%	客户留存 >95%、License 收入 +18%

[[墨青:国际核心厂商的高净利率与高留存，本质是"被绑定深度"的量化体现——核心一旦投产，替换成本与中断风险使客户长期续费；国产厂商营收规模更小、盈利波动更大，护城河仍在建设中。]]【推断·中】

11.6 读者向解读

把市场盘子与厂商财务放在一起看，能看清一件事：银行业 IT 投资 1693 亿元的大盘里，核心系统替换只是其中一块，却被政策窗口（2027 截止）压缩成四年的集中投放。这意味着 2024—2027 是厂商的订单高峰，也是能力分水岭——头部集中、恶性价格竞争趋缓，不具备产品力与交付力的厂商会被淘汰。对读者而言，判断一家金融科技公司值不值得长期跟踪，不该看它接了多少单，而该看它的高留存与续费能力（国际厂商 >95% 留存是标杆），以及海外单能否真正落地的利润质量，而非合同额的表面增长。

十二、竞争格局：国产厂商 vs 国际厂商

维度	国产厂商（长亮/神州信息/宇信/中电金信）	国际厂商（Temenos/Oracle/Infosys）
核心客群	六大行、股份行、城农商行、信创场景	跨国银行、多币种、复杂合规场景
产品成熟度	追赶中，模块化与海外合规深度较弱	数十年沉淀，多国合规包完备
交付与定制	陪跑式定制、响应快、成本低	标准化强、本地化交付周期长、 License 贵
自主可控	国产数据库/OS 适配原生优势	受出口与地缘约束
全球化	东南亚/中东出海加速（长亮泰国份额破 40%）	全球 3000+ 客户、覆盖 150 国
真实购买维度	谁更懂我的监管、预算与定制节奏	谁更能支撑我的跨境与多准则

按"真实购买维度"而非评分排名看：一家城商行选长亮/神州信息更现实；一家做东盟跨境业务的银行，Temenos 的 API-first 与 Oracle 的 3000+ 银行 API 更有吸引力。竞争不是零和，而是客群分层。

读者向解读：这一格局对银行甲方的含义是——不要被"国产替代"或"国际先进"的叙事带节奏，而要看自己的客群与合规画像。如果你是一家服务本地、受国内监管、预算有限的城商行，国产厂商的贴身交付与信创适配是真实优势；如果你做跨境、多币种、多地合规，国际厂商几十年沉淀的多国合规包能省下你自研的几年时间。选错维度的代价，就是花大价钱买了一套与你的业务节奏不匹配、实施周期失控的系统。

十三、护城河与差异化

国产厂商的护城河在"贴身交付 + 监管语感 + 信创适配能力"，这三样国际厂商难低成本复制。长亮以分布式核心 + 海外大单切入东南亚，神州信息在银行核心、渠道、开放银行细分市场连续多年第一且获汇丰中国、三菱日联核心升级订单，证明其能力已获国际商业银行认可。国际厂商的护城河在"产品深度 + 全球合规资产 + 高切换成本"（FLEXCUBE 留存 >95%、净利率 >32% 即切换成本与粘性的量化体现）。

[[墨青:核心系统厂商的护城河本质是"被绑定深度"——一旦核心跑起来，替换成本与业务中断风险使客户难以离开，这也是国际厂商高留存、高净利率的结构性来源。]]【推断·中】

读者向解读：对银行甲方而言，"被绑定"是一把双刃剑——它既意味着你被厂商锁定、议价权弱，也意味着厂商有动力长期陪你迭代、不会轻易弃坑。选核心厂商时，与其纠结"谁便宜"，不如评估"谁能在未来五年里持续把我的核心维护好、且不被地缘或出口政策卡脖子"。对国产厂商而言，护城河的真正考验不是拿下首单，而是拿下首单后能否做出国际厂商那种 >95% 的留存率——那才是"被绑定深度"的兑现。

十四、数字化现状与未来 AI/数字化发展机会

14.1 当前数字化底座

六大行已完成核心分布式与国产化底座，但"数据泥潭"仍是普遍痛点：同一财务指标在各系统口径不一、老核心牵一发而动全身、部门数据标准难统一。AI 落地因此受限——脏数据直接喂给大模型会产生幻觉。监管层面，2026 年 6 月金融监管总局发布《关于银行业保险业人工智能安全开发应用的指导意见》，明确 AI 责任归属与风险边界，把"分级决策"作为落地框架。

14.2 AI 的真实边界

[[暖红:大模型在信贷审批、资产定价、资金交易等核心决策环节，因黑箱、幻觉、责任不清，目前多数仍由人终审，AI 只做分析与建议。]]【已确认】工商银行大模型落地 600+ 场景、招行 1386 个智能场景，但真正嵌入核心业务流程的寥寥；建行 AI 助手内部覆盖率 99.42%，本质是问答与文档辅助。业内共识：AI 当前价值以降本为主，收入端增量尚未释放。

14.3 六个有经营价值的 AI/数字化场景

场景一：贷前材料解析与授信报告生成

• 业务问题：信贷员案头工作重，百页授信报告耗时长。
• 当前决策：人工搜集财报、写报告。
• 数据：企业财报、征信、工商、司法。
• AI/系统：NLP 解析 + 大语言模型生成草稿。
• 输出：结构化授信调查报告。
• 使用者：信贷员、审批官。
• 行动：人工复核后采用。
• KPI：光大银行"问数"5 分钟生成百页授信报告；宁夏银行"宁银小智"把 3 天贷前调查缩至 2 小时、风险要素识别完整度 +40%。
• 财务价值：释放信贷员工时、加速放款。
• 风险：幻觉导致错误结论，须人工终审。
• 自动化边界：生成草稿，决策权不交 AI。

场景二：全链条反欺诈与反洗钱

• 业务问题：贷款欺诈隐蔽化、产业化。
• 当前决策：规则引擎 + 人工甄别。
• 数据：文本、图像、设备、行为轨迹、跨机构黑名单。
• AI/系统：多模态融合建模 + 知识图谱 + 多方安全计算。
• 输出：实时欺诈评分与拦截指令。
• 使用者：风控官。
• 行动：自动拦截 + 人工复核高危。
• KPI：邮储 2025 上半年防资金损失超 8 亿元、人工甄别 +30%、审贷助手日处理 3 万+ 笔；新网银行年度欺诈拦截率 +5%、累计拦涉诈超 5.3 亿元、伪盗损失降至 0。
• 财务价值：直接减损。
• 风险：误拦正常客户、模型对抗演化。
• 自动化边界：自动拦截低风险，高危转人工。

场景三：实时智能风控预警

• 业务问题：风险事后处置慢。
• 当前决策：人工监控指标。
• 数据：10 万+ 行为指标、时序数据。
• AI/系统：LSTM 时序模型 + 实时流计算。
• 输出：15 分钟内风险预警。
• 使用者：风控官。
• 行动：触发核查。
• KPI：工行"智慧风控 3.0"风险发生 15 分钟内预警、效率较人工 +40 倍；建行"天眼"覆盖 98% 零售信贷、信用卡欺诈损失率 -52%。
• 财务价值：减不良、降损失。
• 风险：指标漂移、误报。
• 自动化边界：预警不自动处置。

场景四：核心运维的智能诊断

• 业务问题：分布式核心设备繁多、故障定位难。
• 当前决策：人工巡检 + 经验排查。
• 数据：日志、指标、调用链。
• AI/系统：AIOps 异常检测 + 根因分析。
• 输出：故障定位与处置建议。
• 使用者：运维团队。
• 行动：按建议处置或自动隔离。
• KPI：邮储自建分布式运维平台实现全景可视、量化管控。
• 财务价值：缩短停机、保连续性。
• 风险：误隔离。
• 自动化边界：建议为主，高危隔离人工确认。

场景五：数据治理与金融语义库（AI 落地的前置条件）

• 业务问题：数据脏、口径乱，AI 不敢用。
• 当前决策：人工治理，推进慢。
• 数据：全行各系统业务数据。
• AI/系统：数据标准引擎 + 语义库 + 质量监控。
• 输出：统一指标与可信数据底座。
• 使用者：数据治理团队、业务部门。
• 行动：压实业务部门数据质量责任。
• KPI：BCG 建议的"统一基础数据标准 + 金融语义库"是 AI 生效前提。
• 财务价值：解锁前述所有 AI 场景。
• 风险：组织阻力大。
• 自动化边界：治理规则由人定。

场景六：合规报送与监管一表通自动化

• 业务问题：多头报送、人工对齐负担重。
• 当前决策：各系统手工抽取、对齐。
• 数据：核心、信贷、总账等多源。
• AI/系统：规则引擎 + 大模型对齐 + 自动抽取。
• 输出：标准化监管报文。
• 使用者：合规/报送岗。
• 行动：自动生成、人工校验。
• KPI：2025 年超 30 个"一表通"项目启动，中信 520 万、盛京 475 万中标。
• 财务价值：减人力、降合规差错。
• 风险：口径错导致监管风险。
• 自动化边界：生成报文，校验人工。

14.4 分级决策框架：AI 的权该怎么交

2026 年 6 月金融监管总局《关于银行业保险业人工智能安全开发应用的指导意见》给出了责任归属与风险边界的顶层框架。浦发银行首席人工智能科学家郑波的表述更具操作性：AI 决策权不是简单的"交"或"不交"，而应按风险程度、可解释性、责任边界分级——规则清晰、结果可验证的任务可逐步让 AI 自主；授信审批、资金交易等高风险事项，AI 提供分析与建议，关键决策点必须由人把控。

[[墨青:AI 在银行的正确落地形态是"分级授权 + 人工终审 + 全程留痕"，而不是"AI 替代人"。当前所有成功案例（反欺诈拦截、智能运维、报送自动化）都守住了这一边界；越过边界直接做核心决策的，目前只有罚款与事故。]]【已确认】

这也解释了为什么前述六个场景中，每一个的"自动化边界"都落在"生成/预警/建议、人工确认"上：场景一生成授信草稿、场景二自动拦低风险、场景三只预警不处置、场景四建议隔离、场景五治理规则由人定、场景六生成报文人工校验。AI 的价值在"把人从重复与海量里解放出来"，不在"替人拍板"。

十五、Red Team 反例与失败模式

1. [[暖红:分布式核心不一定更快]]：分布式架构的红利在扩展性与自主可控，但某分布式数据库厂商直言其运维需内核级能力，多数银行 DBA 不具备，架构复杂可能拖慢而非加速。

2. [[暖红:LLM 不能进核心交易决策]]：信贷审批、资金交易容错率为零，大模型黑箱与幻觉使其无法独立决策；2024 年某城商行因 AI 训练数据地域偏差导致特定区域贷款歧视，被罚 2000 万元。

3. [[暖红:去 IOE 不等于去风险]]：国产化后运维从"原厂兜底"转为 DBA 全栈能力，人才转型滞后于架构演进；部分机构次核心向核心推进时仍"不敢动"。

4. [[暖红:双轨并行抬高 TCO]]：绍兴银行为保 0 故障构建"一主一备读写分离 + 异步流复制 + 异构双轨"，双轨意味着双倍基础设施与运维人力，直接拉高总拥有成本。

5. [[暖红:迁移失败的代价远超节省]]：TSB 为省每年约 8.9 亿元许可费启动迁移，结果 13 亿记录出错、赔偿约 29 亿元、罚款 4865 万英镑，成本完全倒挂。

6. [[暖红:测试不充分是头号杀手]]：台北富邦银行花 5 年、动员 73 万人次、8 次平行测试，上线仍连出三、四天故障（ATM 扣款不出钞、App 转账同错），根源是 ESB 参数设计错误与极端值未模拟。

7. [[暖红:云原生可能形成再绑定]]：分布式/云原生打破硬件绑定，却换来云平台绑定，下云或跨云改造代价极高，不是真正的自由。

15.8 失败案例深拆：TSB 与北富银的异同

两个案例都证明同一件事——核心迁移失败的成本远超迁移想节省的费用。

TSB（2018）：为摆脱每年约 8.9 亿元人民币（1 亿英镑）向原母公司劳埃德支付的系统许可费，TSB 在 2018-04-22 启动把 540 万用户、数十亿条数据迁往 Banco Sabadell 系统的工程。结果 13 亿条客户记录出错、系统数周无法恢复，赔偿与各类成本合计约 29 亿元人民币，FCA 与 PRA 以运营风险与治理失败处以 4865 万英镑罚款。[[金棕:省 8.9 亿/年 vs 赔 29 亿 + 罚 4865 万英镑]]【计算·高】根因是缺乏严格测试与外包治理失效。

台北富邦银行：花 5 年筹备、动员 73 万人次、做 8 次大规模平行测试，上线后仍连出三、四天故障——ATM 扣款不出钞、App 转账同错、约 3000 名客户受影响。根因是核心与周边系统的中介 ESB 参数设计错误、CPU 资源用不足，且人工测试未覆盖上线后高交易量极端值。[[暖红:即便 8 次平行测试，人工测试仍漏掉极端值，证明核心上线必须高度自动化覆盖异常场景。]]【已确认】

异同：TSB 是"跨行系统整体迁移 + 数据平移"的灾难，北富银是"核心瘦身 + 周边解耦"的参数错误；共同点是都把核心切换当成工程事件而非"客户能否触达资金"的接入事件，且都低估了测试与组织配套的复杂度。

十六、决策含义

对银行甲方：核心重构应坚持"分批、双轨、按应用下移"，把"稳"放在"快"前面；AI 投入先做数据治理与外围辅助场景，核心决策权暂不下放；数据库选型看真实高峰承载与工具链完备性，而非榜单。

对厂商：护城河在"被绑定深度 + 贴身交付 + 信创适配"，出海要补产品深度与多国合规资产；单纯拼价格的厂商会被收敛周期的头部集中淘汰。

对监管与行业：信创窗口 2024—2027 是集中投放期，核心迁移的"逃生舱"（双轨 + 影子系统 + 一键回退）应成为准入硬要求，避免 TSB 式系统性事故。

十七、Knowledge Update

1. [[墨青:核心系统的重构动机是零售高并发 + 主机成本 + 信创合规 + 敏捷四力共振，而非单纯技术赶时髦，2024—2027 是集中投放窗口。]]【推断·中】
2. [[墨青:交易与核算分离是企业级核心架构升级的枢纽，农行/工行/建行/浦发已落地独立会计引擎，使产品创新与准则调整不再牵动核心代码。]]【已确认】
3. [[墨青:六大行核心迁移全部采用数年、分批、双轨、按应用下移的工艺，不存在"一键替换核心"的稳妥路径。]]【已确认】
4. [[墨青:AI 在银行业当前以降本（反欺诈、智能运维、报送）为主，信贷审批/资产定价/资金交易等核心决策仍由人终审，大模型落地核心业务仍受黑箱与幻觉制约。]]【已确认】
5. [[暖红:核心迁移的真实风险在数据与规则平移、双轨 TCO 与测试充分性，TSB 与北富银案例证明失败代价远超迁移节省。]]【已确认】
6. [[墨青:国产核心厂商护城河在贴身交付 + 监管语感 + 信创适配，国际厂商护城河在被绑定深度（高留存、高净利率），二者客群分层共存。]]【推断·中】

十八、经营模型总图（文字版）

核心系统的经营闭环可抽象为：银行甲方支付 License + 实施 + 多年运维费用 → 厂商投入人力做业务建模、分布式底座、会计引擎、数据迁移 → 银行获得"稳（连续性）+ 快（敏捷）+ 自主可控（信创）"三项能力 → 监管合规与零售高并发被同时满足 → 厂商通过高切换成本锁定客户、靠运维续费与升级持续变现。AI 是叠加在这一闭环外层的"降本杠杆"，当前主要作用在反欺诈、智能运维、合规报送等外围，尚未进入"记账与核心决策"的内核。决定这门生意天花板的，不是模型参数，而是银行对"账记对、记稳"的底线信任，以及厂商把老账本安全平移的工程能力。