特表 2022-553486 安全な資金移動のための方法及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-12-23

(54)【発明の名称】安全な資金移動のための方法及びシステム

(51)【国際特許分類】

   G06Q 40/02 20120101AFI20221216BHJP

【ＦＩ】

G06Q40/02

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022514164

(86)(22)【出願日】2019-09-02

(85)【翻訳文提出日】2022-04-27

(86)【国際出願番号】 IB2019057390

(87)【国際公開番号】W WO2021044185

(87)【国際公開日】2021-03-11

(81)【指定国・地域】

(71)【出願人】

【識別番号】522081059

【氏名又は名称】アールティージーエス リミテッド

【氏名又は名称原語表記】ＲＴＧＳ ＬＩＭＩＴＥＤ

【住所又は居所原語表記】Ｔｈｅ Ｍｏｄｅｒｎ Ｇｒｏｕｐ Ｏｆｆｉｃｅｓ， Ｂｒｏｏｋｌｙｎ Ｓｔｒｅｅｔ， Ｓｔ Ｈｅｌｌｉｅｒ， Ｊｅｒｓｅｙ ＪＥ１ ＡＨＥ Ｕｎｉｔｅｄ Ｋｉｎｇｄｏｍ

(74)【代理人】

【識別番号】100169904

【弁理士】

【氏名又は名称】村井 康司

(74)【代理人】

【識別番号】100219117

【弁理士】

【氏名又は名称】金 亨泰

(72)【発明者】

【氏名】ジョゼフ ゴードン クーパー

(72)【発明者】

【氏名】ニック オグデン

(72)【発明者】

【氏名】アンドルー スミス

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055BB08

(57)【要約】

第１の貨幣の資金を第１の場所における第１の送信銀行口座から第２の場所における第２の受取人銀行口座へ転送するように作動可能であるセキュア送金を処理するための方法及びシステム。本発明の目的は、国境を跨ぎ且つリアルタイムで動作するシステムを提供することである。本発明の別の目的は、資金の存在を保証し且つ資金が転送されることを確実にしこれにより銀行がＨｅｒｓｔａｔｔリスクに晒されるリスクを低減するシステムを提供することである。

【特許請求の範囲】

【請求項1】

第１の貨幣の資金を第１の場所における第１の（送信）銀行口座から第２の場所における第２の（受取人）銀行口座へ転送するように作動可能であるセキュア送金システムと共に使用するためのコンピュータ実施方法であって、
第１の処理手段は、或る金額が転送される前記第１の口座内の資金の合計を識別し；
プロトコルバッファは、前記転送される資金の合計に関するブロックコードを生成し；
メモリは、前記第１の送信銀行口座の前記資金の合計及びユニーク口座識別子を識別するデータを含む前記ブロックコードを格納し；
通信デバイスは、前記資金の合計が転送される受取人銀行における受取人口座とのセキュア通信チャネルを確立し；
ローカル送信プロトコルバッファは前記セキュア通信チャネルを介し前記ブロックコードをリモート受取人プロトコルバッファへ送信し；
前記リモート受取人プロトコルバッファは、前記ブロックコードを受信し、そして前記ブロックコードを、前記送信銀行口座から導出された口座データ及び流動性査証を前記受取人銀行口座へ中継する双方向同期装置へ送信し；
同期装置は前記送信銀行口座と前記受信銀行口座とを同期させ、これによりその間の直接的高速接続を確立し；
前記同期装置から認可信号を受信すると、第２の処理手段は、ここから前記資金の合計が転送される前記第１の口座内の前記資金の合計を識別しリングフェンスするように作動可能であり；
前記ブロックコード内の識別される前記資金の合計が前記リングフェンスされた資金の合計に対応する場合、認定ユーザ（口座名義人）は所定期間の間商取引選択肢を提示され；
前記商取引選択肢の受諾を確認する前記認定ユーザ（口座名義人）からの入力を受信すると、双方向取り消し不能認証事象を確立し、これにより資金が転送されることを可能にするための相互協定が前記受取人銀行口座と前記送信銀行口座との間で確立される、方法。

【請求項2】

前記第２の受取人銀行口座へ支払われる前記資金は前記第１の貨幣とは異なる貨幣で支払われる、請求項１に記載の方法。

【請求項3】

暗号化エンジンを介しプロトコルバッファへ及び／又はそれから送信する工程を含む請求項１又は２に記載の方法。

【請求項4】

公開／秘密キー暗号化システムプロトコル及び／又は暗号化アルゴリズム（例えばＲＳＡ暗号化アルゴリズムなど）にしたがって動作する暗号化エンジンを使用することによりメッセージを暗号化する工程を含む、請求項３に記載の方法。

【請求項5】

前記第１の送信銀行口座の前記ユニーク口座識別子は以下のもの：口座番号及び銀行分類コード；銀行識別子コード（ＢＩＣ）；国際銀行口座番号（ＩＢＡＮ）；国識別コード番号及び分散型識別子（ＤＩＤ）からの番号を含むグループから導出される、請求項１乃至４のいずれか一項に記載の方法。

【請求項6】

前記ユーザ（口座名義人）は商取引選択肢を所定期間の間提示される、請求項１乃至５のいずれか一項に記載の方法。

【請求項7】

前記ユーザ（口座名義人）が前記所定期間内に提示された商取引選択肢を受諾しなければ、前記提示の再計算が、更新された流動性査証を前記送信銀行口座から取得することにより導出される、請求項６に記載の方法。

【請求項8】

前記ユーザ（口座名義人）は、前記第２の場所における前記第２の（受取人）銀行により認識されるユーザ選択可能貨幣で商取引選択肢を提示される、請求項１乃至７のいずれか一項に記載の方法。

【請求項9】

商取引の受諾を確認する入力信号（前記ユーザ（口座名義人）からの認可命令を含む）を受信すると、前記第１の（送信）銀行口座から転送される前記資金はリングフェンスされる、請求項１乃至８のいずれか一項に記載の方法。

【請求項10】

プロセッサが少なくとも１つの決済課金を前記リングフェンスされた資金合計と前記送信及び／又は受信銀行により適用された流動性ロックの値に基づく少なくとも１つの商取引課金とに基づき判断する、請求項９に記載の方法。

【請求項11】

プロセッサが、前記送信及び／又は受信銀行により適用された前記流動性ロックの前記値に基づき少なくとも１つの商取引課金を判断する、請求項９又は１０に記載の方法。

【請求項12】

前記プロセッサは銀行間リスク要因に基づき流動性ブロックの値を判断する、請求項１１に記載の方法。

【請求項13】

プロプライアタリ支払いシステムをセキュア通信チャネルへ接続するための少なくとも１つのゲートウェイが、確立され、そして以下のものを含むグループからの１つを含む：ＴＣＰ／ＩＰルーティングプロトコルゲートウェイ；リモートプロトコルバッファ、ウェブソケット、仮想私設ネットワーク（ＶＰＮ）、及びＳＷＩＦＴ(登録商標)支払いネットワーク、請求項１乃至１２のいずれか一項に記載の方法。

【請求項14】

少なくとも１つの中央銀行により監督される管轄区内にリアルタイムで取り込まれる商取引事象のデータレイクを確立することを含む、請求項１乃至１３のいずれか一項に記載の方法。

【請求項15】

ユーザにより可視であるディスプレイへメニューを届けるように構成されるとともにそしてここからユーザ命令が通信ネットワークへ送信されるウェブベースポータルを含む、請求項１乃至１４のいずれか一項に記載の方法。

【請求項16】

貨幣整合／ルーティングエンジンを採用することにより少なくとも１つの参加銀行及び前記商取引における使用に好適な指定貨幣を識別する工程を含む、請求項１乃至１５のいずれか一項に記載の方法。

【請求項17】

参加銀行がプロトコルバッファ構成要素間のポイント・ツー・ポイント暗号化及び通信ネットワークを採用する、請求項１乃至１６のいずれか一項に記載の方法。

【請求項18】

前記プロトコルバッファは、内部通信データを公開又はプロプライアタリネットワークへ転送するように作動可能な暗号化オフローディングシーケンスにしたがって動作する（暗号化された秘密インフラストラクチャ上で動作する）、請求項１７に記載の方法。

【請求項19】

データベース及び／又は分散台帳又はブロックチェーンを使用することによりプロトコルバッファから双方向同期装置への又は双方向同期装置からプロトコルバッファへの通信をログ記録する工程を含む、請求項１乃至１８のいずれか一項に記載の方法。

【請求項20】

プロトコルバッファ群とプロトコルバッファと双方向同期装置との間の通信に関係する格納されたデータの監査ログ記録を行う工程を含む、請求項１９に記載の方法。

【請求項21】

データのエッジ暗号化を行う工程を含む、請求項１乃至２０のいずれか一項に記載の方法。

【請求項22】

多くの独立サイト、及び／又は様々な国々、及び／又は独立機関に位置する分散された台帳を採用する工程を含む、請求項１乃至２１のいずれか一項に記載の方法。

【請求項23】

第１の貨幣の資金を第１の場所における第１の（送信）銀行口座から第２の場所における第２の（受取人）銀行口座へ転送するように作動可能であるセキュア送金を処理するためのシステムであって、
第１の処理手段は、或る金額が転送される前記第１の口座内の資金の合計を識別し；
プロトコルバッファは、前記転送される資金の合計に関するブロックコードを生成し；
メモリは、前記第１の送信銀行口座の前記資金の合計及びユニーク口座識別子を識別するデータを含む前記ブロックコードを格納し；
通信デバイスは、前記資金の合計が転送される受取人銀行における受取人口座とのセキュア通信チャネルを確立し；
ローカル送信プロトコルバッファは前記セキュア通信チャネルを介し前記ブロックコードをリモート受取人プロトコルバッファへ送信し；
前記リモート受取人プロトコルバッファは、前記ブロックコードを受信し、そして前記ブロックコードを、前記送信銀行口座から導出された口座データ及び流動性査証を前記受取人銀行口座へ中継する双方向同期装置へ送信し；
同期装置は前記送信銀行口座と前記受信銀行口座とを同期させ、これによりその間の直接的高速接続を確立し；
前記同期装置から認可信号を受信すると、第２の処理手段は、ここから前記資金の合計が転送される前記第１の口座内の前記資金の合計を識別しリングフェンスするように作動可能であり；
前記ブロックコード内の識別される前記資金の合計が前記リングフェンスされた資金の合計に対応する場合、認定ユーザ（口座名義人）は所定期間の間商取引選択肢を提示され；
前記商取引選択肢の受諾を確認する前記認定ユーザ（口座名義人）からの入力を受信すると、双方向取り消し不能認証事象を確立し、これにより資金が転送されることを可能にするための相互協定が前記受取人銀行口座と前記送信銀行口座との間で確立される、システム。

【請求項24】

前記第２の受取人銀行口座へ支払われる前記資金は前記第１の貨幣とは異なる貨幣で支払われる、請求項２３に記載のシステム。

【請求項25】

プロトコルバッファへの及び／又はプロトコルバッファからの送信を暗号化するように作動可能な暗号化エンジンを含む、請求項２３又は２４に記載のシステム。

【請求項26】

前記暗号化エンジンは公開／秘密キー暗号化システムプロトコル及び／又は暗号化アルゴリズム（例えばＲＳＡ暗号化アルゴリズムなど）にしたがって作動可能である、請求項２５に記載のシステム。

【請求項27】

