第一章 · 前世今生 | 银行核心业务系统知识体系 · 第 1 篇
📖 全文约 4500 字 | 预计阅读时间 11 分钟
1970 年代的某个深夜，中国某人民银行支行的营业室里还亮着灯。
一名年轻柜员面前摊开着三本厚厚的账簿——一本记存款、一本记贷款、一本记内部往来。他左手翻着客户的存折，右手握着蘸水笔，一笔一笔地把当天几十笔交易的数字誊抄到对应页码上。
抄完之后，他开始做一件今天所有银行系统都会在凌晨自动完成的事——轧账。
把所有借方加起来，把所有贷方加起来，看两边是否相等。如果差了一分钱，对不起，把今天的所有交易一笔一笔倒回去查，直到找到那一分钱为止。
这个过程，有时候要到凌晨三四点。
这就是银行核心系统的起点：一个人、一支笔、一本账。
01 | 纸质账本时代：一本账走天下
在计算机进入银行之前，银行的全部业务运转依赖一套看似原始、实则精密的手工账务体系。
复式记账法的千年传承
首先要理解的是，银行记账并不是「我记你欠我多少钱」那么简单。银行使用的是复式记账法（Double-Entry Bookkeeping） ——每笔交易必须同时记两笔：一笔记「从哪来」，一笔记「到哪去」。
这个方法 15 世纪由意大利数学家帕乔利系统化总结，至今仍是全球银行业的会计基础。
在纸质账本时代，一笔「客户张三存入 100 元」的业务，柜员需要做以下动作：
第 1 步：在张三的个人存折上，写下日期、金额、余额
第 2 步：在存款登记簿上，记一笔：借方「库存现金」+100，贷方「活期存款」+100
第 3 步：在现金登记簿上，记录实收现金 +100 元
第 4 步：在日终汇总时，把所有交易按科目汇总
四步做完，一笔最简单的存款才算真正「入账」。
手工记账的「系统架构」
别小看纸质账本时代。实际上，当时的银行已经形成了一套相当成熟的「系统架构」，只不过载体是纸而不是电子：
| 账簿类型 | 功能 | 现代等价物 |
|---|---|---|
| 客户存折/存单 | 记录单个客户的交易明细 | 账户流水 |
| 总账 | 按会计科目汇总所有交易 | 总账系统（GL） |
| 现金登记簿 | 记录现金收支 | 现金管理系统 |
| 内部往来账 | 记录不同网点之间的资金往来 | 清算系统 |
| 日计表 | 每天的科目余额汇总 | 日终报表 |
注意到了吗？现代银行核心系统的每一个模块，几乎都能在纸质账本时代找到原型。 总账、流水、清算、日终处理——这些概念不是计算机发明的，而是在计算机到来之前就已经存在了上百年的银行实践。
计算机做的，只是把这套手工流程自动化了。
这个时代的工作节奏
手工记账时代的银行，有一个非常明确的「批处理」节奏：
- ☀️ 白天：开门营业，柜员手工记录每一笔交易
- 🌙 晚上：关门之后，开始「轧账」——汇总、对账、结计利息
- 📋 月末/季末：编制财务报表，上报上级部门
白天营业、晚上结算——这个节奏一直延续到今天，就是银行核心系统「日终批处理」的源头。
02 | 计算机的到来：从打孔卡片到大型机
最早的银行计算机：打孔卡片时代
银行引入计算机的尝试，可以追溯到 20 世纪 50 年代。
1950 年，美国银行（Bank of America）与斯坦福研究院（SRI）合作，启动了一个名为 ERMA（Electronic Recording Machine, Accounting）的项目。这个系统的核心思路是：用打孔卡片和磁性墨水字符识别（MICR）来自动处理支票。
在此之前，银行处理一张支票需要人工核对签名、手写记账、手动归档——一个熟练的职员一天最多处理 300 张左右。ERMA 系统投入使用后，处理速度提升到了每小时 33,000 张。
这是银行第一次尝到「自动化」的甜头。
IBM 360/370：银行计算机的第一次飞跃
真正让计算机在银行业站稳脚跟的，是 IBM 在 1964 年推出的 System/360。
System/360 之所以重要，不仅因为它的计算能力，更因为它引入了一个革命性的概念——兼容性。在此之前，每一代计算机都需要重写所有程序。而 360 系列，从最小到最大的机型，都可以运行同一套软件。
对银行来说，这意味着什么？意味着你可以在一台小型机上开发和测试程序，然后在大型机上部署运行。软件资产不再是「一次性」的了。
随后 IBM 在 1970 年推出的 System/370 进一步增强了虚拟内存和多道程序设计能力，让一台大型机可以同时运行多个程序——这为银行同时处理多种业务（存款、贷款、汇款）提供了基础。
为什么银行选择了大型机？
互联网时代的人可能会疑惑：为什么不直接用个人电脑？
因为 1970 年代没有个人电脑。即使到了 1980 年代 IBM PC 推出之后，它的性能也无法满足银行的需求。
银行需要的不是一台「跑得快」的电脑，而是一台绝对可靠、绝对准确、能同时处理上千笔交易的机器。在当时的条件下，只有大型机能做到。
更重要的是，银行的核心需求是事务一致性——每一笔交易要么完整成功，要么完全不发生，不能出现「扣了钱但没到账」的中间状态。IBM 的 CICS（Customer Information Control System，客户信息控制系统）在 1969 年推出，专门为在线事务处理（OLTP）设计，提供了锁机制和事务恢复能力。
CICS 后来成为了银行核心系统领域最重要的中间件之一，直到今天仍在很多银行的生产环境中运行。
03 | 批量处理模式：白天营业、晚上结算
「批处理」到底在处理什么？
前面说到，手工记账时代的银行已经是「白天营业、晚上结算」的节奏。当计算机接管之后，这个节奏被保留了下来，并且赋予了更精确的内涵。
大型机时代的银行核心系统，典型的运行模式是：
┌─────────────────────────────────────────────────────────┐
│ 一个完整业务日 │
├──────────────┬──────────────────────────────────────────┤
│ 09:00-17:00 │ 联机交易时间 │
│ （营业时间） │ 柜员录入交易→实时更新账户余额 │
├──────────────┼──────────────────────────────────────────┤
│ 17:00-18:00 │ 日终批处理开始 │
│ （结算时间） │ ① 汇总当日交易 │
│ │ ② 计算当日利息 │
│ │ ③ 更新会计科目余额 │
│ │ ④ 生成各类报表 │
│ │ ⑤ 数据备份 │
├──────────────┼──────────────────────────────────────────┤
│ 18:00-次日 │ 数据备份/维护窗口 │
│ 09:00 │ 日始处理：加载当日参数，准备新一天的营业 │
└──────────────┴──────────────────────────────────────────┘
这看起来很简单，但每一项都有它的技术深意。
日终计息：白天柜员只记录了「这个账户今天发生了哪些交易」，但利息怎么算？需要把全量账户的余额变动拿出来，按积数法计算利息。这是当时计算量最大的批处理任务。
科目余额更新：白天的交易虽然已经实时更新了账户余额，但会计科目的汇总余额需要等到日终才能更新——因为汇总运算的计算量太大，实时做会影响联机交易性能。
数据备份：在磁带时代，把当天的全量数据备份到磁带上，是防止数据丢失的唯一手段。
为什么「批处理」这个概念一直活到了今天？
到了 2026 年，银行核心系统早已不是大型机一家独大了。分布式架构、微服务、实时计算……技术在飞速进步，但「日终批处理」这个概念，几乎没有任何一个银行能完全抛弃。
原因有三层：
第一层：性能折衷。 即使在今天，对数千万账户做全量利息计算、全量余额汇总，仍然是一个重量级操作。在联机交易时段做这些事，会占用大量计算资源，影响客户体验。
第二层：数据一致性。 批处理提供了一个天然的「检查点」——一天的业务结束了，我们来做一个完整的对账。如果发现差错，还有时间在第二天开门之前修正。
第三层：监管要求。 银行的很多监管报表，是基于「每日终了」这个时间点的数据生成的。1104 报表、存款准备金计算、大额交易报告……这些都需要在日终批处理完成后才能产出。
所以，批处理不是「落后的产物」，而是在银行这个特殊行业里，经过几十年验证、最安全可靠的处理模式。它在不断进化——从几个小时缩短到几十分钟，从全量串行变成增量并行——但它的核心理念：「在业务空闲时段做集中处理」，至今未变。
04 | 这个时代留下的遗产
回顾 1950s 到 1980s 这三十年的银行计算机化历程，你会发现，今天银行核心系统的很多基本特征，在这个时代就已经定型了。
遗产一：「批处理」概念
前面已经详细讨论了。这里不再重复，只强调一点：批处理不是技术限制下的权宜之计，而是银行风险管理的基本制度设计。
遗产二：「科目-账户」二元数据结构
大型机时代的银行系统，数据结构通常是「两级」的：
- 上层是会计科目：如「活期存款」「贷款」「库存现金」等
- 下层是具体账户：属于某个科目下的个别客户账户
比如「活期存款」是一个科目，张三的账户 6222xxxxx 和李四的账户 6222yyyyy 都挂在「活期存款」这个科目下面。
这个「科目-账户」的二元结构，在今天几乎所有银行核心系统中仍然保留。它是银行会计核算的基础，也是为什么银行核心系统的数据模型比互联网公司的复杂得多。
遗产三：「日终」作为基本业务周期
银行系统把「一天」作为一个基本的业务周期。这个概念在今天看来可能有些奇怪——互联网系统通常是「持续运行」的，没有「关门结算」的概念。
但银行的「日终」概念根植于它的商业本质：银行每天开门做生意，晚上需要知道今天赚了多少、亏了多少、风险敞口多大。
这个「日终」概念，直接决定了银行核心系统的架构设计——系统必须有明确的「营业」和「结算」状态切换，有完整的对账和校验机制。
遗产四：对「事务一致性」的极致追求
从纸质账本时代开始，银行就有一句话：「账不平，天塌了。」
一本手工账簿如果差了一分钱，柜员要熬夜找到原因。大型机时代的 CICS 系统引入了 ACID 事务（原子性、一致性、隔离性、持久性），就是为了确保计算机处理也能达到「账必平」的标准。
这种对数据一致性的极致追求，贯穿了银行核心系统整个发展史，也使得银行 IT 工程师对「数据可靠性」的敏感度远高于其他行业。
05 | 小结：从纸到电，不变的是什么？
让我们回顾一下这段历史的关键节点：
| 时间 | 关键事件 | 对银行系统的影响 |
|---|---|---|
| 1950s | 纸质账本+复式记账法 | 确立了「科目-账户」的二元数据结构 |
| 1950s | 美国银行 ERMA 项目 | 首次实现支票处理的自动化 |
| 1964 | IBM System/360 推出 | 引入兼容性，软件资产可跨代保留 |
| 1969 | IBM CICS 推出 | 在线事务处理（OLTP）的基石 |
| 1970s | 大型机在银行业广泛部署 | 确立「批处理」为标准运行模式 |
从纸质账本到大型机，银行系统的载体变了、速度变了、处理能力变了，但有三个东西始终没变：
第一，账必平。 无论是手工记账还是计算机记账，借贷必须相等，一分钱都不能差。
第二，日终结算。 白天营业、晚上结算是银行的基本节奏，不是技术的限制，而是业务的需求。
第三，数据是命根子。 账户余额、交易流水、会计分录——这些数据是银行最核心的资产，丢了就是灾难。
这三条，既是银行核心系统的基因，也是理解后续每一次技术演进的关键钥匙。
下一篇预告： 《联机时代的崛起——当银行从「隔日到账」变成「实时扣账》（1980s-1990s）》
你知道吗？在 1980 年代之前，银行转账通常是「隔日到账」的——你今天上午去柜台办一笔汇款，对方可能要第二天才能收到钱。是什么技术突破让银行从「T+1」进化到了「T+0」？关系型数据库在其中扮演了什么角色？ATM 的出现又是如何倒逼银行系统进行「分布式改造」的？
下一篇，我们来看这段改变了银行业运转速度的历史。
银行核心业务系统知识体系 · 第一章 · Fintech.Ren 出品
关注我，和我一起把银行核心系统学透。
