易兑今日牌价
▼
RTGS：九点的账，九点就能结清
先按实时全额结算（Real-Time Gross Settlement，RTGS）走一遍。假设资金充足，九点那笔指令满足结算条件，系统从甲行结算账户划出完整的100万，记入乙行。到这一步，这笔银行间付款就最终结清了。乙行后来是否支付90万，不会改变第一笔已完成的结算。
“全额”指每笔指令按本身的金额结算，不是让两家银行一早就备齐190万。乙行收到的100万，可以接着用于自己的那笔90万付款。倒是甲行，如果九点只有10万可用，也没有可用信用，就不能指着十分钟后的来款要求系统把第一笔算作已付。依规则，指令可能排队或被退回。
DNS：等两笔都进来，再看谁欠谁
换成延时净额结算（Deferred Net Settlement，DNS）。假设这两笔都进入同一轮，甲行应付100万、应收90万，抵销后净付10万；乙行恰好净收10万。到了约定的结算时点，甲行划出10万，就能结清这一轮两行之间的债务。参与银行不止两家时，也可以按规则计算每家对全体的净头寸。
客户应收的100万和90万并没有打折。轧差只回答“本轮银行之间还差多少”，最终结算才回答“这笔差额付清了没有”。既然只划10万就够，为什么不全用DNS？
把钟拨回九点零五分。按上面的RTGS安排，乙行已经拿到100万，可以动用。按DNS安排，即便两家最后的净额能算得很准，在约定时点真正结清以前，乙行还不能把预期净收入当成已经收到的结算资金。这五分钟的差别，就是逐笔结算值得占用更多日间资金的理由。
再看另一头：假如结算时甲行连净欠的10万都拿不出，算对了差额也不能自动完成划款。系统是否动用担保、备用流动性或其他安排，要看具体规则。反过来，RTGS让已结算的付款更早确定，却可能让资金暂时不足的付款排队。两种机制并不是一个有风险、一个没风险。
判断一种支付系统，别只看“快不快”
先问按什么金额结：每笔指令的全额，还是一轮收付相抵后的净额？再问何时算结清：每笔满足条件便最终结算，还是要等约定的结算时点？前者是典型RTGS，后者是典型DNS。“手机马上收到提示”只描述客户看到的速度，不能独自回答这两个问题。
现代支付系统也会借用彼此的办法。例如逐笔结算系统可通过队列管理或流动性节约机制减少资金占用。判断它怎样运作，最终要看系统规则怎样规定资金划拨和结算最终性，而不是仅凭产品名称。
回到九点那道题：如果第一笔要在九点逐笔结清，甲行当时须有足以支付100万的流动性；如果两笔进入同一净额周期，本例到结算时净付10万。差的90万不是凭空省下来的——银行放弃了第一笔在九点就单独结清的确定性。
机制参考：CPSS–IOSCO《金融市场基础设施原则》，附件D（支付系统）；www.bis.org/cpmi/publ/d101a.pdf。本文为简化双边示例，不含费用，亦不预设特定系统的担保要求。
-END-