JP2020067805A - 清算システム及び清算方法 - Google Patents

Abstract

【課題】分散台帳を用いて、債務記録情報の正当性を確認できる基盤システムを利用して、効率的な清算を行なうための清算システム及び清算方法を提供する。【解決手段】清算機関サーバ２０が、金融機関サーバ１０により、分散台帳Ｄ１に記録された債権又は債務を有する金融機関に関する情報を含めた支払情報を取得する。清算機関サーバ２０は、分散台帳Ｄ１に記録された支払情報を用いてネッティングを行ない、ネッティングの結果に基づいて、支払元金融機関又は支払先金融機関、支払額を含めた清算予定情報を分散台帳Ｄ１に記録する。清算機関サーバ２０は、日銀システム３０に対して、清算予定情報に基づいて、支払元金融機関の日銀口座から支払額を引き落とす決済指図と、支払先金融機関の日銀口座に支払額を入金する決済指図とを送信する清算処理を実行する。【選択図】図１

Description

本発明は、債務者から債権者への支払を行なうための清算システム及び清算方法に関する。

ピア・ツー・ピア・ネットワークを活用したブロックチェーン技術が決済等に利用されつつある（例えば、非特許文献１参照）。非特許文献１に記載された技術では、ブロックチェーンを活用して、大規模な決済システムを新規に構築することなく、約定情報を改ざん不可能なデータとして瞬時に共有・決済できる仕組みが検討されている。このブロックチェーン技術では、順序付けられたレコードを、分散台帳で連続的に管理することにより、ブロック内のデータの遡及的な変更を防止する。

また、オンライン取引において利用されている仮想通貨の改ざんを防止するために、ブロックチェーン技術が利用される場合もある（例えば、特許文献１参照）。この技術では、約定情報に基づく残高情報をブロックチェーンで繋げたまとまりとして分散台帳に記録する。

また、ブロックチェーンを用いた債務取引に係る情報処理装置も検討されている（例えば、特許文献２参照）。この技術では、マルチラテラルネッティングの当事者である第１当事者及び第２当事者並びに当事者以外の第三者において、第三者を示すデータ及び第１債務金額を示すデータを含む第１データと、第２当事者を示すデータ及び第２債務金額を示すデータを含む第２データとを用いる。コンピュータが、第２データに係る第２当事者を示すデータを、第３データの債権者データに設定する。そして、コンピュータが、第１データの第１債務金額を示すデータと第２データの第２債務金額を示すデータのうち小さいデータを、第３データの債務金額データに設定することにより、マルチラテラルネッティングを行なう。

特開２０１６−１５１８０２号公報 特開２０１８−０８１５０２号公報

株式会社みずほ銀行、「国境を越えた証券取引の決済プロセス効率化に向けた実証実験を実施」、平成２８年３月８日、［online］、株式会社みずほ銀行、［平成３０年１０月１３日検索］、インターネット＜https://www.mizuhobank.co.jp/release/pdf/20160308release_jp.pdf＞

しかしながら、効率的な金融機関間の決裁システムがなければ、資金移動毎に手数料が発生し、利用者の負担が大きくなる。一方、金融機関間において新たな決済システムを構築する場合には、経済的な負担が大きくなる。

上記課題を解決する清算システムは、日銀システムに接続されるとともに、金融機関システムと、分散台帳により情報の正当性を確認できる基盤システムを介して接続された清算機関システムを含む。そして、前記清算機関システムが、前記金融機関システムにより、前記分散台帳に記録された債権又は債務を有する金融機関に関する情報を含めた支払情報を取得し、前記分散台帳に記録された支払情報を用いてネッティングを行ない、前記ネッティングの結果に基づいて、支払元金融機関又は支払先金融機関、支払額を含めた清算予定情報を前記分散台帳に記録し、前記日銀システムに対して、前記清算予定情報に基づいて、前記支払元金融機関の日銀口座から支払額を引き落とす決済指図と、前記支払先金融機関の日銀口座に支払額を入金する決済指図とを送信する清算処理を実行する。

