第十二章 · 换汇的隐藏地雷：赫斯塔特风险

前面第七章我们埋过一个钩子：一笔付款从「清算算清」到「结算真付」之间，是有时间差的。清算只是把账对明白——谁该给谁多少；结算才是钱真的从一个口袋挪到另一个口袋。这中间的空档里，万一对手方倒了，你就收不到钱。我们当时叫它结算风险，还没细说它到底能坏到什么程度。

这一章，我们把这个空档放到外汇交易里看。你会发现，它在这里变得格外致命——致命到有一家银行用自己的名字给它命了名。

先想清楚外汇交易长什么样。你拿人民币去换美元，付给一个美国人。这里面不是「一笔钱动了一下」，而是两笔钱、两个方向：

一手交钱、一手交货，本该同时发生。可问题在于——这两条腿根本不在同一个地方结算。人民币在中国的清算系统里走，美元在美国的清算系统里走。两套系统、两个国家、两个时区，各管各的。

换句话说：你给对方的人民币，是在中国的账本上划过去的；对方给你的美元，是在美国的账本上划过去的。这是两本完全独立的账，没有任何机制保证它们同一秒都划好。

这里出现一个专有名词：结算风险 settlement risk——在你已经付出去、但还没收到回来的那段时间里，对手方赖账或倒闭，你就本金全损。而它在外汇里的这个特化版本，因为一场真实事故，有了自己的名字：赫斯塔特风险 Herstatt risk。

为什么两条腿凑不到同一瞬间？因为银行和清算系统每天只在本地的工作时段开门。

法兰克福、伦敦、纽约，同一天里的营业时间是错开的。当法兰克福已经是下午、准备收市时，伦敦还在下午早些，纽约那边才刚上午开门。德国马克得在德国的工作时段结算，美元得在美国的工作时段结算——两种货币根本不可能在同一个瞬间同时到账，因为它们各自要账的那扇门开在不同的钟点。

于是就有了这样一个尴尬的顺序：你在法兰克福这边，德国时间大白天，先把马克付出去了；对方承诺的美元，要等纽约那边开门、当天晚些时候才到。这几个小时的空档，就是地雷埋着的地方。

名字来自一家真实的银行：赫斯塔特银行 Bankhaus Herstatt，一家德国的私人银行。它在外汇投机上巨亏，窟窿大到资不抵债。

1974年6月26日，德国监管当局出手，勒令它关门。关键在于关门的时点：这道命令下在德国当地下午收市之后。

就在那一天，赫斯塔特的很多外汇对手方，已经在德国这边按约定把德国马克付给了它——它们那条腿交割完了，正等着当天晚些时候在纽约收回对应的美元（因为时差，纽约还在上午，美元那条腿还没轮到结算）。

然后赫斯塔特被关了。纽约那边，该由赫斯塔特发出的美元付款，戛然而止。

对手方的处境：马克，付出去了，收不回来；美元，该收的，永远没来。一笔交易的两条腿，它们只兑现了对自己不利的那一条。

这不是「利息少赚了」或者「汇率亏一点」，这是本金全损——付出去的那一整笔，凭空蒸发。这场事故第一次让全世界看清楚一件事：时区错开，加上两条腿分开结算，等于可能血本无归。

它的冲击大到直接推动了后来的巴塞尔委员会去正视这类风险，并最终催生了一个专门用来拆掉这颗地雷的系统——那是下一章的主角，这里先按住不表。

如果你写过跨服务的代码，这个故事你应该觉得眼熟得可怕。它就是分布式事务丢了原子性的经典翻车现场。

先解释一下：原子性 atomicity就是「一组操作要么全成、要么全不成，不许卡在中间」。数据库里靠它保证：一条转账 SQL，扣款和入账要么都生效，要么都回滚，绝不会出现「扣了没入」。

把赫斯塔特这笔交易翻译成代码，大概是这样：

本地提交成功，远端提交失败，两半没有绑在一个事务里。要命的是：钱不像数据库那样能回滚。数据库崩了可以把「扣款」撤销；可你付出去的马克，落到别人账上，人家银行都倒闭清算了，你 rollback 给谁看？付出去，就是付出去了。

所以赫斯塔特风险的技术本质，一句话就能说透：两条腿之间缺一个原子提交——缺「要么两条腿都成、要么都不成」的保证。只要这个保证不在，时差就会一直给你留着那个致命的空档。

问题现在很清楚了：麻烦不在于「谁不守信」，而在于结算的机制本身允许「只兑现一半」。只要还是你先付、对方后付，中间总有一段时间你是敞着口子的。

真正的解法，得从机制上下手：把两条腿绑成一个原子操作——要么你的马克和对方的美元同时到账，要么两笔都不动，谁也别想只拿走对自己有利的那半。

可是两种货币在两个国家、两个时区的系统里跑，怎么可能逼它们「同时」？这正是下一章要拆的东西——一套专门为「一手交钱一手交货」而生的机制，叫 CLS，核心思路叫 PvP。地雷怎么排，我们下一章见。