在手机银行里转出一笔钱，几秒后，对方那边余额就变了。
但同一秒内，付款银行不见得已经把等额准备金逐笔划给了收款银行。
客户账户到没到账、银行之间怎么算应收应付、结算资产什么时候真正转移，是三件相关、但并不完全相同的事。把这三件事分开看，实时全额结算和延迟净额结算的区别也就清楚了。
那为什么支付系统不把每一笔钱都立刻结掉？答案不在技术上。技术上完全做得到。难的是支付系统始终要在两件事之间做取舍：
RTGS和DNS，正是这个取舍下形成的两套基本制度安排。
一、A银行欠100亿元，B银行欠98亿元，为什么不一定要转198亿元？
假设一天之内，A银行的客户需要向B银行的客户支付100亿元；与此同时，B银行的客户也需要向A银行的客户支付98亿元。
支付系统至少有两种处理思路。
第一种，是每笔支付指令到来后，立即单独完成最终结算。A银行向B银行支付的每一笔钱，都逐笔在结算账户中划转；B银行向A银行支付的每一笔钱，也照此处理。这是理解RTGS最直观的方式。
第二种，是先处理客户支付，持续记录两家银行之间的应收应付，等到规定的结算时点再计算净头寸：
| 支付方向 | 累计金额 |
|---|---|
| A银行应付B银行 | 100亿元 |
| B银行应付A银行 | 98亿元 |
| 轧差结果 | A银行向B银行净付2亿元 |
客户之间原本发生的支付并没有消失。100亿元和98亿元的交易记录仍然存在，收付款人的账户也要按业务规则处理。变化的是参与机构之间最终需要转移的结算资产：从两个方向累计198亿元的支付总额，变成A银行向B银行转移2亿元净额。
这就是DNS（Deferred Net Settlement，延迟净额结算）最核心的逻辑。
这里还要避开一个常见误解：不能因此断言RTGS一定需要在双方结算账户中准备至少198亿元。因为银行之间的交易是时刻在发生的，上一笔在RTGS中收到的资金会继续用于下一笔付款，同一笔日间流动性能够反复周转，而且支付系统还可能提供排队、抵押融资和流动性节约机制帮助银行节约所需的流动性。
所以，我们关注的不是“198亿元和2亿元谁更小”，而是下面这个更实际的问题：
二、支付、清算和结算，并不是同一个动作
日常语言里，“支付”“清算”“结算”经常混着用。进入支付基础设施以后，就得把它们分开。
| 环节 | 主要解决的问题 |
|---|---|
| 支付 | 付款人如何向收款人发出资金转移指令 |
| 清算 | 指令如何传递、核验，并计算参与机构之间的应收应付 |
| 结算 | 如何转移结算资产，最终解除参与机构之间的债务 |
客户在App里看到“到账”，说的是客户账户层的结果；清算系统算出“A银行净欠B银行2亿元”，说的是机构间债务；央行账户或其他指定结算账户真正完成资金转移，才涉及最终结算。
为了讲清跨行支付，可以先看一张极度简化的银行资产负债表：
| 资产 | 负债端 |
|---|---|
| 存放央行的准备金 | 客户存款 |
| 贷款及其他资产 | 其他负债和所有者权益 |
假设A银行客户通过RTGS向B银行客户支付10亿元，相关会计分录可以简化为：
| 机构 | 资产变化 | 负债变化 |
|---|---|---|
| A银行 | 央行准备金 −10亿元 | 付款客户存款 −10亿元 |
| B银行 | 央行准备金 +10亿元 | 收款客户存款 +10亿元 |
A银行和B银行的客户存款是商业银行对客户的负债，如果客户之间发生了资产负债的转移，那么客户所属银行之间则需要通过央行账户体系中的结算资产完成最终结算。
在DNS安排中，客户账户变化与机构间最终结算可能不在同一时点发生。为了确保收款银行尽快给客户入账，要通过支付系统系统处理规则、风险控制、参与协议等机制保障银行不会因为提前入账导致资金损失。
三、RTGS为什么安全？
RTGS是Real-Time Gross Settlement，即实时全额结算。
“Gross”表示支付不等日终净额轧差，而是逐笔结算；“Real-Time”强调符合条件的指令在系统运行过程中实时处理并取得结算最终性。
以A银行向B银行支付10亿元为例：
- A银行提交支付指令；
- 系统检查A银行是否拥有足够的可用结算资金或获准使用的日间信用；
- A银行的央行账户减少10亿元；
- B银行的央行账户增加10亿元；
- 该笔结算取得最终性。
美国Fedwire就是典型的RTGS。美联储明确说明，Fedwire逐笔借记付款机构账户、贷记收款机构账户，一旦处理，资金转移即具有即时、最终和不可撤销的性质。美联储
RTGS最重要的价值，是让结算最终性更早到来。收款银行不必长时间等着付款银行以后再履约，也不会在一个长结算周期里不断积累对付款银行的未结算信用敞口。
代价是：付款银行必须在付款发生的那一刻就有可用流动性。
能够支持RTGS的资金必须是流动性最高的存放于央行账户的资金，即使银行账面上有100亿元资产，不代表它能立即用于RTGS结算，因为贷款、债券和其他资产不能不经处理就直接拿来完成支付。因此，在RTGS系统中，银行需要做好一系列的管理：
- 实时监测央行账户中的可用余额；
- 提前预估当天可能收到的付款；
- 让客户提前报告即将发出的大额付款；
- 管理可以动用的合格抵押品；
- 确保可以得到央行或市场提供的日间融资；
- 及时处理进入系统但尚未结算的队列。
所以，RTGS结算并不等于“所有支付永远不排队”。如果付款机构暂时缺少可用流动性，支付指令可能进入排队队列，此时需要等资金流入、等融资，或者进入系统的流动性优化程序。
RTGS也不是“没有风险”。它可以降低的是因最终结算尚未完成而产生的机构间信用风险，但流动性风险、操作风险、网络故障和参与者自身的风控问题仍然存在。
四、DNS为什么省流动性？
DNS允许支付先处理，在一个或多个结算周期里累计应收应付，最后只结算净额。
好处很直接：如果A银行和B银行之间存在大量双向支付，只转移最终净额，能明显减少结算资金需求。
问题同样直接。
假设从上午第一笔支付开始，A银行不断向外付款，在系统中形成越来越大的净借记头寸。收款银行可能已经给客户提供了可用资金，但银行之间的最终结算还没有发生。如果A银行在结算前突然无法履约，谁来填这个缺口？
所以，成熟的DNS不会让参与者无限积累净借记头寸。常见的控制手段包括：
| 风险控制工具 | 主要作用 |
|---|---|
| 净借记限额 | 限制参与者在尚未最终付款前最多能够累计多少净欠款 |
| 预融资 | 要求参与者事先在专门账户中准备资金，为最大净债务提供覆盖 |
| 圈存资金 | 将一部分可用资金锁定，避免被重复使用 |
| 抵押品 | 在特定安排下为融资或违约处置提供保障 |
| 保证或损失分摊安排 | 预先约定参与者违约后的资金来源和损失承担方式 |
| 提高结算频率 | 缩短支付处理与最终结算之间的风险窗口 |
净借记限额并不必然意味着参与者要提前存入同等金额的现金，它是一项风险控制额度，究竟由现金、抵押品、保证安排还是其他资源支持，要看具体系统规则。
人民银行公开发布的《小额支付系统业务处理办法》把这一逻辑讲得很清楚：通过净借记限额检查的业务可以纳入实时轧差；未通过检查的部分业务会排队，实时类业务则可能被拒绝。系统还会在规定场次把轧差净额提交资金清算，并对多个参与者之间的排队支付进行多边撮合。中国人民银行《小额支付系统业务处理办法》
也就是说，DNS不是“先欠着，最后再说”，它是有边界的：
英国的做法提供了另一个直观的例子。英国央行的RTGS不仅处理CHAPS的逐笔实时结算，也承接Bacs、Faster Payments等零售系统的净额结算。Bacs通常每日结算一次，Faster Payments在每个工作日进行三次净额结算。采用预融资的系统要求参与者在RTGS专门账户中持有与额度相匹配的资金，以覆盖可能形成的最大净债务。英格兰银行
五、中国的支付系统结算模式的实践。
把RTGS和DNS放到中国支付基础设施里看，往往需要从一笔零售支付开始。
一笔零售支付可能经过以下链条：
这些环节看起来一气呵成，但往往分散在多个系统中各自处理。
1. 大额支付系统HVPS
HVPS主要采用RTGS结算模型，主要服务大额、紧急和银行间资金转移，逐笔实时处理并完成资金清算，是我国银行间资金结算的核心基础设施之一。
2. 小额支付系统BEPS
BEPS面向批量和零售支付业务。符合条件的业务经过净借记限额检查后纳入轧差，再按规定场次把净额提交资金清算。
所以，不能简单地认为“BEPS只传消息、不结算”，而是：
BEPS在自身规则下完成支付处理、限额检查和轧差，机构间净额最终在央行清算账户体系中完成资金结算。
3. 网上支付跨行清算系统IBPS
IBPS通常被称为“超级网银”。它支持跨行资金汇划和实时反馈，但客户拿到实时处理结果，并不等于每笔银行间的准备金都在同一时刻逐笔结算。
人民银行清算总中心提到，IBPS在2016年把业务处理模式从“实时转发、实时轧差”调整为“实时转发、定时轧差”，以缓解大业务量参与者可能遇到的热点账户问题。银清科技IBPS介绍
这个调整也从另一方面说明：“前端实时”和“后台逐笔实时最终结算”不能画等号。
4. 银联与网联
银联、网联承担交易转接、清分清算等功能，但它们并不负责参与者间的最终结算。
可以通过人民银行大额支付系统制度修改中得知，银行卡跨行支付净额、支付机构网络支付净额业务由直接参与者发起即时转账业务完成资金结算。这为理解清算机构与大额支付系统、央行账户最终结算层之间的关系提供了明确的制度依据。中国人民银行相关制度修改公告
对非银行支付机构的网络支付业务，还要理解客户备付金与银行准备金的区别。
备付金是支付机构为客户办理支付业务而实际收到的预收待付资金，不是支付机构为了自己履约而缴纳的普通保证金。现行监管要求支付机构通过规定的清算机构处理跨机构支付业务，并建立备付金信息核对、监督和风险监测机制。《非银行支付机构监督管理条例》
把这些关系压缩成“三层账本”，会更好理解：
| 层次 | 记录的核心内容 |
|---|---|
| 客户账户层 | 个人或企业在银行、支付机构看到的余额 |
| 清算层 | 参与机构之间谁应收、谁应付以及净额是多少 |
| 最终结算层 | 央行货币或制度指定结算资产的最终转移 |
所以，能够同时做到客户秒到账但银行间却尚未结算，说明客户体验与机构间最终结算，可能由不同层次、不同时间表和不同风险控制共同支撑。
六、全球支付系统都在解决同一道题：怎样既快，又少占流动性？
RTGS和DNS不是中国特有的选择。各经济体的支付基础设施都在处理结算最终性、流动性成本和风险控制之间的关系。
| 经济体 | 系统 | 主要定位 | 值得观察的机制 |
|---|---|---|---|
| 中国 | HVPS | 大额及银行间支付 | 实时全额结算 |
| 中国 | BEPS | 零售批量支付 | 限额检查、轧差和净额资金清算 |
| 中国 | IBPS | 实时跨行零售支付 | 实时转发、定时轧差 |
| 美国 | Fedwire Funds | 大额、时效性强的美元支付 | 逐笔RTGS，处理后最终且不可撤销 |
| 美国 | CHIPS | 大额美元支付 | 连续日间最终结算与流动性节约机制 |
| 欧元区 | T2 | 大额欧元支付 | 央行货币RTGS |
| 欧元区 | TIPS | 即时零售支付 | 7×24小时使用央行货币结算 |
| 英国 | CHAPS | 大额英镑支付 | 通过英国央行RTGS逐笔结算 |
| 英国 | Bacs、Faster Payments | 零售支付 | 延迟净额结算与预融资 |
| 香港 | HKD CHATS | 港元银行间支付 | RTGS、排队和流动性优化器 |
| 香港 | FPS | 即时零售支付 | 余额充足时即时RTGS结算 |
美联储把Fedwire定义为实时全额结算系统；欧元体系的T2承担RTGS，TIPS则可以7×24小时使用央行货币结算即时支付。这说明零售支付并不天然等于DNS。美联储、欧洲央行
另一方面，美国CHIPS持续匹配和抵销参与者之间的付款义务，在提供日间最终结算的同时减少资金需求。它通过独特的算法实现了能够RTGS和流动性节约的兼顾。The Clearing House
香港HKD CHATS同样采用RTGS，但加入了排队、日间回购和流动性优化器。优化器会定期寻找排队付款之间可以多边抵销、同时完成结算的组合，以降低参与机构的日间资金压力。香港FPS则在付款参与者余额充足时即时按RTGS模式结算。香港金融管理局
从这些系统里，能看到四个共同趋势：
- 对系统重要性高、时效要求强的付款，市场更重视尽早取得最终性；
- DNS通过提高结算频率，不断缩短风险敞口存在的时间；
- 风险控制越来越前置，限额、预融资和抵押安排在付款放行前就开始发挥作用；
- RTGS也在通过排队、双边或多边抵销以及LSM，提高单位流动性能够支持的支付规模。
所以，现代支付系统的发展方向不是“DNS最终全部变成RTGS”，而是两类机制都在吸收对方的优点。
七、RTGS和DNS代表的是两套不同的制度回答
最后回到A银行和B银行。
如果A银行需要向B银行支付100亿元，B银行需要向A银行支付98亿元，单纯从减少结算资金占用的角度看，最终只结2亿元当然更划算。
但选择DNS之后，系统必须回答：
- A银行最多可以累计欠多少？
- 如果A银行在结算前无法履约怎么办？
- 收款银行为什么敢提前给客户入账？
- 最大净债务由什么资金或抵押品覆盖？
- 净额多久结算一次？
- 发生违约时，损失由谁承担？
反过来，如果所有付款都通过RTGS逐笔结算，系统又必须回答：
- 银行如何获得足够的日间流动性？
- 暂时缺少资金的付款如何排队？
- 收到的资金怎样更快循环使用？
- 哪些付款应该优先结算？
- 怎样避免参与者相互等待，形成流动性“死锁”？
所以，RTGS与DNS并不是“先进”和“落后”的区别，而是两套不同的制度选择：
现代支付系统正在形成第三种答案：
在保持更早最终结算的同时，通过排队、抵销、预融资、限额和流动性节约机制，把流动性需求降下来。
把这一点想通之后，下一个问题也就顺理成章地冒出来了：
RTGS既然是实时结算，为什么银行的支付还会排队？
本文首发于 Luminale 金融科技观察：https://luminale.cn/articles/rtgs-dns-settlement-tradeoff