Arch Day 38: 核心银行系统选型 — Build vs Buy决策框架与选型方法论

日期: 2026-05-07 (Day 38) 阶段: 第二阶段 - 金融域深度 标签: #核心银行 #BuildVsBuy #系统选型 #TCO分析 #供应商评估 #迁移策略

---

核心概念

一句话定义

核心银行系统选型是金融机构最高风险的技术决策之一——它不是简单的"买还是自己做"的二选一，而是一套涵盖业务战略、技术架构、组织能力、成本结构、监管合规的系统化评估方法论，决策失误的代价通常以数亿美元+3-5年时间计。

为什么资深架构师必须关注

常见误区与反模式

---

知识点详解

知识点1：Build vs Buy决策框架

Build vs Buy不是一个简单的对比表可以回答的问题。我提出一个四维评估框架：

核心银行 Build vs Buy 决策框架
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

维度1: 战略差异化评估
├── 核心银行是否构成竞争优势？
│   ├── 如果你的银行靠"产品创新速度"竞争 → 倾向Build
│   ├── 如果你的银行靠"成本效率"竞争 → 倾向Buy
│   └── 如果你的银行靠"生态整合"竞争 → 倾向Build+Buy混合
├── 市场上是否有满足需求的产品？
│   ├── 功能覆盖度 >80% → 可以考虑Buy
│   ├── 功能覆盖度 50-80% → Buy+定制
│   └── 功能覆盖度 <50% → 优先考虑Build
└── 差异化需求的变化频率？
    ├── 高频变化(每月) → 需要极高的可配置性或自研
    └── 低频变化(每年) → 外购产品通常够用

维度2: 组织能力评估
├── 是否有500+人的持续研发团队？
├── 是否有核心银行领域的深度专家(≥10年)？
├── 是否有成熟的DevOps/SRE能力？
├── 是否有金融系统的测试体系(性能/灾备/合规)？
└── 人才市场是否能持续招到合适的人？

维度3: 经济性评估(TCO)
├── 5年总成本对比(不是首年成本)
├── 隐性成本：集成、培训、迁移、并行运行
├── 机会成本：Build占用的人力能否创造更大价值
└── 退出成本：供应商锁定程度

维度4: 风险评估
├── 项目失败概率(Build通常高于Buy)
├── 交付延期风险(Build平均延期40-60%)
├── 供应商风险(倒闭/被收购/停止维护)
└── 监管合规风险(自研能否满足审计要求)

决策矩阵：

知识点2：主流核心银行系统全景对比

全球核心银行市场格局 (2025-2026)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Tier 1: 传统巨头 (市场份额最大，功能最全)
├── Temenos T24/Transact — 全球150+国家，3000+银行
├── FIS Modern Banking Platform — 北美主导
├── TCS BaNCS — 印度+亚太+非洲
├── Infosys Finacle — 新兴市场强势
└── Oracle FLEXCUBE — 中东+亚太

Tier 2: 新一代云原生 (增速最快，架构最新)
├── Thought Machine Vault — Google血统，不可变分类账
├── Mambu — SaaS模式，API-first
├── 10x Banking — 英国新锐
├── Pismo — 拉美起家，Visa收购
└── Finxact — FIS收购的云原生品牌

Tier 3: 区域/专业化
├── 中国：长亮科技/神州数码/中电金信/宇信科技
├── 日本：NTT Data/日立
├── 韩国：Samsung SDS
└── 开源：Apache Fineract (微型金融)

Tier 4: 包装型/Headless Banking
├── Galileo (SoFi旗下) — BaaS模式
├── Marqeta — 发卡即服务
├── Synapse/Unit — 嵌入式金融
└── Railsr — 欧洲BaaS

核心产品深度对比：

知识点3：选型评估维度详解

七维评估模型(FATCSER)：

F - Functionality (功能覆盖度)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
├── 账户管理(开户/销户/冻结/解冻)
├── 存款产品(活期/定期/通知/结构化)
├── 贷款产品(信贷/抵押/循环/分期)
├── 支付(转账/汇款/代收代付/跨境)
├── 外汇/贸易融资
├── 理财/基金代销
├── 信用卡
└── 评分：每项0-5分，加权合计

A - Architecture (技术架构)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
├── 架构风格(单体/微服务/事件驱动)
├── 云原生程度(容器化/K8s/无状态)
├── 数据库架构(单机/分布式/多模型)
├── API设计(REST/gRPC/GraphQL/AsyncAPI)
├── 扩展性(水平扩展能力/性能上限)
└── 评分：技术Review+PoC验证