本発明によれば、分散台帳を用いて、債務記録情報の正当性を確認できる基盤システムを利用して、効率的な清算を支援することができる。

本実施形態のシステム概略図。 ハードウェア構成例の説明図。 本実施形態で分散台帳に記録される情報の説明図であって、（ａ）は支払情報、（ｂ）は清算予定情報、（ｃ）は突合結果情報、（ｄ）は入金完了情報の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。

以下、図１〜図６を用いて、清算システム及び清算方法を具体化した一実施形態を説明する。
図１に示すように、本実施形態では、分散台帳Ｄ１（分散型台帳）を備える金融機関サーバ１０、清算機関サーバ２０を用いる。この清算機関サーバ２０は、日銀システム３０に接続される。本実施形態では、ブロックチェーンにより債権債務の記録の正当性を確認できる基盤システムを用いて、債権債務の清算を支援する場合を想定する。なお、ネットワークに接続された複数のノードで同じデータを保持し合う分散台帳Ｄ１を用いるものであれば、ブロックチェーン技術を用いる場合に限定されるものではない。そして、債務記録情報は、金融機関の債権債務関係を電子的に記録するものであり、債務記録情報は分散台帳Ｄ１に記録され、ブロックチェーン技術により固定化される。更に、所謂仮想通貨とは異なり、この記録自体では決済は完了せず、単に債権債務関係が記録されるだけである。債権債務関係では、債務記録情報に関わる関係者間で契約に基づき、一覧、又は定められた支払期日に銀行預金が振替られて初めて決済が完了する（債権債務関係の成立）。

金融機関サーバ１０、清算機関サーバ２０は、ピア・ツー・ピア（Peer to Peer）のネットワークで接続されている。このピア・ツー・ピアは、多数のシステム間で通信を行なうためのアーキテクチャのひとつであり、ピア同士が通信を行なう通信方式の基盤システムである。例えば、情報の改ざんを防止するために、ブロックチェーン方式を用いることができる。ブロックチェーン方式では、「取引の記録」をまとめた「ブロック」を「チェーン」状に順次追加していく。ブロックチェーンを構成するそれぞれのブロックは、そのブロックと一つ前のブロックに関する情報を含む「ヘッダ」と、ある時間内に行なわれた取引のリストを記録した「トランザクション」とにより構成される。ブロックチェーンにおいては、過去からの全取引記録が記録されているため、仮に不正を行なおうとした場合、不正以降の全ブロックを書き換える必要があり、計算負荷が大きく改ざんを困難にしている。そして、ピア・ツー・ピアネットワークに接続されている各システムは、一つのピアが発信した情報を、それぞれで分散して共有することになる。

そして、金融機関サーバ１０、清算機関サーバ２０は、それぞれ、ピア・ツー・ピアネットワークにおいて共有する情報を保存する分散台帳Ｄ１を保持する。一つのシステムの分散台帳Ｄ１に、所定の情報が書き込まれた場合、ピア・ツー・ピアネットワークにより、他のすべてのシステムが保有する分散台帳Ｄ１に、同じ分散情報が書き込まれる。

このため、金融機関サーバ１０、清算機関サーバ２０は、それぞれ、台帳管理部Ｍ１、情報記憶部Ｍ２を備える。台帳管理部Ｍ１は、自システムの情報記憶部Ｍ２に書き込まれた情報を、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に書き込む。

（ハードウェア構成例）
図２は、金融機関サーバ１０〜日銀システム３０等として機能する情報処理装置Ｈ１０のハードウェア構成例である。

情報処理装置Ｈ１０は、通信装置Ｈ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶部Ｈ１４、プロセッサＨ１５を有する。なお、このハードウェア構成は一例であり、他のハードウェアを有していてもよい。

通信装置Ｈ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。

