コラム
――資産とお金を「同時に動かす」仕組み
DvP・PvPは、一方を渡したのに、もう一方を受け取れないという事態を防ぐための仕組みです。
「同時に動かす」という表現は分かりやすいものの、二つの処理を同じタイミングで実行するだけでは、この目的を達成できません。
両方の受渡しを相互に条件付け、どの時点で取り消せなくなるかを定める必要があります。
オンチェーンでは、資産とマネーを同じ実行環境で扱い、この条件をプログラムに組み込むことが可能です。ただし、台帳上の処理が成功することと、法的な権利移転や最終決済が成立することは別の論点です。本稿では、この違いからオンチェーンの実装条件を読み解きます。
- DvPは資産と資金、PvPは異なる通貨の受渡しを相互に条件付ける仕組みです。
- 同時刻の送信、即時決済、アトミック決済は、同じ意味ではありません。
- 同一台帳で処理する場合でも、法的効力と決済マネーの性質を確認する必要があります。
- 別々の台帳を接続する場合は、処理を同期する方法や期限切れ時の対応も設計します。
- 元本リスクを減らしても、価格変動、資金不足、取引不成立、システム障害は残ります。
1. なぜ受渡しを結び付けるのか
例えば、売り手が買い手へ債券を渡し、その後に代金を受け取る取引を考えます。代金を受け取る前に買い手が破綻すれば、売り手は債券を失い、代金も回収できない可能性があります。先に代金を払う方式では、同様のリスクを買い手が負うことになります。これが元本リスクです。
DvP（Delivery versus Payment）は、証券などの引渡しと代金の支払を相互に条件とし、片側だけが実行されることを防ぐ仕組みです。外国為替では、円を渡したのにドルが支払われないというような、一方の通貨だけが支払われることを防ぐため、二つの通貨の支払を相互に条件とするPvP（Payment versus Payment）が用いられます。これらは、既存の金融市場でも使われてきた原則です。
出典：CPSS・IOSCO「金融市場インフラのための原則」（2012年4月）原則12「交換型決済システム」
2. 同時刻と条件付き成立は違う
2つのシステムへ同時に指図しても、一方が成功し、他方が失敗すれば片側だけの受渡しが残ります。画面上で同時に完了を表示しても、裏側で取消可能な処理と取消不能な処理が混在していれば、決済の安全性は別途確認が必要です。
アトミック決済とは、一連の処理をすべて成立させるか、すべて成立させないかのどちらかにする仕組みです。ただし、どこまでの処理が対象に含まれるかを確認する必要があります。トークンの移転が一括で処理されても、銀行口座の更新や外部の権利登録まで同時に確定するとは限りません。
例えば、円の支払が確定した後にドル側の処理が止まる構成は、通常時には数秒で完了していても、片側の元本リスクが残ります。一方、処理に時間がかかっても、両方の条件が満たされるまでどちらの受渡しも確定しない仕組みであれば、片側だけが成立するリスクを防げます。このように、処理の速さと安全性を別の軸で考えることが重要です。
3. DvPとPvPを業務から比較する
DvPとPvPは、受渡しの対象は異なりますが、片側だけの履行を防ぐという基本的な考え方は共通しています。いずれの場合も、取引条件の合意、資産・資金の確保、実行権限の確認、決済の確定といった手続きが必要です。取引が成立していることと、決済が完了していることも区別して考える必要があります。
下表では、それぞれの仕組みによって抑えられるリスクと、それだけでは対応できないリスクを整理しています。リスクに対しては、与信管理や流動性管理、契約、運用による対策が必要です。
■実務上の比較と確認事項
| 仕組み | 結び付ける対象 | 抑えられるリスクと残る論点 |
| DvP | 証券等の資産と代金 | 片側だけの受渡しを抑制。資産の法的効力とマネーの信用は別途確認 |
| PvP | 円とドルなどの両通貨 | 片側通貨だけの支払を抑制。為替変動・資金不足は残る |
| 条件付き支払 | 検収等の業務条件と支払 | 条件を満たした後に支払。外部情報の正確性と紛争対応が必要 |
4. 同一台帳で決済する場合
同一の実行環境に債券トークンと決済用トークンがある場合、スマートコントラクト（条件に基づき処理を実行するプログラム）が双方の残高と権限を確認し、両方の移転を一つの処理として実行する設計が考えられます。条件を満たさなければ、資産移転は成立しません。
ただし、同じチェーンを使っているだけでは十分ではありません。対象トークンの凍結機能、移転制限、管理者権限、処理失敗時の挙動が異なることがあります。事前の残高確認後に別取引が資金を使うこともあるため、予約や競合制御まで含めて設計します。
例えば、売り手の債券と買い手の代金をあらかじめ確保し、制裁確認などの条件が整った後に受渡しを実行します。期限までに条件が整わなければ確保を解除し、確保している間は同じ債券や代金を別の取引に使用できないようにします。
また、買い手が代金を払えることだけでなく、売り手がその資産を移転できることも確認します。担保に差し入れられた資産、保有資格の制限がある証券、移転先の登録が未了の資産では、残高が存在しても受渡しが認められない場合があります。このため、残高だけでなく、資産ごとの業務ルールも実行条件に含める必要があります。
5. 別台帳や既存決済とつなぐ場合
資産をDLT（分散台帳技術）上で管理し、資金決済は銀行口座や中央銀行の決済システムで行う構成も考えられます。重要なのは、どの記録を根拠に相手側の処理を進め、通信断絶時や遅延時に何を止めるかです。APIで接続しただけではDvPは成立しません。
ECBのPontesは、市場DLTとTARGET Servicesを接続する仕組みです。ECBは2026年9月21日の初期提供開始を公表し、台帳をまたいで取引を同期させつつ、資金側の決済はT2で確定する設計としています。資産とマネーをすべて同じ台帳へ移さなくても接続を設計できる例です。
異なる台帳を結ぶ方式では、ロックの解除条件、確定を通知する主体、期限の扱い、誤通知時の責任を確認します。技術方式の名称だけで判断せず、どのような状況で片側だけが確定する可能性があるのかを確認する必要があります。
期限切れも、単に時間を見て解放すればよいわけではありません。相手側で既に確定しているのに通知だけが遅れている場合、こちらの拘束を解いてしまうと整合性が崩れてしまいます。期限を過ぎた場合は、相手側の処理状況を確認できないまま、一方の拘束だけを解除しない手順が必要です。
6. 決済マネーと法的確定を確認する
代金に使うのが中央銀行マネー、銀行預金、ステーブルコインのどれかによって、受取人が取得する権利は変わります。DvPが成立しても、受け取った民間トークンの信用・償還リスクまで消えるわけではありません。
ファイナリティとは、決済が取り消せず、無条件に確定した状態を指します。システム上の処理が完了しただけで、法的にも決済が確定したとは限りません。どの時点で権利の移転が確定し、倒産時にもその効力が維持されるのかを確認する必要があります。BIS・IOSCOの金融市場インフラの原則も、法的基盤と決済の確定を重視しています。
出典：CPSS・IOSCO「金融市場インフラのための原則」（2012年4月）原則1「法的基盤」、原則8「決済のファイナリティ」、原則9「資金決済」
証券の場合は、台帳の記録がどのような権利を表し、誰が権利者となるのかを確認する必要があります。トークンを受け取っただけで、証券や担保権を法的に取得したとは限りません。
7. 決済の速さと資金効率は分けて考える
取引ごとに即時決済すれば、受渡しまでの時間を短縮できます。一方で、取引のたびに資産と資金を用意しなければならないため、差額だけを決済するネッティングや、日中の信用供与を利用する方式に比べて、必要な資金が増える場合があります。
DvP・PvPの決済方法には、取引ごとに決済する方式や、複数の取引をまとめて差額だけを決済する方式があります。即時・総額決済だけを唯一の正解とせず、対象取引の頻度、金額、資金調達の条件に応じて選ぶ必要があります。資金予約が長時間続けば、別の支払に使えない資金も増えます。
例えば、午前の支払と午後の受取を相殺していた参加者が、すべての取引を即時決済へ変えると、午前の支払資金を別途調達する必要が生じます。受渡しリスクの削減額だけでなく、追加で必要になる流動性や資金調達費用を含めて比較することが、事業としての判断につながります。
8. 条件付き支払との違いを理解する
「商品が届いたら代金を払う」という条件付き支払も、業務上は有用です。ただし、現物の到着や品質を確認する外部情報と、金融資産の確定的な受渡しは同じではありません。センサーや物流会社の通知が誤っていれば、コードが正しく動いても不適切な支払になります。
したがって、現物取引を扱う場合には、何をもって条件達成とするか、誰が証明するか、争いがあれば誰が停止・判断するかを定めます。DvPは資産と代金の受渡しを結び付ける仕組みであり、現物の引渡しや品質を保証するものではありません。
9. 実証で確認する項目を決める
検証では、まず対象資産と決済マネーを一種類ずつに絞ります。売買条件、資産の拘束、資金の拘束、実行、確定、解除を定義し、各段階で片側が停止した場合の結果を確認します。実証用の架空残高による成功と、実価値・法的効力を伴う検証も区別して考える必要があります。
評価指標は処理時間だけでなく、片側成立の有無、予約資金の量と時間、期限切れ件数、復旧時間、照合負荷です。BISのProject Agoráでは実価値取引の検証も行われていますが、現時点ではプロトタイプによる検証段階であり、商用サービスとして提供されているものではありません。
導入前には、「両方が成立した場合」「両方とも成立していない場合」「片側の結果を確認できない場合」に分け、参加者が参照すべき情報と、実行できる操作を整理します。正常な取引を何件実行できたかに加え、障害時に片側だけの確定を防げたかという点を確認すれば、実証の結果を契約・運用・システムの要件へ引き継げます。
10. 受渡しを成立させる条件を明確にする
金融トークナイゼーションでのDvP・PvPは、資産とマネーをつなぐ中核機能です。導入判断では、何と何を条件付け、どのリスクを減らし、どこで決済を確定させるのかを先に決めます。
そのうえで、利用する台帳や決済マネー、参加者の権限、異常時の対応を具体化することで、技術的なデモにとどまらず、実際の金融業務への適用を検討できるようになります。
金融トークナイゼーションの検討に向けて
対象となる業務と関係者を整理し、現在の処理との比較から、実証の範囲と商用化の条件を具体化することが第一歩です。
オンチェーン金融の構想・業務設計・システム連携については、TISIまでご相談ください。