T - TCO (总拥有成本)
━━━━━━━━━━━━━━━━━━━
├── 许可费(一次性/年付/按交易量)
├── 实施费(供应商+SI+内部)
├── 运维费(基础设施+监控+升级)
├── 集成费(与周边系统对接)
├── 培训费(开发+运维+业务)
├── 并行运行期成本
└── 5年/10年TCO建模

C - Compliance (合规能力)
━━━━━━━━━━━━━━━━━━━━━━━━
├── 监管报表生成能力
├── 审计追踪(操作日志/变更历史)
├── 反洗钱(AML/KYC/CTF)
├── 数据安全(加密/脱敏/分级)
├── 数据主权(数据存储位置)
└── 合规更新频率和成本

S - Scalability (可扩展性)
━━━━━━━━━━━━━━━━━━━━━━━━━━
├── 性能指标(TPS/响应时间/并发数)
├── 产品扩展(新产品上线速度)
├── 地域扩展(多国家/多币种/多语言)
├── 渠道扩展(手机银行/开放银行/嵌入式)
└── API扩展(第三方集成能力)

E - Ecosystem (生态系统)
━━━━━━━━━━━━━━━━━━━━━━━
├── 供应商稳定性(财务状况/市场地位)
├── 合作伙伴网络(SI数量/质量)
├── 用户社区(开发者生态/知识库)
├── 第三方集成(Marketplace/预建连接器)
└── 供应商锁定程度(数据可迁移性)

R - Risk (风险评估)
━━━━━━━━━━━━━━━━━━━
├── 供应商风险(倒闭/被收购/战略转向)
├── 技术风险(架构过时/安全漏洞)
├── 实施风险(延期/超预算/质量)
├── 运营风险(系统故障/性能问题)
└── 锁定风险(迁移成本/数据导出)

知识点4：核心银行迁移策略

三种主流迁移策略的对比：

策略1: Big Bang (一次性切换)
━━━━━━━━━━━━━━━━━━━━━━━━━━━
                    ┌─── 新系统上线
旧系统运行 ─────────┤
                    └─── 旧系统下线

优点:
  - 没有长期双系统并行成本
  - 一次性完成，不拖泥带水
  - 数据一致性更容易保证

缺点:
  - 风险集中，失败影响巨大
  - 测试要求极高(回归测试覆盖率>99%)
  - 回滚困难(通常只有48小时窗口)

适用: 小型银行/产品线简单/团队经验丰富

策略2: 渐进式迁移 (Strangler Fig Pattern)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
旧系统 ████████████████████▓▓▓▓▓▓▓░░░░░
新系统 ░░░░░▓▓▓▓▓▓████████████████████

阶段1: 新产品在新系统上线
阶段2: 存量产品逐批迁移
阶段3: 旧系统逐步退役

优点:
  - 风险分散，每阶段影响可控
  - 可以根据反馈调整策略
  - 团队逐步积累经验

缺点:
  - 双系统并行期长(通常2-5年)
  - 需要建设数据同步/路由层
  - 组织需要同时维护两套系统的能力

适用: 大型银行/产品复杂/风险偏好低

策略3: 平行运行 (Parallel Run)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
旧系统 ████████████████████████(主)
新系统 ████████████████████████(影子)
       ↑ 两系统同时处理，对比结果 ↑

阶段1: 新系统接收所有交易(影子模式)
阶段2: 逐笔对比新旧系统结果
阶段3: 差异率<0.01%后切换主系统

优点:
  - 最安全的迁移方式
  - 可以精确衡量新系统质量
  - 随时可回退

缺点:
  - 成本最高(双倍基础设施+对比引擎)
  - 需要完善的自动化对账
  - 适用于批处理，实时交易困难

适用: 核心账务/清结算等资金相关系统

知识点5：中国市场的特殊性

中国核心银行市场特征
━━━━━━━━━━━━━━━━━━━━

1. 自研文化盛行
├── 大型银行(工农中建交): 几乎全部自研
│   ├── 工行: ECOS(自研)
│   ├── 建行: 新一代核心(自研)
│   ├── 中行: OASIS(自研)
│   └── 招行: 自研(最早实现分布式改造)
├── 股份制银行: 自研为主+少量外购
│   ├── 招行、平安: 自研
│   ├── 兴业、中信: 外购+深度定制(长亮等)
│   └── 浦发: 自研
├── 城商行/农商行: 以外购为主
│   ├── 长亮科技、宇信科技、中电金信等
│   └── 部分大型城商行开始自研(如南京银行)
└── 互联网银行: 自研(微众、网商、百信)

