上一章我们看清了一件事：两家银行都在央行开着户，跨行转账的终点，就是央行在自己那本账上改两行数字——一家减、一家加，钱真正易手，谁也赖不掉。那一下叫「钱到了」。
可是等一下。如果每一笔转账都要惊动央行去改账，那央行这台机器一天得转多少圈？工商银行和招商银行之间，光是双十一那种日子，来回打款可能有上千万笔。真要一笔一笔都跑去央行账上过一遍，那画面你想象一下——就像每次数据库写一个字段就单独开一个事务、单独 commit 一次，磁盘头都快磨没了。
现实当然不是这样。这里藏着一对总被人当成同义词、其实完全是两回事的词：清算和结算。这一章就干一件事：把它俩掰开。
「算账」和「付钱」是两件事
清算 clearing，说白了就是算账、对账：交易双方（乃至整个市场里所有银行）坐下来核对——到底谁给谁转了多少、来来回回抵消完，最后谁还欠谁多少？这一步只动脑子和账本，不动真钱。
结算 settlement，才是真掏钱：按照清算算出来的结果，在央行的准备金账户上把钱真正划过去，钱真正易手的那一下。
清算是「算」，结算是「付」。一个是对账单，一个是转账成功。算清楚了不等于钱到了；钱到了之前，得先算清楚。
工程师最熟这个套路。想想数据库事务：你在事务里 UPDATE 来 UPDATE 去，改的都是内存里、还没落地的中间状态——这就是清算，账在算、还没作数。直到 COMMIT 那一下，数据才真正写进去、别人才看得见、才不可撤销——那就是结算。你在 commit 之前记的那些账，说翻脸就能 ROLLBACK；commit 之后，泼出去的水。
为什么不能一笔一笔付：净额轧差
现在回到那上千万笔转账。清算这一步最值钱的魔法，叫净额轧差 netting：把方向相反的款项互相抵消，只留下净下来的差额。
举个最小的例子。一整天下来：
- A 银行的客户给 B 银行的客户，一共打了 100 亿；
- B 银行的客户给 A 银行的客户，一共打了 98 亿。
笨办法是：在央行账上划 100 亿，再反方向划 98 亿，来回搬 198 亿。聪明办法是：这两股水流方向相反，先在纸上对冲掉——A 净欠 B 就 2 亿。于是最后只在央行账上划一笔 2 亿就完事了。
感受一下这个压缩比。原本上千万笔、总额小两百亿的资金流，轧差之后，真正惊动央行准备金账户的，可能就是几家银行之间的那么几笔净额。海量交易被压成了极少数几次真金白银的划转。
省下来的是什么？是流动性——银行在央行账上真正要备着的钱。如果每笔都全额真划，A 得时时刻刻在账上备够 100 亿现钱才转得动；轧差之后，它当天只需要备够那 2 亿的净额。同一笔钱能顶一百笔用，压力天差地别。
净额轧差，就是「别一笔笔搬钱，先把来回账抵掉，只搬最后的差额」。它不改变谁欠谁多少，只是把要真正搬动的钱压到最小。
这也是工程师熟悉的批处理 batch思路：不是每来一条请求就立刻落盘一次（那太贵），而是攒一批、合并、去重、抵消，最后一次性写入。轧差就是资金界的批处理加去重。
两种结算模式：逐笔 vs 攒批
那问题来了：到底该「每笔都立刻真付」，还是「攒一批轧差后付一次」？这是一道经典的取舍题，对应两种真实存在的结算模式。
RTGS 全额实时结算（Real-Time Gross Settlement）：每一笔转账，立刻、单独、按全额在央行账上结清，一笔是一笔，绝不抵消、绝不拖延。
- 好处：安全。钱一笔笔即时到账、即时终局，收款方拿到就是拿到，中间不存在「算好了还没付」的悬空状态。
- 代价：吃流动性。你得随时在账上备着足额的钱，一笔 100 亿就得有 100 亿现钱趴着，占用巨大。
净额结算（Net Settlement，常见的是「延迟净额结算」）：攒够一段时间（比如一整天，或几个批次），把大家的账全部轧差，最后按净额结一次。
- 好处：省钱、省流动性。就是上面那个 198 亿压成 2 亿的魔法。
- 代价：有风险。因为清算和结算之间，隔着一段时间。
对应到工程师的直觉：RTGS 就是每条请求单独同步提交——慢、贵、但每一步都落地、都可靠；净额结算就是攒一批异步刷盘——快、省，但在刷盘之前，那批数据还悬在半空，万一断电……
「算清了」和「付到了」之间的那段空档
问题就出在这个「悬在半空」。净额结算里，白天大家疯狂交易、账在不停地算，但真正的那笔净额划转，要到收盘后才发生。也就是说：从「清算算清了，账面上你该收我 2 亿」，到「结算真付了，2 亿真到你央行账上」，中间隔着好几个小时。
这段空档里，钱在账面上已经「算是」你的了，但还没真到你手里。这就埋下了一种风险：
结算风险 / 日间信用风险：在「算清」到「真付」之间的这段时间差里，如果欠钱的那家银行突然倒闭了，对手方就可能收不到本该到账的钱——账上算得清清楚楚该给你 2 亿，可人没了，这 2 亿也就悬了。
说人话：对账单上写着「他欠你 2 亿」，不等于这 2 亿已经安全躺进你口袋。在他真掏钱之前，他要是垮了，你手里就只剩一张对账单。
你可以把它类比成：数据库里一堆事务都 UPDATE 完了、就等最后统一 COMMIT，结果 commit 之前进程崩了——那些「已经算好」的改动，一笔都没真正落地。区别在于，数据库崩了可以重来，银行倒了，那笔钱是真没了。
正是为了省流动性，市场大量采用净额结算；也正因如此，这段空档里的结算风险，成了整个支付体系必须严肃对付的东西。它有个响当当的名字，来自一家真的倒在这段空档里的银行——但那是第十二章的故事。而人们为了消灭这段空档想出的精巧机制，是第十三章的事。这里我们只需记住这颗种子已经种下：清算和结算之间，有时间，有风险。
把这一章收进一句话
清算是算账，结算是付钱；净额轧差让海量交易压成极少数几笔真金白银的划转，省下大把流动性；代价是「算清」和「付到」之间出现了空档，空档里藏着结算风险。
下一章我们要问一个新问题：前面这一切「都在央行开户、账上一划就终局」的前提，跨出国门就崩了。中国的银行，在美联储可没有账户。那跨国的钱，到底是怎么挪的？答案要从代理行说起。