前記第１の送信銀行口座のユニーク口座識別子は以下のもの：口座番号及び銀行分類コード；銀行識別子コード（ＢＩＣ）；国際銀行口座番号（ＩＢＡＮ）；国識別コード番号、及び分散型識別子（ＤＩＤ）の使用から導出され得る番号、を含むグループから導出される、請求項２３乃至２６のいずれか一項に記載のシステム。

【請求項28】

プロセッサは前記ユーザ（口座名義人）へ商取引選択肢を所定期間の間提示するように作動可能である、請求項２３乃至２７のいずれか一項に記載のシステム。

【請求項29】

タイマは一定期間を開始し、そして前記ユーザ（口座名義人）が前記所定期間内に提示された商取引選択肢を受諾しなければ、前記提示の再計算が、更新された流動性査証を前記送信銀行口座から取得することにより導出される、請求項２８に記載のシステム。

【請求項30】

前記ユーザ（口座名義人）は、前記第２の場所における前記第２の（受取人）銀行により認識されるユーザ選択可能貨幣で商取引選択肢をディスプレイ上に提示される、請求項２３乃至２９のいずれか一項に記載のシステム。

【請求項31】

商取引の受諾を確認する入力信号（前記ユーザ（口座名義人）からの認可命令を含む）を受信すると、前記システムは前記第１の（送信）銀行口座から転送される前記資金をリングフェンスする、請求項２３乃至３０のいずれか一項に記載のシステム。

【請求項32】

プロセッサは少なくとも１つの決済課金を前記リングフェンスされた資金合計と前記送信及び／又は受信銀行により適用された流動性ロックの値に基づく少なくとも１つの商取引課金とに基づき判断する、請求項２３乃至３１のいずれか一項に記載のシステム。

【請求項33】

プロセッサは、前記送信及び／又は受信銀行により適用された前記流動性ロックの前記値に基づき少なくとも１つの商取引課金を判断する、請求項３１又は３２に記載のシステム。

【請求項34】

前記プロセッサは銀行間リスク要因に基づき前記流動性ブロックの前記値を判断する、請求項３３に記載のシステム。

【請求項35】

プロプライアタリ支払いシステムを前記セキュア通信チャネルへ接続するための少なくとも１つのゲートウェイが、確立され、そして以下のもの：ＴＣＰ／ＩＰルーティングプロトコルゲートウェイ；リモートプロトコルバッファ、ウェブソケット、仮想私設ネットワーク（ＶＰＮ）、及びＳＷＩＦＴ(登録商標)支払いネットワークを含むグループからの１つを含む、請求項２３乃至３４のいずれか一項に記載のシステム。

【請求項36】

少なくとも１つの中央銀行により監督される管轄区内にリアルタイムで取り込まれる商取引事象のデータレイクを含む、請求項２３乃至３５のいずれか一項に記載のシステム。

【請求項37】

ユーザにより可視であるディスプレイへメニューを届けるように構成されるとともにここからユーザ命令が通信ネットワークへ送信されるウェブベースポータルを含む、請求項２３乃至３６のいずれか一項に記載のシステム。

【請求項38】

貨幣整合／ルーティングエンジンが少なくとも１つの参加銀行及び指定された通貨を識別することを採用することにより少なくとも１つの参加銀行と前記商取引における使用に好適な指定貨幣とを識別するように作動可能な手段を含む、請求項２３乃至３７のいずれか一項に記載のシステム。

【請求項39】

参加銀行はプロトコルバッファ構成要素間のポイント・ツー・ポイント暗号化及び通信ネットワークを採用する、請求項２３乃至３８のいずれか一項に記載のシステム。

【請求項40】

前記プロトコルバッファは、内部通信データを公開又はプロプライアタリネットワークへ転送するように作動可能な暗号化オフローディングシーケンスにしたがって動作する（暗号化された秘密インフラストラクチャ上で動作する）、請求項３９に記載のシステム。

【請求項41】

プロトコルバッファから双方向同期装置への又は双方向同期装置からプロトコルバッファへの通信をログ記録しそしてデータベース及び／又は分散台帳又はブロックチェーンを含む手段を含む、請求項２３乃至４０のいずれか一項に記載のシステム。

【請求項42】

プロトコルバッファ群とプロトコルバッファと双方向同期装置との間の通信に関係する格納されたデータの監査ログ記録を行う手段を含む、請求項４１に記載のシステム。

【請求項43】

データのエッジ暗号化を行う手段を含む、請求項２３乃至２６のいずれか一項に記載のシステム。

【請求項44】

多くの独立サイト、及び／又は様々な国々、及び／又は独立機関に位置する分散された台帳を含む、請求項２３乃至４３のいずれか一項に記載のシステム。

【請求項45】

モバイル電話、タブレット又はラップトップであって、ディスプレイを含み、ソフトウェアにしたがって作動可能であり請求項２３乃至４４のいずれか一項に記載のシステムと通信するように構成される、モバイル電話、タブレット又はラップトップ。

【請求項46】

商取引の受諾を確認する認定ユーザ（口座名義人）からの入力を提供するように前記認定ユーザにより作動可能である生体測定デバイスを有する、請求項４５に記載のモバイル電話、タブレット又はラップトップ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は安全な資金移動のための方法及びシステムに関する。

【背景技術】

【0002】

銀行間又は外国為替取引市場は銀行同士が様々な貨幣を交換するトップレベル外国為替市場である。銀行は直接的に又は電子仲介プラットホームを介し互いに取り引きし得る。電子仲介サービス（ＥＢＳ：ｅｌｅｃｔｒｏｎｉｃ ｂｒｏｋｉｎｇ ｓｅｒｖｉｃｅ）は、世界中の何百もの銀行を接続して１つの国の貨幣を別の国の異なる貨幣へ転送することを可能にする電子仲介プラットホームの一例である。

【0003】

銀行間取引市場は外国為替市場の重要部分である。銀行間取引市場はほとんどの貨幣取引が仲介される卸売市場である。銀行間又は外国為替市場は、電信メッセージサービスを置換するために１９７０年代の初めのＳＷＩＦＴ(登録商標)ネットワークの導入により電子メッセージを開発した。

【0004】

１９７３年、１５か国からの２３９の銀行が共通問題（すなわち、どのようにクロスボーダー支払いに関して安全に通信するか）を解決するために協調した。２３９の銀行はベルギーに本部を置く国際銀行間通信協会（ＳＷＩＦＴ(登録商標)：Ｓｏｃｉｅｔｙ ｆｏｒ Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｂａｎｋ Ｆｉｎａｎｃｉａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）として知られた公益事業共同体を形成した。ＳＷＩＦＴ(登録商標)は、１９７７年にそのメッセージサービスと共に立ち上がり、そのとき広く用いられていた電信技術に置き換わった。ＳＷＩＦＴ(登録商標)銀行システムは世界中の機関のための信頼可能且つ信用される銀行システムに急速になった。

【0005】

ＳＷＩＦＴ(登録商標)サービスの主構成要素は、メッセージングプラットホーム、メッセージを検証しルーティングするコンピュータシステム、及び一組のメッセージング標準規格を含む。この標準規格は、言語的境界、国及びシステムの境界を跨ぐデータの共通理解を可能にするためにそしてユーザ間で交換される通信のシームレス自動化送信、受信、及び処理を許容するために開発された。１９５５年に設立されたＨｅｒｓｔａｔｔ銀行は、１９７４年までに２０億ドイツマルク（ＤＭ）超の資産を有していた。Ｈｅｒｓｔａｔｔ銀行は外国為替市場における重要参加者になった。

【0006】

１９７３～１９７４年の間に、米ドルは著しい価格変動率を経験した。ほぼ同時期に、Ｈｅｒｓｔａｔｔ銀行は、僅かＤＭ４千４百万の資本準備金と比較してＤＭ４億７千万の損失を積んでいだ。１９７４年６月、独国規制当局はＨｅｒｓｔａｔｔ銀行を清算させた。同じ日の早い段階で、多くの銀行は、ニューヨーク市内に届けられることになっていた米ドル（ＵＳＤ）と交換にフランクフルト市内のＨｅｒｓｔａｔｔ銀行へのドイツマルクの支払いを発表した。しかし、Ｈｅｒｓｔａｔｔ銀行は１０：３０ニューヨーク時間（１６：３０独国時間）に閉鎖された。

【0007】

時差のために、Ｈｅｒｓｔａｔｔはそれぞれの支払いの時間の間に営業を中止した。その結果、ニューヨーク市内の相手方銀行はＵＳＤ支払いを受信しなかった。したがってこのタイプの決済リスク（外国為替取引における一方の当事者が、売り払った貨幣を支払うが購入した貨幣を受領しない）は時折Ｈｅｒｓｔａｔｔリスクと呼ばれる。

【0008】

Ｈｅｒｓｔａｔｔ瓦解の管轄区越え結果に応答して、Ｇ１０グループの国々は国際決済銀行（ＢＩＳ：Ｂａｎｋ ｆｏｒ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｅｔｔｌｅｍｅｎｔｓ）の後援下に常任委員会を形成した。「銀行監査に関するバーゼル委員会」と呼ばれるこの委員会は、中央銀行の代表と様々なＧ１０加盟国の規制当局とを含む。

【0009】

Ｈｅｒｓｔａｔｔ銀行の失敗は、１つの銀行と別の銀行との間の支払いがリアルタイムで実行されそして最終的であると見做されるということを保証するリアルタイムグロス決済（ＲＴＧＳ：ｒｅａｌ－ｔｉｍｅ ｇｒｏｓｓ ｓｅｔｔｌｅｍｅｎｔ）システムの世界的実装に到った主要因だった。これらの課題に関する作業は、国際決済銀行下のＢａｓｅｌ Ｃｏｍｍｉｔｔｅｅ ｏｎ Ｂａｎｋｉｎｇ Ｓｕｐｅｒｖｉｓｉｏｎによりコーディネートされた。

【0010】

連続同時外為決済（ＣＬＳ：ｃｏｎｔｉｎｕｏｕｓ ｌｉｎｋｅｄ ｓｅｔｔｌｅｍｅｎｔ）プラットホームが約３０年後の２００２年に立ち上げられた。このｐａｙｍｅｎｔ ｖｅｒｓｕｓ ｐａｙｍｅｎｔ（ＰＶＰ）プロセスは、このプロセスに伴う決済リスク（相手方が、先物取引のそれらのレッグを届ける前に失敗する又は不履行となる可能性がある）を想定すること無く会員銀行が外貨を交換することを可能にする。

【0011】

Ｈｅｒｓｔａｔｔ余波、ＣＬＳの開発、及び２００７年のグローバル金融危機にもかかわらず、ＲＴＧＳシステムは依然として相互接続されていない。その結果、これは、グローバルリアルタイム銀行間支払いが或る危険度でもって依然として取引されているということを意味する。

【0012】

Ｈｅｒｓｔａｔｔリスクは残されたままであり、そして銀行が所謂「当方及び先方勘定：ｎｏｓｔｒｏ ａｎｄ ｖｏｓｔｒｏ ａｃｃｏｕｎｔｓ」を操作することを中央銀行が解決する能力が挑戦されている。

【0013】

１９７４年の所謂Ｈｅｒｓｔａｔｔ事例を囲む事象及びその時以来の他の事象（２００７－２００９年のグローバル金融危機を含む）に続いて、銀行間又は外国為替取引を行うためのより安全、より信頼でき、且つリアルタイムな能力が求められてきた。

【0014】

