第一章 · 前世今生 第 1 篇:手工记账到大型机时代：银行核心系统的「史前史」

第一章 · 前世今生| 银行核心业务系统知识体系 · 第 1 篇

📖 全文约 4500 字 | 预计阅读时间 11 分钟

1970 年代的某个深夜，中国某人民银行支行的营业室里还亮着灯。

一名年轻柜员面前摊开着三本厚厚的账簿——一本记存款、一本记贷款、一本记内部往来。他左手翻着客户的存折，右手握着蘸水笔，一笔一笔地把当天几十笔交易的数字誊抄到对应页码上。

抄完之后，他开始做一件今天所有银行系统都会在凌晨自动完成的事——轧账。

把所有借方加起来，把所有贷方加起来，看两边是否相等。如果差了一分钱，对不起，把今天的所有交易一笔一笔倒回去查，直到找到那一分钱为止。

这个过程，有时候要到凌晨三四点。

这就是银行核心系统的起点：一个人、一支笔、一本账。

01 | 纸质账本时代：一本账走天下

在计算机进入银行之前，银行的全部业务运转依赖一套看似原始、实则精密的手工账务体系。

复式记账法的千年传承

首先要理解的是，银行记账并不是「我记你欠我多少钱」那么简单。银行使用的是复式记账法（Double-Entry Bookkeeping）——每笔交易必须同时记两笔：一笔记「从哪来」，一笔记「到哪去」。

这个方法 15 世纪由意大利数学家帕乔利系统化总结，至今仍是全球银行业的会计基础。

在纸质账本时代，一笔「客户张三存入 100 元」的业务，柜员需要做以下动作：

第 1 步：在张三的个人存折上，写下日期、金额、余额 第 2 步：在存款登记簿上，记一笔：借方「库存现金」+100，贷方「活期存款」+100 第 3 步：在现金登记簿上，记录实收现金 +100 元 第 4 步：在日终汇总时，把所有交易按科目汇总

四步做完，一笔最简单的存款才算真正「入账」。

手工记账的「系统架构」

别小看纸质账本时代。实际上，当时的银行已经形成了一套相当成熟的「系统架构」，只不过载体是纸而不是电子：

注意到了吗？现代银行核心系统的每一个模块，几乎都能在纸质账本时代找到原型。总账、流水、清算、日终处理——这些概念不是计算机发明的，而是在计算机到来之前就已经存在了上百年的银行实践。

计算机做的，只是把这套手工流程自动化了。

这个时代的工作节奏

手工记账时代的银行，有一个非常明确的「批处理」节奏：

• ☀️白天：开门营业，柜员手工记录每一笔交易
• 🌙晚上：关门之后，开始「轧账」——汇总、对账、结计利息
• 📋月末/季末：编制财务报表，上报上级部门

白天营业、晚上结算——这个节奏一直延续到今天，就是银行核心系统「日终批处理」的源头。

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 | 小结：从纸到电，不变的是什么？

让我们回顾一下这段历史的关键节点：

从纸质账本到大型机，银行系统的载体变了、速度变了、处理能力变了，但有三个东西始终没变：

第一，账必平。无论是手工记账还是计算机记账，借贷必须相等，一分钱都不能差。

第二，日终结算。白天营业、晚上结算是银行的基本节奏，不是技术的限制，而是业务的需求。

第三，数据是命根子。账户余额、交易流水、会计分录——这些数据是银行最核心的资产，丢了就是灾难。

这三条，既是银行核心系统的基因，也是理解后续每一次技术演进的关键钥匙。

下一篇预告： 《联机时代的崛起——当银行从「隔日到账」变成「实时扣账》（1980s-1990s）》

你知道吗？在 1980 年代之前，银行转账通常是「隔日到账」的——你今天上午去柜台办一笔汇款，对方可能要第二天才能收到钱。是什么技术突破让银行从「T+1」进化到了「T+0」？关系型数据库在其中扮演了什么角色？ATM 的出现又是如何倒逼银行系统进行「分布式改造」的？

下一篇，我们来看这段改变了银行业运转速度的历史。

银行核心业务系统知识体系 · 第一章 ·Fintech.Ren 出品

关注我，和我一起把银行核心系统学透。