最終決済と決済尻の処理
ブロックチェーンによる最終決済と決済尻の処理
まず、基本形として、手形交換所や清算機関のような機構が必要なく、最終決済尻に対して、最小限の銀行送金で支払いが完了することを図示します。決済尻を送金せずに、再度、債務証書を発行して、期日付きの企業間債務・債権として、支払いを猶予することもシステム化できます
（応用形）当事者1社が臨時で決済親になる
中央の清算機関（決済親）が不要な一つの応用形として、決済日にネッティンググループの中の1社が臨時で決済親になるという仕組みです
この場合も、決済尻を銀行振り込みで終わらせてもいいし、再度、債務証書を発行して、期日付きの企業間債務・債権として、支払いを猶予することもできます
債務証書が流通した場合の決済上の問題
下図のように、C社が協力会社のC1, C2, C3社に債務があったとして、B社やD社から受け取った債務証書を、手形の流通のように、三つの協力会社への支払いに使うと、どうなるでしょうか
三つの協力会社がC社やB、D社に対して支払い債務が無い、一方向の債権債務関係の場合、ネッティングの必要がありません
右端の図のように、B、D社がCの三つの協力会社に対して直接払う必要があります
結果的には「指示払い」ですが、支払う会社にとって、変な感じがするでしょう。また、C社が三つの協力会社との商流を隠したい場合もあるでしょう
決済尻の送金に収納代行機能を使う
収納代行は、直接の債権者に対して支払わず、債権者が指定する第三者に対して「指示払い」することで、支払い債務が解消されるものです。当事者同士の契約で成り立ちます
収納代行サービスは、2020年の資金決済法改正で、資金移動業として規制する案がありましたが、一部のC2C（特に、受け取り側の債権者が一般消費者）のみ規制対象となり、企業間は問題なく、後述のエスクロー決済も規制対象外となっています 下図では、収納して支払うことの代行のため、「支払い代行」と名付けています
収納代行を使うか否か選択できる
収納代行サービスの手数料を払うのが嫌な場合は、決済尻の送金時に、債務者が収納代行を使用しない受領者を決めておくことができます。予めシステムのマスターファイルに登録し、受領者も確認しておきます
良く知れた顔ぶれのグループ企業や取引先同士であれば、収納代行を使用する必要はないでしょう
登録した先への決済尻の送金指図には、「支払い代行（収納代行）」は作動しません
登録されていない受領者へは、自動的に支払い代行サービスが適用される、という仕組みです
収納代行にエスクロー機能を兼ねる
前述で、債務証書が分割流通した際の最終受領者のマスキングのため、「仮親」に収納代行機能を持たせるシステムを紹介しました
決済尻の送金と決済完了の確実性を担保する必要もあり、「エスクロー機能」を伴うつくりとなります
エスクローとは
- もともとは、第三者が売り手、買い手の間に立ち、一定の条件が満たされた時に、商品と支払いを安全に交換させるという、第三者への預託の仕組みです
- 一般には、ネットオークションサイトなどでお馴染みですが、消費財に限らず、有価証券と銀行預金との交換、貿易における船積書類と支払いなど、Deliver versus Paymentを同期させたいところに、広い意味で、何らかのエスクローの仕組みが存在します
- 下図のように、決済尻の送金は、payment だけですが、毎月末などの時点決済であれば、最終の支払いと受領は事前に分かっており、これを予定し、決済が完了することを管理するという意味で、エスクロー機能です
ステーブルコインで完済する １
決済尻について、ブロックチェーンのステーブルコインで完済することを考えます
収納代行を使えますし、代行不要の登録をすれば直接支払います。ブロックチェーンでは、スマートコントラクトというシステムを利用してエスクロー機能を自動的なシステムとして作れますので、人為的な第三者への預託の必要が無く、システムが安全な完済を担保します 川上に分割流通した債務証書の受取者のマスキングもできます
1. ステーブルコインとは？ 次を参照、 https://bccc.global/activity/stablecoin/
一言でいうと、リアルの通貨にペッグした、ブロックチェーンによる支払手段であり、法定通貨との交換が保証され、発行者は国債などを裏付けとして流通させて、その意味で仮想通貨ではなく、支払手段、交換手段と言えます。法定通貨以外の価値とペッグしたり、プログラムで変動を抑えるステーブルコインも登場していますが、ここでは法定通貨型でお話しします
2. ブロックチェーンのエスクロー機能
2008年10月31日 Satoshi Nakamotoの最初の論文に、エスクロー機能の可能性が示されました
“routine escrow mechanisms could easily be implemented to protect buyers. ”
その後、ビットコインコアとも呼ばれる、Bitcoinの開発者たちとSatoshi Nakamotoの通信記録によれば、2010年夏から秋にかけて、機能設計が議論され、Satoshi Nakamotoが仕組みの提案をしています。次のURLはその議論の最後のほうの記録です https://bitcointalk.org/index.php?topic=750.0
3. ビットコインでは結局、エスクローはそのソースコードに組み込まれず、取引所システムや信託サービスのひとつの機能として、業者によって作られることはありますが、その後の世代、例えば、Ethereumでは、スマートコントラクトという機能を利用して、チェーンに組み込むことができます。次を参照、https://ethereum.org/developers/docs/smart-contracts/
もっとも、スマートコントラクトはプログラミング言語を持ち、色々機能を作れるほか、この機能とインターフェースをとって、ウォレット（電子財布）などを各業者が固有のサービスとして構築しますので、特色は分れます。既存のシステムについては各社を検索、ご参照ください
ステーブルコインで完済する ２
ステーブルコインの処理は、ブロックチェーン基盤上でスマートコントラクト言語などで「プログラマブル」であり、ブロックチェーン基盤の中に実装すると、安全に自動化できます。いずれの参加者も恣意的に変更できませんので、銀行や信託などの業法による監督も不要、ブロックチェーンの中で完結します
前述のように、「C社」が受け取り債務証書を協力会社3社に対して、「支払い」に使っていたとして、最終決済尻について、受領当事者３社のマスキングもできます
決済親なしネッティングへの一つの疑問 １
商社などの仲介者がサプライヤーから商品を仕入れて転売するとき、決済尻送金の時に、商社の差益がバイヤーにバレてしまうのでは、という疑問があります
たった一件の取引だけで、決済日を待つとき、その可能性はあります。下図の通りです
決済親なしネッティングへの一つの疑問 ２
しかし、現実的には下図のように、多数の契約、しかも期日の異なるものが並行し、その処理も債務証書が手形のように流通して分割して川上の支払に使われて、途中で金融サービスに引き受けてもらうこともあるので、原取引のマージンを想像することはほぼ不可能でしょう
