2026 金融信创：从“替代率”到“替代质量”

2026 年，金融信创的讨论正在换一个问题。过去几年，大家问的是“替不替、替多少”；现在更常问的是“替完能不能稳、能不能退、能不能过审计”。这不是文字游戏，而是项目阶段变了：外围系统能替的已经替得差不多，剩下的多是核心账本、关键链路和复杂存量。

IDC 2025 年中国银行业 IT 解决方案市场 714.5 亿元，同比只增长 0.2%，市场进入“低速高质”周期。另一边，2026 年 7 月人民银行等四部门发布的《金融业网络安全管理办法（征求意见稿）》，把信创风险管理放进了网络安全保护义务；2026 年 6 月金融监管总局金发〔2026〕8 号文，又把“自主可控”写进银行业保险业 AI 开发应用的原则。两件事指向同一个方向：信创不再只是采购比例，而是运行责任。

一、替代率为什么会失真

“替代率”是一个好汇报、难验收的指标。同样说 80%，可能是金额、台数、系统数，也可能是“上线了但还在双轨”。口径不同，结论差很远。

表 1　三种常见替代率口径

口径	常见算法	容易高估或低估的原因	更适合回答的问题
金额替代率	国产采购额 ÷ 总采购额	把集成、服务、维保算进去；重复采购也会推高	预算花向了哪里
台数 / 套数替代率	国产设备或软件套数 ÷ 总套数	外围、办公、测试环境占比高；核心系统数量少但权重大	资产台账换了多少
核心系统替代率	已单轨运行的核心系统 ÷ 核心系统总数	“上线”“双轨”“单轨”“全栈”口径混用；分母难界定	关键业务到底稳不稳

三种口径都能用，但不能互相替代。董事会关心的是核心系统替代率，采购部门关心金额，运维部门关心台数和版本。真正需要对齐的是：替代率回答“投入了多少”，替代质量回答“运行得怎么样”。

二、2026 年的三个变化

第一个变化是市场从“普涨”转向“结构升级”。IDC 的数据说明，银行 IT 解决方案市场已经进入低速增长，预算不再平均撒，而是向核心系统、信创、数据和 AI 集中。对服务商来说，项目数量不一定增加，但单项目的复杂度和验收要求明显提高。

第二个变化是监管从“鼓励替代”转向“管理替代风险”。2026 年 7 月的《金融业网络安全管理办法（征求意见稿）》提出，金融机构要把信息技术应用创新纳入风险管理，供应链安全、年度检测评估、关基保护也要同步落地。这意味着“买了国产产品”不等于“合规完成”，还要证明替换后的风险可控。

第三个变化是 AI 把“自主可控”的范围拉长了。金发〔2026〕8 号文把 AI 治理、数据治理、算力建设和供应链管理放在同一张监管框架里。对金融机构来说，信创不再只是 CPU、操作系统、数据库，还包括 AI 芯片、AI 服务器、模型框架、向量数据库和智能体平台。全栈自主可控，正在从传统 IT 栈延伸到 AI 栈。

三、替代质量的四维验收

把“替代质量”拆开，至少要看四个维度。每个维度都要有可复核的证据，而不是一句“运行正常”。

表 2　金融信创替代质量的四维验收

维度	核心问题	最低证据	常见误区
性能质量	真实业务峰值下，P99 时延、吞吐、批量窗口、超分比是否达标？	真实负载 POC、长稳报告、验收阈值、容量模型	只跑 TPCC 或峰值 TPS，不看批量窗口和长稳
迁移质量	对象级兼容、数据一致性、双轨运行、回退路径是否验证？	兼容清单、双轨比对、回退演练记录、差异闭环	兼容率 99% 就认为完成，忽略优化器和事务语义
安全合规质量	信创风险台账、供应链审查、等保/密评、AI 治理是否覆盖？	风险台账、审查报告、测评报告、整改闭环	只报国产化率，不报风险和整改
运维质量	监控、备份、版本、备件、人才、SLA 能不能接住？	监控覆盖、恢复演练、MTTR、备件协议、值班记录	上线即交付，运维体系和知识没有转移