2. 国产化替代浪潮(信创)
├── 硬件: x86 → 鲲鹏/飞腾/海光
├── OS: CentOS → 麒麟/统信
├── 数据库: Oracle → OceanBase/TiDB/TDSQL/GaussDB
├── 中间件: IBM MQ/WebSphere → RocketMQ/自研
├── 时间表: 2028年前核心系统完成信创替换
└── 挑战: 性能/稳定性/生态成熟度

3. 监管要求
├── 核心系统RTO < 30分钟(银保监会)
├── RPO ≈ 0(资金系统)
├── 数据不出境(个人金融信息)
├── 年度灾备演练(监管检查)
├── 等保三级+(核心系统)
└── 自主可控评估(信创合规)

4. 业务特殊性
├── 跨行支付: 人行大小额支付系统/网联
├── 监管报表: 1104报表/反洗钱报告
├── 特色产品: 大额存单/结构性存款/理财子
├── 渠道: 手机银行/微信银行/小程序
└── 数字人民币(e-CNY)接入

知识点6：核心银行迁移中最大的风险清单

---

对比分析

云原生核心 vs 传统核心 vs 包装型方案

Build vs Buy：不同类型银行的推荐

---

架构设计实操

设计目标

为一家中型城商行(资产规模5000亿，500万零售客户，10万对公客户)设计核心银行选型评估方案。

当前现状：

• 运行10年的传统核心银行(长亮科技旧版本)
• 性能瓶颈：日终批处理超过6小时窗口
• 产品上线慢：新产品配置需要3-6个月
• 信创要求：2028年前完成国产化替代

选型评估矩阵

加权评估矩阵
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

评估维度(FATCSER)        权重    方案A       方案B        方案C
                               (长亮新版)   (自研)      (TM Vault)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

F-功能覆盖              20%     4.0(0.80)   3.5(0.70)   3.0(0.60)
  存款/贷款/支付               ★★★★☆       ★★★★        ★★★
  监管报表/特色产品            ★★★★★       ★★★         ★★

A-技术架构              20%     3.0(0.60)   4.5(0.90)   5.0(1.00)
  云原生/分布式                ★★★          ★★★★☆      ★★★★★
  可扩展性                     ★★★          ★★★★★      ★★★★★

T-TCO(5年)             15%     3.5(0.53)   2.5(0.38)   3.0(0.45)
  实施成本                     ★★★★        ★★★         ★★★
  运维成本                     ★★★          ★★          ★★★★

C-合规能力              15%     4.5(0.68)   4.0(0.60)   3.0(0.45)
  中国监管/信创                ★★★★★       ★★★★        ★★★
  审计追踪                     ★★★★        ★★★★        ★★★★★

S-可扩展性              15%     3.5(0.53)   4.5(0.68)   4.5(0.68)
  产品扩展速度                 ★★★★        ★★★★★      ★★★★★
  渠道扩展                     ★★★          ★★★★★      ★★★★

E-生态系统              10%     4.0(0.40)   3.0(0.30)   3.5(0.35)
  本地SI/社区                  ★★★★★       ★★★         ★★★

R-风险                  5%      4.0(0.20)   3.0(0.15)   3.5(0.18)
  实施风险                     ★★★★        ★★★         ★★★★
  供应商风险                   ★★★★        N/A          ★★★

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
加权总分                       3.74        3.71         3.71
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ADR: 核心银行选型决策

# ADR-038: 中型城商行核心银行选型

## 状态
PROPOSED

## 上下文
某城商行需要在2028年前完成核心银行系统更换，需满足信创要求、
性能提升、产品敏捷性提升三大目标。评估了三个方案：
A) 长亮科技新一代产品升级
B) 组建团队自研
C) 引入Thought Machine Vault

## 决策
选择方案A(长亮新版)作为基础，辅以方案B的思路在创新层自研。

具体策略：
1. 核心账务层：升级长亮新版(分布式版本，基于OceanBase)
2. 产品引擎层：在长亮基础上增强，保留自研扩展能力
3. 渠道/开放银行层：自研(基于微服务+API Gateway)
4. AI层：自建AI中台，与核心系统通过API集成

## 理由
- 长亮在中国监管合规方面经验最丰富(功能覆盖+合规得分最高)
- 自研风险太高：该行无500+人团队，核心银行领域专家不足
- Thought Machine在中国缺乏本地化支持和监管经验
- 混合策略平衡了稳定性(核心用长亮)和敏捷性(创新层自研)

