实时支付通道全天候运行，几秒内完成结算。而大多数核心系统仍按批次过账。两者之间的过账层，正是问题所在。

即时支付通道改变参与者账本的一件事：余额必须在任何时刻、对每条报文都保持正确。美国的 FedNow，以及加拿大从 2026 年底开始分阶段上线的 Real-Time Rail，都能在几秒内完成一笔支付的端到端处理，全年无休。而大多数参与者仍然把账过到一个为批量处理、日终跑批和维护窗口而设计的核心系统上。

支付通道不会等待核心系统。必须有东西夹在两者之间，实时保证每个账户的余额精确无误。这就是过账层，而接入即时支付通道的大部分风险，实际上就集中在这里。

TulaDB 是按照 Payments Canada 的 Real-Time Rail 对参与者的要求来设计的，设计者本人从事过实时支付、清算和结算方面的工作。本文描述我们所看到的问题，以及我们为引擎设定的、要提供的保证。

开发者预览说明：TulaDB 目前处于开发者预览阶段。下文描述的引擎行为已经发布，并且已经对照运行中的引擎验证过；通道适配器（ISO 20022 报文解析）不属于引擎的一部分，是路线图中的下一步。参见尚未构建的部分。

抛开报文格式不谈，即时支付通道对参与者的账本提出了七项要求：

通常的做法是用一张备忘过账表：在通用数据库里记录行，由支付中枢写入，核心系统之后再跟上。于是每一项要求都变成应用层代码，每个团队都要重新实现一遍——而边界情况会在生产环境中暴露出来：

这些都不是什么稀奇的事。它只是系统中必须做到完美的那一部分，却被当作系统中无人负责的那一部分来构建。

TulaDB 把上述每一项保证都移入账本引擎本身，使它们对每个写入方都成立，并贯穿每一次故障。一笔即时支付的出站流程，直接映射到引擎的两阶段生命周期上：

RTR = 1 # 每条通道一个 source_id e2e = "E2E-20261029-000042" # 该报文的端到端 id pay = TransferCreate(source_id=RTR, ledger_id=L, currency=124, debit_account_id=MEMBER, credit_account_id=RTR_SETTLE, amount=80_000, txn_id=e2e) r = c.reserve(pay) # 已发送：资金被冻结，可用余额立即下降 c.reserve(pay) # 超时后重发：返回 OK_DUPLICATE，transfer_id 相同 c.commit_by_key(RTR, L, 124, e2e) # 通道已接受：冻结转为过账

或者

c.rollback_by_key(RTR, L, 124, e2e) # 通道拒绝：冻结被释放

引擎在这里提供的保证，每一项都对照运行中的引擎验证过：

限额与故障切换保证来自同一个引擎：limit_low 在每次变更时原子地强制执行，集群在节点被杀和网络分区的情况下仍能持续过账——在每一次产生判定结果的故障注入云端运行中，资金都精确到最小单位保持平衡。

重点不是替换核心系统。替换核心系统是一个多年期的工程。实时过账层是加在它前面的：

支付通道与过账层对话。核心系统继续做它擅长的事——产品、对账单、利息——并通过为它量身构建的 feed 从账本历史中更新；仍然源自核心系统的过账，比如手续费和利息，则反向流入过账层。财务从 Iceberg 导出中对账，每一条已提交的记录都会带着自己的身份标识落盘，并且可以选择附带其生效后两个账户的余额。

评估过账层风险最低的方式，是让它与你现有的系统并行运行。在你自己的环境中向它喂入回放或匿名化的通道流量，不让任何面向客户的东西依赖它，然后把它的余额和拒绝结果与现有账本对同一批支付记录的结果做比较。不一致之处才是有意思的部分：每一处要么是新层的缺陷，要么是旧层搞错的一笔支付。

在支付领域，对范围的诚实比平时更重要：

如果你正在为接入即时支付通道做准备，而过账层正是让你担心的部分，欢迎成为设计合作伙伴。接下来的两篇文章分别讨论跨所有通道的单一余额，以及你可以强制执行的日内流动性。

在有任何东西依赖它之前，先用回放或匿名化流量在影子模式下验证实时过账层。我们在一个工作日内回复。