現在、国際的銀行支払いが取り引きされるやり方は以下のとおりである。国際的支払いに関して、２つの銀行（例えば、伝統的当方銀行／先方銀行としての）が直接互いに決済していなければ、この取引は１つ又は複数のコルレス（ｃｏｒｒｅｓｐｏｎｄｅｎｔ）銀行を介しルーティングされる。この提携における仮定は両銀行が、対外支払いを決済するために当該（又は各）コルレス銀行との提携を有するということである。これは支払い複雑性、追加費用及び取引遅延を増し、これによりＨｅｒｓｔａｔｔリスクに起因する銀行破綻のリスクを増加する。これは実際の流動性が絶対的確実性でもって決して識別されないためである。

【0015】

支払いサイクルでは、送金先銀行（ｂｅｎｅｆｉｃｉａｒｙ ｂａｎｋ）は、顧客がそれらの銀行口座への支払いを受信する受取人銀行（ｒｅｃｉｐｉｅｎｔ ｂａｎｋ）である。仲介（ｉｎｔｅｒｍｅｄｉａｒｙ）又はコルレス銀行は、第三者銀行に対する資金の国際的振替及び決済を容易にするために送金先銀行により使用される第三者銀行である。

【0016】

仲介銀行はまた、２つの銀行間の資金の国際的振替及び決済を容易にするために使用される第三者銀行である。仲介銀行とコルレス銀行との主な違いはコルレス銀行は通常、仲介銀行より多くの種類の貨幣で取引することを選択するということである。

【0017】

コルレス銀行及び仲介銀行の両方は、国際資金振替及び取引決済を容易にするために送金先銀行と協調する第三者銀行として働く。いずれの場合も、人又は事業者は顧客が発行銀行に口座を有することを要求し；発行銀行は、異なる貨幣で資金を送金先銀行へ移動するプロセスを完了するためにコルレス又は仲介銀行を使用する。

【0018】

しかし、コルレス銀行と仲介銀行との差は一貫したものではない。この差は、口座名義人が世界中のどこに拠点を置いているかと、どの程度コルレス銀行が仲介銀行と異なるか又はコルレス銀行が或るタイプの仲介銀行として処理され得るかどうかとを含むいくつかの要因に依存する。いくつかの事例では、コルレス銀行は仲介銀行とは区別不能かもしれない。

【0019】

コルレス銀行は、別の銀行の代わりにサービスを提供し、そしてしばしば発行銀行と受取人銀行との「仲介人」の資格でサービスする。国内銀行はしばしば、発行銀行が位置する国とは異なる国において開始する又は終了される最終商取引を完了するために、異なる国内の代理人としてコルレス銀行を使用する。

【0020】

コルレス銀行は国内銀行の代わりに多くの商取引を実行し得る。商取引は、電信送金を完了すること、預託金を受諾すること、振替代行として働くこと、及び別の銀行のための文書をコーディネートすることを含む。

【0021】

仲介銀行はコルレス銀行と同様な役割を果たす。仲介銀行はまた、発行銀行（時に受取人銀行とは異なる国に位置する）と受取人銀行との間の仲介人である。

【0022】

仲介銀行は国際電信送金が２つの銀行間で行われる場合にしばしば必要とされる。仲介銀行はしばしば、確立された金融関係を互いに有しない異なる国内にある。仲介銀行は外国商取引を完了するために現金を送信するが、この商取引は１つの貨幣のためだけのものである。通常、この事例では、国内銀行は、国際振替を扱うには小さすぎるので、仲介銀行に働きかける。

【0023】

いくつかの国（例えばアメリカ合衆国及び世界のいくつかの他の部分）では、仲介銀行の特定役割とコルレス銀行の特定役割との間の線引きが時折ある。

【0024】

仲介銀行とコルレス銀行との間の１つの差は、コルレス銀行はいくつかの貨幣に関与する商取引に責任があるということである。例えば、送金を行う一方の当事者が米国を本拠としており、金をデンマーク内の当事者へ送れば、米ドルからデンマーククローネへのすべての商取引に責任を負うコルレス銀行が通常は関与する。外貨を扱うデンマーク内のコルレス銀行が受取人銀行の金を集める。

【0025】

電信送金は、現金を別の人又は事業者へ送る電子的方法であり、すべての銀行との極めて一般的商取引であるが、国際電信送金はより高価であり、実行するのがより困難である。

【0026】

オーストラリア又はＥＵ加盟国などの世界のいくつかの部分では、国際振替を扱う銀行は仲介銀行と呼ばれる。いかなる区別も仲介銀行とコルレス銀行との間でなされない。

【0027】

ほとんどの国際電信送金は国際銀行間通信協会（ＳＷＩＦＴ(登録商標)）のネットワークを介し取り扱われる。ＳＷＩＦＴ(登録商標)は１９７０年に設立された。発行銀行と受信銀行との間にいかなる仕事上の関係も無ければ、この発信銀行は、両方の金融機関と提携を有するコルレス又は仲介銀行を求めてＳＷＩＦＴ(登録商標)ネットワークを検索し得る。

【0028】

コルレス銀行は、外貨両替及び支払いを容易にするために国際的購入、販売、又は送金商取引において最も一般的に使用される。

【0029】

ＳＷＩＦＴ(登録商標)コルレス銀行は、外国における別の銀行又は金融機関のためのサービスを提供することが認可された一国内の銀行である。コルレス銀行により提供される最も一般的なサービスは両替、企業商取引及び貿易文書の処理、及び送金である。

【0030】

コルレス銀行は外国銀行と国内銀行との間の契約（代理口座（先方又は当方口座と通常は呼ばれる）が他銀行のために１つの銀行において確立される）を履行する。コルレス銀行は通常、２つの銀行が互いに相互口座を確立することに関与する。これらの相互口座は、国内銀行が外国銀行の代わりに支払い又は送金を行うことを可能にするために確立される。

【0031】

このような代理口座は、外貨両替（一国内の輸出企業と別の国内の輸入業者との間で一般的に発生するものなど）を通常は必要とする顧客のための国際金融商取引を銀行が取り扱うことを可能にする。

【0032】

先行技術
米国特許第Ｂ－１０，１４０，６５９号明細書（Ｃｈｉｃａｇｏ Ｍｅｒｃａｎｔｉｌｅ Ｅｘｃｈａｎｇｅ）は、金利スワップ（「ＩＲＳ：ｉｎｔｅｒｅｓｔ ｒａｔｅ ｓｗａｐ」）のための電子商取引システムの効率を、ＩＲＳ契約が基準貨幣で資金供給される一方で関連キャッシュフローは基準貨幣とは異なる現地貨幣で建てられることを可能にすることにより改善するシステムについて説明している。このシステムは、キャッシュフローが相殺決済されることを保証し、これにより、移動されるために必要とされる資金の大きさを最小化し、したがって取引システムにより処理される商取引の数を低減する。

【0033】

前述のシステムは、両替のいくつかのエリアにおけるＨｅｒｓｔａｔｔリスクを既存銀行ネットワークを越えて低減するシステムを提供するという点で有用であるが所謂チャレンジャー銀行（その１つはピア・ツー・ピア銀行と呼ばれる）の成長市場に対処しない。

【0034】

２０１０年頃から、インターネットベース銀行（ピア・ツー・ピア（Ｐ２Ｐ：ｐｅｅｒ－ｔｏ－ｐｅｅｒ）銀行と呼ばれる）の新しい波が出現し始めた。これらの外貨両替サービスはそれらの料金を切り詰めることにより伝統的銀行を脅かしているので、いくつかの市場において益々優勢なっている。

【0035】

オンラインＰ２Ｐプラットホームを通して、個人は、他国内の個人を見つけ出し、そして伝統的銀行が課金してきた費用よりさらに低い費用で貨幣を安全に交換し得る。ほとんどのオンラインＰ２Ｐ会社は、国際為替及び振替料に関し最大９０の％費用節約を顧客に提供することを主張する。

【0036】

銀行及び仲買人は通常、振替料だけでなく振替えられた合計金額に関して数％を課金する。ＣｕｒｒｅｎｃｙＦａｉｒ（商標）、Ｋａｎｔｏｘ（商標）及びＴｒａｎｓｆｅｒＷｉｓｅ（商標）などのＰ２Ｐ貨幣交換会社は、ユーザが口座にオンラインで登録しそしてそれへお金を預けることを可能にする。特定Ｐ２Ｐ銀行に依存して、ユーザは自身の選択する為替レートに関する所与の為替レート又は入札を受諾し得る。ユーザが受諾可能レートを識別すると、Ｐ２Ｐプラットホームは、自発的買い手との整合性を識別し、そして資金を一方から他方へ転送する。資金は通常、国内送金により買い手の銀行口座内に一日程度内に送金される（決済される）。

【0037】

これらのタイプの口座資金を使用することは、発生国から決して実際には離れないが、その代りにユーザ間で単純に交換される。ユーザは、お金を別の国内の任意の人、企業口座、又はさらには自身の口座へ送信し得る。

【0038】

Ｐ２Ｐプロバイダは、一方の側に不足があれば又は良好な両替整合性が無ければ流動性を提供することにすら介入し得る。このような状況では、Ｐ２Ｐプラットホームは通常、追加料金又は取扱手数料を徴収し得る。例えば、好適な貨幣整合性がなければ、１つのＰ２Ｐプラットホームは、商取引の０．５％を課金し、そしてそれ自身の資金を使用することにより交換を行う。これは、標準的ピア・ツー・ピア整合性の典型的０．３５％より若干大きい。

【0039】

別のＰ２Ｐプラットホームは、このような状況において１．５％の定額料を課金するだけでなく、同Ｐ２Ｐプラットホームが送るプリペイド式クレジットカードを介した送金の選択肢を、旅行者及び観光客にアピールするユーザへ提供する。

【0040】

Ｐ２Ｐ外貨両替は依然として比較的新しいが、ドル、ポンド、ユーロ及び円のような共通貨幣を変更するのに最も好都合であり、受容及び人気度が増加している。運営するプラットホームは様々な国々内の個々のユーザ同士を接続することに依存するので、少額貨幣のユーザは良好な対応整合性を直ちに見出さないかもしれない。また、いくつかの国々内の貨幣ユーザはいくつかのプラットホームがそれらの現地貨幣での商取引を未だ行っていないということに気付き得る。

【0041】

Ｐ２Ｐ外貨転送の魅力的な特徴はその費用節約である。銀行及び仲買人を避けることにより、これらのプラットホームはさらに低いレートで且つ正規ユーザのために両替を提供するので、現在課金される料金が商取引の２％～５％であり得るほとんどの銀行と比較して既存国際的振替を越えるかなりの節約があり得る。したがって、これらのＰ２Ｐプラットホームが成長しそしてより人気がでてきているということは驚きではない。

【0042】

また、伝統的銀行とは異なり、ユーザは、任意の場所から任意の時点にオンラインＰ２Ｐ口座にアクセスし得る。オンラインＰ２Ｐ口座は少額及び高額両方に使用するのが容易であり且つ商取引は速やかに清算されるが、いくつかの口座は保証された同日又は翌日振替のための付加料金を要求する。

【0043】

最近、Ｐ２Ｐ外貨両替は今やそのサービスをビジネスへ提供している。したがって、ピア・ツー・ピア貨幣交換は２００５年にはほとんど存在していなかったということを考えれば、これらの新しい銀行は今や著しい貨幣総額を取り引きし始めている。最近、Ｐ２Ｐｅｘｃｈａｎｇｅ ＣｕｒｒｅｎｃｙＦａｉｒ（商標）は約￡１５億で取り扱われる資金の現在勘定を２０１５年１月に報告した。