入力装置Ｈ１２は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置Ｈ１３は、各種情報を表示するディスプレイやタッチパネル等である。

記憶部Ｈ１４は、金融機関サーバ１０〜日銀システム３０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置（例えば、情報記憶部Ｍ２）である。例えば、記憶部Ｈ１４は、情報記憶部Ｍ２に示した情報を記憶する。記憶部Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。

プロセッサＨ１５は、記憶部Ｈ１４に記憶されるプログラムやデータを用いて、金融機関サーバ１０〜日銀システム３０における各処理（例えば、台帳管理部Ｍ１における処理）を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各種処理に対応する各種プロセスを実行する。例えば、プロセッサＨ１５は、金融機関サーバ１０、清算機関サーバ２０のアプリケーションプログラムが起動された場合、後述する図４、図５に示す各処理を実行するプロセスを動作させる。

プロセッサＨ１５は、自身が実行するすべての処理についてソフトウェア処理を行うものに限られない。例えば、プロセッサＨ１５は、自身が実行する処理の少なくとも一部についてハードウェア処理を行う専用のハードウェア回路（例えば、特定用途向け集積回路：ＡＳＩＣ）を備えてもよい。すなわち、プロセッサＨ１５は、（１）コンピュータプログラム（ソフトウェア）に従って動作する１つ以上のプロセッサ、（２）各種処理のうち少なくとも一部の処理を実行する１つ以上の専用のハードウェア回路、或いは（３）それらの組み合わせ、を含む回路（circuitry）として構成し得る。プロセッサは、ＣＰＵ並びに、ＲＡＭ及びＲＯＭ等のメモリを含み、メモリは、処理をＣＰＵに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。

（各情報処理装置の構成）
図１を用いて、金融機関サーバ１０〜日銀システム３０の構成を説明する。
金融機関サーバ１０は、各顧客の口座を管理する金融機関のコンピュータシステムである。この金融機関サーバ１０は、取引管理部１１、取引情報記憶部１２、口座情報記憶部１３を備える。

取引管理部１１は、金融機関に開設された顧客口座を管理する。更に、取引管理部１１は、顧客口座を用いての取引（ここでは送金）を受け付ける。

取引情報記憶部１２には、顧客からの送金依頼についての取引管理情報が記録される。この取引管理情報には、送金日、送金額、引落口座、送金先口座に関する情報が記録される。
送金日データ領域には、送金を行なう年月日に関するデータが記録される。
送金額データ領域には、送金対象の金額に関するデータが記録される。

引落口座データ領域には、この金融機関に開設された顧客口座を特定するための識別子（金融機関コード、預金種別、本支店コード、口座番号）に関するデータが記録される。
送金先口座データ領域には、送金先口座を特定するための識別子（金融機関コード、預金種別、本支店コード、口座番号）に関するデータが記録される。

口座情報記憶部１３には、口座管理情報が記録される。この口座管理情報には、口座識別子、残高、入出金履歴が記録される。
口座識別子データ領域には、この口座を特定するための識別子に関するデータが記録される。
残高データ領域には、この口座の残高に関するデータが記録される。
入出金履歴データ流域には、この口座に対する入金や、この口座からの出金に関する履歴情報が記録される。

清算機関サーバ２０は、各金融機関から取得した支払情報に基づいて、金融機関間の支払を清算するセントラル・カウンターパーティ（ＣＣＰ）のコンピュータシステムである。清算機関サーバ２０は、清算管理部２１、支払情報記憶部２２を備える。

清算管理部２１は、各金融機関サーバ１０から取得した支払情報を用いてネッティングを行なうことにより、同じ金融機関についての債権と債務とを相殺して、金融機関による支払又は送金の金額を算出する。そして、清算管理部２１は、ネッティングに基づいて清算予定情報を生成し、分散台帳Ｄ１に記録する。

