デジタル証券
配達対支払い: 原子決済の仕組み
Delivery versus payment が取引の資産レッグと現金レッグをどのように連携させ、原子決済が何を除去し、どのような流動性、法的、運用上のリスクが残るか。
Securities.io を Google の優先ソースに追加
取引には二つの約束があります: 資産の引き渡しと資金の支払いです。これらのレッグが別々に決済されると、一方の当事者は履行できてももう一方は失敗する可能性があります。Delivery versus payment はそれらを結びつけ、取引が同時に完了するか、全く完了しないかのいずれかにします。
これは純粋にスマートコントラクトの問題のように聞こえますが、法的最終性、保管、流動性、そして決済資産の品質も依然として重要です。当社のスマートコントラクトに関する入門記事ではコード層を解説しています。
Delivery versus payment（DvP）は、有価証券の移転と支払いの移転を結びつけ、一方のレッグが完了したときにのみもう一方も完了します。プログラマブル台帳上では、両方の状態変化を単一の原子取引で実行するか、同等の最終性を持つ調整システムを通じて実行できます。これにより、原本リスク――一方が価値を提供し、対価を受け取れない可能性――が大幅に減少します。
原子性がすべてのリスクを消すわけではありません。資産と決済資金は法的に有効な権利を表す必要があり、当事者は必要な時点で流動性を保有しなければなりません。取引は実行前に失敗することもあり、ガバナンスは障害やエラーに対処しなければなりません。即時総決済は、まず多くの義務をネット化する場合に比べて、相手方エクスポージャーを減らす一方で、日中の資金需要を増加させます。
配達対支払いの全体像
Delivery Versus Payment のシーケンスは、ソフトウェア手順の列ではなく証拠のチェーンとして読むべきです。各段階は、次の参加者が欠落した事実を捏造することなく検証できる記録を残す必要があります。
Delivery Versus Payment の責任は誰にあるか？
| 買い手と売り手 | 有効な指示、適格な資産、十分な決済流動性を提供する。 |
|---|---|
| 取引所またはマッチングシステム | 一貫した決済データを持つ合意取引を作成する。 |
| 証券台帳 | 引渡し可能な資産とその所有権制限を維持する。 |
| 現金または決済資金台帳 | 支払い資産を提供し、資金移転が最終的になる時点を定義する。 |
| 決済コーディネーター | 両レッグにわたる条件、タイムアウト、障害処理、証拠を接続する。 |
レビューは最終性を記録から開始し、逆方向に進めます。最終的な保有者または機関は、自身のポジションを両方のレッグをロックの決定に、そして取引に合意で受け入れられた証拠に結び付けられるべきです。もしそのチェーンがダッシュボードや取引ハッシュで止まっている場合、システムはソフトウェアが実行されたことを証明しただけで、約束された権利、支払い、またはレジストリの変更が法的に執行可能であることを示すわけではありません。
参加者マップは第二の境界を示します。買い手と売り手、決済コーディネーターは同一製品内で動作することがありますが、異なる記録を保持し、異なる義務を負います。運用タスクを外部委託しても、顧客の約束や誤りを修正する義務が自動的に移転するわけではありません。信頼できる設計は、障害が発生する前にフォールバック所有者を指定し、障害後に指定しません。
現実的なストレステストでは、資産の無効性と流動性の行き詰まりを組み合わせます。参加者に正しい状態を凍結させ、正当な保有者権利を保持し、シーケンスを再構築して一つの調整済み結果に到達させることを要求します。この演習は、Delivery Versus Payment が統治された回復パスを持つか、単に効率的なハッピーパスに過ぎないかを明らかにします。
Delivery Versus Payment に関する商業的主張も、測定可能なビフォーアフター比較に変換すべきです。設計が変更しようとする手作業のハンドオフ、調整遅延、資本コスト、流動性バッファ、または分配障壁を特定します。その上で、証券台帳、レジストリ、決済資産、回復プロセスがもたらす新たな依存関係をすべて数えます。例外が遅くなったり集中したりすれば、転送が速くてもライフサイクルコストが必ずしも低くなるわけではありません。
最後に、実例の一つの事実を変更します: 原子的に決済を遅らせる、取引所またはマッチングシステムを利用できなくする、または現金・決済資金台帳が保持する記録に異議を唱える。堅牢な製品は、文書と権威ある記録に基づいた予測可能な回答を提供すべきです。結果が未文書化の電話に依存する場合、Delivery Versus Payment は可視的なプロセスをデジタル化したものの、決定的なコントロールをシステム外に残すことになります。
Delivery Versus Payment が設計通りに機能したときに誰が利益を得るか、そして最終性の衝突が発生したときに誰がコストを負うかを問うべきです。収益はインターフェースやプラットフォームに集まる一方で、流動性、サービス、法的リスクは別の機関に残ります。手数料と損失配分の両方を追跡することで、魅力的な運用図が製品の信用を支えるバランスシートを持つ当事者を隠すことを防げます。
Delivery Versus Payment の記録が合意すべき場所
顧客向けの Delivery Versus Payment の残高、トークン台帳、法的レジスター、保管口座、現金記録は異なるタイミングで更新されることがあります。製品は、どの記録が支配し、他のすべての記録がそれにどのように調整されるかをルールで説明できる場合にのみ信頼できるものです。
Delivery Versus Payment の仕組み
1. Delivery Versus Payment における取引合意
取引はまず一致した義務を生成します。当事者は商品、金額、価格、決済口座に合意します。この段階でのエラーは資産がロックされる前に解決すべきです。さもなければ、プログラマブル決済は内部的に有効な誤った指示を非常に効率的に実行してしまう可能性があります。
2. Delivery Versus Payment における資産検証
システムは、売り手が引渡し可能な証券を保有し、買い手が受け入れ可能な支払いを保有していることを確認します。また、適格性、制裁、転送制限、口座状態も検証します。法的文書が凍結されている、または支払いトークンが額面で償還できない場合、トークン残高だけでは不十分です。
3. Delivery Versus Payment における両レッグのロック
両レッグが予約されます。単一台帳上では原子スマートコントラクトを使用でき、複数台帳間ではロック、条件付き転送、信頼できるコーディネーター、または同期ウィンドウを使用することがあります。設計は、いずれかの当事者が予約された資産を他で使用できないようにし、相手方が消失した際に無期限ロックになることを防がなければなりません。
4. Delivery Versus Payment における原子的決済
決済は両方の所有権記録を変更します。すべての条件が満たされれば、証券は買い手に、資金は売り手に、一つの不可分なシーケンスで移転します。条件が失敗するか時間が切れると、どちらの転送も最終的ではなく、予約された資産は既知のルールに従って解放されます。
5. Delivery Versus Payment における最終性の記録
その後、システムは最終性を記録し、ポジションを調整します。即時利用可能になることで、買い手は証券を担保として再利用でき、売り手は現金を再利用できますが、カストディアン、リスクシステム、法的枠組みが同じ最終状態を認識している場合に限ります。そうでなければ、迅速な台帳は下流システムが調整しなければならない別の記録を生成します。
Delivery Versus Payment の経済学
DvP は元本リスク、担保バッファ、調整を削減できますが、決済設計は流動性需要を変化させます。総原子決済は各取引が実行時に資金提供されることを要求します。ネット決済は義務を相殺することで資金需要を減らしますが、ネットサイクルが完了するまでエクスポージャーが残ります。市場は、最短の決済が常に最も安価であると仮定せず、適切なバランスを選択しなければなりません。
決済資産は経済的に重要です。中央銀行マネーは信用リスクを最小化しますが、すべてのプラットフォームで利用できるわけではありません。トークン化された預金は銀行リスクとネットワーク規則を伴い、ステーブルコインは発行者、準備金、償還リスクを加えます。分散した形態の資金をブリッジまたは事前に資金提供するコストは、証券レッグで得られる効率性の一部を相殺する可能性があります。
Delivery Versus Payment の失敗モード
- 資産の無効性: 引き渡されたトークンが執行可能な証券権利を移転しない。
- 資金リスク: 支払い資産が額面価値を失う、または償還できない。
- 流動性の行き詰まり: 当事者は資産を保有しているが、必要な正確な時間と場所で利用できない。
- クロス台帳失敗: 資産システムと現金システム間でロックやメッセージが食い違う。
- 最終性の衝突: 技術的な完了が法的または下流の記録で認識されない。
実例で見る Delivery Versus Payment
ディーラーはトークン化された債券を 500 万ドルで、トークン化された商業銀行マネーを使用して購入します。決済契約は両方の承認済み口座を検証し、債券と 500 万ドルをロックした上で、単一の原子操作で転送します。この取引では元本リスクが除去されます。しかし、ディーラーはその時点で正しいプラットフォーム上に 500 万ドルを保有している必要があり、両当事者は債券記録の法的有効性と銀行マネーの信用品質に依然として曝露しています。
Delivery Versus Payment の裏付け証拠
BIS の2026 年年次経済報告書はトークン化された貨幣・金融システムを検討し、IOSCO のトークン化レポートは決済、相互運用性、法的確実性を実務上の制約として指摘しています。これらは、原子的実行が安全な DvP 設計の一層に過ぎない理由を示しています。
Delivery Versus Payment で何が変わっているか？
中央銀行と市場インフラは、サンドボックス実証から実際の価値を伴う DvP パイロットへと進んでいます。焦点は相互運用可能な決済資金、法的最終性、流動性管理へとシフトしています。BIS の 2025 年および 2026 年の取り組みは、トークン化された中央銀行準備金、商業銀行マネー、証券を、脆弱なブリッジで接続された孤立したチェーンではなく、統合されたプログラマブルシステムの構成要素として位置付けています。
Delivery Versus Payment に関して問うべき質問
- どの記録が取引に合意を証明し、資産、数量、価格、相手方、口座、意図された決済時間を照合したときにそれを修正できるのは誰か。
- どの記録が資産を検証を証明し、売り手が適格な証券を保有し、買い手が受け入れ可能な資金を保有していることを確認したときにそれを修正できるのは誰か。
- どの記録が両方のレッグをロックを証明し、資産と支払いを予約または条件付けし、どちらも他で使用できないようにしたときにそれを修正できるのは誰か。
- どの記録が原子的に決済を証明し、条件が失敗したときに両方の請求を同時に転送するか、どちらも解放しないようにしたときにそれを修正できるのは誰か。
- どの記録が最終性を記録を証明し、権威ある記録を更新し、完了したポジションを再利用可能にしたときにそれを修正できるのは誰か。
Delivery Versus Payment の後に読むべきもの
証券レッグについてはセキュリティトークン取引の仕組みを参照し、次にPaxosの解説で決済資産を比較してください。より広範な支払いシーケンスは自律型エージェントによる決済とトークン化された決済に掲載されています。
Delivery Versus Payment の要点
DvP は資産の引き渡しと支払い受領の間のギャップを解消しますが、資金需要、取引失敗、身元管理、保管リスク、または両レッグが法的に最終であるという要件は除去しません。
Delivery Versus Payment の情報源