1. 性能质量：用业务峰值说话

性能验收最常见的错误，是把“产品基准测试”当成“业务基线”。数据库的 TPCC 分数、虚拟化的虚拟机密度、国产 CPU 的核数，都不能直接回答“月末结算能不能在窗口内跑完”。

更可靠的做法，是用真实业务负载做 POC：联机交易的 P99 时延、批处理窗口、报表查询、备份恢复、故障切换，逐项记录。对核心系统，还要提前写清楚“性能下降多少算不可接受”，否则上线后很难判定是否达标。

2. 迁移质量：兼容率不是终点

Oracle 兼容 99.4% 听起来很高，但放到 80 万条 SQL、3000 多个数据库对象里，剩下的 0.6% 仍可能是几千条需要人工复核的语句。优化器行为、执行计划、锁机制、事务隔离和存储过程语义，往往不是语法转换工具能解决的。

迁移质量要看三件事：对象级兼容清单是否闭环、双轨期间数据是否一致、回退路径是否演练过。没有回退方案的迁移，只是把一次风险拆成多次更大的风险。

3. 安全合规质量：从“国产化率”到“风险台账”

信创风险管理不是一张采购清单，而是一张风险台账：哪些系统已经替换、哪些还在双轨、哪些依赖国外组件、哪些存在供应链集中风险、哪些需要年度评估。2026 年的监管趋势是把这些台账和等保、密评、关基保护、供应链审查放在一起看。

对金融机构来说，最容易被忽略的是“隐性依赖”：国产服务器里还有国外 RAID 卡、网卡、固件；国产数据库的工具链、备份代理、监控插件仍依赖国外产品；AI 栈的框架和模型来源没有纳入供应链审查。全栈自主可控，必须做到 BOM 级，而不是品牌级。

4. 运维质量：上线只是开始

信创替换后，运维对象会变多：多芯、多版本、多数据库、多工具链。原来一套监控、一套备份、一套值班流程，可能变成两套甚至三套。如果运维体系没有同步升级，替换后的故障定位时间会变长，月结、年结和版本升级的风险会更高。

运维质量至少要看：监控是否覆盖新栈、备份能否恢复、版本升级是否有回退、备件是否可持续、值班团队是否具备多栈能力、厂商责任边界是否清晰。

四、把替代质量写进合同

替代质量不能只在验收会上讨论，最好在合同里写清楚。以下六类条款，建议在信创项目招标和合同中明确：

验收指标：性能、容量、可用性、恢复时间、批量窗口，逐项量化，不用“满足业务需求”这种模糊表述。
双轨期限：双轨运行多长时间、覆盖哪些业务周期、双轨期间的数据一致性怎么验证。
回退触发：什么条件下回退、谁决策、回退窗口多长、回退后的数据怎么追平。
数据一致性：全量加增量比对、差异定位、差异修复和复核责任。
运维交接：监控、备份、版本、备件、知识库、值班培训的交付清单。
退出条款：许可证、数据导出、工具链、云资源、原厂支持的退出安排，避免“二次锁定”。

五、对银行和服务商的启示

对银行来说，信创项目的管理重心要从“采购进度”转向“运行质量”。建议建立一张“替代质量台账”，把每个核心系统的性能、双轨、回退、安全、运维五项状态记录清楚，按季度向科技委员会和董事会报告。

对服务商来说，机会正在从“交付项目”转向“运行结果”。客户不缺一个能把产品装上去的团队，缺的是能在多栈环境里接住月结、年结、故障切换和监管检查的团队。谁能把性能基线、双轨回退、运维承接做成标准化服务，谁就更容易进入核心系统。

信创的终点不是“国产化率 100%”，而是关键业务在国产栈上持续稳定运行。 这句话说起来简单，做起来需要性能、迁移、安全、运维四条线同时达标。