支払情報記憶部２２には、分散台帳Ｄ１を介して取得した支払情報が記録される。
図３（ａ）に示すように、支払情報５００には、発行番号、支払日、債権者、債務者、支払金額に関する情報が含まれる。この支払情報５００は、必要に応じて、本取引に関わる関係者（金融機関サーバ１０〜日銀システム３０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、支払を特定するための識別子に関するデータが記録される。
支払日データ領域には、債務者が債権者に対して支払を行なう予定日に関するデータが記録される。
債権者データ領域には、金額を取得する債権者である金融機関（支払先金融機関）を特定するための識別子に関するデータが記録される。

債務者データ領域には、金額を支払う債務者である金融機関（支払元金融機関）を特定するための識別子に関するデータが記録される。
支払金額データ領域には、債務者が債権者に支払う金額に関するデータが記録される。

図３（ｂ）に示すように、清算予定情報５１０には、発行番号、支払日、金融機関、清算方式、清算金額に関する情報が含まれる。この清算予定情報５１０は、必要に応じて、本取引に関わる関係者（金融機関サーバ１０〜日銀システム３０等）で復号可能なキーにより暗号化される。
発行番号データ領域には、清算に用いる支払情報５００を特定するための識別子（支払情報５００の発行番号）に関するデータが記録される。発行番号は、後述する清算に係る一連の情報（トランザクション）を特定するための識別情報である。

支払日データ領域には、清算に基づいて支払を行なう予定日に関するデータが記録される。
金融機関データ領域には、この清算に関わる金融機関（支払元金融機関又は支払先金融機関）を特定するための識別子に関するデータが記録される。

清算方式データ領域には、この清算において、日銀口座からの引落（清算における「負け」）、又は日銀口座へ入金（清算における「勝ち」）を識別するためのフラグが記録される。
清算金額データ領域には、この清算において支払われる金額に関するデータが記録される。

日銀システム３０は、各金融機関が開設した預金口座（日銀口座）を管理する日本銀行のコンピュータシステムである。そして、清算機関サーバ２０から取得した決済指図に基づいて、各金融機関の日銀口座からの引落や入金を行なう。また、日銀システム３０は、日銀口座からの引落不能に備えて、各金融機関の担保情報を保持している。そして、引落不能が生じた場合には、この担保情報を利用しての支払可否を判定する。

（清算処理）
次に、図４を用いて、清算処理を説明する。ここでは、例えば、支払情報又は清算予定情報として、ブロックチェーンを利用するオープンアセットプロトコルによるカラードコインを用いる。

まず、金融機関サーバ１０は、支払情報の記録処理を実行する（ステップＳ１−１）。具体的には、金融機関サーバ１０の取引管理部１１は、清算時期が到来した場合、清算時期に対応する支払日に基づいて、取引情報記憶部１２に記録された取引管理情報を取得し、自行から他行に支払う取引管理情報を特定する。次に、取引管理部１１は、債権者（他行）毎に、取引管理情報の送金額を合計した支払額を算出する。次に、取引管理部１１は、支払日、債権者（他行）、債務者（自行）、支払額を含めた支払情報を生成し、情報記憶部Ｍ２に記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に支払情報を書き込む。

次に、清算機関サーバ２０は、ネッティング処理を実行する（ステップＳ１−２）。具体的には、清算機関サーバ２０の清算管理部２１は、情報記憶部Ｍ２の分散台帳Ｄ１に記録された支払情報を、支払情報記憶部２２に記録する。そして、清算管理部２１は、支払日の所定時間前のネッティング開始時刻になった場合、ネッティングを開始する。

図６に示すように、４つの支払情報（５０１〜５０４）を用いてネッティングを行なう場合を説明する。ここでは、債務者から債権者に対する支払を清算機関が仲介する場合を想定する。この場合、Ａ銀行においては、支払情報５０１、５０３により、清算機関から清算金額「１５０」が入金されることになる。また、Ｂ銀行においては、支払情報５０１と支払情報５０２とが相殺されて、清算機関から清算金額「１６０」が入金されることになる。同様に、Ｃ銀行においては、支払情報５０２，５０３と支払情報５０４とが相殺されて、清算金額「１９０」を清算機関に支払うことになる。Ｄ銀行においては、支払情報５０４により、清算金額「１２０」を清算機関に支払うことになる。