【0044】

多くのＰ２Ｐ外貨両替会社は英国を本拠とするか又は英国内に登録事務所を有するかのいずれかである。登録された金銭サービス業として、彼らは英国歳入税関庁（ＨＭＲＣ：ＵＫ ｇｏｖｅｒｎｍｅｎｔ ｒｅｖｅｎｕｅ ａｎｄ ｃｕｓｔｏｍｓ）により管理されており、そして様々な厳しい規則に従い、遵守し、適合しなければならない。

【0045】

英国金融行動庁（ＦＣＡ：ｆｉｎａｎｃｉａｌ ｃｏｎｄｕｃｔ ａｕｔｈｏｒｉｔｙ）内には、次の２つのカテゴリがある：登録（より小さな）会社及び認定（より大きな）会社。認定会社は、リングフェンスとして知られたプロセスにおいて各日の終了時点の自身の金から顧客の金を分離しなければならない。これは、顧客のためのより良いセキュリティを提供し、そして万一の銀行破綻又は会社債務不履行時に金を回収するより高い機会を提供する。

【0046】

会社は、それぞれの国の銀行部門により送金業者として免許を受ており、したがって反マネーローンダリング（ＡＭＬ：ａｎｔｉ－ｍｏｎｅｙ ｌａｕｎｄｅｒｉｎｇ）政策に従わなければならない。いくつかの会社は２つ以上の国により規制される。例えば、ＣｕｒｒｅｎｃｙＦａｉｒ（商標）は、オーストラリアを本拠としており、そしてオーストラリア証券投資委員会（ＡＳＩＣ：Ａｕｓｔｒａｌｉａｎ Ｓｅｃｕｒｉｔｉｅｓ ａｎｄ Ｉｎｖｅｓｔｍｅｎｔ Ｃｏｍｍｉｓｓｉｏｎ）により規制される。ＣｕｒｒｅｎｃｙＦａｉｒ（商標）はまた、アイルランド内に登録事務所を有しており、アイルランド共和国の中央銀行により規制される。

【0047】

米国では、米国財務省の金融犯罪取締ネットワーク（ＦＩＮＣＥＮ：Ｆｉｎａｎｃｉａｌ Ｃｒｉｍｅｓ Ｅｎｆｏｒｃｅｍｅｎｔ Ｎｅｔｗｏｒｋ）がＰ２Ｐ両替会社を監督する。

【0048】

より高い商取引高及び資金を転送する会社はより大きな顧客流動性を有する傾向がある。これは、これらの会社がより良いレート、より迅速な変換、そしてより円滑な振替を提供することを可能にする。このようなより大きな会社は広範囲の貨幣をますます提供することになる。

【0049】

規制要件のために、Ｐ２Ｐ会社は顧客資金を共通口座ではなく分離口座内に維持することを要求される。会社が財政難であれば、分離口座だけが保護を提示する。しかし、流動性が、商取引地位をバランスさせるために国同士間で転送されれば、資金を急いで回収する能力は消え得る。したがって、これらの比較的新しい銀行会社がＨｅｒｓｔａｔｔリスクに晒される可能性がある。

【0050】

Ｐ２Ｐ交換は規制銀行より高リスクであるので、Ｐ２Ｐ交換は、金融規制当局がピア・ツー・ピア交換を介し取り引きされる増加する量の資金を考慮又は監査することができないので成長リスクと金融規制当局が知らないリスクとを提示する。その結果、破綻又は大きな不履行が発生した場合に別の金融危機がトリガされるリスクがある。

【0051】

本発明の目的は、国境を跨ぎ且つリアルタイムで動作するシステムを提供することである。

【0052】

本発明の別の目的は、資金の存在を保証し且つ資金が転送されることを確実にし、これにより銀行がＨｅｒｓｔａｔｔリスクに晒されるリスクを低減するシステムを提供することである。

【発明の概要】

【課題を解決するための手段】

【0053】

本発明の第１の態様によると、第１の貨幣の資金を第１の場所における第１の（送信）銀行口座から第２の場所における第２の（受取人）銀行口座へ転送するように作動可能であるセキュア送金システムと共に使用するためのコンピュータ実施方法が提供され、ここでは、
第１の処理手段は、或る金額が転送される第１の口座内の資金の合計を識別し；
プロトコルバッファは、転送される資金の合計に関するブロックコードを生成し；
メモリは、第１の送信銀行口座の資金の合計及びユニーク口座識別子を識別するデータを含むブロックコードを格納し；
通信デバイスは、資金の合計が転送される受取人銀行における受取人口座とのセキュア通信チャネルを確立し；
ローカル送信プロトコルバッファはセキュア通信チャネルを介しブロックコードをリモート受取人プロトコルバッファへ送信し；
リモート受取人プロトコルバッファは、ブロックコードを受信し、そしてこれを、送信銀行口座から導出された口座データ及び流動性査証を受取人銀行口座へ中継する双方向同期装置へ送信し；
同期装置は送信銀行口座と受信銀行口座とを同期させ、これによりその間の直接的高速接続を確立し；
同期装置から認可信号を受信すると、第２の処理手段は、ここから資金の合計が転送される第１の口座内の資金の合計を識別しリングフェンスするように作動可能であり；
ブロックコード内の識別される資金の合計がリングフェンスされた資金の合計に対応する場合、認定ユーザ（口座名義人）は所定期間の間商取引選択肢を提示され；
商取引選択肢の受諾を確認する認定ユーザ（口座名義人）からの入力を受信すると、双方向取り消し不能認証事象を確立し、これにより資金が転送されることを可能にするための相互協定が受取人銀行口座と送信銀行口座との間で確立される。

【0054】

本発明の第２の態様によると、第１の貨幣の資金を第１の場所における第１の（送信）銀行口座から第２の場所における第２の（受取人）銀行口座へ転送するように作動可能であるセキュア送金を処理するためのシステムが提供され、ここでは、
第１の処理手段は、或る金額が転送される第１の口座内の資金の合計を識別し；
プロトコルバッファは、転送される資金の合計に関するブロックコードを生成し；
メモリは、第１の送信銀行口座の資金の合計及びユニーク口座識別子を識別するデータを含むブロックコードを格納し；
通信デバイスは、資金の合計が転送される受取人銀行における受取人口座とのセキュア通信チャネルを確立し；
ローカル送信プロトコルバッファはセキュア通信チャネルを介しブロックコードをリモート受取人プロトコルバッファへ送信し；
リモート受取人プロトコルバッファは、ブロックコードを受信し、そしてこれを送信銀行口座から導出された口座データ及び流動性査証を受取人銀行口座へ中継する双方向同期装置へ送信し；
同期装置は送信銀行口座と受信銀行口座とを同期させ、これによりその間の直接的高速接続を確立し；
同期装置から認可信号を受信すると、第２の処理手段は、ここから資金の合計が転送される第１の口座内の資金の合計を識別しリングフェンスするように作動可能であり；
ブロックコード内の識別される資金の合計がリングフェンスされた資金の合計に対応する場合、認定ユーザ（口座名義人）は所定期間の間商取引選択肢を提示され；
商取引選択肢の受諾を確認する認定ユーザ（口座名義人）からの入力を受信すると、双方向取り消し不能認証事象を確立し、これにより資金が転送されることを可能にするための相互協定が受取人銀行口座と送信銀行口座との間で確立される。

【0055】

したがって、銀行Ａの顧客が別の国の銀行Ｂの顧客へ支払うことを望めば、銀行Ｂは銀行Ａが支払い能力がありそして商取引責任を瞬時に満たすために振替に利用可能な流動性を有するということが保証されるということが決定的に重要である。支払いを、瞬間的なものにし且つ保証された流動性に反するようにすることにより、相殺並びに長期決済リスクは完全に除去される。

【0056】

銀行間でリングフェンスされた保証された資金に基づく固定料が事業者により課金され得る。

【0057】

本発明の利点は本発明が、送信待ち時間を最小化し、そして送信銀行及び受取人銀行両銀行内の資金（流動性）について知っているということである。これは結果的にＨｅｒｓｔａｔｔリスクを除去する。

【0058】

したがって、本発明は、単純な銀行間メッセージング及びそれに伴う固有遅延関連メッセージングを使用するのではなく国境を跨いで且つリアルタイムで動作しそして流動性ポジションを検証する銀行間システムを提供する。

【0059】

本発明は資金の合計をリングフェンスするので、認定ユーザ（口座名義人）は、送信銀行が検証可能合計金額を確実に届けることができるので商取引選択肢を確実に所定期間の間提示される。

【0060】

商取引事象に先立って資金を識別し、検証し、そして効果的にリングフェンスする資金の所謂「流動性ブロック」の確立が、資金の存在を保証し、そして国境を跨ぎそして複数の貨幣での資金の移動の後続のログ記録及び報告をリアルタイムに可能にする。

【0061】

好適には、第２の受取人銀行口座へ支払われる資金は第１の貨幣とは異なる貨幣で支払われる。

【0062】

いくつかの実施形態では、送信は、暗号化エンジンを使用することによりプロトコルバッファへ及び／又はプロトコルバッファからなされる。理想的には、暗号化エンジンは公開／秘密キー暗号化システム及び／又は暗号化アルゴリズム（例えばＲＳＡ暗号化アルゴリズムなど）にしたがって動作する。

【0063】

銀行のユニーク口座識別子は通常は以下のものを含むグループである：口座番号及び銀行分類コード；銀行識別子コード（ＢＩＣ：ｂａｎｋ ｉｄｅｎｔｉｆｉｅｒ ｃｏｄｅ）；国際銀行口座番号（ＩＢＡＮ：ｉｎｔｅｒｎａｔｉｏｎａｌ ｂａｎｋ ａｃｃｏｕｎｔ ｎｕｍｂｅｒ）；及び国識別コード番号。口座はまた、口座名義人の識別子から導出され得る（通常は分散型識別子（ＤＩＤ：ｄｅｃｅｎｔｒａｌｉｓｅｄ ｉｄｅｎｔｉｔｙ）を介し）。

【0064】

好ましい実施態様では、ユーザ（口座名義人）は商取引選択肢を所定期間の間提示される。これは、ユーザに考えが変わる機会を与え、そして散漫が商取引キャンセル無く発生し得る時間間隔（通常は最大３０秒、好適には最大２０秒）を許容する。

【0065】

ユーザ（口座名義人）が所定期間内に提示された商取引選択肢を受諾しない状況では、提示の再計算は、更新された流動性査証を送信銀行口座から取得することにより導出される。商取引選択肢は理想的には、第２の場所における第２の（受取人）銀行により認識される選択可能貨幣でユーザへ提示される。

【0066】

いくつかの実施形態では、商取引の受諾を確認する入力信号（ユーザ（口座名義人）からの認可命令を含む）を受信すると、第１の（送信）銀行口座から転送される資金はリングフェンスされる。

【0067】

理想的には、プロセッサが、リングフェンスされた資金の合計に基づき得る少なくとも１つの決済課金を判断するように作動可能である。理想的には、プロセッサはまた、送信及び／又は受信銀行により適用される流動性ブロックの値に基づき商取引課金を判断するように作動可能である。他の実施形態では、プロセッサは流動性ブロックの値を銀行間リスク要因に基づき判断する。

【0068】

