Delivery versus payment

ヤナは代金を受け取る前にペトルへ BTC を送りたくありません。ペトルもビットコインを受け取る前には払いたくありません。DvP は、双方の義務を実際に果たす「決済」のルールによって、この不確実性に対処します。国際的な金融市場インフラのための原則である PFMI は、一方の最終決済が他方の最終決済を条件とすることを求めています。ここでの最終性は、システムの規則と法的枠組みによって定まる移転の状態です。指図を受け付けただけでは足りません。単に互いをもっと信用するよう求める話ではないのです。 [1]

独自の例として、ヤナとペトルが 1 BTC を 60,000 USD で売買するとします。これは現在の価格提示ではありません。ペトルが資金を用意できなかった場合、適切な DvP は、ヤナがビットコインを取り消せない形で引き渡したまま未払いになることを防ぎます。取引が未決済のままでも、売り手が渡した資産を失わずに済むのです。ビットコインが用意されない場合には、買い手にも同じ保護が必要です。守るのは交換する元本であり、すべての合意の成立を保証するわけではありません。 [1]

多数の取引があると、義務ごとに別の送金を行う必要は必ずしもありません。グロス決済は義務を個別に扱い、ネット決済は相殺後の残高を扱います。BIS は、資産と資金をともに個別決済するモデル 1、資産を個別に引き渡して資金の純債務をサイクルの最後に決済するモデル 2、両側を相殺するモデル 3 を区別しています。中間のモデルでは、運営者の支払保証が両側の結び付きを保ちます。したがって、先に引き渡すことは、無保護で買い手を待つだけの状態ではありません。ただし、モデル名だけで規則や保証の評価を済ませることはできません。 [2]

ペトルの資金が取引のために拘束されていても、ヤナにはまだ届いていない場合があります。資金の予約はその利用を一時的に制限するもので、最終的な移転そのものではありません。DvP はシステム間の調整や、サイクル単位の決済でも実現できます。PFMI が重視するのは最終的な履行の結び付きであり、ボタンを押した瞬間にすべてを終えることではありません。具体的なサービスでは、資金が拘束される期間と解除条件も重要です。 [1] [2]

連携する二つの記録は、同じアプリケーション内にある必要はありません。BIS と Bank of England は、2023 年の Project Meridian でこの点を検証しました。試作システムは、不動産登記と RTGS を接続しました。RTGS は中央銀行マネーによる個々の支払いを継続的に決済する仕組みです。同期を担う運営者が、不動産の所有者変更と資金移転を互いに条件となるよう調整しました。これは記録された試作システムと特定のインフラ実験です。DvP と名乗るあらゆるサービスが、同じ保護を自動的に備えることを示すものではありません。 [3]

ヤナとペトルが同時に送信を押しただけでは DvP にはなりません。BTC は Bitcoin ネットワークの規則に従い、通常の通貨は銀行システムの規則に従って移転します。Bitcoin の取引確認が示すのは、その取引のチェーン内での位置です。確認が増えると履歴の変更に対する保護は強まりますが、銀行側の入金を確認することはできません。BTC と通常の通貨の DvP を提供するサービスは、両側の実際の履行がどう結び付き、どの条件で最終と扱われるかを説明する必要があります。銀行の送金指図の画像や Bitcoin の取引識別子だけで、その結び付きは生まれません。 [1] [4]

取引が成立しなければ、ヤナはビットコインを保持できても、自分が支払うべき期限に資金が足りないかもしれません。別の買い手を探し、より不利な価格を受け入れる必要も考えられます。DvP は元本を渡したのに対価を得られないリスクを扱いますが、代替取引の費用や流動性不足まではなくしません。運用の信頼性、法的規則、待機中に誰が資金を保管するかは引き続き重要です。交換の保護は、有利な価格、常時利用可能なサービス、仲介者の無事故を保証しません。 [1] [2]

具体的なサービスについて、誰がビットコインと資金を管理し、何が移転を開始させ、適用される規則上いつから一方的な取消しができなくなるかを確認します。そのうえで、支払いか資産が欠けた場合を検討します。何が拘束されたままになり、誰が判断し、いつ資金を再び使えるのでしょうか。有意義な DvP の検証には、成功例の実演だけでなく、手順の途中での障害と運用再開も含まれます。根拠のある仕組みと、画面上の安心させる文言との違いはそこに表れます。 [1] [3]