次に、清算機関サーバ２０は、清算予定の記録処理を実行する（ステップＳ１−３）。具体的には、清算機関サーバ２０の清算管理部２１は、まず、ネッティングに基づいて、清算予定情報を生成する。
ここでは、図６に示すように、上述のネッティングにより、清算予定情報５１１〜５１４を生成する。そして、清算機関サーバ２０の台帳管理部Ｍ１は、情報記憶部Ｍ２の分散台帳Ｄ１に、清算予定情報５１０を記録する。この場合、台帳管理部Ｍ１は、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に清算予定情報５１０を書き込む。

次に、金融機関サーバ１０は、清算予定の取得処理を実行する（ステップＳ１−４）。具体的には、金融機関サーバ１０の取引管理部１１は、台帳に記録された清算予定情報５１０を取得する。

次に、金融機関サーバ１０は、突合処理を実行する（ステップＳ１−５）。具体的には、金融機関サーバ１０の取引管理部１１は、取引情報記憶部１２において、清算予定情報５１０に記録されている支払日の取引管理情報を取得する。次に、取引管理部１１は、取引管理情報の取引金額の合計値と、清算予定情報５１０の清算金額とを突合する。そして、取引管理部１１は、取引金額の合計値と清算金額との一致又は不一致を示す突合結果を生成する。

次に、金融機関サーバ１０は、突合結果の記録処理を実行する（ステップＳ１−６）。具体的には、金融機関サーバ１０の取引管理部１１は、突合結果を記録した突合結果情報を生成する。

図３（ｃ）に示すように、突合結果情報５２０には、発行番号、支払日、金融機関、突合結果に関するデータを含める。この突合結果情報５２０は、必要に応じて、本取引に関わる関係者（金融機関サーバ１０〜日銀システム３０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、清算に用いる支払情報５００を特定するための識別子（支払情報５００の発行番号）に関するデータが記録される。そして、この発行番号により、清算予定情報５１０を特定することができる。
支払日データ領域には、債務者が債権者に対して支払を行なう予定日に関するデータが記録される。

金融機関データ領域には、突合を行なった金融機関を特定するための識別子に関するデータが記録される。
突合結果データ領域には、取引金額の合計値と清算予定情報の金額との一致又は不一致を示すフラグが記録される。

そして、台帳管理部Ｍ１は、生成した突合結果情報５２０を、情報記憶部Ｍ２の分散台帳Ｄ１に記録する。この場合、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に突合結果情報５２０が書き込まれる。

次に、清算機関サーバ２０は、日銀口座からの引落指図処理を実行する（ステップＳ１−７）。具体的には、清算機関サーバ２０の清算管理部２１は、分散台帳Ｄ１に記録された突合結果情報５２０を取得する。そして、すべての金融機関の突合結果情報５２０において一致フラグが記録されている場合には、清算管理部２１は、日銀システム３０に対して、清算方式「引落」（ネッティングにおいて「負け」）の金融機関の口座から清算金額を引き落とす決済指図を送信する。

次に、清算機関サーバ２０は、引落不能があるかどうかについての判定処理を実行する（ステップＳ１−８）。具体的には、清算機関サーバ２０の清算管理部２１は、引落口座の中で、引落不能口座があるかどうかを判定する。

