A Proposal for a Decentralized Liquidity Savings Mechanism with Side Payments：サイドペイメントによる分散型流動性貯蓄メカニズムの提案
R3 June 11,2018
✅１．前置き
ほとんどの国では、中央銀行は、最小の支払い（現金）を物理的に決済するための媒体と、通常は銀行間の卸売りの支払いである最大の支払いを電子的に決済する手段を提供します。
後者の目的のために、中央銀行は通常、銀行が中央銀行のお金で支払いを決済できるシステムを運用しています。
歴史的に、銀行間決済は（一日の終わりに）ネッティングシステムを介して決済されていましたが、量と価値が増加するにつれて、中央銀行は繰延ネット決済システムに固有のリスクを懸念するようになり、ほとんどの中央銀行は即時グロス決済の実装を選択しました（ RTGS）システム。
RTGSを使用すると、支払いは個別に、即座に、そして営業時間中に最終的に処理されます。 これにより、参加者による流動性供給の必要性が高まるという犠牲を払って、決済リスクと支払いの潜在的な巻き戻しが排除されます。
RTGSシステムの流動性需要は膨大なものになる可能性があります。 米国の大口決済システムであるFedwireFundsは、1日平均約590,209回の支払いで、2016年の総額は3兆ドル近くになります。 2017年に3,340億ポンド。
欧州連合の大規模な支払いシステムであるTarget2の2016年の1日あたりの平均支払い額は342,008ユーロで、最大1.7兆ユーロに相当します。 年間GDPに相当します。
過去20年ほどにわたって、世界中の中央銀行は、これらのシステムの流動性需要を削減するために、高額決済システムに流動性貯蓄メカニズム（LSM）を実装してきました。
LSMは、流動性のリサイクルを促進するか、銀行が日中に正味債務を決済できるようにすることで機能します。 流動性のリサイクルは、銀行が入金を使用して出金を行うことができるという事実から生じます。
一般に、銀行がタイムリーに支払いを行うと、より多くの流動性がリサイクルされます。4タイムリーな支払い処理を奨励するポリシー（スループットガイドラインなど）または遅延者を罰するポリシー（ 時変料金）により、流動性が再利用される可能性が高くなり、システムの全体的な流動性ニーズが減少します。
ただし、最も効果的なLSMは、中央キューに送信された相殺支払いを照合し、正味債務をカバーするために必要な流動性のみを使用してこれらの支払いを決済することにより、流動性ニーズを節約するものです。
銀行Aが銀行Bに100の値で支払いを行う必要があり、銀行Bが銀行Aに80の値で支払いを行う必要があるとします。次に、これら2つの支払いが入力された場合、それらを決済するための流動性要件の金額 オフセットアルゴリズムを操作するキューに入れると、銀行Aから銀行Bへの正味の義務の値は20になります。
対照的に、LSMのない純粋なRTGSシステムでは、これら2つの支払いを決済するための流動性要件は100.5大きくなる可能性があります。 利益は、多国間ベースで3つ以上の銀行間の支払いを相殺することによって得ることができます。
相殺アルゴリズムの潜在的な流動性の節約は、正味債務が計算される頻度で減少しています。
最大の潜在的な流動性の節約は、支払い日全体のすべての支払いが1日の終わりに相殺された場合に発生します。実際、これは、Bacs、Check and Credit、英国のFPS、米国のACH、カナダのACSSなどのシステムで行われていることです。
ただし、ほとんどの卸売り支払いを1日中遅らせることはできません。銀行が顧客から受け取る一般的な支払い要求は、当日処理が必要ですが、銀行は、日中にいつ実行するかに関して、ある程度の柔軟性を備えていることがよくあります。
Ball etal。 （2011）は、支払いの4％が緊急であると見積もっています。つまり、すぐに処理する必要があります。そうしないと、顧客に重大な影響が生じます。
しかし、これは支払いの96％がやや柔軟であることを意味します。しかし、多くのエコノミストは、支払いを遅らせると顧客の不満が生じることを示唆しています。したがって、支払いを遅らせることによる流動性の節約と、ネッティングの機会を増やし、流動性を節約することと、遅延のコストとの間にはトレードオフがあります。
中央銀行によって実行されるネッティングアルゴリズムは、通常、所定の時間間隔でクリアされる集中キューを操作します。
オペレーターは、より長いネッティングサイクルから生じる相殺支払いを見つける可能性の増加と、より長い平均決済時間のコストとの間のトレードオフのバランスをとろうとします。これは、中央銀行が不完全な情報で解決しようとしなければならない難しい作業です。
中央銀行は、個々の銀行がRTGSシステムの外部でどのような支払い義務を負っているのか、またはそれらをキューに入れることを選択するのかを知りません。
さらに、集中型システムが支払いを完全に相殺することだけを考慮した場合、ネッティングの機会はかなり制限されます。代わりに、集中型システムによって実行されるアルゴリズムは、利用可能な流動性で決済できる不完全に相殺された支払いのセットを探します。
キューで利用可能な流動性は参加者の選択変数であり、これも中央のオペレーターがシステムを設計するときに見積もる必要があるかもしれません。
流動性と支払いがわかっている場合でも、最適なネッティングソリューションを解決する問題は非常に複雑になる可能性があります。
支払いファイルにn個の支払いがある場合、考慮すべきネッティングの組み合わせの数は2 n-1であり、nが大きい場合はNP困難になる可能性があります。
もう1つの問題は、集中型ネッティングアルゴリズムが、決済できる支払いの価値または量を最大化しようとすることですが、通常、支払いの重要性を重み付けしたり、銀行間や1日を通して変動する可能性のある流動性供給のコストを評価したりする方法がありません。
中央のオペレーターがシステムの社会福祉を最大化することを妨げる不完全な情報の問題があります。 最後に、集中型キューは、特定の管轄区域または銀行システム内で動作します。
システム間で支払いをネッティングすることはできますが、それはさらに別の集中型システム（CLSペイインなど）に流動性を提供することを含みます。
このホワイトペーパーでは、上記の問題に対処すると同時に、分散型台帳テクノロジーに関連する追加のメリットを追加する、集中型ネッティングキューの代替案について検討します。
このホワイトペーパーで説明するアプローチを、分散型の流動性節約メカニズムと呼びます。
分散型アプローチにより、個々の参加者は、現在の状況をリアルタイムで反映するネッティング提案を行うことができます。 これにより、市場の状況を反映し、参加者の福祉を向上させる競争力のある提案が可能になります。
分散型台帳システムは複数の管轄区域にまたがる可能性が高く、これらのシステムの参加者は、複数のオペレーターに流動性を前払いすることなく、管轄区域内および管轄区域間で流動性節約の機会を提案できます。
提案されたソリューションには2つの部分があります。
1つは、個々のノードがネッティングの機会を決定し、ネッティングの提案を行うために必要な情報を収集する方法です。 もう1つの部分は、正味債務を決済するために流動性をどのように提供するか、および分散システム全体で債務を実際に決済する方法に関する提案です。
流動性の提案は、各参加者にそれぞれのネットデビットポジションに等しい流動性を提供させるのと同じくらい簡単かもしれませんが、サイドペイメントの可能性もあります。
適切に選択された副次的支払いは、特定の条件下で交渉の結果を再現し、公平性、公平性、中立性の会計目標を達成する結果を促進します（Roth and Verrecchia1979）。
提案されたソリューションに関連する2つの重要な技術革新があります。
1つ目は、ネットワーク上の任意のノードが、潜在的に寄与する可能性のあるすべてのネッティングの機会を識別できるようにする再帰的なグラフスキャンアルゴリズムです。
2つ目は、元帳への複数の変更を1つのトランザクションにまとめて、全体として成功または失敗するアトミックトランザクションの使用です。
これらのイノベーションには、すべての分散型台帳プラットフォームに存在するとは限らない特定の機能が必要です。
R3と銀行および金融機関のコンソーシアムによって開発されたブロックチェーンに着想を得たオープンソースの分散型台帳プラットフォームであるCordaの現在のバージョンは、私たちの要件を満たしています。
Cordaには、複数の支払いを含むアトミックトランザクションを作成する機能があります。これは、一度に決済するか、まったく決済しないかのいずれかです。
複数の当事者、義務、および解決の支払いを含む複雑なネッティング解決は、任意の参加者によって作成される可能性があり、セット全体が解決されるか、まったく解決されません。ネッティングサイクルを部分的に解決すると、システムが複雑な状態になって巻き戻されるため、この原子性は非常に重要です。
セクション2では、関連する文献を確認します。 セクション3では、集中型キューについて説明し、キュー内の義務を解決するためにオペレーターが使用するさまざまなアプローチの例を示します。
セクション4では、中央オペレーターが福祉を最大化する方法で中央キュー内の義務を解決する能力を制限する不完全および不完全な情報の問題について説明します。
セクション5では、分散型多国間ネッティングへのアプローチを正式に紹介し、概念側の支払いの概念を紹介します。 セクション6は終わります。
✅２．関連文献と進行中のプロジェクト
価格設定されたクレジット（例：Fedwire）および担保付きクレジット（例：CHAPS）システムの福祉を強化するための流動性貯蓄メカニズムの可能性を探る理論論文がいくつかあります。
前者の例についてはMartinand McAndrews（2008）を、後者の例についてはJurgilas and Martin（2013）を参照してください。これらの論文は特殊なモデルを使用し、一般的な洞察を提供します。
結論は非常に簡単です。担保付きクレジットの世界では、LSMがない場合の唯一の均衡は「悪い」（すべての参加者が支払い処理を遅らせる）であり、LSMは常に役立ちます。
価格のあるクレジットの世界では、「良い」（参加者が支払い処理を遅らせることはありません）とLSMがなければ「悪い」均衡になり、LSMが事態を悪化させる可能性があります。
実際には、LSMの福祉上のメリットは、流動性の提供コスト、遅延コスト、個別の銀行支払いなど、いくつかの要因に依存する可能性があります。
特性（サイズ、到着時間、時間の重要性）、共同支払いの特性、および行動要因（たとえば、どの支払いがキューに入れられるか）、およびこれらのモデルでは、これらのことを完全に説明することはできません。
より適切なのは、おそらく、実際のLSMのパフォーマンスをテストする論文です。
Norman（2010）は、キューの特定のアプリケーションの利点を調べる研究の概要を提供しています。 Norman（2010）は、韓国銀行のBOK-Wire +決済システムで20％、日本のBOJ-Netシステムで15％の節約を報告しています。
最近では、Davey and Grays（2014）とDavid Seaward（2016）のフォローアップにより、2013年4月にCHAPSに導入されたLSMによる流動性の節約が見積もられています。初期の節約は約20％でしたが、この数値はほぼゼロになりました。 近年、銀行は量的緩和政策により流動性に溢れています。
Atalay etal。 （2010）LSMをFedwireに追加することの仮想的な利点を定量化します。 彼らは、LSMが福祉を低下させる可能性があることを発見しましたが、現実的なシナリオでは、潜在的な利益は1日あたり500,000米ドルを超えています。
同様のアプローチを使用して、Diehl and Schollmeyer（2011）は、TARGET2でLSMの福利厚生の評価を実施します。 彼らは、手数料ベースと担保ベースの両方の流動性供給を評価し、福祉効果が1日あたり17万から30万ユーロのオーダーに達する可能性があることを示しています。
2016年、一部の中央銀行は、ホールセール決済プラットフォームに基づく分散型台帳テクノロジーの概念実証にLSMを追加する可能性の実験を開始しました。
彼らの調査結果を最初に報告したのは、カナダ銀行のJasper Project（Chapman etal。2017、Project Jasper White Paper 2017）でした。 このグループは、定期的な多国間支払いネッティングを備えた集中型キューの形式で集中型LSMを実装しました。
ジャスパーフェーズ2設計に組み込まれた集中型キューは、流動性の節約の可能性と引き換えに、送信者が決済前の遅延を受け入れる意思のある支払いに使用することを目的としています。
ユーザーは、アトミック決済を選択するのではなく、支払い義務をキューに送信します。
キューは、「マッチングサイクル」と呼ばれる、短期間にユーザーから送信されたすべての支払い義務を収集します（公証人ノードによって構成されます）。マッチングサイクルの最後に、多国間ネッティングアルゴリズムが実行されます。 流動性の制約を受ける可能性があるため、キュー。
マッチングアルゴリズムを実行するには、正味債務を決済するために利用できる流動性の量を正確に知る必要があります。
これを行う1つの方法は、アルゴリズムの実行中にシステム全体をフリーズすることです。
ただし、ジャスパーフェーズ2アーキテクトはより良いアイデアを持っていました。 システム全体を凍結する代わりに、参加者はアルゴリズムが実行される直前に公証人に支払いを行います。
これは吸入段階と呼ばれます。 これらの資金が公証人の管理下にある場合、アルゴリズムが実行され、必要に応じてこの流動性が利用され、アルゴリズムが終了すると、未使用の流動性と追加のネットクレジットがマッチングソリューションから参加者に返されます。
これは呼気段階と呼ばれます。 吸入/呼気アーキテクチャにより、集中型キューが分散型システム内で動作できるようになりました。
ECBと日本銀行による合弁事業に関する最近の報告書（2017）は、ステラプロジェクトにおける二国間ネッティングの分散型アプローチについて説明しています。
LSMは、銀行が分散型台帳環境でLSMとの支払い転送を実行できるようにするスマートコントラクトを介して実装されます。
シンガポールでは、Project Ubinが、銀行間決済とグリッドロック解決の目的で導入されたLSMとの決済に分散型台帳テクノロジーを使用することを検討しています（シンガポール金融管理局2017）。
グリッドロックとは、支払いシステムの各参加者が利用できる流動性が未払いの支払い義務のいずれよりも少ないために、銀行が支払いを決済できない状況を指します。
グリッドロック解決への標準的なアプローチは、利用可能な流動性で決済できる正味金額を提供する一連のグリッドロック支払い内のネッティングサイクルを探すことです。
プロジェクトのフェーズ2は2017年10月に完了しました。
3つの主要なDLTプラットフォーム（Corda、Hyperledger Fabric、Quorum）で3つのソフトウェアプロトタイプが開発されました。 3つのワークストリーム設計は、異なる方法で異なる機能を活用します。
たとえば、資金移動機能とトランザクションのプライバシーは、未使用トランザクション出力（UTXO）モデルと機密IDを備えたCorda、チャネル設計を備えたHyperledger Fabric、およびConstellationとゼロ知識証明（ZKP）を使用したQuorumによって実現されます。
さらに、キューイングメカニズムとLSMは、さまざまなソリューション設計を通じて実装されます。
もともと集中キューでの二国間および多国間ネット決済をサポートするために開発されたEAF2アルゴリズム7は、HyperledgerFabricとQuorumの両方のプロトタイプでグリッドロックの解決に使用されました。
前者はグリッドロックの解決を2つの主要な段階（開始/参加と決済）に分割し、後者は4つのシステム状態（通常、整列、解決、および決済）のサイクルを使用します。
Hyperledger Fabricは、決済を容易にするために中央機関を表す特殊なMASノードに依存し、Quorumは、グリッドロックの解決をトリガーするためにシステム内のキューに入れられた支払いを追跡するためにグローバルグリッドロックキューに依存するため、これら2つのプラットフォームは完全には達成されていません。分散型の設計。
対照的に、Cordaワークストリームは、分散型グリッドロック解決の実装において最高度の分散化を達成しました。
分散環境でキューに入れられた支払いの発見を容易にするために、グラフベースのキュースキャンアプローチを提案しました。さらに、検出、計画、実行の3つの段階で構成される新しいサイクルベースのアルゴリズムを開発しました。
この革新的な設計の技術的な詳細については、セクション5で説明します。
ここで説明するメカニズムは、ProjectUbinフェーズ2レポートで説明されているCordaグリッドロック解決メカニズムを拡張したものです。
グリッドロックメカニズムは決済システムの緊急機能であり、流動性を節約しますが、この目的のために特別に呼び出されることはありません。
私たちが提案するメカニズムは、3つの重要な点でグリッドロック解決メカニズムとは異なります。まず、グリッドロックソリューションとしてのみメカニズムを呼び出すことはありません。
むしろ、銀行は、前述の遅延と流動性の節約の間のトレードオフを反映して、流動性を節約するために自発的に支払いをネッティングのキューに入れることが想定されています。
次に、Ubinレポートに記載されているグリッドロック解決メカニズムは、特定の事前に指定された基準に従って特定のネッティングサイクルを選択するようにプログラムされています（たとえば、Cordaアプローチでは、グリッドロックメカニズムは最大の義務合計をクリアするネッティングサイクルを実行します）。
対照的に、銀行はネッティングサイクルを提案することができます。
第三に、Ubinレポートで説明されているグリッドロックソリューションでは、銀行は選択されたマッチングサイクルの下で正味債務を支払います。
対照的に、銀行はサイドペイメントを提案できます。
✅３．一元化されたキューの設計
銀行間決済システムで使用されるキューイングの取り決めは、キューに提出された支払いを（部分的に）相殺し、正味債務をカバーするために必要な流動性のみを使用してこれらの支払いを決済することにより、流動性ニーズを節約します。
一元化されたキューイングメカニズムを設定するときに考慮しなければならない多くの設計上の問題があります。
これらの問題の1つは、キューをクリアする頻度の決定です。 潜在的な流動性貯蓄は、正味債務が計算される頻度で減少していますが、遅延は顧客の不満につながるためコストがかかります。
したがって、支払いを遅らせてネッティングの機会を増やすことによる流動性貯蓄と遅延のコストの間にはトレードオフがあります。
中央オペレーターが下さなければならないもう1つの重要な決定は、どの支払いを決済するかです。
キュー内の一連の支払いが与えられると、中央オペレーターは各銀行の正味の義務を計算できます。 負の正味借方ポジションにあるすべての銀行が負のポジションに等しい流動性を提供する場合、キュー全体を決済できます。
ただし、中央キューは通常、事前に資金が提供されており、銀行はキューのクリアに貢献できる金額を指定しており、これらの金額はすべての負の借方ポジションをカバーするのに十分ではない場合があります。
この状況が発生した場合、利用可能な流動性でネットベースで決済できるキューに入れられた支払いのサブセットを決定する必要があります。
最適なネッティングソリューションを解く問題は非常に複雑になる可能性があります。
支払いファイルにn個の支払いがある場合、考慮すべきネッティングの組み合わせの数は2 n − 1であり、nが大きい場合は非常に大きくなります。
より正式には、決定問題はNP完全であり、最適化問題はNP困難です。つまり、多項式時間で最適解を見つけることが保証されている既知のアルゴリズムはありません。
この問題は、組み合わせ最適化の一般的なクラスに属します。 問題。 オペレーションズリサーチにおける巡回セールスマン問題とナップサック問題、および組み合わせオークションにおける勝者決定問題は、組み合わせ最適化問題の他のよく知られた例です。
問題のサイズが大きくなるにつれて、最初に最適なソリューションを取得するのは計算上困難になります。
次善の解決策を得るために、銀行は流動性の制約が満たされるまで支払いを破棄するルーチンを利用します。
ここでは、複数の目的が機能している可能性があります。一方では、オペレーターの目標は、決済された支払いの価値、または場合によっては支払いの数を最大化することである可能性があります。
しかし同時に、キューに挿入した銀行の観点から、キュー内のすべての支払いが同じ優先順位を持っているわけではないことが認識されています。
現在運用されている決済システムの中央に配置されたキューイング施設（表1を参照）は、その単純さと公平さ、または効率を向上させるためのFIFOルールのバリエーションのため、主に先入れ先出し（FIFO）の原則を利用しています。
FIFOでは、流動性不足によりキュー内のすべての支払いが決済されない場合、最初に追加された支払いが最初に除外されます。これは必ずしも厳密に守られているわけではありません。
一部のシステムでは、銀行がキューに入れる支払いに優先度レベルを指定できます。10支払いは、各優先度レベル内でFIFOベースで決済するために解放されます。
優先順位を使用すると、銀行はFIFO処理の柔軟性を高めることができます。 FIFOの他のバリエーションには、単純なFIFOと並べ替えやバイパスなどの機能の組み合わせが含まれます。
FIFO-Reorderには、支払いをキューの最後に移動するか、優先コードを変更することが含まれます。 FIFOバイパスを使用すると、オペレーターは、資金不足のために決済できない場合に、支払いを再注文することなく、多額の支払いをバイパスできます。
さらに、一部のアルゴリズムは、オフセット効率を向上させるためにソートされたキュー方式を利用します。 これにより、オペレーターはFIFOを完全に放棄できます。
アルゴリズムは最初に、値に基づいて昇順または降順で支払いを並べ替えます。 次に、支払いを徐々に追加または削除して、銀行が当座貸越を被ることなく、銀行の指定された優先順位から逸脱することなく、同時に決済できる支払いの最大のサブセットを識別します。
オフセットアルゴリズムでより高い効率を達成するために、他のいくつかの形式の最適化も提案されています。
これらには、流動性の制約に従って可能な限り多くのキューに入れられた支払いを決済する取り決めを見つけるために、キューに入れられた着信支払いとキューに入れられた発信支払いのさまざまなサブセットの下で各参加者の正味残高をシミュレートする最適化ルーチンが含まれます。
柔軟で洗練されたキュー配置により、システムはより高いオフセット効率を実現できます。 最も一般的に使用されるFIFOおよびソートされたキューのオフセットアルゴリズムを以下に示します。
FIFOベースのアルゴリズム
- 1.保留中のすべてのキューに入れられた支払いをアクティブにし、各参加者のネットバランスポジションを計算します。
- 2.カバーされていないデビットポジションが最大の参加者を特定します（つまり、出金と入金の差が最大で、利用可能な流動性が最大です）。
- 3.残高がマイナスでなくなるまで、手順2で特定した参加者の最新の支払いを削除します。
- 4.すべての参加者の残高が負でなくなるまで、手順2と3を繰り返します。
- 5.利用可能な流動性を使用して、キューに残っているすべての支払いを決済します。
ソート済みキューアルゴリズム
- 1.保留中のキューに入れられたすべての支払いをアクティブにし、各参加者の正味残高ポジションを計算します。
- 2.カバーされていないデビットポジションが最大の参加者を特定します（つまり、出金と入金の差が最大で、利用可能な流動性が最大です）。
- 3.手順2で特定した参加者の支払いを金額に基づいて昇順（または降順）で並べ替え、残高がマイナスでなくなるまで、リストの最後から逆方向に進んで支払いを削除します。
- 4.すべての参加者の残高が負でなくなるまで、手順2と3を繰り返します。
- 5.利用可能な流動性を使用して、キューに残っているすべての支払いを決済します。
上記の基本的な形式のFIFOおよびソートされたキューのアルゴリズムは、キューに入れられた支払いの最適な決済を保証することはできません。
一部のシステムでは、オフセットのパフォーマンスを向上させるために、より高度なアルゴリズムが開発されています。
たとえば、シンガポール金融管理局の電子決済システム（MEPS +）は、FIFOアルゴリズムのステップ3で支払いを再注文するための反復アプローチを採用し、各参加銀行の合計取引額が最大になる反復を選択します。
MEPS +は、ソートされたキューアルゴリズムと組み合わせて、一連の非アクティブ化/アクティブ化チェックも実行します。 アルゴリズムは最初に、受け取り銀行に悪影響を及ぼさない無害な除去を特定しようとします。
そのような機会が見つからない場合、アルゴリズムはソートされたキューのアルゴリズムに戻ります。
一部の集中キューでは、参加者は支払いをキューから解放できる条件を指定できます。
オフセットアルゴリズムを実行するトリガーは、時間または何らかの支払いイベントの発生に基づくことができます。時間駆動型アルゴリズムは、事前定義された時間間隔、指定された時間、またはシステムオペレータの決定時に実行されます。
イベント駆動型アルゴリズムは、新しい支払いの到着、支払いの累積量または金額などの基準が満たされた場合、または特定のネッティングの機会が発生した場合に実行されます。
さらに、残高反応型LSMを使用すると、銀行は、それを下回ると支払いがキューから解放されない残高しきい値を選択できます（Martin and McAndrews（2010））。
システムはまた、参加者が使用できる彼ら自身の流動性の量に追加の制限を設定することを可能にするかもしれません。二国間制限は、参加者が別の参加者に支払う意思のある最大正味額を制限します。
多国間制限は、参加者がシステム内の他のすべての参加者または参加者のグループに許可することをいとわない資金の最大純流出を決定します。
そして最後に、合計制限は、RTGSとLSMの両方の運用に利用できる流動性の合計量を制限します。
純粋なRTGSシステムのグリッドロック防止機能としてのオフセットアルゴリズムの使用と、RTGSモードと並行した個別の決済モードとしての使用には違いがあることに注意してください。
前者の場合、オフセットメカニズムは、特定の時間または必要なときに（たとえば、特定の金額の支払いが特定の期間未決済のままである場合）、未払いの支払いキューをクリアするためにたまにしか実行されません。
後者の場合（表1に示すように）、このシステムは「LSMを備えたRTGSシステム」と呼ばれ、通常、RTGSモードとLSMモードの2つの決済モードがあります。
一般に、銀行は、RTGSモードでは決済口座の完全な流動性を使用でき、LSMモードでは割り当てられた流動性のみを使用できます。
割り当てられた流動性は、専用のLSMアカウント、または特定の種類の支払い用に作成された予約の形をとることができます。
専用LSMアカウントの場合、LSMアカウントの流動性はさまざまな設計機能で管理できます。参加者は通常、1日の始めに口座残高を前払いする必要があります。補足的な資金提供も終日可能です。
中央銀行による信用供与の2つの一般的な形態は、レポ取引と中央銀行口座の当座貸越（質権）です。決済機関は、事前定義された制限（ネットデビットキャップ）までの日中クレジットを提供することもできます。
表1は、主要国における既存の集中型キューイングメカニズムをまとめたものです。
これは、中央キューイング機能とLSMアカウント機能の設計に関して、国やシステム間で大きな違いがあることを示しています。まず、ほとんどすべてのシステムが優先設計のFIFO集中型キューを採用しています。
MEPS +には5つのレベルがあり、RIXでは最大9レベルの支払い優先度が許可されていることを除いて、通常、（非常に）緊急で通常の支払いを表す2つまたは3つの優先度のカテゴリがあります。
第2に、既存のシステムはすべてFIFOの原理と、並べ替えやバイパスを含むそのバリエーションを採用しています。
オフセットアルゴリズムでFIFOバイパス（RITS、TARGET2、BOK-Wire +、BOJ-NET、RIX）とソートされたキュー（MEPS +とCHAPS）について具体的に言及したシステムは、表1に示されています。
を組み合わせて使用すると、ほとんどのシステムは、バイラテラルオフセットアルゴリズムを1日中継続的に実行し、マルチラテラルオフセットアルゴリズムを実行する頻度は低くなります（たとえば、30分ごとにBOK Wire +、1日4回BOJ-NET）。
最後に、BOJNETとRIXには専用のLSMアカウントがありますが、システムの大部分には個別のLSMアカウントはありませんが、LSMキュー処理の流動性予約は可能です。
LSMを備えた最新のRTGSシステムは英国のCHAPSであり、2013年にLSMを導入しました。
このシステムでは、RTGSモードとLSMモードは単一の処理ストリームで動作し、RTGSモードは2つごとにLSMモードに切り替えられます。
マッチングサイクルの分（Denbee and McLafferty（2013）、Dent and Dison（2012））。 マッチングサイクルは約20秒続き、二国間または多国間オフセットアルゴリズムが実行されて、緊急でない支払いをマッチングして決済します。
オフセットアルゴリズムは、異なるキュー解放方法（FIFOまたは値でソートされたキュー）から選択できます。 マッチングサイクルで決済されなかった支払いはキューに残り、システムは次のサイクルでそれらのマッチングと決済を試みます。
日本銀行は、RTGSとLSMを2つの独立したメカニズムとして別々に運営しています。
参加者は、各決済日の開始時にLSMアカウントに資金を送金する必要があります。 LSMアカウントへの追加の送金は、日中いつでも可能です。
1日の終わりに、LSMアカウントの残高は自動的にRTGSアカウントに戻されます。 日銀では、二国間オフセットが主要なLSMメカニズムであり、日中継続的に実行されますが、多国間オフセットは補足的であり、4つの固定時間（10：30、13：30、14：30、および15:30）で実行されます。 ） 毎日。
オフセットアルゴリズムは基本的なFIFOのリリース順序に従いますが、参加者は支払いの順序を変更できます（Nakajima2015）。
計算能力の向上により、複雑な決済メカニズムの実装が可能になり、オフセットアルゴリズムを継続的に適用できるようになりました。
技術の進歩により、実現可能な設計のセットが広がり、革新的な新しいソリューションの開発がサポートされます。
ただし、技術の進歩だけでは、集中型キューのオペレーターが参加者の福祉を最大化する結果を達成できない場合があります。
✅４．一元化されたキューに関する問題
中央事業者は、支払いの重要性を評価する方法（システムが許可する大まかな優先順位の分類を超えて）や、銀行間および1日を通して変動する可能性のある個々の銀行の流動性供給コストを評価する方法がありません。
そのため、彼らは正確な福祉評価を行ったり、社会福祉を最大化するためのシステムパラメータを設定したりすることはできません。
動的ゲームの正式なモデルの用語を使用すると（Fudenberg and Tirole（1991））、中央オペレーターが直面する問題は不完全で不完全な情報の問題です。
不完全な情報の場合、プレーヤーは他のプレーヤーの以前のまたは同時の動きを観察することができません。情報が不完全な場合、プレーヤーは、他のプレーヤーのペイオフなど、ゲームの基本的な特性のいくつかについて確信が持てません。
4.1.不完全な情報
中央のオペレーターがシステム内のすべての参加者のすべての動きを見るわけではないため、不完全な情報が発生します。
中央オペレーターから隠されているアクションには、顧客から参加者への支払い要求の到着が含まれます。
これは、LSMの有無にかかわらずRTGSシステムの挑戦的な側面でした。支払いシステムがスムーズに機能するには、参加者がタイムリーに支払いを処理する必要があります。
流動性の提供には費用がかかるため、銀行は、他のシステム参加者に、出金を行うための流動性を獲得するために、入金を待つことによってフリーライドするインセンティブを持っています。
ただし、情報が不完全なため、フリーライディングの動作を検出することは困難です（Denbee et al（2012、2015）およびDiehl（2011）を参照）。
中央銀行は、顧客からの支払い要求がいつ銀行に到着するかを知りません。そのため、RTGSシステムは通常、比較的弱いガイドラインを採用して、タイムリーな支払い処理を保証します。
たとえば、一定期間の平均でのみ満たす必要のあるスループットガイドラインなどです。
たとえば、英国のCHAPS参加者は、正午までに50％、午後2時30分までに75％を完了する必要がありますが、この制限は1か月間の平均としてのみ評価され、銀行が違反している場合の「罰」は彼らは星室庁（CHAPSメンバーの集まり）の前に現れ、彼らの行動を説明しなければならないこと。
つまり、悪い行動を明確に検出できない場合、良い行動を強制することは困難です。これは、中央キューの有無にかかわらず、RTGSシステムに当てはまります。
4.2．不完全な情報
中央オペレーターがシステムのすべての参加者の支払い義務に関する完全な情報を持っていたとしても（つまり、顧客からの要求を確認できるか、これらの支払いを処理するかどうかの参加者の決定を確認できます）、それでも困難です。
参加者の費用と便益のすべてを知っているわけではないため、福祉最大化システムを設定します。
メリットの1つとして、最も緊急の支払いはすぐに決済する必要があり、銀行がキューに入れるのではなく、純粋なRTGSストリームを使用してすぐに決済することをすでに説明しました。
ただし、銀行が受け取る一連の支払い要求のうち、即時決済を必要としないものには、緊急度にばらつきがあります。既存のシステムでは、銀行が支払いをキューに入れるときに優先度レベルを指定できる場合があります。
これを許可するシステムは、通常、緊急（高優先度）と非緊急（通常）の2つのカテゴリのみを許可します。
TARGET2では3つのレベルが許可され、MEPS +では5つのレベルの優先順位が許可されます（表1を参照）。
支払いセットを細かく分割しすぎるとネッティングの機会が制限される可能性があるため、カテゴリの数を制限するのには十分な理由があります。
ただし、ここでのポイントは、情報の粗さがある程度あると、中央オペレーターがカテゴリ内の2つの支払いを区別する能力が制限されるため、支払いが最適ではない順序で処理するように選択される可能性があるということです。
参加者が所有するもう1つの重要な個人情報は、流動性を提供するためのコストです。
参加者が正味債務を決済するために中央キューに提供する資金の機会費用は、参加者自身の流動性費用と将来の流動性ニーズに関する予測に依存します。
銀行は多くの場合、マッチングサイクルの終了時に中央キューで利用できるようにする資金に制限を設定し、個人情報を使用してこの決定を通知します。
ただし、指定された制限がある場合、中央オペレーターは、特定の流動性ソースを使用して1セットの支払いを決済するか、別のソースを使用して別のセットを決済するかを決定するときに、この情報を利用できません。
4.3.事前積立とハード制限
不完全または不完全な情報の直接的な結果ではない集中型キューの制約的な側面は、中央キューのオペレーターがネッティングソリューションを探す必要がある利点を知る前に、銀行が集中型キューに提供する流動性の量を決定することです。
これらの所定の流動性金額の対象となります。
言い換えると、ネッティングアルゴリズムは、厳しい制限の対象となるソリューションを探します。少量の追加流動性が提供された場合、中央キューから多数の高額の支払いを処理できる例を構築することは難しくありませんが、追加の流動性を要求および受信する機能を備えた集中キューシステムはありません。 マッチングサイクル中。
以下、翻訳を中断
コメント