## 迁移策略
采用渐进式迁移(Strangler Fig)：
- Phase 1 (6月): 新开户/新产品在新系统上线
- Phase 2 (12月): 存量活期存款迁移
- Phase 3 (18月): 存量定期/贷款迁移
- Phase 4 (24月): 旧系统退役

## 后果
- 正面：合规风险低、实施确定性高、成本可控
- 负面：技术架构不是最先进的、对长亮有一定依赖
- 缓解：创新层自研保持技术灵活性，合同中约定数据可迁移性条款

权衡分析

核心权衡点
━━━━━━━━━━

1. 稳定性 vs 先进性
   ├── 选择长亮：架构不是最新，但稳定性和合规有保障
   ├── 如果选TM Vault：架构最新，但在中国落地风险高
   └── 决策：金融系统稳定性优先，通过分层架构在上层追求先进性

2. 自主可控 vs 效率
   ├── 全自研：完全自主，但需要3-5年+巨额投入
   ├── 全外购：最快上线，但供应商锁定
   └── 决策：混合策略，核心外购+上层自研

3. 一步到位 vs 分步演进
   ├── Big Bang：一次性到位，没有并行运行成本
   ├── 渐进式：风险分散，但双系统并行2年
   └── 决策：渐进式，该行的风险承受能力不适合Big Bang

4. 短期成本 vs 长期价值
   ├── 长亮新版5年TCO: ~2.5亿人民币
   ├── 自研5年TCO: ~4亿人民币(含人力)
   ├── TM Vault 5年TCO: ~3亿人民币(含本地化)
   └── 决策：长亮方案TCO最优，但需要在合同中控制后续升级成本

---

AI增强实践

AI在核心银行选型中的应用

AI增强的选型评估流程
━━━━━━━━━━━━━━━━━━━

1. AI辅助需求分析
   ├── 使用LLM分析银行年报/战略规划，提取技术需求
   ├── 自动对比各供应商RFP响应文档
   └── 生成需求覆盖度矩阵

2. AI辅助TCO建模
   ├── 基于历史项目数据训练成本预测模型
   ├── 蒙特卡洛模拟不同场景下的TCO分布
   └── 敏感性分析：哪些因素对TCO影响最大

3. AI辅助风险评估
   ├── NLP分析供应商财报/新闻，评估供应商风险
   ├── 分析历史迁移项目的失败模式
   └── 预测项目延期概率

4. AI在新一代核心银行中的嵌入
   ├── 智能产品推荐(基于用户行为)
   ├── AI驱动的信贷审批(嵌入贷款引擎)
   ├── 实时反欺诈(嵌入交易引擎)
   ├── 智能客服(嵌入渠道层)
   └── AI辅助合规(自动监管报表)

AI-Native核心银行的未来形态

# 概念：AI驱动的核心银行产品引擎
class AIProductEngine:
    """
    未来的核心银行产品引擎不再是参数配置表，
    而是AI驱动的动态产品生成器
    """

    def create_product(self, customer_segment, market_conditions):
        """
        传统方式: 产品经理配置参数 → IT开发 → 测试 → 上线(3个月)
        AI方式: AI分析市场+客群 → 自动生成产品参数 → 合规检查 → 上线(1天)
        """
        # AI分析客群需求
        needs = self.ai_engine.analyze_segment(customer_segment)

        # AI生成产品参数
        product_params = self.ai_engine.generate_product(
            needs=needs,
            constraints=self.compliance_rules,
            market=market_conditions,
            pricing=self.pricing_model.optimize(needs)
        )

        # 合规自动审查
        compliance_check = self.compliance_ai.review(product_params)
        if not compliance_check.passed:
            product_params = self.ai_engine.adjust(
                product_params, compliance_check.issues
            )

        # 风险评估
        risk_assessment = self.risk_ai.evaluate(product_params)

        return Product(
            params=product_params,
            compliance=compliance_check,
            risk=risk_assessment,
            auto_generated=True
        )

---

与Web3/DeFi的关联

核心银行选型思维在DeFi中的映射

DeFi中的"核心银行"

DeFi协议 = 链上核心银行
━━━━━━━━━━━━━━━━━━━━━