少なくとも一つの日銀口座において、引落不能があると判定した場合（ステップＳ１−８において「ＹＥＳ」の場合）の処理については、図５を用いて後述する。
一方、すべての金融機関の日銀口座において、引落不能がないと判定した場合（ステップＳ１−８において「ＮＯ」の場合）、清算機関サーバ２０は、日銀口座への入金指図処理を実行する（ステップＳ１−９）。具体的には、清算機関サーバ２０の清算管理部２１は、日銀システム３０に対して、清算方式「引落」（ネッティングにおいて「勝ち」）の金融機関の口座に対して清算金額の入金を指示する決済指図を送信する。
次に、清算機関サーバ２０は、入金完了情報の記録処理を実行する（ステップＳ１−１０）。具体的には、清算機関サーバ２０の清算管理部２１は、入金完了情報を生成する。

図３（ｄ）に示すように、入金完了情報５３０には、発行番号、支払日、金融機関、入金結果に関するデータを含める。この入金完了情報５３０は、必要に応じて、本取引に関わる関係者（金融機関サーバ１０〜日銀システム３０等）で復号可能なキーにより暗号化される。

発行番号データ領域には、清算に用いた支払情報５００を特定するための識別子（支払情報５００の発行番号）に関するデータが記録される。そして、この発行番号により、清算予定情報５１０を特定することができる。
支払日データ領域には、日銀口座を用いて支払を完了した年月日に関するデータが記録される。
金融機関データ領域には、入金を行なった日銀口座の名義人（金融機関）を特定するための識別子に関するデータが記録される。
入金結果データ領域には、入金を完了したことを示すフラグが記録される。

そして、台帳管理部Ｍ１は、生成した入金完了情報５３０を、情報記憶部Ｍ２の分散台帳Ｄ１に記録する。この場合、ピア・ツー・ピアネットワークに接続された他システムの情報記憶部Ｍ２の分散台帳Ｄ１に入金完了情報５３０が書き込まれる。

次に、金融機関サーバ１０は、顧客との間で債権債務の成立処理を実行する（ステップＳ１−１１）。具体的には、金融機関サーバ１０の取引管理部１１は、情報記憶部Ｍ２の分散台帳Ｄ１に記録された入金完了情報５３０を取得する。次に、取引管理部１１は、入金完了情報５３０の発行番号を用いて、取引（入金又は引落）対象の顧客口座を特定する。そして、取引管理部１１は、特定した顧客口座について、口座情報記憶部１３に入金又は引落を記録する。

（引落不能処理）
次に、図５を用いて、引落不能があると判定した場合（図４のステップＳ１−８において「ＹＥＳ」の場合）の引落不能処理を説明する。

ここでは、清算機関サーバ２０は、日銀口座からの再引落指図処理を実行する（ステップＳ２−１）。具体的には、清算機関サーバ２０の清算管理部２１は、所定の時間間隔で、引落不能が生じた金融機関の日銀口座から清算金額を引き落とす決済指図を、日銀システム３０に対して送信する。

次に、清算機関サーバ２０は、決済時限までに再引落可能かどうかについての判定処理を実行する（ステップＳ２−２）。具体的には、清算機関サーバ２０の清算管理部２１は、現在時刻と引落時限とを比較する。

決済時限までに再引落可能と判定した場合（ステップＳ２−２において「ＹＥＳ」の場合）、清算機関サーバ２０は、日銀口座に入金処理（図４のステップＳ１−９）に戻る。

一方、決済時限までに再引落不可と判定した場合（ステップＳ２−２において「ＮＯ」の場合）、清算機関サーバ２０は、担保等による清算可能かどうかについての判定処理を実行する（ステップＳ２−３）。具体的には、日銀システム３０は、引落不能口座の金融機関の担保情報を確認し、この担保等により、清算金額を引落可能かどうかについて判定する。そして、日銀システム３０は、清算機関サーバ２０に対して、担保による清算結果を返信する。この場合、清算機関サーバ２０の清算管理部２１は、日銀システム３０から取得した清算結果により、清算可否を判定する。

担保等による清算可能と判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）も、清算機関サーバ２０は、日銀口座への入金指図処理（図４のステップＳ１−９）に戻る。