理想的には、プロプライアタリ支払いシステムをセキュア通信チャネルへ接続するための少なくとも１つのゲートウェイ（ＴＣＰ／ＩＰルーティングプロトコルゲートウェイ；仮想私設ネットワーク（ＶＰＮ）、リモートプロトコルバッファ、ウェブソケット及びＳＷＩＦＴ(登録商標)支払いネットワークを含み得る）が確立される。

【0069】

任意に、商取引事象に関係するデータが、任意にリアルタイムで取り込まれるデータベース又はデータレイク構成内に格納される。データベースが、プロトコルバッファから双方向同期装置への又は双方向同期装置からプロトコルバッファへの通信をログ記録し得る。

【0070】

任意に、ユーザにより可視であるディスプレイへメニューを届けるように構成されるとともにそしてここからユーザ命令が通信ネットワークへ送信されるウェブベースポータルが提供される。別の実施形態では、モバイル送金が本発明にしたがって行われることを可能にするソフトウェアの制御下で作動可能であるモバイルデバイス、タブレット又はラップトップへ特殊用途ソフトウェア（ＡＰＰ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｓｏｆｔｗａｒｅ）が供給される。

【0071】

貨幣整合のための施設が、少なくとも１つの参加銀行及び指定貨幣を識別するルーティングエンジンにより任意に実現される。

【0072】

いくつかの実施形態では、参加銀行は、プロトコルバッファ構成要素間のポイント・ツー・ポイント暗号化及び通信ネットワークを採用する。プロトコルバッファは、内部通信データを公開又はプロプライアタリネットワークへ転送する暗号化オフローディングシーケンスにしたがって動作する（暗号化された秘密インフラストラクチャ上で動作する）ように構成され得る。

【0073】

任意に、プロトコルバッファ群とプロトコルバッファと双方向同期装置との間の通信に関係するデータを含む格納されたデータの監査ログが取得される。

【0074】

データのエッジ暗号化が通信シーケンス内の任意の時点で行われ得る。

【0075】

複製、共有、及び同期されたデジタルデータのコンセンサスの分散型デジタル台帳がシステム内に取り込まれそしてシステムにより信頼され得るということがさらに理解される。分散台帳は通常、多くの独立サイト、及び／又は様々な国々、及び／又は独立機関にわたって地理的に分散される。このような分散デジタル台帳は、しばしば「ブロックチェーン」と呼ばれており、そして商取引又はデジタル相互作用を記録するために依存され得、そしてユーザ及び商取引を認証及び検証することによりビジネスに対する透明性及びセキュリティを確実にし得る。

【0076】

本方法の前述の好ましい又は任意の特徴は、所望により、そして当業者により規定される要件にしたがってシステムに含まれ得るということが理解される。

【0077】

同様に、参照されるシステムの態様及び構成要素は１つ又は複数の方法請求項に含まれ得る。

【0078】

変形が、モバイル電話、タブレット又はラップトップなどのモバイル電子デバイス上へダウンロード可能である特定用途ソフトウェア（ＡＰＰの形式の）を提供し、そして前述のシステムと通信しその一部として動作しこれによりユーザが資金を所望口座へ安全に転送することを可能にするために前述のモバイル電話、タブレット又はラップトップを構成するようにすることにより本発明に対しなされ得る。

【0079】

本システムは、ソフトウェアにしたがって作動可能でありそしてシステムと通信するように構成されるディスプレイを含むモバイル電話、タブレット又はラップトップを含み得るということが理解される。

【0080】

理想的には、モバイル電話、タブレット又はラップトップは、認定ユーザ（口座名義人）からの入力を提供して商取引の受諾を確認するために同ユーザにより作動可能である生体測定デバイスを有する。

【0081】

本発明の好ましい実施形態について、一例として、以下の添付図面を参照し次に説明する。

【図面の簡単な説明】

【0082】

【図1】コルレス銀行業務の典型的例のダイアグラム表示を示す；

【図2】１つの国の銀行の顧客が、別の国の供給業者から購入される製品の代金を支払う必要がある例を示す。

【図3】他の参加銀行の代わりに流動性口座を保持する銀行が、同口座がＲＴＧＳグローバネットワークの好適な実施形態と同期して維持されることを確実にするためにどのように働くかを示す。

【図4】どのように本発明が、識別された流動性要件をＲＴＧＳグローバルプラットホーム上で渡されることを可能にするかそしてどのように流動性が二次銀行によりブロック／ロックされるかの例を示す。

【図5】どのように本発明が送信銀行及び受理銀行の両方において商取引を完了するために要求される必要流動性をロックするかそしてどのように状態メッセージがネットワーク上で中継されるかを示す。

【図6】中央銀行へ直接接続される参加銀行と特定管轄区内のローカル支払いシステムとの例を示す。

【図7】中央銀行の役割とそしてどのように中央銀行がＲＴＧＳグローバルシステムの好適な実施形態において動作するかとを図式的に示す。

【図8】ＲＴＧＳグローバルシステム内のコルレス銀行業務モデルの例を描写する。

【図9】ＲＴＧＳグローバネットワークセキュリティシステムの一例の全体ダイアグラム図を示す。

【図10-12】その会員資格が英国管轄区（不換貨幣ＧＢＰ）内にある第１の参加銀行及び欧州銀行からの支払いに関与する一連の商取引のダイアグラム表現を示す。

【図13】どのようにＲＴＧＳグローバネットワークが参加銀行のネットワーク全体にわたる不換貨幣での流動性を獲得するために参加者のために使用されるかを示すダイアグラム表現である。

【発明を実施するための形態】

【0083】

本発明をより良く理解するように、図１を参照して、どのようにＳＷＩＦＴ(登録商標)支払いなどのコルレス銀行業務がなされるかを示す例が説明される。チェーン内のコルレス銀行の数は管轄区に依存して広範に変わり得る。図１では２か国だけが示されるが、対応銀行業務の多くの例では、複数の国が、商取引を完了しそして最終払いを確実にするために関与し得る。

【0084】

図１において、資金が引き出されている口座から資金１０１を送信している銀行が示される。プロプライアタリＳＷＩＦＴ(登録商標)フォーマットメッセージ１０２が送金先銀行１０３へ送信される。これは送信銀行口座１０１に課金される。

【0085】

送金先銀行１０３は、支払明細書だけでなく必要な流動性（資金）がコルレス銀行１０７、１０８において受信されたという確認も含むメッセージ（ＭＴ１０３）を受信する。コルレス銀行１０７、１０８はまた、関連ローカル管轄区内のローカル貨幣でオンワード支払いを行う。通常、これらの最終レグ支払いは、個々の発注ベースの決済支払いの連続性を確実にする従来のリアルタイムグロス決済（ＲＴＧＳ）プラットホーム又はローカル支払いシステムにより行われる。

【0086】

プロプライアタリＳＷＩＦＴ(登録商標)メッセージ１０４が送信銀行のコルレス銀行１０５へ送信される。これは「カバー・オブ・ペイメント：ｃｏｖｅｒ ｏｆ ｐａｙｍｅｎｔ」と時折呼ばれる（ＭＴ２０２ＣＯＶ）。メッセージ課金は通常、カバー・オブ・ペイメントメッセージのために送信銀行に課される。

【0087】

送信銀行コルレス銀行１０５は、カバー・オブ・ペイメントメッセージを受信し、商取引を処理する。残高調整が完了され、支払い１０６が処理される。カバー・オブ・ペイメント・メッセージ（ＭＴ２０２ＣＯＶ）は送金先コルレス銀行１０７へ再送信される。送信コルレス銀行はＳＷＩＦＴ(登録商標)メッセージに関し課金される。

【0088】

カバー・オブ・ペイメント・メッセージはプロセッサにより受信され処理される（１０７）。この時点で、必要な残高調整が行われ、そして流動性（受信された資金）の確認が次に送金先銀行口座へ送信される（１０３）。

【0089】

追加のＭＴ２０２ＣＯＶメッセージ１０８が送金先銀行１０３へ送信される、又は流動性が受信されたことを確認するプロプライアタリＳＷＩＦＴ(登録商標)メッセージＭＴ９１０が送信される。送金先コルレス銀行１０７はこのプロプライアタリＳＷＩＦＴ(登録商標)メッセージＭＴ９１０に関して課金される。

【0090】

図２を参照すると、第１の場所の国１において外国へ送金するために既存送金サービスを使用する人２０１が示される。人２０１は、上述のように一種のＰ２ＰサービスであるＴｒａｎｓｆｅｒＷｉｓｅ（商標）などの外国為替（ＦＸ）サービスのプロバイダに対し支払いを行う。

【0091】

例えば、メアリーが、一年間パリで働きそしてユーロを稼ぐアメリカ人であると仮定する。彼女は、ユーロをドルへ変換し、そして彼女のアメリカの住宅ローンを支払うためにこのドルを自身のアメリカ銀行口座に入れる必要がある。一方、ロサンジェルスを本拠とするジョンは、フランスで勉学している息子へ送信するためにドルをユーロへ変換したい。銀行へ行く代わりに、メアリーとジョンはＰ２Ｐ両替ウェブサイト上で口座の契約を交わす。彼らのそれぞれのＰ２Ｐ口座は匿名にもかかわらず整合される。

【0092】

メアリーはユーロを自身のＰ２Ｐ口座内へ預け、そしてジョンはドルを自身の口座内へ預ける。Ｐ２Ｐウェブサイトは、どれだけのドル又はユーロをメアリー及びジョンがこの振替に関し受信することになるかを彼らに示し、そして彼らはそれぞれこの振替を確認する。決済上、Ｐ２Ｐ両替サービスはジョンのドルをメアリーのアメリカの銀行口座内へ転送し、そして同時にメアリーのユーロはフランス内のジョンの息子へ転送されることになる。

【0093】

支払い２０２はサービス業銀行口座を提供する企業内へ行われる。資金２０３はローカル不換貨幣で同企業銀行口座内に預けられる。企業銀行２０４は資金を保持する責任がある。クロスボーダー支払いを受信することを待っている顧客２０５が、資金をローカル不換貨幣で受け取る。

【0094】

支払い２０６は、企業２０４（サービスプロバイダ）からクロスボーダー支払いを受信することを待つ顧客２０５へ行われる。支払いは銀行２０４により保持される企業銀行口座から行われる。これは本質的に、ローカル管轄区がクロスボーダー支払いの準備ができているので顧客により受領される資金である。したがって、人２０１により引き出された預金は、２０５への不換貨幣支払いを果たすために部分的に又は完全に使用される。

【0095】

外国へ送金するためにサービスを使用している第２の管轄区内の顧客２０７はＴｒａｎｓｆｅｒＷｉｓｅ（商標）などの外国為替サービスのプロバイダへの支払いを行う。

【0096】

支払い２０２は、サービス業銀行口座２１１を提供している企業内へ行われる。クロスボーダー支払いを受信することを待っている顧客２０９は、資金をローカル不換貨幣で受け取る。したがって、支払い２１０は国境を跨いで企業（サービスプロバイダ）から顧客へ行われる。

【0097】

支払いは、プロバイダの銀行２１１により保持される企業銀行口座から行われる。したがって、預金２０７が、引き出され、そして受取人２０９への不換貨幣支払いを果たすために部分的に又は完全に使用される。プロバイダの銀行口座２１１は通常は第２の管轄区内に位置する。

【0098】

