クロスボーダー支払いの同期-Project STELLA
June 2019
https://www.ecb.europa.eu/paym/intro/publications/pdf/ecb.miptopical190604.en.pdf
✅１．導入
近年の分散型台帳技術（DLT）の出現により、支払いと証券決済をサポートする金融市場インフラストラクチャ（FMI）の将来に関する議論が活発化しています。
プロジェクトステラは、2016年12月に開始された欧州中央銀行（ECB）と日本銀行（BOJ）による共同研究であり、DLTのFMIの機会と課題を探る実験的研究と概念的研究で進行中の議論に貢献することを目的としています。
現在のレポート（以下、ステラフェーズ3と呼びます）は、DLT（2017年9月）2と証券配達対支払い（DVP）を使用した高額支払いの処理に焦点を当てた前の2つのフェーズから得られた洞察に基づいています。
DLT環境（2018年3月）。ステラフェーズ3は、国境を越えた支払い、つまり通貨圏間の支払いのための革新的なソリューションを探求します。
国境を越えた支払いには、複数の管轄区域にわたるさまざまなエンティティが関係します。
国境を越えた支払いの需要は増加していますが、国内の支払いと比較すると、多くの場合、時間がかかり、費用がかかるという特徴があります。
特に、システム間で共通の通信またはメッセージング標準がないため、シームレスな相互運用性が妨げられることがよくあります。
国境を越えた支払いのこれらの現在の非効率性に対処するためのイニシアチブは存在しますが、支払い元帳間のトランザクションの安全性の側面は依然として課題です。
図1に示すように、国境を越えた転送が完了する前に当事者が失敗した場合、信用リスクが発生する可能性があります。
この簡略化された例では、エンティティAは、ユーロと円の両方の元帳にアクセスできるエンティティB（仲介銀行など）に100万ユーロを送金することにより、エンティティCに1億円を送金し、次に、代わりに1億円を送金する予定です。
エンティティAの。転送の最初のレグが完了した後（つまり、AからBへの100万ユーロの転送）、転送の2番目のレグが完了する前にエンティティBが失敗した場合、エンティティAは資金を失うリスクに直面します。
このリスクは、支払いが同期され、資金がロックされている場合に軽減できますが、今日の世界では、このような同期はめったに発生しません。
クロスボーダー資金移動に起因する信用リスクの簡易例
このような背景の下、ステラフェーズ3では、特に新しいテクノロジーを使用することで安全性の観点から、国境を越えた支払いを改善できる可能性があるかどうかを調査します。
具体的には、（i）中央銀行が運営する元帳や中央銀行が運営する即時グロス決済（RTGS）システムとの間で使用されている元帳支払いのプロトコルに基づいて、グローバルな相互運用性を分析します。
DLT元帳、（ii）DLT元帳間、および（iii）集中型元帳間。 これにより、国境を越えた資金移動のバックエンドの取り決めに焦点が当てられます（図2を参照）。
このレポートに示されている分析と実験結果は、中央銀行が運営する決済システムを含む既存の取り決めを置き換えたり補完したりすることを目的としていません。
さらに、法的および規制の側面はプロジェクトの範囲外です。 Project Stellaは、決済および金融市場インフラストラクチャサービスの分野でのDLTの使用の可能性に関する幅広い議論に貢献しています。
第2章では、潜在的なDLTの使用に関する既存の分析を考慮して、調査の主な結果を要約します。
第3章では、元帳間支払いのプロトコルの概念と、プロトコルの動作の詳細について概説します。第4章では、関連する支払い方法について説明し、個々の支払い方法に必要な元帳機能をリストします。
第5章では、日銀とECBのエンジニアがプロトコルを使用して行った実験をまとめています。第6章では、利用されているプロトコルに基づいて、特定の支払い方法の安全性と効率性の側面を評価します。第7章では、安全性と効率性以外の追加の考慮事項について説明します。
✅２．ステラフェーズ３の関連分析と主な結果
2.1．元帳の相互運用性に関する関連分析
いくつかの公的および民間部門のイニシアチブは、異なる元帳間の相互運用性を強化し、国境を越えた支払いの同期決済を可能にすることを目的とした革新的なソリューションを模索しています。
次のサブセクションでは、選択したイニシアチブの概要を示します。
2.1.1.中央銀行による調査
イングランド銀行は、RTGSサービスの更新に関する分析のコンテキストで、RTGS支払いと他のシステムでの支払いとの同期決済を含む、より広範な相互運用性を調査しました。 そのコンテキストでは、概念実証は、高価値の国境を越えた支払いシナリオの下で、2つの異なる元帳での支払いの同期決済で実施されました。
イングランド銀行はまた、元帳と通貨間の同時決済に適用できる同期サービスを提供する信頼できるサードパーティが関与する同期決済の潜在的なモデルを提示しました。
カナダ銀行とシンガポール金融管理局は、ハッシュタイムロック契約（HTLC12）を使用して、2つのDLTプラットフォーム間の相互運用性を調査しました。これは、プロジェクトステラの第2フェーズでも調査されました。
彼らは、DLTベースの国境を越えた高価値の転送をシミュレートしました。 異なるプラットフォーム上のRTGSシステム。
2.1.2.選択された民間セクターのイニシアチブ
World Wide Web Consortium（W3C）のコミュニティグループは、Interledger Protocol（ILP）をさらに開発しています。
これは、さまざまなタイプの元帳間で支払いを送信できるようにする一連のルールです。
ILPは、ホワイトペーパー「A Protocol for Interledger Payments」（Thomas and Schwartz、2015年）に記載されている最初の提案に基づいて構築されています。第3章では、ILPの基本的な概念について詳しく説明します。
Rippleは、参加エンティティのグローバルネットワーク（RippleNet）を介して金融機関を接続するxCurrentを開発しました。xCurrentはILPを中心に構築されており、参加エンティティ間の双方向通信と元帳間の支払いの調整を可能にします。
SWIFTは、コルレス銀行ネットワーク全体の国境を越えた支払いのスピード、セキュリティ、透明性を向上させるために、参加機関の新しい標準であるSWIFT gpi（グローバルペイメントイノベーション）を確立しました。 SWIFT gpiには、次の3つの主要な機能があります。
- （i）支払いステータスのリアルタイム監視を可能にするエンドツーエンドの支払い追跡データベース。
- （ii）最適な支払いルートを見つけることができるように、参加機関、通貨、締め切り時刻などの運用情報を提供するディレクトリ。
- （iii）参加機関に、ビジネス慣行を強化するために新しく作成された一連のルールへの他のメンバーの順守のグローバルなビューを提供する中央サービス。
2.2.ステラフェーズ３の共同分析の主な結果
Stellaフェーズ3は、特に安全性の観点から、国境を越えた支払いを改善するための革新的なソリューションを探求します（図3の定型化された支払いチェーンを参照）。
これは、プロジェクトステラの傘下で以前に実施された実験的および概念的な作業に基づいており、他の中央銀行および民間部門のエンティティの調査作業も考慮に入れています（セクション2.1を参照）。
プロジェクトステラの第2フェーズでは、HTLCを介した元帳間の決済の新しいアプローチを特定しました。これにより、決済の同期を通じて信用リスクを軽減できる可能性があります。
ステラフェーズ3は、この分析の範囲を拡大します。 これは、前述のホワイトペーパー「A Protocol for Interledger Payments」で紹介されたプロトコルを研究します。
このプロトコルは、さまざまなタイプの元帳間で支払いを同期する元帳にとらわれないプロトコルを提示しようとします。
また、元帳間支払いで使用できるさまざまな支払い方法の安全性と効率性への影響を評価します。
クロスボーダー決済を構成する様式化された支払いチェーン
これらの支払いは次のとおりです。
- 1.トラストラインは、支払人と元帳の外部の受取人との間の取り決めであり、受取人が事前定義された条件を満たす場合に支払人が支払いを行うことを約束します。 同時に、決済されていない支払いの合計は、支払人が元帳で決済せずに支払うことができる所定の最大額を超えてはなりません。
- 2. HTLCを使用した元帳保留/エスクロー（以下「元帳エスクロー」）により、受取人が事前定義された条件を満たす場合に元帳に記録され、元帳によって強制される条件付き転送が可能になります。
- 3.サードパーティのエスクローは、概念的には元帳のエスクローに似ていますが、条件付き転送を実施するために、元帳ではなく、支払人と受取人によって信頼されているサードパーティに依存しています。
- 4.単純な支払いチャネルは、元帳の共有一時アカウントでエスクローされた資金を使用する支払人と受取人の間の取り決めです。両当事者は、受取人が事前定義された条件を満たす場合、エスクローされた資金の特定の部分に対する権利を表す、署名された請求を元帳外で交換することを約束します。複数の二国間支払いの最終的な正味ポジションのみが実際に元帳で決済されます。
- 5. HTLCを使用した条件付き支払いチャネル（以下「条件付き支払いチャネル」）は、両当事者が署名された請求を元帳外で交換するという意味で単純な支払いチャネルに似ていますが、さらに、受取人は事前定義された条件を満たす。
これらの5つの可能な方法は、次のように要約できる独特の特性を示します（表1も参照）:
- ( i）個別の支払いが元帳で決済されるか、元帳外で記録されるか、
- （ii）資金がロックまたはエスクローされるかどうか 支払いの事前定義された条件が満たされたときに支払いが実施されるかどうか、および
- （iv）条件付き転送を実施し、署名された請求を処理する機能など、転送を実行するために特定の元帳機能が必要かどうか。
支払方法および元帳要件の概要
安全性に関して、ステラフェーズ3は、すべてが執行メカニズムを備えた元本エスクロー、第三者エスクロー、および条件付き支払いチャネルにより、取引プロセスにおける責任を完全に果たす各取引当事者が 送金される元本の損失を被るリスク。
流動性効率については、本報告書で検討している5つの支払い方法を、効率の高い順に、（1）トラストライン、（2）オンレジャーエスクローとサードパーティエスクロー、（3）シンプルで条件付きの支払いチャネルに分類できます。
Trustlineは、資金提供後の唯一の支払い方法であるため、他の支払い方法よりも優れているようです。
オンレジャーエスクローおよびサードパーティエスクロー（1回の支払いにのみ必要なお金をエスクローする）の流動性効率は、一般に、単純な支払いチャネルおよび条件付き支払いチャネル（すべての支払いに必要なお金をエスクローする）よりも優れています。 支払いチャネルで処理されます）。
結論として、技術的な観点から、今日の国境を越えた支払いの安全性は、支払いを同期し、支払いチェーンに沿って資金をロックする支払い方法を使用することによって潜在的に改善される可能性があります。
ただし、このような新しい方法の実装の可能性を検討する前に、法律およびコンプライアンスの問題、テクノロジーの成熟度、および費用便益分析についてさらに考察する必要があることに注意してください。
✅３．インターレジャー支払いプロトコル
この章では、送信者がさまざまなタイプの元帳間で支払いを行えるようにする、元帳に依存しないプロトコルである元帳間支払いのプロトコルの概念について説明します。 このプロトコルは、ホワイトペーパー「A Protocol for Interledger Payments」（Thomas and Schwartz、2015）および最近の開発で概説されているユニバーサルインターレジャー支払いの提案に基づいています。
現在、このプロトコル（Interledger Protocol、またはILP）に基づく仕様は、主にW3Cコミュニティグループによって開発されています。
ILPの最新バージョン（バージョン4、またはILPv4）は公開されています。この章では、一般的な概念と、それらを元帳間支払いシナリオに適用する方法について説明します。
プロトコルの構成要素は、参加者、元帳、および支払い方法です。
私たちの文脈では、元帳は、アカウント間の価値の移転とアカウントの残高を追跡するために使用されるシステムの総称です。
このレポート全体を通して、送金は常に元帳に記録されますが、支払いは決済が延期される可能性があるため、常に元帳に記録されるとは限りません。
参加者は、1つ以上の元帳にアカウントを持ち、元帳間の支払いに参加するエンティティです。
最後に、支払い方法は、支払いを行い、元帳の義務を決済するための特定の方法に関する参加者間の二国間協定です。
支払い方法の選択は、参加者の好みと元帳の機能によって異なります。
２つのエンティティ間の様式化された図
参加者は、Interledger Protocol内で、送信者、受信者、またはコネクタの3つの役割を引き受けることができます。
コネクタは、2つ以上の元帳にアカウントを持つエンティティであり、元帳間で支払いを中継する流動性プロバイダーとして機能し、元帳間の支払いを正常に実行するために重要な役割を果たします。
流動性プロバイダーは、ある元帳のアカウントからの入金を別の元帳のアカウントへの出金と交換することにより、元帳間の支払いを可能にします。
単一のコネクタが送信者と受信者の間で支払いをリンクできない場合、または効率的な方法でリンクできない場合、複数のコネクタを支払いチェーンに構成できます。
図5は、3つの元帳と2つのコネクタが機能する支払いシナリオの例を示しています。 流動性プロバイダーとして。
クロス元帳支払チェーンの例
支払いチェーンに沿ったすべての個別の支払いは、受取人（受信者またはコネクタ）による次の条件の充足に依存します：所定の時間（タイムアウト）の前に暗号化ハッシュ値のプリイメージを提示します。
ハッシュ値は支払い条件を定義するために使用され、対応するハッシュプリイメージはその条件の履行をマークします。同じ暗号化ハッシュ関数、値、およびプリイメージを単一のクロスレジャー支払いチェーンで使用する必要があります。
クロスレジャー支払いが開始される前に、ハッシュ関数を使用して任意のプリイメージからハッシュ値を導出することにより、プリイメージとその暗号化ハッシュ値がレシーバーによって生成されます。
次に、ハッシュ値は、外部の通信手段（電子メールなど）を使用して、支払い金額、支払い通貨、支払いタイムアウト、受信者情報など、他の支払い条件とともに送信者と共有する必要があります。
途中で翻訳を終了
コメント