第二章 · 鸟瞰全局 第 5 篇:银行系统分层体系总览
第二章 · 鸟瞰全局| 银行核心业务系统专栏建议阅读时间：15 分钟关键词：分层架构、渠道层、业务层、数据层、企业级架构
一、为什么需要理解银行的分层架构？
在很多人的印象里，银行就是"前台接业务、后台做账"——一个柜员敲几笔交易，系统自动记账出报表。
但现实是，一笔看似简单的转账交易，可能穿越 5-8 个系统，经过 10+ 个中间件。如果你不理解银行 IT 系统的整体分层，就会像盲人摸象一样，只看到局部，无法建立全局认知。
这一篇，我们画一张银行 IT 系统的全景分层图，从上到下、从外到内，把银行的 IT 家底摸清楚。
二、银行 IT 系统的四层架构
绝大多数银行的 IT 系统都可以归纳为四个层次。这不是某个标准强制规定的，而是经过几十年的实践沉淀下来的"最佳实践"：
┌─────────────────────────────────────────────────┐ │ 第一层：客户交互层（渠道层） │ │ 手机银行 / 网上银行 / 柜面 / ATM / 微信银行 │ ├─────────────────────────────────────────────────┤ │ 第二层：渠道整合层（集成层） │ │ 统一认证 / 统一支付路由 / 渠道网关 / API 开放 │ ├─────────────────────────────────────────────────┤ │ 第三层：业务处理层（核心层） │ │ 核心系统 / 信贷系统 / 理财系统 / 国际结算 / ... │ ├─────────────────────────────────────────────────┤ │ 第四层：数据与管理层（基础层） │ │ 数据仓库 / 风控平台 / 监管报送 / 运维管理 │ └─────────────────────────────────────────────────┘下面逐层展开。
三、第一层：客户交互层（渠道层）
这是客户唯一能"看到"和"触摸"到的部分。
客户不会关心后台跑着什么核心系统、什么分布式架构。他们只关心一件事：我通过手机银行转账，钱到没到？
3.1 主要渠道
| 渠道 | 触达方式 | 特点 |
|---|---|---|
| 手机银行 | App（iOS/Android） | 当前第一大渠道，交易量占比超 80% |
| 网上银行 | PC 浏览器 | 企业客户主力渠道，大额转账、对公业务 |
| 柜面系统 | 柜员终端 | 复杂业务办理，开户、挂失、大额取现 |
| ATM/自助设备 | 硬件终端 | 取现、查询、转账，7×24 |
| 微信银行/小程序 | 微信生态 | 轻量级服务入口，适合查询、小额支付 |
| 电话银行 | IVR + 坐席 | 中老年客户，投诉咨询 |
| POS 终端 | 商户刷卡 | 收单业务，线下消费 |
| 开放银行 API | 第三方接入 | 场景嵌入，银企直连 |
3.2 渠道层的核心挑战
渠道层的关键不在于"做一个好看的 App"，而在于：
（1）一致性体验
同一笔转账，通过手机银行和柜面办理，后端逻辑必须一致。余额、利率、限额——不管从哪个入口进来，看到的数据必须是同一份。
（2）多渠道协同
客户在手机银行发起了一笔大额转账，因为超出限额被挂起，柜员在柜面看到审批请求并完成授权。这种跨渠道协同的场景越来越多。
（3）快速迭代
手机银行 App 平均每 2-4 周迭代一次，但后台核心系统可能一年才升级一次。渠道层必须做好前后端解耦，前端快速变化不影响后端稳定。
四、第二层：渠道整合层（集成层）
这是渠道层和业务层之间的"粘合剂"。
如果没有这一层，每个渠道都要直接对接每个业务系统，系统间的连接数会爆炸：4 个渠道 × 10 个业务系统 = 40 条直连线路。
有了整合层，变成：4 个渠道 → 1 个整合层 → 10 个业务系统 = 14 条线路。
4.1 整合层的核心组件
┌──────────┐ ┌──────────┐ ┌──────────┐ │ 手机银行 │ │ 网上银行 │ │ 柜面 │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └──────────────┼──────────────┘ ▼ ┌─────────────────┐ │ 渠道网关 │ ← 统一入口、路由分发 └────────┬────────┘ ▼ ┌─────────────┼─────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌──────────┐ ┌──────────┐ │统一认证 │ │统一支付路由│ │API开放平台│ │(SSO/4A) │ │(智能路由) │ │(OpenAPI) │ └─────────┘ └──────────┘ └──────────┘4.2 各组件详解
（1）渠道网关（Channel Gateway）
所有渠道请求的统一入口。负责：
- 协议转换：HTTP → MQ，JSON → ISO8583（银联报文）
- 流量控制：限流、熔断、降级
- 安全防护：防重放、防篡改、加解密
- 日志审计：全链路 TraceID，方便追踪
（2）统一认证（4A 平台）
- 统一身份认证：一套账号体系打通所有渠道
- 统一授权：柜员权限分级、客户交易限额控制
- 统一审计：谁在什么时间、从什么渠道、做了什么操作
（3）统一支付路由
这是支付业务的"交通指挥中心"。一笔转账进来后，路由要判断：
- 行内转账？→ 走行内核心
- 跨行大额？→ 走大额支付系统（HVPS）
- 跨行小额？→ 走小额批量系统（BEPS）或网联
- 第三方支付？→ 走银联/网联渠道
（4）API 开放平台
面向外部合作方的标准化接口：
- 银企直连：企业 ERP 直接调用银行接口查账、付款
- 场景嵌入：房产交易、电商结算等场景中嵌入银行能力
- 监管对接：人民银行、银保监会的标准化数据报送接口
五、第三层：业务处理层（核心层）
这是银行 IT 系统的"心脏"。
所有真正"处理业务"的系统都在这一层。按功能域可以划分为三大类：
5.1 核心业务系统群
| 系统 | 职责 | 关键特征 |
|---|---|---|
| 核心银行系统 | 账户管理、存贷款、支付结算、总账会计 | 银行的"操作系统"，不可停机 |
| 信贷管理系统 | 贷款申请、审批、放款、贷后管理 | 与核心系统紧密联动 |
| 理财/代销系统 | 基金、保险、理财产品的销售与管理 | 资产配置型系统 |
| 国际结算系统 | 信用证、汇款、保函、外汇交易 | 跨境业务专属 |
| 信用卡系统 | 发卡、收单、账单、分期、积分 | 高并发、高复杂度 |
| 支付清算系统 | 行内清算、同业清算、轧差 | 涉及资金准确性 |
5.2 支撑业务系统群
| 系统 | 职责 |
|---|---|
| 客户信息系统（CIF） | 统一客户视图、客户号管理 |
| 产品工厂/参数中心 | 产品参数化配置、利率/费率管理 |
| 统一签约平台 | 签约关系管理、协议绑定 |
| 凭证管理 | 重要空白凭证的领用、使用、核销 |
| 柜员/机构管理 | 柜员号、权限、机构的层级管理 |
5.3 风险与合规系统群
| 系统 | 职责 |
|---|---|
| 反洗钱系统 | 大额/可疑交易监测、名单筛查 |
| 实时风控引擎 | 交易反欺诈、实时拦截 |
| 征信管理系统 | 人行征信查询与报送 |
| 1104 监管报表 | 银保监会非现场监管报表 |
5.4 业务层的关键问题
核心系统 vs 外围系统的边界在哪里？
这是一个经典的架构争议话题，我们将在下一篇文章中深入讨论。但可以提前透露一个共识：
核心系统 = 账户 + 账务 + 基础交易其他都是外围。
当然，"基础交易"的定义一直在演变——曾经信用卡算外围，现在很多银行已经把信用卡纳入核心。曾经理财算外围，现在也在讨论要不要回收。
六、第四层：数据与管理层（基础层）
这一层不直接处理业务，但为所有业务系统提供"地基"。
6.1 数据域
┌─────────────────────────────────────────────────┐ │ 数据管理域 │ │ │ │ ┌───────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ 数据仓库 │ │ 实时数据平台 │ │ 数据湖 │ │ │ │ (T+1报表) │ │ (实时大屏) │ │ (原始数据)│ │ │ └───────────┘ └──────────────┘ └───────────┘ │ │ │ │ ┌───────────┐ ┌──────────────┐ ┌───────────┐ │ │ │ 数据治理 │ │ 数据安全 │ │ 数据标准 │ │ │ └───────────┘ └──────────────┘ └───────────┘ │ └─────────────────────────────────────────────────┘数据仓库（EDW）：银行数据量最大的系统之一。所有业务系统的数据通过 ETL 流程汇聚到数据仓库，生成 T+1 的管理报表、监管报表。
实时数据平台：近年来兴起的建设重点。传统数据仓库是 T+1，管理层要"昨天的数据做今天的决策"。实时平台能做到秒级/分钟级数据更新，支撑实时大屏、实时风控。
数据湖：存储原始数据，不做太多清洗和建模。为机器学习、AI 分析提供数据底座。
6.2 运维与管理域
| 平台 | 职责 |
|---|---|
| 运维管理平台 | 监控告警、日志管理、配置中心 |
| 分布式事务协调 | Seata/TCC 事务管理器 |
| 消息中间件 | Kafka/MQ，异步解耦 |
| 服务治理 | 服务注册发现、限流熔断 |
| 开发测试平台 | CI/CD、自动化测试 |
七、真实案例：某股份制大型商业银行企业级业务架构
理论讲完，来看看真实的大行是怎么做的。
某股份制大型商业银行是国内最早推进"企业级架构"转型的银行之一，其架构可以概括为：
7.1 架构特点
┌────────────────────────┐ │ 客户体验层 │ │ JIN行 / JIN联 / JIN购 │ ├────────────────────────┤ │ 业务中台层 │ │ 产品中心 / 营销中心 │ │ 风险中心 / 运营中心 │ ├────────────────────────┤ │ 技术中台层 │ │ 交易中台 / 数据中台 │ │ AI中台 / 安全中台 │ ├────────────────────────┤ │ 基础设施层 │ │ 分布式数据库 / 云平台 │ └────────────────────────┘关键特点：
- 双中台架构：业务中台 + 技术中台，实现能力复用
- 产品化思维：把业务能力封装成"产品"，通过配置而非开发来上线新产品
- 数据驱动：全行统一数据标准，数据入湖入仓，AI 赋能业务
7.2 城商行 vs 大行的差异
与工行相比，城商行的架构通常更简洁：
| 维度 | 大行（工行/建行/农行） | 城商行 |
|---|---|---|
| 系统数量 | 200+ | 50-100 |
| 核心系统 | 自研或深度定制 | 采购（T24/神州数码等） |
| 分层层数 | 5-6 层 | 3-4 层 |
| 技术架构 | 分布式 + 微服务 | 部分分布式，部分集中式 |
| 数据平台 | 数据湖 + 实时平台 | 数据仓库为主 |
| 建设团队 | 数千人 | 几十到两三百人 |
不要被大行的复杂架构吓到。小银行不需要、也不应该照搬大行的架构。分层的目的不是"越多越好"，而是职责清晰、边界明确、可维护、可扩展。
八、一张图总结
┌───────────────────────────────────────────────────────────┐ │ 银行IT系统分层全景 │ │ │ │ 📱 客户交互层 │ │ 手机银行 | 网上银行 | 柜面 | ATM | 微信 | POS │ │ ────────────────────────────────────────────── │ │ 🔀 渠道整合层 │ │ 渠道网关 | 统一认证 | 支付路由 | API开放平台 │ │ ────────────────────────────────────────────── │ │ ⚙️ 业务处理层 │ │ 核心系统 | 信贷 | 理财 | 国结 | 信用卡 | 支付清算 │ │ CIF | 产品工厂 | 签约 | 凭证 | 反洗钱 | 征信 │ │ ────────────────────────────────────────────── │ │ 🗄️ 数据与管理层 │ │ 数据仓库 | 实时平台 | 数据湖 | 运维平台 | 中间件 │ │ │ └───────────────────────────────────────────────────────────┘九、本篇小结
- 银行 IT 系统天然适合四层架构：渠道层、整合层、业务层、数据层
- 渠道层是客户触点，追求体验一致性和快速迭代
- 整合层是粘合剂，避免渠道和业务系统的网状直连
- 业务层是心脏，核心系统是其中最关键的一个
- 数据层是地基，为决策和监管提供数据支撑
- 大行和城商行的架构复杂度差异很大，但分层思路是一致的
下一篇，我们将深入讨论这个全景图中最核心的问题：核心系统与外围系统的边界到底在哪里？"瘦核心"和"胖核心"之争的本质是什么？
📖下一篇：文章 6 · 核心系统与外围系统的关系
📚本系列：开篇 → 第一章 →第二章 · 鸟瞰全局→ 第三章 → ...
© 2026 Fintech.Ren · 银行核心业务系统专栏