次に図３～図９を参照すると、Ｈｅｒｓｔａｔｔリスクをなくために資金の瞬間的調停を可能にするためにすべての参加当事者のすべての関連資金の可視性により連続的にリアルタイムで作動可能である本発明の好適な実施形態が示される。

【0099】

次に図３を参照すると、参加銀行３０１及びＲＴＧＳグローバルプラットホーム３０２を含むシステムが示される。本システムは、ネットワーク内の他の参加銀行の代わりに流動性口座を保持する参加銀行（第１又は第２のいずれか）を有効にする。本発明のこの特徴は、これらの口座がＲＴＧＳグローバネットワークと同期して維持されるということを確実にする。

【0100】

不換貨幣の流動性プール３０３が、その代わりに参加銀行３０１及び他のＲＴＧＳグローバル参加銀行により制御され操作される。これらは、ＲＴＧＳグローバル運用約款に沿って分離口座と呼ばれる。

【0101】

ＲＴＧＳグローバルプロトコルバッファ構成要素３０４は、リアルタイムデータが流動性プールから取得されることとＲＴＧＳグローバルプラットホーム内のリモート受取人１０５へリアルタイムで送信されることとを可能にする。受取人プロトコルバッファ構成要素３０５が、送信バッファ３０４から流動性のリアルタイムデータフィードを受信する。流動性の同期されたデータ投影３０６が参加銀行から取得される。

【0102】

本発明は、グローバル銀行間ネットワークを使用することにより銀行間の商取引を安全にし、認証し、そしてそれに対する取り消し不能性を提供するために流動性ブロック及びロックの使用に依存する。

【0103】

図４に示す例では、銀行Ａ（英国の銀行）は、ヨーロッパを本拠とする銀行Ｂに銀行Ａが振替を行うためにユーロを獲得したいということを助言する。

【0104】

図４は、どのようにＲＴＧＳグローバルプラットホーム及びネットワークが二次銀行をブロック／ロックするかを示す。必要流動性は両方の銀行においてロックされる。流動性ロックは、銀行Ａにおいて実行され、１ブロックとして銀行ＡからＲＴＧＳグローバルプラットホームへ中継される。

【0105】

次に、ＲＴＧＳグローバルプラットホームは、銀行Ｂ内の必要流動性をロックするロックを銀行Ａ内の口座の同期投影に対し適用する。ロックは、今や完了しており、提案された商取引に関して適用される。これは、銀行Ａが、無債務且つリングフェンスされたＧＢＰ資金により流動性であり、したがってリスク無しにそれらからのユーロを獲得することができるということを銀行Ｂに確認する。ユーロ貨幣レートは、ＲＴＧＳグローバネットワーク内へのその参加の一部として銀行Ｂにより既に設定されており、そして市場データに基づきＲＴＧＳグローバルプラットホーム内へ構成され、そして任意の料金が支払われるべきである。この情報は、流動性ロックを確立するユニークメッセージへ追加された。

【0106】

次に図４を参照すると、参加銀行４０１が受取人銀行４１２へ支払いを送信しようとするＲＴＧＳグローバルプラットホーム４０１が示される。流動性プール４０２は、参加銀行４０１の管轄区内の他の参加銀行（受取人銀行４１２を含む）の参加銀行内に表される。

【0107】

受信参加銀行へ送信される資金の不換貨幣表現が４０３として示される。この量は、どれだけの量の資金が最終送金先銀行４１２により受信されるべきかを設定する送信者に基づく。この量は、貨幣同士を整合すること（４０８）により計算され、そして「売り」レートは受取人銀行４１２により設定される。

【0108】

料金はまた、送信銀行が商取引を完了するために正しい量の流動性資金をリングフェンスしブロックするように適用される。このプロセスは、自動的に発生し、そして４０２、４０５においてプロトコルバッファを介しリアルタイムに同期する送信銀行４０１の資金をリアルタイムでロックする。次に、流動性ブロックは、４０７の形で４０６へリアルタイムで同期的に適用される。

【0109】

次に、流動性ブロックは、受取人銀行が商取引を完了するために送信銀行へ売る不換最終目的貨幣の４１０の形式で４０９で受取人銀行へ適用される。これらの格納はリアルタイムで発生する。これは、４１１において第１のプロトコルバッファを介し流動性ブロックデータを送信し、そしてその後受取人銀行のプロトコルバッファ４１３へ送信することにより受取人銀行システムと同期される。次に、受取人銀行は、商取引がリアルタイムで保証されるようにその流動性へ適用される流動性ロックを有する。

【0110】

特定管轄区内の１つ又は複数の参加銀行により保持される流動性プール４０６の存在は、為替レートが外国為替流動性ロックサービス４０８によりロックされるとクロスボーダー支払いを容易にするために必要な流動性要件４０７を満たすために利用可能な十分な流動性があるということを保証する。

【0111】

外国為替流動性ロックサービス４０８は、予め構成された参加銀行レートを採用し、これをクロスボーダー商取引へ適用する。レートが送信参加銀行４０１により選択されると、これは、時間ロックされ、そして要求される流動性計算が完了されそして流動性ロックが導入されることを可能にする。

【0112】

次に、流動性ロックは参加銀行４０１、４１２の両方へ流れる。４０７、４１０においてＲＴＧＳグローバルとロックされると、流動性（利用可能残高）は流動性のＲＴＧＳグローバル予測内で減少され、発生する他の商取引の精確な流動性を保証する。同じ通知が参加銀行内で実行される。

【0113】

送信参加銀行における流動性プールの予測の表現が４０９において示され、そして商取引を容易にするためにロックされなければならない必要流動性の表現が４１０として示される。資金は今や、ロック済み流動性（ｌｏｃｋｅｄ ｌｉｑｕｉｄｉｔｙ）と呼ばれる。

【0114】

ＲＴＧＳグローバルプロトコルバッファ構成要素４０４、４０５は参加銀行４０１との同期を確実にする。第２の参加銀行４１２が管轄区内の商取引を容易にする。ＲＴＧＳグローバルプロトコルバッファ構成要素４１１、４１３は、参加銀行４１２がまたＲＴＧＳグローバルプラットホームと同期状態にあるということを保証する。そうする際、銀行４０１、４１２の両方及びＲＴＧＳグローバルプラットホームは同期状態のままであり、流動性ロックは所定時間間隔の間同期状態に維持される。

【0115】

銀行４０１の顧客が商取引を認定すると、同時に、参加銀行４０１における流動性口座はＧＢＰ値が低下し、そして受取人銀行４１２におけるユーロでの流動性口座は銀行４０１に関し増加する。これらの動きの両方は、リアルタイムでそして所定貨幣で発生する。

【0116】

これらの動きはまた、先方及び当方口座構造で反映されており、参加銀行４１２が今や、その商取引のＧＢＰ値を送信銀行４０１内に保持しており、そして銀行４０１の代わりに対応ユーロ値をその国内の国内支払いレール上でその顧客へ支払ったということを確実にする。受取人銀行４１２は、資金を国内支払いレール上で支払う前に必要なユーロ合計額だけ送信銀行の当方ユーロ口座に払い戻す。

【0117】

この商取引を完了するための時間は８秒未満、そしてＲＴＧＳプラットホーム内で費やされる予想時間は２秒未満でなければならない。これは、例えばＶＩＳＡ（商標）又はＭａｓｔｅｒＣａｒｄ（商標）を使用する既存国際電子的ポイントオブセール商取引に等しい。

【0118】

図５は、ＲＴＧＳグローバルプラットホーム５００の別の実施形態と、どのようにシステムが送信銀行及び受信銀行の両方において商取引を完了するために要求される必要流動性をロックするかだけではなくどのように送信銀行が次に、商取引を受諾し完了する要求を処理するかも示すダイアグラムである。この例における参加銀行５０１は支払いを５１２へ送信しようしている。

【0119】

流動性プール５０２は当該管轄区内の他の参加者の参加銀行内に表される。不換貨幣は、受信参加銀行５１２へ送信される資金５０３として表される。ＲＴＧＳのグローバルＦＸレートロックサービス５０８の通知が実行されるものとして示される。

【0120】

ＲＴＧＳグローバルプロトコルバッファ構成要素５０４及びその受取人５０５は、ＲＴＧＳグローバルプラットホームとのリアルタイム同期を可能にする。ＲＴＧＳグローバルプロトコルバッファ構成要素はまた、ＲＴＧＳグローバルプラットホームと参加銀行との間のリアルタイム同期を保証する。

【0121】

図５では、特定管轄区内の参加銀行により保持される流動性プールの表現が示される。必要な流動性要件５０７が、外国為替レートロックサービス５０８が適用された後のクロスボーダー支払いを容易にするために照査される。

【0122】

外国為替レートロックサービス５０８は事前構成済み参加銀行５１２が、参加銀行５０１において開始されたクロスボーダー商取引へ適用するレートを与えられるということを照査する。多くの受取人銀行が送信銀行５０１に利用可能かもしれないが、この図解では、ただ１つの受取人銀行が商取引５１２を完了するのに必要な流動性を提供するとして示される。

【0123】

レートが送信参加銀行５０１により選択されると、商取引に関係するレート及びデータが、プロセッサ５０８により時間ロックされ、そしてＲＴＧＳグローバルプラットホーム全体にわたって適用される。これは、任意の要求される流動性計算が完了されることと、流動性ロックが当事者、資金の合計及びレートに関し導入されることとを可能にする。

【0124】

流動性ロックが導入されたということを指示するメッセージが次に参加銀行５０１、５１２の両方へ送信される。ＲＴＧＳグローバルシステム５００を使用することによりロックされると、流動性利用可能残高が両銀行の流動性のＲＴＧＳグローバル予測内で減少される。これは、発生する他の商取引の流動性を記録が精確に表すということを保証する。

【0125】

これらの記録は、多くの独立サイトにわたって、及び／又は様々な国々内に、及び／又は独立機関内に理想的に分散され、そしてしばしば「ブロックチェーン」と呼ばれる分散台帳へ取り込まれ得る又はこれを含み得る。したがって、「ブロックチェーン」は、商取引の流動性ロックと両管轄区上の商取引を完了するために要求される既知の流動性とを記録する。

【0126】

再び図５を参照すると、同じ通知メッセージが参加銀行５０１、５１２内で実行され、そして送信参加銀行における流動性プールの予測の表現が５１０に示される。商取引を容易にするためにロックされなければならない必要流動性の表現５０９はここではロック済み流動性と呼ばれる。

【0127】

ＲＴＧＳグローバルプロトコルバッファ構成要素５１１、５１３もまた、参加銀行５１２との同期と、参加銀行が、当該管轄区内の商取引を容易にすることができ、そしてそうするように要請されるとそのようにすることになるということとを保証する。

【0128】

ＲＴＧＳグローバルプロトコルバッファ構成要素５１３は、参加銀行５１２とＲＴＧＳグローバルプラットホーム５００とを互いに同期状態に維持し、これにより特定管轄区内の参加者の流動性プールの真の表現が存在することを保証する。

【0129】

レートが受諾されると、流動性は商取引を容易にするようにロックされる（５１５）。この時点で、銀行５０１は支払い商取引５１６を実行する。これを確認するメッセージ５１６が、プロトコルバッファ構成要素５０４を介しＲＴＧＳグローバルプラットホーム５００へ中継され、そしてそのプロトコルバッファ５０５を介し受信される。

【0130】