一方、担保等による清算不可と判定した場合（ステップＳ２−３において「ＮＯ」の場合）、清算機関サーバ２０は、引落不能金融機関を除いて，再ネッティング処理を実行する（ステップＳ２−４）。具体的には、清算機関サーバ２０の清算管理部２１は、支払情報記憶部２２に記録された支払情報において、引落不能金融機関が関係する支払情報を清算対象から外す。そして、清算管理部２１は、残った支払情報を用いて、再度、ネッティング処理を実行する。この場合、清算管理部２１は、日銀システム３０に対して、ステップＳ１−４の引落指図を取り消し、清算予定の記録処理（図４のステップＳ１−３）からやり直す。

本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、支払情報５００、清算予定情報５１０、突合結果情報５２０、入金完了情報５３０が分散台帳Ｄ１に記録される。これにより、取引（清算）の関係者が、清算内容や清算状況を確認することができる。そして、ブロックチェーンを用いた分散台帳Ｄ１により、記録の内容が不変で、記録の照合が容易であり、迅速で効率的な清算を行なうことができる。

（２）本実施形態では、金融機関サーバ１０は、支払情報の記録処理を実行し（ステップＳ１−１）、清算機関サーバ２０は、ネッティング処理を実行する（ステップＳ１−２）。これにより、各金融機関において、他行への送金をネッティングにより集約し、送金の効率化を図ることができる。

（３）本実施形態では、清算機関サーバ２０は、清算予定の記録処理を実行し（ステップＳ１−３）、金融機関サーバ１０は、清算予定の取得処理（ステップＳ１−４）、突合処理（ステップＳ１−５）を実行する。これにより、ネッティングを行なった清算予定について、分散台帳Ｄ１に記録された支払情報との整合を確認することができる。

（４）本実施形態では、清算機関サーバ２０は、日銀口座からの引落指図処理（ステップＳ１−７）、日銀口座への入金指図処理（ステップＳ１−９）、入金完了情報の記録処理（ステップＳ１−１０）を実行する。これにより、ネッティングの整合性を確認した結果に基づいて、支払を行なうことができる。

（５）本実施形態では、清算機関サーバ２０は、引落不能があると判定し（ステップＳ１−８において「ＹＥＳ」）、担保等による清算不可と判定した場合（ステップＳ２−３において「ＮＯ」の場合）、清算機関サーバ２０は、引落不能金融機関を除いて再ネッティング処理を実行する（ステップＳ２−４）。これにより、日銀口座において引落不能が生じた場合にも、新たなネッティングにより、効率的に清算を行なうことができる。

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、支払情報５００〜入金完了情報５３０として、ビットコインのブロックチェーンを利用するオープンアセットプロトコル（カラードコイン）を用いる場合を想定した。債務記録は、カラードコインに限定されるものではない。ビットコイン以外の分散台帳Ｄ１を応用した、通貨以外の役割・機能を持たすことを主目的とした基盤システムを利用することができる。

・上記実施形態では、金融機関サーバ１０は、支払情報の記録処理を実行する（ステップＳ１−１）。この場合、金融機関サーバ１０の取引管理部１１は、債権者（他行）毎に、取引管理情報の送金額を合計する。ここで、他行に送金が必要な取引管理情報を支払情報として分散台帳Ｄ１に記録するようにしてもよい。この場合には、清算機関サーバ２０が、支払日に基づいて、金融機関毎に、取引管理情報の送金額を合計した支払額を算出するようにしてもよい。

