Delivery versus payment

雅娜不愿在收款前把 BTC 发给彼得，彼得也不愿在收到比特币前付款。DvP 通过结算规则处理这种不确定性；结算就是实际履行双方的义务。国际《金融市场基础设施原则》PFMI 要求，一方义务的最终结算必须以另一方义务的最终结算为条件。这里的最终性，是系统规则和法律框架所界定的转移状态，仅仅接受指令并不够。解决办法不是简单地要求两人更加信任对方。 [1]

在我们自拟的例子中，雅娜和彼得约定用 60,000 USD 购买 1 BTC；这不是当前报价。彼得没有备好款项。正常运作的 DvP 此时应阻止雅娜不可撤销地交出比特币，却没有收到钱。交易可以保持未结算状态，而不让卖方损失已经交出的资产。如果缺少比特币，买方也应得到同样的保护。这防范的是交换过程中交出的本金得不到对应回报，并不承诺每一笔约定都能成交。 [1]

交易较多时，每项义务不一定都要产生一笔单独的资金划转。全额结算逐项处理义务，净额结算处理相互抵销后的余额。BIS 区分三种模式：模式 1 对资产和款项都逐笔结算；模式 2 逐笔交付资产，在周期结束时结算净付款义务；模式 3 对两边都进行净额结算。在中间那种模式中，运营方的付款担保维持两者的联系。因此，提前交付资产并不是毫无保护地等待买方付款。不过，模式名称本身不能代替对规则和担保的审查。 [2]

彼得的资金可能已经为交易冻结，但雅娜还没有收到。预留只是暂时限制资金的使用，本身还不是最终划转。DvP 可以依靠系统间协调，也可以在结算周期内运作。PFMI 把保护的关键放在最终履行之间的联系上，并不要求按下按钮的一刻就完成所有步骤。因此，评估具体服务时，还要看资金预留多久、在什么条件下解除。 [1] [2]

两个相互联系的记录系统，不必运行在同一个应用中。BIS 与 Bank of England 在 2023 年的 Project Meridian 中研究了这一点。原型把房地产登记簿与 RTGS 连接起来，后者是使用央行货币持续逐笔结算支付的系统。同步运营方协调房产所有权的变更和资金划转，让两者互为条件。这是一个有记录的原型和具体的基础设施实验，并不能证明任何冠以 DvP 名称的服务都会自动提供同样的保护。 [3]

雅娜与彼得同时点击发送，并不意味着已经实现 DvP。BTC 遵循比特币网络的规则转移，普通货币则遵循银行系统的规则。比特币交易确认说明的是它在链中的位置。更多确认会增强抵御这段历史被改写的保护，却不能确认银行付款。一项声称在 BTC 与普通货币之间提供 DvP 的服务，必须说明两边实际履行如何关联，以及各自最终性的条件。银行指令截图或比特币交易标识符，都不能自动建立这种联系。 [1] [4]

如果交易没有完成，雅娜可能保住了比特币，却没有钱支付自己到期的账款。她也可能不得不另找买家，接受更低的价格。DvP 针对的是交出本金却收不到对价的风险；替代交易的成本和流动性短缺并不会消失。运营是否可靠、法律规则如何，以及等待期间谁保管资金，仍然重要。因此，保护交换过程不等于保证价格有利、服务一直可用，或中介永不出问题。 [1] [2]

评估具体服务时，先弄清谁控制比特币和钱款，什么条件触发转移，以及按适用规则从何时起不能单方面撤销。然后考察缺少款项或资产的情况：什么会继续冻结，谁作决定，何时才能重新使用资金？有意义的 DvP 验证，应覆盖步骤之间发生故障及恢复运行的过程，而不只是一次成功演示。这正是有依据的机制与屏幕上安慰性提示的区别。 [1] [3]