商取引の完了が、５１７において指示され、商取引の「最終レグ」のデータが転送され、これにより、参加銀行５１２がそのローカル管轄区内のそのローカル銀行業務及び支払いレールを使用することにより支払いを完了することを可能にする。状態メッセージ５１８が、商取引の結果を確認し、そして商取引の最終レグに関するデータを含む完全な「エンド・ツー・エンド」支払いの追跡履歴を提供する。この状態メッセージ５１８は、開始参加銀行５０１へ戻る準備ができているＲＴＧＳグローバルシステム５００へ送信される。これは図５では、状態メッセージがＲＴＧＳグローバルシステム５００を介し関与送金先銀行５１２により渡されたということを指示する５１９として示される。

【0131】

サービス中継５２０が、任意の状態メッセージを、支払いを開始した顧客へ伝えるために使用される。これはまた、ＲＴＧＳグローバネットワークではなく参加銀行５０１により実行されるが、ＲＴＧＳグローバネットワークがいくつかの事例では状態メッセージを直接中継し得る。

【0132】

ＲＴＧＳグローバネットワークのあらゆる銀行（それ自身のリアルタイムグロス決済（ＲＴＧＳ）システムから切り離された銀行を含む）ユーザ間の各商取引はリアルタイムで（週末においてすら）働く。このような場合、ＲＴＧＳグローバルシステム５００内の制御ソフトウェアは、国内ＲＴＧＳが次に例えば週末後の月曜日の朝にオンラインになると相殺が自動的に発生する商取引メッセージを認定する。

【0133】

中央銀行への報告もまたリアルタイムで管理され、したがって、一日の終わりに固定及び保証された流動性ポジションがＲＴＧＳグローバルシステムにより確認される。会員銀行破綻処理の場合、この能力はＲＴＧＳグローバル管理された商取引からＨｅｒｓｔａｔｔリスクを除去する。加えて、この能力は、中央銀行、規制当局及び破綻処理関係当局へ一日の終わりに又は別の期間に報告及び確認するために使用され得る。

【0134】

ＲＴＧＳグローバルは国内ＲＴＧＳプラットホームへ接続する。やがてＲＴＧＳグローバルシステムは、中央銀行業務当局により運営されるキー国内ＲＴＧＳシステムと接続し、そして同時リアルタイムメッセージングを中央銀行貨幣口座へ届けることになるということが予想される。加えて、これはまた、管轄区の国法銀行内で保持される当方／先方口座に関するリアルタイム眺望を保持している。

【0135】

この展開の利点は流動性ポジションが、リアルタイムで中央銀行内で、中央銀行へ、そして中央銀行から迅速且つシームレスに移動し、そしてこの段階でＲＴＧＳグローバルシステムが支払い方式に適応化し得る（具体的にはクロスボーダーリアルタイム支払いを支援するために）ということである。

【0136】

図６を参照すると、ＲＴＧＳグローバルシステム内の国法銀行の役割の結果としての外国為替対リスクに関する費用節約が図式的に示される。

【0137】

操作の開始時、国内支払いシステム及びローカルネットワークレールへ直接接続しているキー国法銀行の役割が要求される。参加銀行６０１は管轄区内にある。支払いシステム６０２は、以下のものを通常含む技術へ銀行６０１を接続する：ＴＣＰ／ＩＰゲートウェイ、ＶＰＮ又はＳＷＩＦＴ(登録商標)。

【0138】

参加銀行が当該管轄区内の中央銀行６０４の会員であるローカル支払いシステム６０３の表現。中央銀行ＲＴＧＳシステム６０５は、直接的中央銀行会員全体にわたる資金とローカル支払いシステム６０３によりトリガされる金移動とを制御する。

【0139】

コラテラル口座６０６はいくつかの支払いシステムが作用するものである（例えば英国内のｆａｓｔｅｒ ｐａｙｍｅｎｔｓ ｓｅｒｖｉｃｅ（ＦＰＳ））。

【0140】

参加銀行口座６０７は金が中央銀行内に保持される場所である。ＲＴＧＳ ６０５は金を参加銀行口座間で移動する。リアルタイム接続がＲＴＧＳグローバルサービスの配布にとってキーであるということは明らかである。国法銀行はダイレクト国法支払い方式接続及びストレート・スルー・プロセッシング（ＳＴＰ：ｓｔｒａｉｇｈｔ ｔｈｒｏｕｇｈ ｐｒｏｃｅｓｓｉｎｇ）能力を有することが期待されている。これらは、国法銀行により受信された支払いがＲＴＧＳグローバネットワーク内へ決済又は処理されることを可能にする。

【0141】

ＲＴＧＳグローバル内の中央銀行の役割が図７に示される。中央銀行は、ＲＴＧＳグローバネットワーク内の自身の健全な規制責任を維持する。ＲＴＧＳグローバルプラットホーム７０１は、中央銀行が貨幣管理を設定することを可能にするサービスの構成を商取引「フロー」及び／又は「商取引値」に基づき許可する。この制御はこれらの規則をトリガする商取引が処理され得なく、したがって根源で停止されるということを保証する。これは商取引がＲＴＧＳグローバルコントローラ７０２により許可され認定された場合にだけ発生するということを保証するので重要である。

【0142】

すべての関連商取引のグローバル商取引記録７０３はＲＴＧＳ又はグローバネットワーク７０１を介しなされる。７０３は分散台帳技術（ブロックチェーン）を使用することにより実施され得る。事象ベースコントローラ７０４は、データベース内、ブロックチェーン内のデータ格納のために又は処理活動をトリガするために任意の他の接続された構成要素により使用され得るように、ＲＴＧＳグローバル事象を追跡し記録するために使用される。この特徴の利点は、事象ベースコントローラ７０４が中央銀行による事象及び関連データへの定期購読（規定目的又は計画のために重要であり得る）も許容するということである。

【0143】

データレイク７０５は特定管轄区内で中央銀行へ届けられる。データレイク７０５は、事象ベースコントローラ７０４（流動性及び潜在的露出及びリスクを判断するのを助けるためにログ記録され得るが、重要なことには、アクセスされることができる）へ参加することによりリアルタイムでその中へストリーミングされる商取引事象を有する。

【0144】

ウェブベースポータル７０６は、中央銀行により使用されるデータであって中央銀行がフロー又は値に基づき商取引スロットリングを構成することを可能にするデータを送出する。７０６は、当該中央銀行の管轄区内の参加銀行のＲＴＧＳグローバネットワーク全体にわたる流動性プール及び資金割り振りに明瞭性を提供する際に支援する。

【0145】

ＲＴＧＳのグローバルコルレス銀行業務モデルの例を描写し、そして自身の貨幣を売る時に銀行８１２はこのモデルでは買い手銀行８０９の貨幣で貨幣支払いを受信するということを示す図８を参照する。これは通常、売り手銀行に賛成する買い手銀行により信託又はＥＳＣＲＯＷ上で効果的に保持された当方／先方モデル内の保護又はリングフェンス済み口座内に預けられる。参加銀行８０１はクロスボーダー支払いを開始する。参加銀行８０１は、資金が送信されている銀行８１２の最終目的貨幣を保持することを望まない又は保持することができない。

【0146】

ＲＴＧＳグローバルプロトコルバッファ構成要素８０２は、参加銀行８０１とＲＴＧＳグローバルプラットホーム８０３との間の双方向通信及び同期のために使用される。

【0147】

ＲＴＧＳグローバルプロトコルバッファ構成要素８０４は、対応ルーティング規則（ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ ｒｏｕｔｉｎｇ ｒｕｌｅ）８０５による参加銀行８０１とＲＴＧＳグローバルプラットホーム８０３との間の同期タスク及び指令を含む双方向メッセージングを送受信するように作動可能である。これらのルーティング規則８０５は、どの銀行がどの貨幣を保持するかを識別するために使用される規則である。

【0148】

ＲＴＧＳグローバル貨幣整合／ルーティングエンジン８０６は、参加銀行と特定貨幣とを整合させるために使用され、商取引が、ＲＴＧＳグローバネットワーク内の二次参加者へ貨幣整合及びＦＸをオフロードすることを望む参加者により完了されることを可能にする。

【0149】

プロトコルバッファサービス中継器８０７は、商取引メッセージを参加銀行８０１から別の参加銀行８０９へ、そして次に第３以降の参加銀行８１２上へ中継する。ＲＴＧＳグローバルプロトコルバッファ構成要素８０８は、参加者８０１、８１２とＲＴＧＳグローバルプラットホーム８０３との間の双方向通信及び同期必要性のために配備される。

【0150】

参加銀行８０９が必要最終目的貨幣データ及び開始不換貨幣データ保持する場合、ＲＴＧＳグローバルプロトコルバッファ構成要素８１０は参加銀行とＲＴＧＳグローバルプラットホーム８０３との間の双方向通信及び同期を監督するために使用される。

【0151】

ＲＴＧＳグローバルプロトコルバッファ構成要素は、商取引を完了するために必要とされる不換貨幣を保持する参加銀行が資金を有するということをＲＴＧＳグローバルプラットホームが照査することと、これらの資金が、受諾を保留にする適切な期間の間リングフェンスされるということをＲＴＧＳグローバルプロトコルバッファ構成要素が照査することとを保証する。

【0152】

図９は、ＲＴＧＳグローバネットワークセキュリティシステムの全体ダイアグラム図であり、ポイント・ツー・ポイント暗号化とＲＴＧＳグローバルプロトコルバッファ構成要素間の通信とのための秘密鍵９０１を採用する参加銀行９０１を示す。

【0153】

ＲＴＧＳグローバルプロトコルバッファ９０２のこの配置は、ＲＴＧＳグローバルプラットホーム内の構成済みＲＴＧＳグローバルプロトコルバッファ９０６との通信だけを可能にする。これはＲＴＧＳグローバルプラットホーム９０４を介しインターネット上で暗号化通信（ＨＴＴＰＳ）９０３により実現される。

【0154】

参加銀行通信のための対応キー９０５はＲＴＧＳグローバルプロトコルバッファ９０６により供給される。暗号化オフローディングはプラットホーム９０４の「エッジ」へ移動され、したがってすべての内部通信は、エンド・ツー・エンド完全暗号化される仮想私設ネットワーク（ＶＰＮ）などの秘密インフラストラクチャ上で導かれることができる。ＲＴＧＳグローバルプロトコルバッファ間のすべての通信の監査ログ９０７がコンパイルされる。サービス中継器９０８はメッセージをプロトコルバッファ９０６、９１０間で移動するように作動可能である。

【0155】

エッジ暗号化は、ＲＴＧＳグローバルプロトコルバッファ構成要素９１０と協働する対応キー９０９により行われる。暗号化通信（ＨＴＴＰＳ）９１１は、ＲＴＧＳグローバルと参加銀行プロトコルバッファ９１３との間のインターネット上で処理される。秘密鍵９１２は、すべての通信が安全にされることを保証するために参加銀行において使用される。この構成は、任意のセキュリティ情報に対応しない又はそれを互いに共有しない参加銀行間のエンド・ツー・エンド暗号化を保証する。

【0156】

資金はこれらの２点間だけで移動され得、資金が第３の銀行へ（参加銀行又はそれ以外の銀行のいずれへも）移動され得ないということを保証する。

【0157】

ＲＴＧＳグローバル銀行間課金は、プロセッサを使用することによりそして独立サイトに位置する分散された台帳と通信状態である設備に課金することにより行われる。

【0158】