・上記実施形態では、清算予定情報５１０には、発行番号、支払日、金融機関、清算方式、清算金額に関する情報が含まれる。この清算予定情報５１０において、ネッティングに用いる支払情報５００を特定できる情報であれば、発行番号に限定されない。例えば、支払情報５００の発行番号を記録するデータ領域を設けてもよい。そして、突合結果情報、入金完了情報には、清算予定情報５１０を特定できる情報（例えば、清算予定情報５１０の発行番号）を含める。この場合には、各金融機関において、清算予定情報５１０に記録された支払情報５００の発行番号を用いて、支払情報５００を特定し、突合処理を行なう。これにより、金融機関サーバ１０において、効率的に清算予定情報と支払情報との突合を行なうことができる。
・上記実施形態では、分散台帳Ｄ１に記録する情報は、必要に応じて、本取引に関わる関係者で復号可能なキーにより暗号化される。暗号化の必要性は、ネットワークや情報に応じて行なえばよい。例えば、関係者のみが用いるクローズド型（プライベート型）ネットワークの場合には、暗号化の必要はない。
・上記実施形態では、分散台帳Ｄ１に記録される一連の情報を特定するための識別子として、支払情報５００の発行番号を用いる。一連の情報を特定できる識別子であれば、支払情報５００の発行番号に限定されるものではない。

１０…金融機関サーバ、１１…取引管理部、１２…取引情報記憶部、１３…口座情報記憶部、２０…清算機関サーバ、２１…清算管理部、２２…支払情報記憶部、３０…日銀システム、Ｄ１…分散台帳、Ｍ１…台帳管理部、Ｍ２…情報記憶部。

Claims (6)

1. 日銀システムに接続されるとともに、分散台帳により情報の正当性を確認できる基盤システムを介して、金融機関システムと接続された清算機関システムを含む清算システムであって、
   前記清算機関システムが、
   前記金融機関システムにより、前記分散台帳に記録された債権又は債務を有する金融機関に関する情報を含めた支払情報を取得し、
   前記分散台帳に記録された支払情報を用いてネッティングを行ない、
   前記ネッティングの結果に基づいて、支払元金融機関又は支払先金融機関、支払額を含めた清算予定情報を前記分散台帳に記録し、
   前記日銀システムに対して、前記清算予定情報に基づいて、前記支払元金融機関の日銀口座から支払額を引き落とす決済指図、又は前記支払先金融機関の日銀口座に支払額を入金する決済指図を送信する清算処理を実行することを特徴とする清算システム。
2. 前記金融機関システムが、債権又は債務を有する金融機関に関する情報を含めた前記支払情報を前記分散台帳に登録することを特徴とする請求項１に記載の清算システム。
3. 前記清算機関システムが、
   前記金融機関システムにより前記分散台帳に記録された前記清算予定情報と、前記分散台帳に記録された前記支払情報とを突合した突合結果を前記分散台帳から取得し、
   前記突合結果に基づいて、前記清算処理を実行することを特徴とする請求項１又は２に記載の清算システム。
4. 前記清算機関システムが、前記清算処理の清算結果を前記分散台帳に記録することを特徴とする請求項１〜３の何れか一項に記載の清算システム。
5. 前記清算機関システムが、支払元金融機関の日銀口座から引き落としができなかった場合、前記支払情報において、前記支払元金融機関を除いた支払情報を用いて、再度、ネッティングを行なうことを特徴とする請求項１〜４の何れか一項に記載の清算システム。
6. 日銀システムに接続されるとともに、分散台帳により情報の正当性を確認できる基盤システムを介して、金融機関システムと接続された清算機関システムを含む清算システムを用いて、清算を支援する方法であって、
   前記清算機関システムが、
   前記金融機関システムにより、前記分散台帳に記録された債権又は債務を有する金融機関に関する情報を含めた支払情報を取得し、
   前記分散台帳に記録された支払情報を用いてネッティングを行ない、
   前記ネッティングの結果に基づいて、支払元金融機関又は支払先金融機関、支払額を含めた清算予定情報を前記分散台帳に記録し、
   前記日銀システムに対して、前記清算予定情報に基づいて、前記支払元金融機関の日銀口座から支払額を引き落とす決済指図、又は前記支払先金融機関の日銀口座に支払額を入金する決済指図を送信する清算処理を実行することを特徴とする清算方法。

Images