传统核心银行组件 → DeFi等价物
├── 账户系统 → 钱包地址
├── 存款引擎 → Lending Protocol (Aave/Compound)
├── 贷款引擎 → Lending Protocol + CDP (MakerDAO)
├── 支付引擎 → Token Transfer / Payment Protocol
├── 交易引擎 → DEX (Uniswap/Curve)
├── 风控引擎 → Liquidation Bot + Oracle
├── 清结算 → 链上即时结算(T+0)
├── 日终批处理 → 不需要(实时处理)
├── 监管报表 → 链上透明(The Graph/Dune)
└── 产品配置 → Smart Contract参数

关键差异:
1. DeFi没有"日终"概念——所有交易实时结算
2. DeFi没有"对账"需求——区块链本身就是唯一真相源
3. DeFi的"产品配置"是智能合约代码，比传统配置更灵活也更危险
4. DeFi的"迁移"通过代理合约或流动性迁移实现，用户可选择不迁

---

今日思考

深度问题1

"如果你是一家资产500亿的新设数字银行CTO，你会Build还是Buy核心银行？"

关键考虑：新设银行没有历史包袱，但也没有技术积累。500亿资产规模意味着IT预算有限(大约3-5亿/年)。建议Buy云原生核心(如Mambu/10x Banking)+自研客户体验层+AI中台。理由：将有限资源集中在差异化竞争优势上，而非重复造轮子。

深度问题2

"核心银行迁移项目中，技术因素和组织因素哪个更常导致失败？"

行业数据显示，核心银行迁移项目中70%的失败原因是组织因素而非技术因素——包括高层支持不够、业务部门抵制变革、项目管理不力、关键人员流失。技术上有成熟的方法论，但组织变革管理往往被低估。

深度问题3

"信创替代是否意味着中国银行核心系统会和全球脱节？"

不一定。信创要求的是基础设施层(芯片/OS/数据库)的国产化，不限制应用架构设计。OceanBase等国产数据库在TPC-C测试中已经超过Oracle。真正的风险是生态孤立——如果国产技术栈形成封闭生态，将影响中国银行的海外扩展能力。

---

面试题准备

面试题1：自研vs购买核心银行如何决策？

30秒版本： 决策取决于四个维度：战略差异化需求(核心银行是否构成竞争优势)、组织能力(是否有足够的研发团队和领域专家)、TCO(5年总成本对比)、风险承受度。大型银行通常自研因为资源充足且差异化需求多，中小银行通常外购因为更经济高效。

2分钟版本： 核心银行的Build vs Buy不是一个简单的二选一，而需要一个系统化的评估框架。我会从四个维度评估：

第一，战略差异化。如果银行的竞争优势来自产品创新速度——比如微众银行需要快速迭代消费金融产品——那自研更有利。如果银行竞争优势来自服务网络或品牌，核心银行不是差异化点，买更高效。

第二，组织能力。自研核心银行需要至少500人的持续研发团队，且需要有10年+核心银行经验的架构师。大多数城商行不具备这个条件。

第三，TCO对比。不能只看首年成本。自研的开发成本只占TCO的20%，后续维护和演进占80%。外购虽然有License费，但分摊到10年可能更经济。

第四，风险。全球核心银行迁移项目的成功率只有约40%。自研项目平均延期40-60%。外购项目通过选择成熟产品可以降低技术风险，但增加了供应商锁定风险。

实际操作中，我推荐混合策略——核心账务用成熟产品，差异化层自研。

可能的追问：

• Q：如何评估供应商锁定风险？

• A：从三个角度评估：数据可导出性(格式/API/工具)、接口标准化程度(是否使用BIAN等行业标准)、合同中的退出条款(是否有源码托管/知识产权约定)。

• Q：迁移过程中最大的风险是什么？

• A：数据迁移和业务连续性。数据迁移的风险在于历史数据的格式转换和完整性验证——建议使用平行运行+逐笔对账的方式。业务连续性的风险在于切换瞬间的交易中断——建议灰度切换+快速回滚机制。

面试题2：迁移过程中最大的风险是什么？

30秒版本： 最大风险有三个层面：技术层面是数据迁移完整性(历史数据格式转换+金额精度)，业务层面是业务连续性(切换期间的交易不能中断)，组织层面是变更管理(业务部门抵制和关键人员流失)。其中组织因素导致的失败占比最高。

2分钟版本： （展开上述三个层面，各举一个案例说明）

---

学习资源

---

明日预告

Day 39: 日终批处理架构 — 为什么银行需要日终批处理？批处理架构模式(ETL Pipeline/Spring Batch/分布式)、编排与容错设计、性能优化、从日终到准实时的演进。这是核心银行中最容易被忽视但对系统稳定性影响最大的部分。