図１０は、その会員資格が英国管轄区（不換貨幣ＧＢＰ）内にある第１の参加銀行（会員銀行、英国）を示す。商取引開始は、商取引詳細を記録するＲＴＧＳグローバルへ送信される。次に、商取引要求は、その会員資格がＥＵＲＯ管轄区（不換貨幣ＥＵＲＯ）内にある第２の参加銀行（会員銀行、ＥＵＲ）へ履行メッセージとして送信される。ＦＸレートが確認され、そしてＲＴＧＳグローバルへ返送される。ＲＴＧＳグローバルシステムは、商取引詳細を更新し、そして第１及び第２の参加銀行の両方に対し流動性ロックを行う。

【0159】

最終顧客は第１の参加銀行によっても確認される商取引を確認し、ＲＴＧＳグローバルは商取引を完了し、そして完全商取引メッセージを第２の参加銀行へ送信する。第２の参加銀行は、商取引状態と共に返送メッセージを、商取引状態を維持し更新するＲＴＧＳグローバルへ送信する。次に、ＲＴＧＳグローバルは商取引状態のメッセージを中継して第１の参加銀行へ戻す。

【0160】

追加の商取引状態更新が、これらを第１の参加銀行上へ中継するＲＴＧＳグローバルへ第２の参加銀行によりトリガされ戻され得る、

【0161】

図１１は、その会員資格が商取引を開始する英国の管轄区（不換貨幣ＧＢＰ）内にある第１の参加銀行（会員銀行、英国）を示す。このメッセージは、商取引を記録するＲＴＧＳグローバルへ送信される。ＲＴＧＳグローバルシステムは、ＦＸレート及び商取引ベース料金に関する事前構成済み情報を有する。ＲＴＧＳグローバルシステムはまた、或る観点を有し、したがってその会員資格がＥＵＲＯ管轄区（不換貨幣、ＥＵＲＯ）内にある第１の参加銀行及び第２の参加銀行（会員銀行、ＥＵＲ）において必要流動性の既知状態を記録する。ＲＴＧＳグローバルは第１及び第２の参加銀行の両方において流動性ロックを行う。

【0162】

最終顧客は商取引を確認し、そして、第１の参加銀行はこの確認を、商取引を完了するＲＴＧＳグローバルへ送信する。次に、商取引完了メッセージが第２の参加銀行上へ送信される。第２の参加銀行は商取引状態メッセージを、商取引状態更新を第１の参加銀行へ中継する前に商取引状態を更新するＲＴＧＳグローバルシステムへ送信する。

【0163】

図１２は、その会員資格が商取引を開始する英国の管轄区（不換貨幣ＧＢＰ）内にある第１の参加銀行（会員銀行、英国）を示す。このメッセージは、商取引を記録するＲＴＧＳグローバルへ送信される。しかし、ＲＴＧＳグローバルは、全体的観点を有し、したがって、その会員資格がＥＵＲＯ管轄区（不換貨幣ＥＵＲＯ）内にある第１の参加銀行及び第２の参加銀行（会員銀行、ＥＵＲ）の両方において必要流動性の検証を提供することができる。

【0164】

この例では、流動性不足があり、したがって流動性ロックが参加銀行のいずれにおいても行われ得ない。したがって、流動性ロック失敗メッセージがＲＴＧＳグローバルから第１の参加銀行へ返送される。

【0165】

図１３は、参加者が参加銀行のネットワーク全体にわたって流動性を不換貨幣で獲得するためにどのようＲＴＧＳグローバルネットワークが使用されるかを示す。この例では、その会員資格が英国管轄区（不換貨幣ＧＢＰ）内にある第１の参加銀行（会員銀行、英国）がＥＵＲＯ流動性を獲得することを望む。

【0166】

要求がＲＴＧＳグローバルシステムへ送信される。ＲＴＧＳグローバルシステムは、商取引を記録し、そして履行依頼メッセージを、その管轄区がＥＵＲＯ区域（不換貨幣ＥＵＲＯ）内にある第２の参加銀行（会員銀行ＥＵＲ）、及び他の参加銀行（会員Ａ、Ｂ、Ｃ）、参加銀行３、４、５それぞれへ送出する。参加銀行３、４、５はそれぞれ、第２の参加銀行（会員銀行ＥＵＲ）内にＥＵＲＯ流動性を保持する。

【0167】

参加銀行２、３、４、５はすべて、それらのＦＸレートと確認された流動性メッセージとを返送する。ＦＸレートは第１の参加銀行へ中継され戻される。

【0168】

第１の参加銀行は商取引と好ましい流動性パートナーとを確認する。このメッセージは、商取引を記録するＲＴＧＳグローバルシステムへ送信される。流動性ロックはＥＵＲＯ貨幣を保持する第２の参加銀行上に置かれる。第２の流動性ロックは流動性を提供している第４の参加銀行（会員銀行Ｂ）上に置かれる。次に、商取引確認がＲＴＧＳグローバルシステムから第４の参加銀行（会員銀行Ｂ）へ送信され、商取引実行メッセージが第２の参加銀行（会員銀行ＥＵＲ）へ送信される。

【0169】

第２の参加銀行は状態メッセージ（決済に関係する）をＲＴＧＳグローバルシステムへ返送し、ＲＴＧＳグローバルシステムは商取引の状態及び決済を第１の参加銀行へ中継する前に商取引状態を更新する。

【0170】

本発明は単に一例として説明された。したがって特許請求の範囲により定義される保護の範囲から逸脱することなく実施形態に対する変形がなされ得るということが理解されることになる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【手続補正書】

【提出日】2022-08-31

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

通信ネットワークを介し、ＲＴＧＳを通じた当事者Ａから少なくとも１人の当事者Ｂに対する安全な資金移動のための方法であって、
前記ＲＴＧＳは、当事者Ａに関連付けられた構成要素と、前記少なくとも１人の当事者Ｂのそれぞれに関連付けられた構成要素と、前記当事者Ａに関連付けられた構成要素及び前記少なくとも１人の当事者Ｂのそれぞれに関連付けられた構成要素へ安全な通信チャネルを介して通信するように構成されたＲＴＧＳプラットフォームを有し、
前記ＲＴＧＳプラットフォームで、前記当事者Ａに関連付けられたＲＴＧＳ構成要素から、所望の取引の詳細、少なくとも通貨の詳細、送金される資金の額、及び宛先を含む開始メッセージを受信し、
前記取引を記録し、
前記所望の取引の詳細からブロックコードを生成し、
前記ＲＴＧＳプラットフォームから単一の前記当事者Ｂに関連付けられたＲＴＧＳ構成要素に、前記ブロックコードを含む要求履行メッセージを送信し、
前記ＲＴＧＳプラットフォームで、前記当事者Ｂに関連付けられたＲＴＧＳ構成要素から、少なくとも前記取引のレートを含むレートメッセージを受信し、
前記取引のさらなる詳細を記録し、
流動性ロックの期間を計算し、
前記ＲＴＧＳプラットフォームから前記当事者Ａに関連付けられたＲＴＧＳ構成要素に、少なくとも前記レート、手数料、および固定期間を有する流動性ロックを含む取引メッセージを送信し、前記流動性ロックは、前記資金の額が当事者Ａでリングフェンスされることを指示し、
前記ＲＴＧＳプラットフォームから前記当事者Ｂに関連付けられたＲＴＧＳ構成要素に、前記固定期間を有する流動性ロックを送信し、
当事者Ａと当事者Ｂの間に直接的高速接続を確立し、
前記当事者Ａに関連付けられたＲＴＧＳ構成要素から確認メッセージを受信し、
前記流動性ロックの前記固定期間内に受信された前記確認メッセージに応答し、
前記取引の完了を記録し、
前記ＲＴＧＳプラットフォームから前記当事者Ａに関連付けられたＲＴＧＳ構成要素及び前記当事者Ｂに関連付けられたＲＴＧＳ構成要素に、取消不能な完全取引メッセージを送信する、
安全な資金移動のための方法。

【請求項2】

前記当事者Ａと前記当事者Ｂに関連付けられた構成要素に前記流動性ロックの前記固定期間が送信された後、前記ＲＴＧＳプラットフォームは、前記当事者Ａに関連付けられたＲＴＧＳ構成要素と前記当事者Ｂに関連付けられたＲＴＧＳ構成要素の両方からロック確認メッセージを受信する、
請求項１に記載の安全な資金移動のための方法。

【請求項3】

前記ＲＴＧＳプラットフォームは、前記取引の詳細を分散型台帳に記録する、
請求項１又は請求項２に記載の安全な資金移動のための方法。

【請求項4】

前記ＲＴＧＳプラットフォームは、前記当事者Ａに関連付けられたＲＴＧＳ構成要素に複数のレートをさらに送信する、
請求項１から請求項３の何れか１項に記載の安全な資金移動のための方法。

【請求項5】

前記流動性ロックが有効になる期間に対応するタイマーをさらに開始する、
請求項１から請求項４の何れか１項に記載の安全な資金移動のための方法。

【請求項6】

前記流動性ロックの前記固定期間は、３０秒未満、好ましくは２０秒未満、さらに好ましくは８秒未満である、
請求項１から請求項５の何れか１項に記載の安全な資金移動のための方法。

【請求項7】

前記ＲＴＧＳは、前記当事者Ｂに関連付けられたＲＴＧＳ構成要素から、前記取引の完了を示すステータスメッセージをさらに受信する、
請求項１から請求項６の何れか１項に記載の安全な資金移動のための方法。

【請求項8】

前記当事者Ａに関連付けられたＲＴＧＳ構成要素又は前記当事者Ｂに関連付けられたＲＴＧＳ構成要素は外国にある、
請求項１から請求項７の何れか１項に記載の安全な資金移動のための方法。

【請求項9】

前記ＲＴＧＳプラットフォームは、前記流動性ロック期間内に前記当事者Ａに関連付けられたＲＴＧＳ構成要素から確認メッセージを受信できなかったことに応答して、前記当事者Ａに関連するＲＴＧＳ構成要素に、少なくとも前記レート、手数料、および固定期間を有するさらなる流動性ロックを含むさらなる取引メッセージを送信する、
請求項１から請求項８の何れか１項に記載の安全な資金移動のための方法。

【請求項10】

前記ＲＴＧＳは、データレイクに取引イベントをさらに投入し、
前記データレイクは、少なくとも１つの中央銀行によって安全な通信チャネルを介して問い合わせることができる、
請求項１から請求項９の何れか１項に記載の安全な資金移動のための方法。

【請求項11】

当事者Ａと当事者Ｂの少なくとも一方は、ポイントツーポイント暗号化及び通信ネットワークを使用して、前記当事者Ａと当事者Ｂの少なくとも一方に関連付けられたＲＴＧＳ構成要素と通信する銀行である、
請求項１から請求項１０の何れか１項に記載の安全な資金移動のための方法。

【請求項12】

データのエッジ暗号化をさらに実行する、
請求項１から請求項１１の何れか１項に記載の安全な資金移動のための方法。

【請求項13】

請求項１から請求項１２の何れか１項に記載のステップを実行するように構成されたプロセッサ、
を備えるデータ処理装置。

【請求項14】

安全なサーバアーキテクチャを備える、
請求項１３に記載のデータ処理装置。

【請求項15】

請求項１３又は請求項１４に記載のデータ処理装置と、
当事者に関連付けられた少なくとも１つのＲＴＧＳ構成要素と、
前記ＲＴＧＳプラットフォームと前記ＲＴＧＳ構成要素との間の安全な通信チャネルと、
を備えるコンピュータネットワーク。

【国際調査報告】