(57)【要約】  ブロックチェーン、即ち分散型台帳ネットワークテクノロジーは、取引において参加者が参加することを事前認定することによって、外貨（ＦＸ）取引を容易にし、高速化し、それら取引を信頼性があり信用のあるものとする。参加者を事前認定することによって、当事者が売買に参入する前に取引の資金調達が可能になり、取引を完了するために必要な時間が短縮される。一態様では、これらの取引のクレジット態様は、取引自体から分解され、特にクレジットリスク及びデリバリーリスクを排除する。ブロックチェーン内のデータの不変性は、取引の信頼性を高め、所与の取引の両サイドの信用を高める。別の態様では、ブロックチェーン内に存在する完全に担保されたフィアットコイン（ＦＣＦＣ）は、根源的法定通貨に基づく。ブロックチェーン内では、ＦＣＦＣは独自の通貨である。【選択図】図１
2021528797.tif 000002
【特許請求の範囲】
【請求項１】
高速化された外国為替（ＦＸ）取引処理を実施するためのシステムであって、前記システムは装置を含み、前記装置は、
ＦＸ取引に参入することを望む第１の当事者からの第１の指示に応答して、前記システムにおいて前記第１の指示を暗号化された方法で記録し、前記システム内で暗号化された方法で伝達される第１の所定基準を満たすことに応答して、前記ＦＸ取引に加わるための第１の承認を前記第１の当事者に提供し、
前記ＦＸ取引に参入することを望む第２の当事者からの第２の指示に応答して、前記システムにおいて前記第２の指示を暗号化された方法で記録し、前記システム内で暗号化された方法で伝達される第２の所定基準を満たすことに応答して、前記ＦＸ取引に加わるための第２の承認を前記第２の当事者に提供し、
前記ＦＸ取引を実施するための工程を暗号化された不変の方法で記録し、
前記システムは、
前記第１の当事者が前記システムと通信することを可能にするための第１のユーザインターフェース（ＵＩ）及び第１のアプリケーションプログラミングインターフェース（ＡＰＩ）と、
前記第２の当事者が前記システムと通信することを可能にするための第２のＵＩ及び第２のＡＰＩと、
前記第１の当事者及び前記第２の当事者のアクションに応答して前記ＦＸ取引を管理するための少なくとも１つの状態マシンと、
第１の法定通貨に従って値が付けられた第１のトークンを第２の法定通貨に従って値が付けられた第２のトークンと交換することによって前記ＦＸ取引に参加する前記第１の当事者と、
前記第２の法定通貨に従って値が付けられた前記第２のトークンを前記第１の法定通貨に従って値が付けられた前記第１のトークンと交換することによって前記ＦＸ取引に参加する前記第２の当事者と、を更に備え、
前記第１のトークンの価値は前記第１の法定通貨の根源的価値の変動に従ってのみ変動し、前記第２のトークンの価値は前記第２の法定通貨の根源的価値の変動に従ってのみ変動する、システム。
【請求項２】
前記状態マシンは、前記ＦＸ取引を実施するのに十分な前記第１の当事者の資金を凍結するための装置を備える、請求項１に記載のシステム。
【請求項３】
前記状態マシンは、前記ＦＸ取引を実施するのに十分な前記第２の当事者の資金を凍結するための装置を備える、請求項１又は２に記載のシステム。
【請求項４】
前記状態マシンは、前記ＦＸ取引を実施するのに十分な前記第１の当事者の資金を凍結解除するための装置を備える、請求項１〜３のいずれかに記載のシステム。
【請求項５】
前記状態マシンは、前記ＦＸ取引を実施するのに十分な前記第２の当事者の資金を凍結解除するための装置を備える、請求項１〜４のいずれかに記載のシステム。
【請求項６】
前記ＦＸ取引を実施するために、前記第１及び第２の所定基準を満たすことに応答して、少なくとも１つのスマートコントラクトを実行する装置を更に備える、請求項１〜５のいずれかに記載のシステム。
【請求項７】
前記システムは、ＦＸ取引の資金調達を安全で信頼できる方法で事前認定することによって前記資金調達を前記ＦＸ取引自体から分解する装置を含む、請求項１〜６のいずれかに記載のシステム。
【請求項８】
前記第１及び第２の所定基準の少なくとも１つは、前記第１の当事者及び前記第２の当事者の１つが前記ＦＸ取引に加わることを事前認定するために前記第１及び第２の法定通貨の１つで資金を前記第１の当事者及び前記第２の当事者の１つに提供するための少なくとも１つの貸し手からの合意を含み、前記システムは、前記少なくとも１つの貸し手が前記第１のトークンの少なくともいくつかを前記第１の当事者に提供し又は前記第２のトークンの少なくともいくつかを前記第２の当事者に提供することを可能にする第３のＵＩ及び第３のＡＰＩを更に備える、請求項１〜７のいずれかに記載のシステム。
【請求項９】
前記第１の所定の基準は、前記第１の当事者が前記ＦＸ取引に加わるための資金調達を事前認定するために前記第１の法定通貨で第１の必要金額の資金を前記第１のトークンの少なくともいくつかとして前記第１の当事者に提供するための複数の貸し手からの合意を含む、請求項１〜８のいずれかに記載のシステム。
【請求項１０】
前記第１の必要金額の資金は、前記第１の当事者が前記ＦＸ取引に加わるために使う全ての資金からなる、請求項１〜９のいずれかに記載のシステム。
【請求項１１】
前記第２の所定の基準は、前記第２の当事者が前記ＦＸ取引に加わるための資金調達を事前認定するために前記第２の法定通貨で第２の必要金額の資金を前記第２のトークンの少なくともいくつかとして前記第２の当事者に提供するための複数の貸し手からの合意を含む、請求項１〜１０のいずれかに記載のシステム。
【請求項１２】
前記第２の必要金額の資金は、前記第２の当事者が前記ＦＸ取引に加わるために使う全ての資金からなる、請求項１〜１１のいずれかに記載のシステム。
【請求項１３】
前記ＦＸ取引が行われるブロックチェーンを更に備える、請求項１〜１２のいずれかに記載のシステム。
【請求項１４】
前記ＦＸ取引に関するデータを前記ブロックチェーンと通信するためのオラクルを更に備える、請求項１〜１３のいずれかに記載のシステム。
【請求項１５】
前記第１及び第２の所定基準のための暗号化を提供すると共に前記ＦＸ取引の工程の暗号化された記録を可能にするセキュリティシステムを更に備える、請求項１〜１４のいずれかに記載のシステム。
【請求項１６】
前記セキュリティシステムは、秘密暗号化鍵を管理するための鍵管理サーバと、前記秘密暗号化鍵を生成して前記第１及び第２の所定基準のための暗号化を提供すると共に前記ＦＸ取引の工程の暗号化された記録を可能にするためのハードウェアセキュリティモジュールと、を備える、請求項１〜１５のいずれかに記載のシステム。
【請求項１７】
高速化された外国為替（ＦＸ）取引処理を実施するための方法であって、
前記方法は、
ＦＸ取引に参入することを望む第１の当事者からの第１の指示に応答して、前記第１の指示を暗号化された方法で記録し、暗号化された方法で伝達される第１の所定基準を満たすことに応答して、前記ＦＸ取引に加わるための第１の承認を前記第１の当事者に提供することと、
前記ＦＸ取引に参入することを望む第２の当事者からの第２の指示に応答して、前記第２の指示を暗号化された方法で記録し、暗号化された方法で伝達される第２の所定基準を満たすことに応答して、前記ＦＸ取引に加わるための第２の承認を前記第２の当事者に提供することと、
前記ＦＸ取引を実施するための工程を暗号化された不変の方法で記録することと、を備え、
前記方法は、
前記第１の当事者及び前記第２の当事者のアクションに応答して前記ＦＸ取引を管理することと、
第１の法定通貨に従って値が付けられた第１のトークンを第２の法定通貨に従って値が付けられた第２のトークンと交換することによって前記第１の当事者が前記ＦＸ取引に参加することと、
前記第２の法定通貨に従って値が付けられた前記第２のトークンを前記第１の法定通貨に従って値が付けられた前記第１のトークンと交換することによって前記第２の当事者が前記ＦＸ取引に参加することと、を更に備え、
前記第１のトークンの価値は前記第１の法定通貨の根源的価値の変動に従ってのみ変動し、前記第２のトークンの価値は前記第２の法定通貨の根源的価値の変動に従ってのみ変動する、方法。
【請求項１８】
前記ＦＸ取引を実施するのに十分な前記第１の当事者の資金を凍結することを更に備える、請求項１７に記載の方法。
【請求項１９】
前記ＦＸ取引を実施するのに十分な前記第２の当事者の資金を凍結することを更に備える、請求項１７又は１８に記載の方法。
【請求項２０】
前記ＦＸ取引を実施するのに十分な前記第１の当事者の資金を凍結解除することを更に備える、請求項１７〜１９のいずれかに記載の方法。
【請求項２１】
前記ＦＸ取引を実施するのに十分な前記第２の当事者の資金を凍結解除することを更に備える、請求項１７〜２０のいずれかに記載の方法。
【請求項２２】
前記ＦＸ取引を実施するために、前記第１及び第２の所定基準を満たすことに応答して、少なくとも１つのスマートコントラクトを実行することを更に備える、請求項１７〜２１のいずれかに記載の方法。
【請求項２３】
ＦＸ取引の資金調達を安全で信頼できる方法で事前認定することによって前記資金調達を前記ＦＸ取引自体から分解することを更に備える、請求項１７〜２２のいずれかに記載の方法。
【請求項２４】
前記第１及び第２の所定基準の少なくとも１つは、前記第１の当事者及び前記第２の当事者の１つが前記ＦＸ取引に加わることを事前認定するために前記第１及び第２の法定通貨の１つで資金を前記第１の当事者及び前記第２の当事者の１つに提供するための少なくとも１つの貸し手からの合意を含み、前記少なくとも１つの貸し手は、前記第１のトークンの少なくともいくつかを前記第１の当事者に提供し又は前記第２のトークンの少なくともいくつかを前記第２の当事者に提供する、請求項１７〜２３のいずれかに記載の方法。
【請求項２５】
前記第１の所定の基準は、前記第１の当事者が前記ＦＸ取引に加わるための資金調達を事前認定するために前記第１の法定通貨で第１の必要金額の資金を前記第１のトークンの少なくともいくつかとして前記第１の当事者に提供するための複数の貸し手からの合意を含む、請求項１７〜２４のいずれかに記載の方法。
【請求項２６】
前記第１の必要金額の資金は、前記第１の当事者が前記ＦＸ取引に加わるために使う全ての資金からなる、請求項１７〜２５のいずれかに記載の方法。
【請求項２７】
前記第２の所定の基準は、前記第２の当事者が前記ＦＸ取引に加わるための資金調達を事前認定するために前記第２の法定通貨で第２の必要金額の資金を前記第２のトークンの少なくともいくつかとして前記第２の当事者に提供するための複数の貸し手からの合意を含む、請求項１７〜２６のいずれかに記載の方法。
【請求項２８】
前記第２の必要金額の資金は、前記第２の当事者が前記ＦＸ取引に加わるために使う全ての資金からなる、請求項１７〜２７のいずれかに記載の方法。
【請求項２９】
前記ＦＸ取引をブロックチェーンシステム内で行うことを更に備える、請求項１７〜２８のいずれかに記載の方法。
【請求項３０】
前記ＦＸ取引に関するデータを前記ブロックチェーンシステムと通信することを更に備える、請求項１７〜２９のいずれかに記載の方法。
【請求項３１】
前記第１及び第２の所定基準のための暗号化を提供することと、前記ＦＸ取引の工程の暗号化された記録を可能にすることと、を更に備える、請求項１７〜３０のいずれかに記載の方法。
【請求項３２】
秘密暗号化鍵を鍵管理サーバ上で管理することと、前記秘密暗号化鍵を生成して前記第１及び第２の所定基準のための暗号化を提供すると共に前記ＦＸ取引の工程の暗号化された記録をハードウェアセキュリティモジュール上で可能にすることと、を更に備える、請求項１７〜３１のいずれかに記載の方法。
【発明の詳細な説明】
【関連出願への相互参照】
【０００１】
本出願は、２０１８年６月２１日に出願された米国仮特許出願第６２／６８７，８０５号、２０１９年２月８日に出願された米国仮特許出願第６２／８０３，１５８号、及び２０１９年３月１４日に出願された米国仮特許出願第６２／８１８，６４０号からの優先権を主張し、これらの出願の全体を参照によりここに組み込む。
【技術分野】
【０００２】
本発明は、分散型台帳アプリケーション、特にブロックチェーンアプリケーション、より具体的には、取引、特に金融取引、より具体的には外貨（ＦＸ）取引を完了するために必要な時間を劇的に短縮するブロックチェーンアプリケーションに関する。
【背景技術】
【０００３】
分散型台帳技術の１つのバージョンはブロックチェーンであり、分散型台帳技術は、何年か前から存在している。数ある属性の中でも、ブロックチェーンは、ブロックチェーンを構成している複数のノードに分散された台帳において取引の不変な記録を提供することにより、トラストレス(trustless)な取引を容易にする。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
金融取引を容易にするためにこのトラストレスな環境を提供して、特定の取引を完了するのに必要な時間を劇的に短縮すると共に、１日あたり多数のそのような取引の達成を可能にすることが望ましいであろう。
【課題を解決するための手段】
【０００５】
一態様では、本発明は、ブロックチェーン技術、即ち分散型台帳ネットワーク技術を用いて外貨（ＦＸ）取引のためのオンデマンド支払い流動性を提供する。実施形態は、「資金調達後売買(fund then trade)」モデルに従って、オンデマンドの支払い流動性を可能にする。
【０００６】
ここで説明されるシステムは、所与の金融取引、例えば外貨の売買、の純粋に財政的な考慮を、取引に対する任意の当事者の側でそのような取引に資金提供することに伴うリスクから分離することを可能にする。一態様では、そのような取引は、ここでより詳細に説明されるように、通貨買い手及び通貨売り手を伴うことになる。一態様では、貸し手実体(lending entity)は、取引に対して完全に資金提供されるように買い手又は売り手のいずれかに資金を貸し付けることによって取引に参加してよい。異なる貸し手実体が、それぞれ買い手と売り手に資金を貸し付けてもよい。
【０００７】
別の態様では、実施形態はトークン(tokens)の使用を提供し、これらのトークンは、取引を実施するためにそれらの根源的法定通貨(underlying fiat currency)に等しい価値を有する。トークンは完全に担保とされるので、根源的法定通貨が他の通貨に対して変動するのに従ってのみ、トークンの価値は他の通貨に対して変動する。本発明者らは、そのようなトークンを、完全に担保されたフィアットコグ又はフィアットコイン(fully collateralized fiat cogs or fiat coins)（ＦＣＦＣ）と命名した。
【０００８】
本発明の態様では、システムは高速化された外国為替（ＦＸ）取引処理を実施し、このシステムは装置を含み、この装置は、
ＦＸ取引に参入することを望む第１の当事者からの第１の指示に応答して、システムにおいて第１の指示を暗号化された方法で記録し、システム内で暗号化された方法で伝達される第１の所定基準を満たすことに応答して、ＦＸ取引に加わるための第１の承認を第１の当事者に提供し、
ＦＸ取引に参入することを望む第２の当事者からの第２の指示に応答して、システムにおいて第２の指示を暗号化された方法で記録し、システム内で暗号化された方法で伝達される第２の所定基準を満たすことに応答して、ＦＸ取引に加わるための第２の承認を第２の当事者に提供し、
ＦＸ取引を実施するための工程を暗号化された不変の方法で記録し、
システムは、
第１の当事者がシステムと通信することを可能にするための第１のユーザインターフェース（ＵＩ）及び第１のアプリケーションプログラミングインターフェース（ＡＰＩ）と、
第２の当事者がシステムと通信することを可能にするための第２のＵＩ及び第２のＡＰＩと、
第１の当事者及び第２の当事者のアクションに応答してＦＸ取引を管理するための少なくとも１つの状態マシンと、
第１の法定通貨に従って値が付けられた第１のトークンを第２の法定通貨に従って値が付けられた第２のトークンと交換することによってＦＸ取引に参加する第１の当事者と、
第２の法定通貨に従って値が付けられた第２のトークンを第１の法定通貨に従って値が付けられた第１のトークンと交換することによってＦＸ取引に参加する第２の当事者と、を更に備え、
第１のトークンの価値は第１の法定通貨の根源的価値の変動に従ってのみ変動し、第２のトークンの価値は第２の法定通貨の根源的価値の変動に従ってのみ変動する。
【０００９】
状態マシンは、ＦＸ取引を実施するのに十分な第１の当事者又は第２の当事者の資金を凍結又は凍結解除するための装置を含んでいてよい。
【００１０】
ＦＸ取引を実施するために、第１及び第２の所定基準を満たすことに応答して、少なくとも１つのスマートコントラクトを実行する装置が設けられていてよい。
【００１１】
ＦＸ取引の資金調達を安全で信頼できる方法で事前認定することによって資金調達をＦＸ取引自体から分解する装置が設けられていてよい。
【００１２】
第１及び第２の所定基準の少なくとも１つは、第１の当事者及び第２の当事者の１つがＦＸ取引に加わることを事前認定するために第１及び第２の法定通貨の１つで資金を第１の当事者及び第２の当事者の１つに提供するための少なくとも１つの貸し手からの合意を含んでいてよい。少なくとも１つの貸し手が第１のトークンの少なくともいくつかを第１の当事者に提供し又は第２のトークンの少なくともいくつかを第２の当事者に提供することを可能にするために、第３のＵＩ及び第３のＡＰＩが設けられていてよい。
【００１３】
第１の所定の基準は、第１の当事者がＦＸ取引に加わるための資金調達を事前認定するために第１の法定通貨で第１の必要金額の資金を第１のトークンの少なくともいくつかとして第１の当事者に提供するための複数の貸し手からの合意を含んでいてよい。第１の必要金額の資金は、第１の当事者がＦＸ取引に加わるために使う全ての資金からなっていてよい。
【００１４】
第２の所定の基準は、第２の当事者がＦＸ取引に加わるための資金調達を事前認定するために第２の法定通貨で第２の必要金額の資金を第２のトークンの少なくともいくつかとして第２の当事者に提供するための複数の貸し手からの合意を含んでいてよい。第２の必要金額の資金は、第２の当事者がＦＸ取引に加わるために使う全ての資金からなっていてよい。
【００１５】
システムは、ＦＸ取引が行われる、高度に利用可能な複製された永続性データストレージシステム、及び／又はＦＸ取引に関するデータを、高度に利用可能な複製された永続性データストレージシステムと通信するためのデータ永続性インターフェースモジュール、及び／又は第１及び第２の所定基準のための暗号化を提供すると共にＦＸ取引の工程の暗号化された記録を可能にするセキュリティシステムを含んでいてよい。セキュリティシステムは、秘密暗号化鍵を管理するための鍵管理サーバと、秘密暗号化鍵を生成して第１及び第２の所定基準のための暗号化を提供すると共にＦＸ取引の工程の暗号化された記録を可能にするためのハードウェアセキュリティモジュールと、を含んでいてよい。
【００１６】
本発明の態様では、高速化された外国為替（ＦＸ）取引処理を実施するための方法は、
ＦＸ取引に参入することを望む第１の当事者からの第１の指示に応答して、第１の指示を暗号化された方法で記録し、暗号化された方法で伝達される第１の所定基準を満たすことに応答して、ＦＸ取引に加わるための第１の承認を第１の当事者に提供することと、
ＦＸ取引に参入することを望む第２の当事者からの第２の指示に応答して、第２の指示を暗号化された方法で記録し、暗号化された方法で伝達される第２の所定基準を満たすことに応答して、ＦＸ取引に加わるための第２の承認を第２の当事者に提供することと、
ＦＸ取引を実施するための工程を暗号化された不変の方法で記録することと、を実施し、
方法は、
第１の当事者及び第２の当事者のアクションに応答してＦＸ取引を管理することと、
第１の法定通貨に従って値が付けられた第１のトークンを第２の法定通貨に従って値が付けられた第２のトークンと交換することによって第１の当事者がＦＸ取引に参加することと、
第２の法定通貨に従って値が付けられた第２のトークンを第１の法定通貨に従って値が付けられた第１のトークンと交換することによって第２の当事者がＦＸ取引に参加することと、を更に備え、
第１のトークンの価値は第１の法定通貨の根源的価値の変動に従ってのみ変動し、第２のトークンの価値は第２の法定通貨の根源的価値の変動に従ってのみ変動する。
【００１７】
ＦＸ取引を実施するのに十分な第１の当事者又は第２の当事者の資金は、凍結又は凍結解除されてよい。
【００１８】
ＦＸ取引を実施するために、第１及び第２の所定基準を満たすことに応答して、少なくとも１つのスマートコントラクトが実行されてよい。
【００１９】
ＦＸ取引の資金調達は、資金調達を安全で信頼できる方法で事前認定することによってＦＸ取引自体から分解されてよい。
【００２０】
第１及び第２の所定基準の少なくとも１つは、第１の当事者及び第２の当事者の１つがＦＸ取引に加わることを事前認定するために第１及び第２の法定通貨の１つで資金を第１の当事者及び第２の当事者の１つに提供するための少なくとも１つの貸し手からの合意を含んでいてよく、少なくとも１つの貸し手は、第１のトークンの少なくともいくつかを第１の当事者に提供し又は第２のトークンの少なくともいくつかを第２の当事者に提供する。
【００２１】
ＦＸ取引はブロックチェーンシステム内で行われてよい。ＦＸ取引に関するデータはブロックチェーンシステムと通信されてよい。第１及び第２の所定基準のために暗号化が提供されてよく、ＦＸ取引の工程の暗号化された記録が可能にされてよい。
【００２２】
秘密暗号化鍵が鍵管理サーバ上で管理されてよく、第１及び第２の所定基準のための暗号化を提供すると共にＦＸ取引の工程の暗号化された記録をハードウェアセキュリティモジュール上で可能にするために、秘密暗号化鍵が生成されてよい。
【図面の簡単な説明】
【００２３】
次に、添付の図面を参照して本発明の実施形態を詳細に説明する。
【００２４】
【図１】図１は実施形態による高レベルのシステムアーキテクチャ図である。
【００２５】
【図２】図２は実施形態による別の高レベルシステムアーキテクチャ図である。
【００２６】
【図３】図３は実施形態による状態図である。
【００２７】
【図４】図４は実施形態による別の状態図である。
【００２８】
【図５】図５は実施形態による更に別の状態図である。
【００２９】
【図６】図６は一実施形態による例示的な取引のテイカー側を示すフローチャートである。
【００３０】
【図７】図７は一実施形態による例示的な取引のメイカー側を示すフローチャートである。
【００３１】
【図８】図８は一実施形態による例示的な取引における貸し手の役割を示すフローチャートである。
【００３２】
【図９】図９は一実施形態によるＦＣＦＣでの取引フローを示す高レベル図である。
【００３３】
【図１０】図１０は一実施形態によるＦＣＦＣの作成を示す図である。
【００３４】
【図１１】図１１は一実施形態によるＦＣＦＣを用いるＦＸ取引を示す図である。
【００３５】
【図１２】図１２は一実施形態によるＦＣＦＣを用いるＦＸ取引に対する利息の支払いを示す図である。
【００３６】
【図１３】図１３は一実施形態によるＦＣＦＣを用いるＦＸ取引におけるＦＣＦＣの現金化(redemption)を示す図である。
【００３７】
【図１４】図１４は一実施形態による借入／貸付を伴うＦＸ取引を示す図である。
【００３８】
【図１５】図１５は一実施形態による１つの実体から別の実体への支払いを示す図である。
【００３９】
【図１６】図１６は一実施形態による例示的な貸付取引を示す図である。
【００４０】
【図１７】図１７は一実施形態による種々のノードを有するブロックチェーン及びそれらのノードのうちの３つでの実体間の売買／貸付取引の図である。
【発明を実施するための形態】
【００４１】
当業者が理解するであろうように、以下は、秘密鍵を取り扱うための安全なディスクリートハードウェアモジュールを用いて、証券、通貨、不動産、及び他の資産を伴う種々の金融取引を安全で検証可能な方法で実施するためのブロックチェーン技術の実用的なアプリケーションについて説明する。この技術がなければ、クレジットリスク及びデリバリーリスクの概念全体が一般的であり続ける可能性がある。本発明者らは、外国為替取引が長い間同じ方法で実施されてきたことが重要であると気付いた。ある売買は日付Ｔに開始されるが、取引に固有のクレジットリスク及びデリバリーリスクのため、日付けＴ＋２までに完了しない。ブロックチェーンベースのシステムを開発することで、取引の種々の工程の検証可能で不変の記録を作成及び保持することにより、これらのリスクに関する懸念が取り除かれた。この技術がなければ、ある取引に加わっている２当事者が同じ建物内に居たとしても、あるいは同じ部屋内に居たとしてさえ、彼らは、その取引が成立するはずであることを確認し検証することはできないであろう。
【００４２】
ここに開示される実施形態の詳細に進む前に、以下は、特定の用語集に加えて、本発明のシステムのいくつかの態様の非常に高レベルの議論である。
【００４３】
「ブロックチェーン」という用語は、当業者によって理解される意味を有するのに十分な期間存在してきた。ここでブロックチェーンの定義を限定する意図はないが、ここで提示されている概念の理解を容易にするために、最も基本的なレベルでは、ブロックチェーンは取引の暗号化台帳である。その暗号化台帳は、ブロックチェーン内の複数のノードに分散されている。
【００４４】
ブロックチェーンには種々のカテゴリがある。ブロックチェーンはパブリックであることがあり、プライベートであることがあり、許可されていることがあり、あるいはプライベートで且つ許可されていることがある。当業者はこれらの用語を理解しているので、詳細な定義はここでは提供しない。
【００４５】
パブリックブロックチェーンは、一般に誰でもブロックチェーンのアクティビティに加わり参加してよいブロックチェーンである。一般の人々は、進行中のアクティビティに自由に加わり、そこから去り、又は進行中のアクティビティを自由に読み取り、書き込み、若しくは監査することができる。
【００４６】
プライベートブロックチェーンは、ユーザが招待によって加わってよいブロックチェーンである。従って、パブリックブロックチェーンとプライベートブロックチェーンの１つの違いは、プライベートブロックチェーンが、誰がそのブロックチェーンに参加することを許可されるのかに関する統制を有することである。
【００４７】
許可されたブロックチェーンは、誰が加わってよいか及び参加者が何をしてよいかに関して制限を有するブロックチェーンである。許可されたブロックチェーンは、プライベートブロックチェーンの一種と見なされてよいが、当該技術は、アクセス及びアクティビティの両方が制限されることがあるプライベートの許可されたブロックチェーンへの参照を含む。
【００４８】
暗号化の使用と台帳の分散により、ブロックチェーンをハッキングしてブロックチェーン内のノードを破壊し、並べ替え、又はさもなければ変更する可能性は非常に低くなる。この低い確率が存在するのは、少なくとも部分的には、取引の台帳が単一の第３の当事者のみに属するのではなく、ブロックチェーン内の複数のノード内にあるからである。これらのノードは、取引を裁可するためのコンセンサス機構に従って動作する。イスタンブールビザンチンフォールトトレラント(Istanbul Byzantine Fault Tolerant)（ＩＢＦＴ）等のいくつかのコンセンサス機構により、参加者は相互合意に達する。ＩＢＦＴで動作するブロックチェーンは、いくつかのノードが不正である場合でも、適切に機能し続けることができる。ＲＡＦＴ等の他のコンセンサス機構では、参加者はリーダーを信頼する。当然のことながら、参加者間の合意は必要ないので、ＲＡＦＴはＩＢＦＴよりも高速に動作する傾向がある。プライベートの許可されたブロックチェーンにおいては、参加者は招待によってそこにいて、彼らのアクティビティは制限されているので、参加者が引き継ぐ可能性は低くなる傾向がある。
【００４９】
ブロックチェーンは、一般に、それ自体の外部の情報にアクセスする方法を有していない。このような制限は、ブロックチェーン上の取引の完全性にとって重要である。ブロックチェーンが情報を取得するためには、ブロックチェーンは信頼されている外部ソースを必要とする。オラクルは、ブロックチェーンにデータを提供するそのような信頼されている外部ソースの一例であり、ブロックチェーンの外部で機能する。一般に、オラクルはデータを見つけて検証し、そのデータをブロックチェーンに送信する。１つの状況においては、オラクルは、データソース及びブロックチェーンの両方とインターフェイスするレイヤーと考えられてよい。この意味で、オラクルはデータをブロックチェーンの外部からブロックチェーン上に転送し、移す。実施形態によれば、ブロックチェーンにデータを提供する複数のオラクルが存在してよい。
【００５０】
ブロックチェーンは、スマートコントラクトとして知られる自己実行コードの複数の断片を含んでいてよい。スマートコントラクトは、特定のデータの受信に応答して特定の機能が実行される場合があるという点で自己実行的であってよい。例えば、ＦＸ取引の場合、スマートコントラクトは、取引の資金調達の条件に関するコードを含んでいてよい。これらの条件が満たされていることを示す入力をスマートコントラクトが受け取ると、スマートコントラクトは取引を進めさせてよい。一態様では、これらの入力は、１つ以上のオラクルに由来する。実施形態によれば、所与のＦＸ取引について、実行される複数のスマートコントラクトがあってよい。
【００５１】
一般的に言えば、オラクルは概して、ブロックチェーンの外部（オフチェーン）で実行されるべき取引部分を連携させる。例えば、テイカー（取引を開始しようとしている当事者）とメイカー（テイカーとの取引に参加しようとしている当事者）のマッチングは、オフチェーンで生じてよい。テイカー、メイカー、又はその両方で取引を完了するための資金が不足している状況においては、取引の実行前に取引の資金調達を可能にするための１つ以上の貸し手の識別及び選択もオフチェーンで生じてよい。一態様では、オラクルは情報の取り扱い及びルーティングのためのロジックを含み、関係している金融機関とブロックチェーンの間のインターフェースを提供する。
【００５２】
一態様では、ここで説明するシステムにおける１つ以上のオラクルは、ニューラルネットワーク又は他の機械学習構造の形態にある機械学習を組み込んでいてよい。実施されることになる金融取引の性質及び量は、取引がいつどのように実施されるかについての洞察を得るためにマイニングされ得るユーザ固有ではない相当量のデータを生成し、これらのデータは、種々の取引のタイミングや周期性等だけでなく取引の量も含む。
【００５３】
一態様では、ここに開示されるブロックチェーンは、ＲＡＦＴコンセンサス機構で動作するプライベートの許可されたブロックチェーンであってよい。ＲＡＦＴコンセンサス機構によると、ネットワーク内の全てのノードは、暗号化されていない形態のブロックチェーンのコピーを有していてよい。ＲＡＦＴリーダーとＲＡＦＴフォロワーの間での唯一の描写は、ＲＡＦＴリーダーが、どの取引が有効であると考えられるのかを決定し、有効な取引をブロックへと収集し、次いでそのブロックをチェーンに追加することである。ＲＡＦＴリーダーがチェーン内の次のブロックをアナウンスすると、全てのフォロワーは、新たなブロック内の取引の検証等の追加作業を行うことなく、チェーンのコピーに新たなブロックを単純に追加する。従って、全てのノード、フォロワー、又はリーダーは、生じた全ての取引へのアクセスを含め、暗号化されていないブロックチェーン全体への直接アクセスを有していてよい。
【００５４】
前述のアプローチでは、ブロックチェーンへの直接アクセスが制限されるべき場合には、それは次の方法で達成されてよい。ブロックチェーンは仮想プライベートクラウド（ＶＰＣ）内に存在していてよく、このことは、権限を与えられたシステムのみがブロックチェーンネットワーク内のノードへの直接アクセスを有していることを意味する。全てのノードは、発生した全ての取引のブロックチェーンを含むので、任意の取引の詳細を得るために、任意のノードが問い合わせられ得る。そのようなシステムのユーザ（本発明の態様に従って行われるＦＸ取引においては、テイカー、メイカー、又は貸し手）は、彼らが具体的にアクセスを許可されている取引の特定の詳細のみを受け取ってよい。例えば、システムは、任意の特定のユーザが参加した取引の記録を維持していてよい。次いで、システムは、オラクルに働きかけて、任意の特定の取引（例えば、売買された通貨、通貨額等）に関する詳細を任意のブロックチェーンノードに問い合わせることができ、また、その取引に関する具体的な詳細をＵＩｓに返して当該ユーザに対して表示することができる。
【００５５】
一態様では、ＲＡＦＴコンセンサス機構で動作するプライベートの許可されたブロックチェーンにおいては、リーダーは、ブロックチェーンへの直接アクセスを有する唯一のリーダーであってよく、ブロックチェーンのコピーを有する唯一のリーダーであってよい。システム参加者が取引の一部であったかどうかに関係なく、その参加者はコピーを有する。代わりに、リーダーは、任意の特定の取引に関して適切な当事者に特定の取引の詳細を提供してもよい。その結果、特定の取引の当事者、及び取引を確認する権限のある他の実体（存在する場合）は、取引の詳細を確認することができ、それに対するコピーを有するようになる。取引の詳細を確認する権限のないブロックチェーン上の他の実体もまた取引のコピーを有するようになるが、暗号化された形態、例えば暗号化ハッシュにおけるコピーのみである。一態様では、暗号化ハッシュはデータの一意表現であるので、取引の詳細を確認する権限のない各ノードで記憶された暗号化ハッシュは、取引の詳細と容易に比較されて、詳細の正確さを検証することができる。取引が行われたことを検証するためのコンセンサスプロトコルに関する限り、ハッシュはその必要な検証を提供する。ノードでそのハッシュを受け取ると、そのコンセンサスの提供が可能になる。
【００５６】
一実施形態によれば、所与の取引が本発明のシステム上で実行される場合、資産が交換される。例えば、外国為替取引のために、テイカーはドルでユーロを購入したい場合がある。取引に参入するメイカーは、ドルと引き換えにユーロを提供することになる。取引の開始時に、テイカーはドルでユーロを買いたいことがある。メイカーはドルと引き換えに販売するユーロを有している場合がある。一実施形態では、これらの通貨を表すトークンは、各当事者がそれぞれの法定通貨をカストディアン銀行(custodian bank)に預け入れた場合に作成されてよい。別の態様では、テイカーが所望の取引に加わるのに十分なドルを有している場合、そのドルを表すトークンがブロックチェーン内で作成されることになる。同様に、メイカーが所望の取引に加わるのに十分なユーロを有している場合、そのユーロを表すトークンが作成されることになる。テイカー及びメイカーが十分な資金を有しているという十分な兆候がある場合、トークンはブロックチェーン上で交換されてよく、このことは取引の完了を意味する。一態様では、トークンは、ブロックチェーン上のアカウント間で転送されてよく、持続してよく、１つのアカウントから効果的にデビットされ、別のアカウントにクレジットされる。アカウント間でトークンをクレジット及びデビットすることにより、資産の二重支出を防ぐ。トークンは、参加者がトークンを「現金化する(redeem)」こと及びカストディアン銀行から通貨を引き出すことを決定するまで残り、その時点でトークンは消却される(burned)。別の態様では、トークンは永続的ではない。この別の態様では、取引が完了すると、即ち、取引の両当事者がそれぞれの資金の受領を確認すると、トークンは処分され、即ち消却される。トークンを消却することは、資産の二重支出を回避する１つの方法である。取引が完了すると、テイカーはユーロを手にし、メイカーはドルを手にする。
【００５７】
本発明の態様によれば、トークンの交換は、メイカー及びテイカーが当事者となってよい任意の取引に関して生じ得る。典型的には、そのような取引は、アカウント間での金融資産の電子的交換を伴う。例としてここで論じられるように、本発明の態様は、外国為替（ＦＸ）マーケットに適用可能である。資産は異なる通貨であり得る。
【００５８】
また、先に言及したように、以下の議論のいくつかは、完全に担保されたフィアットコイン（ＦＣＦＣ）と発明者らが命名したものを説明している。ブロックチェーン等の分散型台帳技術システムにおいて交換されるデジタル情報であって、通貨を表し又は意味するデジタル情報には、当業者に知られている種々の名称がある。重要なのは、ＦＣＦＣはブロックチェーン内に単独で存在するということである。いくつかの実施形態によれば、ＦＣＦＣは、より具体的には、プライベートの許可されたブロックチェーン内に存在する。ＦＣＦＣが存在するプライベートの許可されたブロックチェーンの外でＦＣＦＣをマイニングし又は売買する機会はない。実際には、後で論じるように、一部のマーケット参加者にとっては、更なる後続の使用のためにＦＣＦＣをそのままにしておくことに利点がある場合がある。例えば、カストディアン銀行が支払うであろう翌日物金利は、ＦＣＦＣの保有者にとって魅力的である場合がある。
【００５９】
従って、一実施形態では、ＦＣＦＣは永続的であってよく、一旦取引が完了すると処分されなくてよい。本発明の実施形態が動作するブロックチェーン環境はプライベートであり許可されるものであるので、その環境は閉じられている。その結果、参加者が撤退し、カストディアン銀行が参加者に資金を電信送金する旨のメッセージを送信されたときにＦＣＦＣは消却されてよい一方で、それ以外の場合には、ＦＣＦＣはブロックチェーンから離れない。それらは、それらの価値を変えるような方法で「マイニング」又は交換されることはない。代わりに、ＦＣＦＣは、閉鎖システム内で、ＦＣＦＣが発行された法定通貨に対応する価値を保持する。結果として、ＦＣＦＣは存続してよい。
【００６０】
以下では、ＦＸ取引は、２当事者が通貨を交換する売買と称されてよく、例えば、ドル（ＵＳＤ）がユーロ（ＥＵＲ）に、英ポンド（ＧＢＰ）が円（ＵＰＹ）に交換される。買い手と売り手の間の交換について言及する場合、売買(trade)及び取引(transaction)という用語は交換可能に用いられてよい。現在、上記４つの通貨に加えて、カナダドル（ＣＡＤ）及びオーストラリアドル（ＡＵＤ）が、ＦＸマーケットで売買されている外貨の大部分を占める。特に人民元（（ＲＭＢ）及び韓国ウォン（ＫＲＷ）を含む多くの通貨の売買には制限がある。これらの制限自体は、本発明には関係しない。そのような制限が解除されたとき、又は解除されるとすれば、本発明によって提供される技術を用いてこれらの通貨で売買することも同様に有益である。
【００６１】
別の方法で本発明の態様を見ると、外国為替取引の同日売買及び決済を実装するシステムの１つの重要な態様は、所与の取引に対して資金を当事者間でリアルタイムに移動するのに必要な支払いプロセス（支払いレールと称されることがある）に関連する。これらの当事者は、貸し手、テイカー、及びメイカーを含んでいてよい。貸し手は、メイカー又はテイカーのいずれかにオンデマンド支払い流動性を提供することができ、メイカー又はテイカーは、アクティブなトレーダーであってよいが、各取引の支払いをリアルタイムで可能にするために必要な資金を維持していない場合がある。異なる貸し手が異なるメイカー及びテイカーに同様の方法でサービスを提供してよい。本発明の態様によれば、貸し手の存在及び参加により、特定の取引が完全に資金提供されていることを検証することが可能になる。各当事者は、他の当事者が取引の結果を即座に決済することが可能であることを確認し得るので、そのような検証（取引の検証）は重要である。
【００６２】
本発明の態様によれば、所与の取引中に以下のアクションが起こり得る（ここでは、一例として外国為替（ＦＸ）取引が提供される）。第１に、貸し手は、リスクのないベンチマークレート、例えば米国トレジャリービル(US Treasury Bill)（Ｔ−ビル）レートを超えるスプレッド（範囲内）で顧客（取引の買い手又は売り手のいずれか）に資金を提供してよい。第２に、顧客（ここでも、買い手又は売り手のいずれか）は、提供された資金を現金担保として提供してよく、例えばＴ−ビルレートのリターンを支払われてよい。ＦＸ取引の参加者は、取引を完了する前に資金調達を確保するので、取引はリスクがなく、顧客は取引全体のＦＸコンポーネントのクレジットスプレッドを排除することができる。その結果、クレジットは取引自体から分解される。
【００６３】
この分解の１つの効果は、デリバリーリスクの排除である。そのリスクに対処することは、ＦＸ取引の完了に非常に長い時間を要してきた原因の一部であった。デリバリーリスクの排除には、以下の考慮の一部又は全てが伴う。先ず、世界的に共通の銀行取引日がないということは、遅いタイムゾーンからの資金の受領を待つ間、支払いを１日早く行う必要がある可能性があることを意味する。例えば、テイカーとメイカーは異なるタイムゾーンにいる場合があり、多くの場合、国際日付変更線の反対側にいる。本発明の一態様によれば、売買日の取引の両側での同時又はほぼ同時（数秒から数分、ことによると数時間の差）の決済があり、このようにしてデリバリーリスクを排除する。決済までの時間が短いということは、テイカー及びメイカーがはるかに迅速に資金を得て、その結果、所与の日に多くの取引に加わることができることを意味する。結果として、決済の速度が高まり、従ってマーケットで利用可能な流動性が高まるという追加の利益がある。このように、ＦＸ売買の貸付態様を売買自体から分解することにより、本発明の態様は、売買が実行される時点で完全に資金提供されていることを保証する。その結果、メイカーが帳簿に莫大な金額の資本を持ち込む必要性が大幅に減少する。
【００６４】
また、本発明の態様によるＦＸ売買は、通貨監督庁(Office of the Comptroller of the Currency)（ＯＣＣ）が追跡する４つの主要なリスクを軽減する。これらのリスクのうち第１のリスクはクレジットリスクである。本発明の態様によれば、売買は「資金調達後売買」に基づいて実行される。全ての売買は完全に現金で担保されていることにより、クレジットリスクが軽減される。第２のリスクは流動性リスクである。本発明の態様によるＦＸ売買内での貸付の分解により、新しい貸し手が事業に参入し、マーケットへの漸進的な流動性提供者として機能することができる。
【００６５】
第３のリスクは価格リスクである。残りの取引からの貸付の分解により、メイカーはスポットＦＸ取引のみを取引する。その結果、そうでなければ従来の売買でオープンフォワードポジションになったであろうものが排除される。運用リスクとの関連で、この分解にはいくつかの利点がある。第１に、本発明のシステムにおいては、即時且つ不変の売買確認があり、ストレートスループロセッシング(straight-through processing)（ＳＴＰ）をまだ完全に採用していない従来の取引確認プロセスの必要性を排除する。ＳＴＰは、人間の介入を少なくすると共に特定の種類のデータを複数回再入力する必要性を回避することによって、金融機関が決済時間を短縮するために用いる技術である。第２に、世界各国で一貫性のない銀行営業時間によって支払いが制限されなくなる（例えば、米ドルが受け取られる前日に円が支払われる）ので、デリバリーリスクが排除される。第３に、既に論じたように、適切なデータを受信すると自己実行するコードである「スマートコントラクト(smart contracts)」の使用により、売買の失敗が大幅に減少する。第４に、メッセージング／ＳＷＩＦＴ（登録商標）（Society for Worldwide Interbank Financial Telecommunication）コスト、銀行振込手数料、及びより効率的なプロセスを通した人件費の削減により、運用コストが低減される。
【００６６】
本発明の態様によれば、クレジット機能を取引から分解し、ＦＸや金利デリバティブ等、以前はアクセスできなかったマーケットへの全く新しい独特の参入を提供するシステムが提供される。
【００６７】
本発明の態様によれば、ブロックチェーンを調べる別の方法は、ピアツーピアネットワークとして、カウンターパーティ間で直接支払いを可能にし、中央クリアリングハウスの必要性を取り除くことである。この種の取り決めは、通常の営業時間外に支払いがなされることを必要とし、それを可能にし、本発明の態様によるブロックチェーン上で記憶されたデータの不変性は、現在のフレームワークと比較して、より低いリスク及びはるかに効率的な運用をもたらす。
【００６８】
本発明の態様によりブロックチェーン、即ち分散型台帳ネットワークを介して渡される命令は、資金調達について事前に確認されると共にブロックチェーン技術に固有の不変性により変更され得ないという二重の利点を有し、従って資金の二重利用を防ぐ。
【００６９】
本発明の態様によりプライベートの許可されたブロックチェーンネットワークを介して取引を行うことは、両当事者（テイカー及びメイカー）が価格について合意すると、両当事者による実質的に即時の支払いを生じさせる。両当事者は、独力で又は参加している貸し手を介して資金調達する必要がある。従って、両当事者は、ディール適格見積もりを見せる前に、ブロックチェーンを介して、デリバリーに必要な通貨を有していることを実証する必要がある。適切な資金の確立は、スマートコントラクトが自己実行することができるようにするものの１つの態様である。
【００７０】
本発明の態様によるピアツーピア支払いの使用は、全ての売買、例えばＦＸ売買が、その事実の後に資金提供されるのではなく、事前に資金提供されることを意味し、ＦＸ取引のかなりの部分が裸の空売り(naked short sales)として実行されている現在の実務から根本的に逸脱する。裸の空売りにおいては、売り手は、取引が実行されるときに、ドルであろうと外貨であろうと、届けるべき通貨を有していない。売り手は通貨を得なければならず、買い手は売り手が通貨を得たことの証明を必要とする。結果として生じる信頼の欠如（デリバリーリスク）は、取引に資金提供するための長いタイムラインを生じさせる。
【００７１】
対照的に、本発明の態様によれば、本発明の態様が提供する「資金調達後売買」モデルにおいては、全ての取引は、資金が、履行が可能になる前に関連カウンターパーティによるデリバリーに対して既に利用可能である旨の確認を必要とするので、裸の空売りは生じない。従って、この事前資金調達は、スポット取引のクレジット／デリバリーリスクを本質的に排除する。ある実体がそのアカウントにおいて利用可能な資金を有していない場合、その実体は取引に加わるために資金を借りる必要がある。そうしないと、取引に関連付けられたスマートコントラクトが実行されず、売買が生じない。
【００７２】
スポット取引の結果は２つある。第１に、事前資金調達及び取引の非常に迅速な達成により、クレジットリスクは極めて短期的である。第２に、そのような短期では、同じ資金が所与の日に複数回再貸し出される可能性がある。条件が合意されると、スマートコントラクトが作成され、資金は第３の当事者であるカストディアンに届けられてデリバリー日まで分離されるので、先渡取引は、貸し手によるより長いコミットメントを必要とする。デリバリー日に、取引を監督しているスマートコントラクトがデリバリーをアクティブにし、ディールが完了する。借り手に融資がなされていれば、直接それを貸し手に返済する。一態様では、返済はブロックチェーン上で生じる。別の態様では、返済はブロックチェーンの外部で生じる。
【００７３】
本発明の実施形態によれば、プロセスフローは所定の仮定で進行する。例えば、貸し手会社は、借り手に対して独自のクレジット分析を行い、クレジット限度を割り当ててよい。代替的又は追加的に、貸し手会社は、借り手のリスト及び貸し手プラットフォームに対するそれぞれの限度を提供してよい。また、貸付期間がたまたま何であれ、借入をカバーするのに十分高い限度がある場合、融資は自動承認されてよい。
【００７４】
借り手（テイカー又はメイカー）は、資金調達を取得及び／又は検証することによって売買プロセスを開始してよい。借り手は、全額、又は調達資金の一部がデポジットされている場合にはその一部を借りてよい。借入情報は、期日（開始／実行日及び返済日）の他、金利を含んでいてよい。取引の種類又は貸し手若しくは借り手の好みに応じて、借り手が借りようとしている通貨が指定されてもよい。借り手は、借り手に貸し付けることに同意した貸し手であって、借り手に貸し付ける能力を有する貸し手に示されてよい（例えば、貸し手の限度は、要求された金額及び融資の期間に対して十分である）。
【００７５】
借り手は融資の申し出を受け入れることができ、その時点で借り入れ記録が作成されてよい。貸し手と借り手の両方に、貸付（買い手又は売り手の取引の借り入れ部分）が発生したことが通知される。借り手は、融資が受け入れられたことを通知されてよい。貸し手はメッセージを受け取ってよく、あるいは代替的にはプラットフォーム上で直接新しい融資の機会を見ることができてよい。
【００７６】
借入取引が完了すると、資金は、資金を支払うべきカウンターパーティーの貸し手アカウントから確保されてよい。借り手は、取引の一部に対して資金調達を確保してもよく、この場合、資金は借り手から直接調達され得ると共に資金を支払うべきカウンターパーティーから調達され得る。一態様では、例えば、特に大規模な売買の場合、借り手が複数の貸し手から借りることが可能であってよい。複数の貸し手がそのような取引に参加することを望むことがあり、個々の貸し手の限度は特定の取引をカバーするのに十分高くないことがある。借り手が１つ又は全ての貸し手から受取金を受け取ることがより効率的であることがあり、また単一のソースから一度に全ての資金を取引に提供することがより効率的であることがある。この後、取引（手元の例では外国為替取引）が完了する。
【００７７】
一態様では、売買に関連する１つ以上のスマートコントラクトが実行される前に、売買をキャンセルすることができる。例えば、テイカーは、取引を閉じる前に、見積もりを要求し、資金調達を手配し、キャンセルすることができる。システムはブロックチェーン上で単純なキャンセル機能を有することができ、決済はシステム外（ブロックチェーン外）で生じ得る。取引のキャンセルについては、以下で詳しく説明する。また、一態様では、融資の早期返済のための前払いペナルティの規定があってよい。
【００７８】
一態様では、貸し手は、２つのタイプの情報を利用可能にしてよい。１つのタイプの情報においては、貸し手は、各通貨の貸付に利用可能な金額、及び特定の融資がある場合にはその期間を指定してよい。クレジット限度は、通貨、期間、及びクレジット格付けによって割り当てられてよい。
【００７９】
一態様では、全体のクレジット限度は、各借り手に通貨ごとに拡張されてよい。期間又は通貨による限度があってもよい。即ち、例えば、異なる期間に対して１つ以上のレートが存在する場合がある（例えば、１日、１週間、１か月、又は複数月の期間のレート）。また、例えば、特定の通貨に対して異なるレート及び／又は期間が存在する場合がある（例えば、ボラティリティの低い通貨又はボラティリティの高い通貨に対して、より低い又はより高いレート及び／又はより短い又はより長い期間）。
【００８０】
一態様では、システムは、上記で論じた線に沿って複数の通貨をサポートしてよいが、限度及び期間は、特定の通貨、例えばデフォルト通貨に対して定義されてよい。特定の限度に適用可能なものとして他の通貨が指定されてよく、未払いの融資又は申し出は、現在の為替スポットレートで限度通貨に変換されてよい。また、一態様では、借入取引の通貨が多通貨ファシリティに含まれている場合、問題の顧客に対して別個の限度を有するものとしてその通貨を設定することは適切でないであろう。
【００８１】
一態様では、貸し手は、貸し手が通貨ごとに個々の借り手に又は借り入れベース全体の一部若しくは全部に貸し出す意思のある合計金額を指定することができる。借入ベースは、限定はされないが、収入、融資期間、申し出のあった金利、又は信用力（クレジット格付け）に従って借入ベースを分割することを含むいくつかの既知の方法のいずれかで分割されてよい。貸し手は、借り手に関する情報（一態様では、一般的にリスクプロファイル、融資の種類、期間、通貨等に従う）を用いて、種々の時期に種々の金額で種々の貸付金利を案出し申し出ることできる。
【００８２】
ここで論じられるシステムの態様は、テイカーとメイカーのマッチングを容易にし得る。このマッチングの一部として、システムの態様は、テイカーと貸し手の間、メイカーと貸し手の間、又はテイカー及びメイカーの各々とそれぞれの貸し手との間の取引を容易にし得る。１つ以上の貸し手は、将来の売買が完全に資金提供されるために、テイカー又はメイカーのいずれかが不足している必要な資金を提供してよい。
【００８３】
一態様では、ブロックチェーンは、管理者、リーダー、又はマスターによってホストされる比較的少数のノードを有していてよい。テイカー、メイカー、及び貸し手は、ブロックチェーンへのアクセスを得るために管理者／マスターを通過する。別の態様では、ブロックチェーンは、テイカー、メイカー、及び貸し手のための複数のノードの他、マスターノードを有していてよい。例として、テイカー、メイカー、及び貸し手ごとに１つのノードがあってよい。別の例として、テイカー、メイカー、又は貸し手よりも少ないノードがあり得る。この場合、これらの参加者の一部は、管理者／マスターを経由してブロックチェーンにアクセスしてよい。代替的には、当業者は、１つの取引のテイカーが別の取引のメイカーであってよいことを理解するはずである。種々の参加者は、単一のノードにアクセスしている間、又は管理者／マスターを介してブロックチェーンにアクセスしている間、異なる役割を果たす。当業者は、一実施形態による所与のシステムにおいて、複数のテイカー、複数のメイカー、及び複数の貸し手が存在することがあり、通常は存在することを理解するはずである。また、１つの取引のテイカーは、後続の取引のメイカーであってよい。貸し手は、テイカー又はメイカーのいずれか、又は場合によっては両方と関係を有していてよい。
【００８４】
本発明の態様に従って用いられてよいブロックチェーン、即ち分散型台帳ネットワークの一例はクォーラム(Quorum)であるが、当業者が理解するように、適切であろう他のものもある。クォーラムの例示的な説明として、米国公開特許出願番号２０１７／０２８９１１１及び２０１８／０１８３７６８が参照によりここに組み込まれる。これらの公開特許出願は、ここで後述するように、データプライバシーを可能にする。
【００８５】
当業者が理解するように、そして先に論じたように、ここで説明されるタイプの取引を取り扱うブロックチェーンは、そのノードをコンセンサス機構に従って動作させる。ＲＡＦＴは当業者に知られているので、ここではこれ以上説明しない。ＩＢＦＴは、ビザンチンフォールトトレラント（Byzantine Fault Tolerant）機構、即ちＢＦＴ機構として知られるコンセンサス機構のファミリーの１つである。当業者も同様にＢＦＴ、ＩＢＦＴ等を理解しているので、ここではそれらの説明を繰り返さない。クォーラムは、ＩＢＦＴ又はＲＡＦＴコンセンサス機構のいずれかで動作する。一実施形態では、ブロックチェーンアーキテクチャは、ＲＡＦＴコンセンサス機構を備えたクォーラムである。
【００８６】
ＲＡＦＴは、ＩＢＦＴよりも集中化されたコンセンサス機構である。動作のいくつかの態様を管理及び運営するための動作ＵＩ及び管理者ＵＩを有するここで説明される実施形態等のいくつかの実装形態においては、制御はより集中化されてよい。集中化が進むと、単一の攻撃ポイントが生じる可能性が高くなるが、ブロックチェーンのプライベートの許可された性質と、記録の複製ハッシュがブロックチェーン全体に記憶される分散型台帳の態様とが相まって、ハッキングの試みが成功する可能性は低くなる。
【００８７】
当業者は、プルーフオブワーク（ＰｏＷ）、プルーフオブステーク（ＰｏＳ）、又はプルーフオブオーソリティ（ＰｏＡ）等の他のタイプのコンセンサス機構がブロックチェーンシステムにおいて用いられてよいことを理解するはずである。当業者はまた、待ち時間、計算強度、及び他の潜在的なトレードオフが、１つのコンセンサス機構を別のコンセンサス機構よりも有利にする場合があることを理解するはずである。
【００８８】
図１は、複数のユーザインターフェース（ＵＩｓ）を介したメイカー、テイカー、及び貸し手との相互作用を示している。また、メイカー、テイカー、及び貸し手と通信してシステムの態様を管理するための管理者ＵＩもある。管理者ＵＩは、先に論じたＵＩｓのいずれかに表示された情報のいずれか又はすべてを表示するための１つ以上の画面を有していてよい。一態様では、管理者ＵＩはまた、全体的な財務実績、受け取った報酬、取引履歴等に関連する項目を含む管理関連項目を表示してよい。管理者ＵＩはまた、クライアント（テイカー、メイカー、貸し手）、潜在的なクライアント、取引、保留中の取引、及び取引を実施するための他のおそらく関連するデータのマスターライブラリを含む１つ以上のアプリケーションの要素にアクセスしてよい。
【００８９】
システム全体の動作のための動作ＵＩもある。このＵＩでは、いくつかの態様において、現在、保留中、及び／又は最近の取引のためのマネージャ及び／又はキャッシュへのアクセスがあってよい他、アクセス、及び適切な場合又は適用可能な場合には、ブロックチェーン上での挙動を統制する一連の規則を管理及び／又は編集する能力があってよい。
【００９０】
一態様では、テイカーのためのＵＩは、売買の申し出（取引に参入する意図）、売買の作成、売買ステータス、及び取引履歴を表示してよい。該当する場合、そのＵＩは、テイカーの未払いの融資及び残高並びに融資履歴を表示する他、テイカーに対する融資記録へのアクセスを提供してもよい。メイカーのためのＵＩは、潜在的な売買、売買ステータス、及び取引履歴を表示する。該当する場合、そのＵＩは、メイカーの未払いの融資及び残高並びに融資履歴を表示する他、メイカーに対する融資記録へのアクセスを提供してよい。所与の貸し手を伴うＵＩは、借り手（テイカー又はメイカーであってよい）との貸し手ポジション、貸し手の条件、借り手との合意、未払いの融資、及び融資履歴を表示する他、任意の融資記録へのアクセスを提供してよい。
【００９１】
一態様では、テイカーＵＩ又はメイカーＵＩのいずれかとは別に、又はその一部として、特に融資の申し出、融資の受諾、未払いの融資、融資の返済、及び融資履歴を反映する、一般に借り手のためのＵＩがあってよい（図示せず）。従って、貸し手が資金提供に関与し又は所与の取引に資金提供するための入札に関与する場合、借り手が誰であるか（ここでは、テイカー又はメイカーのいずれか）に応じて、その借り手を伴うＵＩは、その借り手に対して、借り手が受け取った融資の申し出、借り手が行った融資の受諾、借り手に対する未払いの融資、借り手が行った融資の返済、及び融資履歴を表示してよい。
【００９２】
一態様では、システムオペレータ（自動化されていても人間であってもよい）は、複数のアプリケーションプログラミングインターフェース（ＡＰＩｓ）を介して、種々の銀行、貸し手、及び他の金融機関と連携してよい。本発明の一態様は、世界中の銀行、貸付機関、及び他のそのような機関等の金融機関が各々固有の又は少なくともいくらか異なるアプリケーションプログラミングインターフェース（ＡＰＩ）を有する傾向があることである一方で、ここで説明される種々の金融取引を容易にする本発明のシステムは、それらＡＰＩｓのいずれか又は全てと共に機能することを目的としている。一実施形態では、本発明のシステムは、これら種々の金融機関がインターフェースすることができる単一のＡＰＩを有する。いくつかの態様においては、システムは複数のＡＰＩを提供してもよい。規制又は単に効率の観点からは、金融商品、証券等を伴うＦＸ及び他のタイプの取引は、ブロックチェーンネットワーク上で実行するように設定されているので、特定のタイプの取引に対してＡＰＩを標準化することが望ましい場合がある。但し、実際には、金融機関間では、ほとんどの場合、全てのＡＰＩが異なり、個々の金融機関の好みに合わせて調整される。従って、一実施形態では、複数の金融機関のＡＰＩｓとの互換性を提供するマーケットファクトリー(Market Factory)等のサービスが呼び出されてよい。マーケットファクトリー等のサービスを用いると、取引に参加する可能性のある全ての実体に対して、数十（又はそれ以上）のＡＰＩｓを用意する必要性を省くことができる。
【００９３】
一実施形態では、取引のログ、取引の注文をリストするオーダーブック、行われた融資のログ、保留中の融資取引、ユーザプロファイル、並びに監査及びロギングの規則及び実務を格納し得るデータベースがあってよい。上記のマスターライブラリは、このようなデータベースに格納されていてよい。上記のキャッシュの内容もまた、特にキャッシュに対する規則やキャッシュのサイズに応じて、データベース内にあってよく、あるいは一定期間後にデータベースに自動的に転送されてよい。当業者は、どのようにキャッシュをデータベースに関連付けてシステム全体で適切な動作を実施するのかをよく理解しているはずである。
【００９４】
一態様では、テイカー、メイカー、及び貸し手の各々は、資金へのアクセスを統制しているシステムに対する償還請求権(recourse)を有することになる。説明の一貫性のために、図１においては、これらのシステムは銀行システムと称されるが、ここでの「銀行」とは、厳密な意味での銀行機関ではなく、単に資金源を参照することが意図されていることを理解すべきである。
【００９５】
図１を更に見ると、ＵＩs及びＡＰＩｓはＡＰＩゲートウェイを介して接続している。一実施形態では、そのゲートウェイは、アマゾンＡＰＩゲートウェイを用いて実装されてよい。認証モジュールは、ＵＩの１つを介してシステムにアクセスしているユーザが認証されることを可能にする。一実施形態では、認証モジュールは、アマゾンコグニト(Amazon Cognito)を用いて実装されてよい。ユーザが認証されると、ＡＰＩゲートウェイを介して権限が与えられてよい。一実施形態では、認証モジュールは、実際のユーザとリンクする必要がある。図２に示すように、そのリンクは、ユーザセッションブローカーによって実施されてよい。
【００９６】
実施形態によれば、複数のＦＸ取引を実施するために、１つ以上のカストディアン銀行が種々の通貨で資金を提供する。状況に応じて、単一のカストディアン銀行が複数の通貨で資金を提供してよく、複数のカストディアン銀行が同じ通貨で資金を提供してよく、あるいは各カストディアン銀行が単一の通貨で資金を提供してよい。ＦＸ取引のための資金の利用可能性は、ＦＣＦＣプロセスに対する入力の一部であり、これらのプロセスは、ここでより詳細に論じられることになるが、図１ではそれぞれのブロックとして示されている。尚、ＦＣＦＣプロセスブロックは、図１においてブロックチェーンの外側に現れている。但し、これらのプロセスの特定の態様、例えばＦＣＦＣ自体は、ブロックチェーン上にある。テイカーとメイカーの間のＦＣＦＣの交換を伴う入出金の記録は、１つの態様に従うと、ブロックチェーン上に記録される。加えて、一態様においては、売買の開始及び実行もブロックチェーン上に記録される。残高の検証もまた、ブロックチェーン上の記録にアクセスすることによって実施されてよい。最後に、貸し手と借り手（テイカー又はメイカー）の間の融資契約は、ブロックチェーン上で保持されてよい。
【００９７】
前述のように、ブロックチェーンはオラクルと呼ばれる信頼できるソースからデータを受け取る。図１が示すように、オラクルは種々の状態マシンと通信し、これらの状態マシンは、図１においては別々に示されているが、本発明の態様によるシステムの代替的実施形態を示す図２においては、単一の実体として示されている。図３〜５はこれらの状態マシンを示しており、これらについて以下で更に詳細に説明する。状態マシンはシステム内の中央ストレージとも通信する。これはブロックチェーンとは別のストレージであり、ブロックチェーン上に記憶されている記録だけでなく、ここで論じられる種々の追加的な記録も含んでいてよい。
【００９８】
ＵＩｓ及びスマートコントラクトの一方又は両方に基づいて、オラクルは、テイカー及びメイカーの身元（アドレス）、関連する通貨、並びに関連する金額を含む特定の取引の詳細をつなぎ合わせる。オラクルは生の取引を鍵管理サーバに送信し、鍵管理サーバは鍵を生成し、生データに署名し、署名されたデータを返す。図１及び図２の実施形態においては、鍵管理は集中化されている。他の実施形態では、各個々の機関が独自の鍵を管理してよい。
【００９９】
図１及び図２の実施形態では、集中化された鍵管理の一部として、ハードウェアセキュリティモジュール（ＨＳＭ）は、一実施形態による暗号化された取引のための秘密鍵を生成する物理的に別個のデバイスである。システムユーザ（メイカー、テイカー、及び貸し手）は、それら独自の秘密鍵を生成する代わりに、この実施形態ではこれらの秘密鍵を用いる。ＨＳＭは秘密鍵を生成するだけでなく、それらを保持して、複製及び／又はハッキングを妨げる。
【０１００】
鍵を生成可能にするために、トークンを最初に初期化する必要がある。オラクルは、初期化を行うために鍵管理サーバを介してＨＳＭに要求を発行する。オラクルは信頼できるソースであるので、ＨＳＭが初期化を行うことになる。次に、ユーザＰＩＮを設定する必要がある。この要求は、オラクルから鍵管理サーバを介してＨＳＭにも届く。要求に応答して、ＨＳＭはユーザＰＩＮを設定する。
【０１０１】
次に、オラクルは、鍵の生成を要求する。ＨＳＭは、鍵管理サーバを介してこの要求を受け取り、鍵を生成する。最後に、オラクルはＨＳＭに取引に署名するように要求する。この場合にも、要求はオラクルから鍵管理サーバを介してＨＳＭに届く。オラクルからの生の取引データに応答して、ＨＳＭはそのデータをハッシュし、ハッシュに署名し、署名されたハッシュを返す。
【０１０２】
１つ以上のメッセージサービスは、前述のように認証において役割を果たす種々のＡＰＩｓ間とシステムの他の部分とのメッセージング通信を容易にする。種々の実施形態において、アマゾンのシンプル通知サービス(Simple Notification Service)（ＳＮＳ）又はシンプルキューサービス(Simple Queue Service)（ＳＱＳ）は、示されたメッセージングサービスを提供してよい。ＳＮＳはメッセージをプッシュする一方で、ＳＱＳはそれらメッセージをキューに入れる。
【０１０３】
一実施形態では、テイカーは、システム内のＵＩに直接接続し、そのＵＩを介して売買を実行する。
【０１０４】
一実施形態では、メイカーは、テイカーとの売買を確認する人であり得る。代替的には、メイカーはアルゴリズムを採用し得る。メイカーはシステムにアクセスして売買を利用可能にする（即ち、売買での金利を示す）。一実施形態では、メイカーはそれら独自のＵＩｓを有する。このような状況においては、マーケットファクトリー(Market Factory)等のサービスの使用は、より多くのメイカーをシステムに接続することを容易にし得る。
【０１０５】
一態様では、当業者は、テイカーが、受け入れたい取引があるかどうかを確認しようとするだけであるから、テイカーは彼ら自身のＵＩを必要としなくてよく又は気にしなくてよく、あるいは必要とせず又は気にしないことを理解するはずである。
【０１０６】
図３はデポジット取引のための状態マシンの図を示しており、このデポジット取引においては、資金がシステムに入力され、完全に担保されたフィアットコイン（ＦＣＦＣ）が、資金を入力しているユーザに転送される。ブロックチェーン用語では、「トークン」という用語は慣用的に用いられている。トークンは作成され、多くの場合、使用後に消却される。本発明の一態様では、後述するように、トークンは、使用後に消却される必要はない。代わりに、トークンをシステムに保持して、更なる取引に用いることができる。ＦＣＦＣは、トークンの通貨表現である。ＦＣＦＣは、ＦＣＦＣが各国の法定通貨、例えば、米ドル（ＵＳＤ））、オーストラリアドル（ＡＵＤ）、ユーロ（ＥＵＲ）、英国ポンド（ＧＢＰ）、カナダドル（ＣＡＤ）、及び日本円（ＪＰＹ）に関連付けられているという点で、暗号通貨の世界のトークンとは異なる。
【０１０７】
図３を見ると、３０５で資金が電信送金され、３１０でデポジットが開始される。システムの態様は種々のエラーを考慮しており、これらのエラーは３９９の例外状態につながる。例えば、ブロックチェーンが認識しないアカウントに資金を電信送金しようとする等の資金入力でのブロックチェーンエラーが例外につながる可能性がある。
【０１０８】
資金の入力に問題がないとすると、３１５でトークンが作成され、ＦＣＦＣアカウントに転送される。この場合にも、認識されないアカウント、転送エラー（例えば、転送の完了を不能にするシステム異常）、又は誤ったユーザアドレス等のブロックチェーンエラーが発生する可能性があり、これらは全て例外条件３９９につながる。作成及び転送に問題がないとすると、３２０でデポジットが決済される。
【０１０９】
デポジットプロセスをもう少し詳しく見ると、資金が銀行に電信送金されたときに、銀行はトークンがマイニングされるように指示する。トークンはブロックチェーン上にある。
【０１１０】
図４は、払い戻し取引のための状態マシンの図を示している。払い戻しの状況では、資金はユーザに返還され、二重支出の状況を回避するために、根源的トークン（ＦＣＦＣ）が消却される。図４を見ると、４０５でトレーダー（メイカー／テイカー）は払い戻しを要求してよい。４１０で払い戻し要求が処理され、開始される。最初に起こる必要があることは、二重支出を避けるために、払い戻されるべき資金を凍結する必要があるということである。従って、４１５で凍結が開始される。状況によっては、そのフリーズ命令を送信又は適切に実装する際にエラーが生じることがある。４９９での例外がその結果である。
【０１１１】
４１５でも、凍結命令に対して承認が保留されている場合がある。ユーザは払い戻しをキャンセルすることを決めてよく、あるいはシステムは資金が凍結され得ないと決定してよい（例えば、払い戻しのサイズが払い戻しに利用可能な資金の金額を超えていることを理由として）。これらの状況のいずれにおいても、４３０で、払い戻しの要求がキャンセル又は拒否されてよい。
【０１１２】
資金が凍結されると、資金の転送にエラーが生じる場合がある（例えば、資金転送に対して誤ったアカウント情報が存在することがある）。この場合、状態は４９９で例外を返す。それ以外の場合、払い戻し要求は４２０でＦＣＦＣアカウントへの転送を呼び出す。４２５で、払い戻されるべき資金の金額に対応する数のＦＣＦＣが消却される。何らかのブロックチェーンエラー又は銀行エラーがある場合、例外条件が返される（４９９）。
【０１１３】
一態様では、売買の資金提供に利用可能なＦＣＦＣをシステム内に配置した貸し手もまた、払い戻しを要求してよい。状態マシンは、その払い戻しを実施するために、今説明したものと同様の工程を進む。
【０１１４】
図５は、売買取引のための状態マシンの図を示している。５０５での初期化の後、５１０で、売買状態は、テイカー及びメイカーの両方に資金提供されていることを確認することによって初期化される。５１５でテイカーの資金が凍結され、５２０でメイカーの資金が凍結される。一態様では、このシーケンスは、テイカーが売買を開始するものであることから生じ、従って、テイカーの資金が最初に見直されることになる。別の実施形態では、メイカーの資金が最初に凍結されてよい。５３５で、テイカーの資金又はメイカーの資金のいずれかの凍結が何らかの理由で失敗した場合、取引はキャンセルされる。
【０１１５】
５２５で、テイカー及びメイカーの両方の資金が凍結された後、売買が実行され、最終価格が設定されてよい。一実施形態では、資金が凍結されると、凍結された金額は合意された価格を超え、単なる例としては、テイカー資金及びメイカー資金の両方に対して、合意された価格の１０１％となる。凍結額は、売買における利息のメイカーによる最初の指示と、テイカーとメイカーの間の価格に関する合意との間の値の変動の可能性を考慮して、合意された価格よりも高い。金額を少し高く設定することにより、資金不足による取引の無効化を防ぐことができる。当業者は、価格が上がるのではなく下がると、凍結された十分な資金があることになるので、取引が進み得ることを理解するはずである。本発明の態様による取引は非常に短期間で生じるので、１０１％の数字は、普通でない通貨変動を除いて全ての変動を包含することが意図されている。何らかの理由で金額が不足している場合、取引はキャンセルされる。
【０１１６】
最終価格が設定されると、５３０で売買は確認のためにメイカーに送られる。メイカーが確認した場合、その状態は５４０で設定される。資金が送金され、５５０で売買が決済される。メイカーが売買を拒否することを決定した場合、５３５で取引がキャンセルされる。５９９では、資金を転送している間のエラーを考慮して、例外条件が設定されている。
【０１１７】
一実施形態によれば、例えば図１においては、説明された各状態マシンは、別個のサービスを構成してよい。別の実施形態では、例えば図２においては、説明された２つ以上の状態マシンは、単一のサービスへと組み合わされてよい。
【０１１８】
図３〜５のこの議論は、議論に値するいくつかの態様を提示している。第１に、一般に、本発明の態様は、外国為替取引等の金融取引が、それらが成立する前に、場合によってはテイカー及びメイカーが条件に合意する前でさえ、資金提供されることを可能にするので、取引の決算は以前よりもはるかに速く生じ、これは、各当事者が取引に加わることができるかどうかを当事者が互いに確認する必要がないからである。第２に、図３〜５の前述の議論においては、資金の借り手（テイカー及び／又はメイカー）が融資をすぐに返済するのか、所定の期間内に返済するのか、あるいは長期間にわたって返済するのかについての言及はなかった。例えば、テイカーが直ちに（例えば、当日の内に）行いたい一連の両替がある場合がある。一方では、頻繁なクレジット延期及び頻繁な融資返済は面倒であり得る。他方、貸し手は、場合によってはテイカー以外の誰かに再び貸し付けるのに資金が利用可能になるように、後でではなく早急に資金を取り戻すことを望むことがある。関連して、システム全体の管理者は、融資ごと、又は取引ごとに報酬を支払われてよい。その結果、システムの管理によっては、各取引の後に返済された融資金額を「乗せる」のではなく、それを受け取るという金銭的インセンティブがマネージャーや貸し手にあってよい。
【０１１９】
図６は、本発明の態様による外国為替取引のテイカー側の流れを示すフローチャートである。６０５で、テイカーは開始されるべき取引を識別し、その情報をブロックチェーン上で広める。６１０で、テイカーはメイカーからの申し出の利用可能性又は提示を待つ。一態様では、テイカーは利用可能な最良の選択肢を受け取る。別の態様では、テイカーは、取引に参入する意思がある可能性がある１つ以上のメイカーから応答を受け取ってよい。フローは、利用可能なメイカーディールが現れるまで当該待機をループする。６２０で、利用可能なメイカーディールがある場合、テイカーが取引を完了するのに十分な資金を有しているかどうかを決定する。尚、ここでは、メイカーを見つけること及び資金の十分性を決定することの順序は、図６に示される順番である必要はない。本発明の一態様は取引の事前資金調達であるので、テイカーは、取引を識別する前に、テイカーが取引に加わるのに十分な資金が、売買されるべき通貨で、テイカーのアカウントにおいて又は貸し手から利用可能であることを知りたい場合がある。一態様では、テイカーは、１つ以上の貸し手からクレジットを事前認定されているであろう結果、十分な資金にアクセスする準備が整っていることを知っているので、タイミングは取引の全体的な速度にとって必ずしも必須ではない。
【０１２０】
６２０で、テイカーが十分な資金を有する場合、６４０で、テイカー及びメイカーが交換を行うことに同意したとすると、テイカー及びメイカーの両方が完全に資金提供される。テイカーが十分な資金を有していない場合、６２５で、テイカーは、取引に十分な資金を提供するために、１つ以上の貸し手から融資の選択肢を提示される。一態様では、テイカーは、利用可能な最良の融資の選択肢を単に提示されてよい。６３０で、テイカーは貸し手を識別又は選択し、６３５で、テイカー及び貸し手は、通常はブロックチェーンから外れて、テイカーが取引に加わるための資金を提供するための契約を締結する。次いで、フローは６４０に進む。
【０１２１】
一態様では、図３の説明と一致して、資金の電信送金に応答して、ＦＣＦＣトークンはＦＣＦＣアカウントにおける残高として表される。代替的には、図６において、６４５で、トークンは、テイカー（テイカーが通貨購入を行うために用いている通貨）とメイカー（テイカーが購入しようとしている通貨で、メイカーが販売する意思がある通貨）の両方に対して作成される。これらのトークンはブロックチェーン内にとどまる。一実施形態では、図３に関して説明したように、ＦＣＦＣアカウントの残高に基づいて、取引を完了するのに十分な金額の凍結が生じる。代替的には、図６において、６５０で、それぞれの要求は、テイカーオラクル及びメイカーオラクルから（又は実施形態によっては単一のオラクルから）テイカー銀行システム及びメイカー銀行システムに出て、取引を完了するのに十分なテイカー及びメイカーのアカウントの金額を凍結する。テイカー及びメイカーの銀行システムが金額の凍結の確認を提供すると、スマートコントラクトは売買に対して完全に資金提供されていることを確認する情報を有しているので、６５５でこの取引のためのスマートコントラクトが実行される。６６０では、テイカー及びメイカーの銀行システム間で資金が交換される。一実施形態では、この工程は、ブロックチェーンの外側で行われる。図３で説明したように、作成されたＦＣＦＣトークンは、クレジット及びデビットとして異なるブロックチェーンアカウントに移動され得るので、将来の取引のために保持されてよい。作成されたトークンは、資金の払い戻しがある場合にのみ消却する必要がある。代替的には、図６に示すように、資金が交換された後、６６５で、外国為替取引を実施するために作成されたトークンが処分され、即ち「消却される」ので、これらのトークンは、例えば暗号通貨マイナー(miner)又は他の実体によって再び用いられ得ることはなく、従ってトークンの二重支出が回避される。
【０１２２】
図３の議論と同様に、図６のこの議論は、議論に値するいくつかの他の態様を提示している。第１に、一般に、本発明は、外国為替取引等の金融取引が、売買が成立する前に、場合によってはテイカー及びメイカーが条件に合意する前でさえ、資金調達することを可能にするので、取引の決算は以前よりもはるかに速く生じ、これは、各当事者が取引に加わることができるかどうかを当事者が互いに確認する必要がないからである。第２に、図６の前述の議論においては、借り手（この場合、テイカー）が融資をすぐに返済するのか、所定の期間内に返済するのか、あるいは長期間にわたって返済するのかについての言及はなかった。例えば、テイカーが直ちに（例えば、当日内に）行いたい一連の両替がある場合がある。一方では、頻繁なクレジット延期及び頻繁な融資返済は面倒であり得る。他方、貸し手は、場合によってはテイカー以外の誰かに再び貸し付けるのに資金が利用可能になるように、後でではなく早急に資金を取り戻すことを望むことがある。関連して、システム全体の管理者は、融資ごと、又は取引ごとに報酬を支払われてよい。その結果、システムの管理によっては、各取引の後に返済された融資金額を「乗せる」のではなく、それを受け取るという金銭的インセンティブがマネージャーや貸し手にあってよい。
【０１２３】
図７は、本発明の態様による外国為替取引のメイカー側の流れを示すフローチャートである。７１０で、メイカーは、テイカーとの可能な取引を待ち、それが興味のあるもの（例えば、入札する価値があるもの）であるかどうかを確認するためにそれを評価する。そうでない場合、７１５で、メイカーはそのテイカー取引を無視し、待機を続ける。取引が興味のあるものである場合、７２０で、メイカーが取引を完了するのに十分な資金を有しているかどうかを決定する。尚、ここでは、図６の場合と同様に、メイカーを見つけること及び資金の十分性を決定することの順序は、図７に示される順番である必要はない。本発明の一態様は取引の事前資金調達であるので、メイカーは、テイカーとの特定の取引機会に応答する前に、メイカーが取引に加わるのに十分な資金が、売買されるべき通貨で、メイカーのアカウントにおいて又は貸し手から利用可能であることを知りたい場合がある。一態様では、メイカーは、１つ以上の貸し手からクレジットを事前認定されているであろう結果、十分な資金にアクセスする準備が整っていることを知っているので、タイミングは取引の全体的な速度にとって必ずしも必須ではない。
【０１２４】
テイカーが十分な資金を有する場合、７４０で、テイカー及びメイカーが交換を行うことに同意したとすると、テイカー及びメイカーの両方が完全に資金提供されることになる。メイカーが十分な資金を有していない場合、７２５で、メイカーは、取引に十分な資金を提供するために、１つ以上の貸し手から融資の選択肢を提示される。７３０で、メイカーは貸し手を選択し、７３５で、メイカー及び貸し手は、通常はブロックチェーンから外れて、メイカーが取引に加わるための資金を提供するための契約を締結する。次いで、フローは７４０に進む。
【０１２５】
図６に関して既に言及したように、一態様では、図３の説明と一致して、資金の電信送金に応答して、ＦＣＦＣトークンはＦＣＦＣアカウントにおける残高として表される。代替的には、図７において、７４５で、トークンは、テイカー（テイカーが通貨購入を行うために用いている通貨）とメイカー（テイカーが購入しようとしている通貨で、メイカーが販売する意思がある通貨）の両方に対して作成される。これらのトークンはブロックチェーン内にとどまる。一実施形態では、図３に関して説明したように、ＦＣＦＣアカウントの残高に基づいて、取引を完了するのに十分な金額の凍結が生じる。代替的には、図７において、７５０で、それぞれの要求は、テイカーオラクル及びメイカーオラクルから（又は実施形態によっては単一のオラクルから）テイカー銀行システム及びメイカー銀行システムに出て、取引を完了するのに十分なテイカー及びメイカーのアカウントの金額を凍結する。テイカー及びメイカーの銀行システムが金額の凍結の確認を提供すると、スマートコントラクトは売買に対して完全に資金提供されていることを確認する情報を有しているので、７５５でこの取引のためのスマートコントラクトが実行される。７６０では、テイカー及びメイカーの銀行システム間で資金が交換される。一実施形態では、この工程は、ブロックチェーンの外側で行われる。図３で説明したように、作成されたＦＣＦＣトークンは、クレジット及びデビットとして異なるブロックチェーンアカウントに移動され得るので、将来の取引のために保持されてよい。作成されたトークンは、資金の払い戻しがある場合にのみ消却する必要がある。代替的には、図６に示すように、資金が交換された後、７６５で、外国為替取引を実施するために作成されたトークンが処分され、即ち「消却される」ので、これらのトークンは、例えば暗号通貨マイナー又は他の実体によって再び用いられ得ることはなく、従ってトークンの二重支出が回避される。この後、メイカーはテイカーからの関心のある更なる取引を聞くことに戻ってよい。
【０１２６】
尚、ここでの他のどこかで論じられるように、ある実体は、１つの取引ではテイカーになることを望み、別の取引ではメイカーになることを望むことがある。その結果として、所与の実体を特定の役割に限定する必要はない。貸し手はまた、手元の取引によっては、テイカー又はメイカーになることを望む場合がある。
【０１２７】
当業者は、取引の当事者、即ちテイカー及びメイカーが同様の工程に加わって、売買に参入する前に彼らの取引に資金提供されることを確実にし得るので、図６及び７の流れの間にはかなりの量の平行性があってよいことを理解するはずである。テイカーに関して図６に関連して上述した他の態様は、取引速度及び融資返済を含めて、メイカーにも適用される。
【０１２８】
図８は、本発明の態様による外国為替取引における貸し手の可能な参加の流れを示すフローチャートである。８２０で、貸し手は取引を待ち、この取引はいくつかの異なる方法のいずれかで貸し手に提示されてよい。これがどのように起こるのかを限定することなく、例えば、テイカー又はメイカーは、可能な貸し手が応対することができる取引を識別してよい。取引は、可能な融資であると貸し手が見なすために一般的にはポストされてよく、あるいはテイカー又はメイカーは、貸し手に働きかけて融資の可能性について直接問い合わせてよい。一態様では、融資を希望又は必要としているテイカー又はメイカーは、貸し手のリストから最良の選択肢を提示されてよい。貸し手は、彼らの条件を事前に利用できるようにすることができる。
【０１２９】
識別され又は提示された取引が興味のあるものである場合、８４０で、テイカー又はメイカーは、複数の貸し手からの競争ベースで、あるいは個々の貸し手との唯一のソースベースで、融資の選択肢を受け取ってよい。一態様では、テイカー又はメイカーは、利用可能なものの中から最良の選択肢を単に提示される。一態様では、貸し手は、期間、金利等を含む融資の選択肢を融資問い合わせ者（テイカー又はメイカー）に提示してよい。取引が貸し手にどのように届くのかに応じて、貸し手は他の貸し手と競合する入札を発表することになるかもしれないし、あるいは１対１ベースでテイカー又はメイカーと直接取引することになるかもしれない。
【０１３０】
８５０で、テイカー又はメイカーが受け取ってよい種々の融資及び貸し手の選択肢から、テイカー又はメイカーは貸し手を選択してよい。条件はブロックチェーンから外れて議論されてよい。当事者が融資条件に合意した場合、８６０で、貸し手は、テイカー又はメイカーと契約又は融資契約を締結することになる。８７０で、契約が完了すると、契約の他の当事者であるテイカー又はメイカーは、完全に資金提供される。８８０で、貸し手は次いで８２０に戻って、より多くの可能な取引を待つことができる。
【０１３１】
図９は、実施形態によるＦＸ取引の動作９００の全体的なシーケンスを示している。図示される例示的なＦＸ取引は、テイカー／メイカー／貸し手の銀行アカウント９０５、カストディアン銀行９２５、担保通貨アカウント９４５、及び管理者／マスター９７５を伴い、管理者／マスター９７５は、メイカーＦＣＦＣアカウント９８０、テイカーＦＣＦＣ顧客アカウント９８５、貸し手ＦＣＦＣアカウント９９０、及び融資／ＦＸ決済９９５を含む。
【０１３２】
９１０で、テイカー／メイカー／貸し手は、そのアカウント９０５からカストディアン銀行９２５に資金を電信送金する。この電信送金は任意の数の方法で達成することができ、これらは、限定はされないが、連邦電信送金(Federal wire)、ＳＷＩＦＴ（登録商標）、又はカストディアン銀行の当座預金アカウント(demand deposit account)（ＤＤＡ）を含む。９２０で、カストディアン銀行９３５は、電信送信メッセージを受け取り、既知の送金プロセスを用いて、テイカー／メイカーのためにＦＣＦＣ担保ＣＵＲアカウント９４５にクレジットする。
【０１３３】
９３０で、カストディアン銀行９２５は、詳細（例えば、ＦＣＦＣアカウント番号、参照番号、通貨、及び金額を含むがこれらに限定されない）を管理者／マスター９７５に伝える。管理者／マスター９７５はＦＣＦＣを発行し、ＦＣＦＣを適切なアカウントにデポジットする。９４０で、メイカー／テイカー／貸し手は、管理者／マスター９７５を介してそのＦＣＦＣアカウントからの払い戻しを要求してよい。一実施形態では、その払い戻しを許可する承認者がいる。管理者／マスター９７５は、払い戻しの詳細（例えば、ＦＣＦＣアカウント番号、参照番号、通貨、及び金額を含むがこれらに限定されない）をカストディアン銀行９２５に伝える。
【０１３４】
９５０で、カストディアン銀行９２５は、適切なＵＩｓ及びＡＰＩｓを介して管理者／マスター９７５から伝達を受け取り、従来の送金プロセスを用いて担保ＣＵＲアカウント９４５にデビットする。９６０では、９１０で上述したプロセスと同様に、カストディアン銀行９２５は、資金をテイカー／メイカー／貸し手の銀行アカウント９０５に電信送金する。
【０１３５】
９７０で、毎日のアカウント照査(reconciliation)が生じる。このプロセスにおいて、カストディアン銀行９２５は、管理者／マスター９７５に毎日のアカウント取引明細書を提供してよい。この取引明細書のフォーマットは、種々の形式をとってよい。一例はＳＷＩＦＴ（登録商標）９５０フォーマットであってよい。他の既存のフォーマットを用いてもよい。管理者／マスター９７５は、残高及び取引の詳細の他、関連するＦＣＦＣアカウントの詳細をインポートしてよく、照査を行ってよい。
【０１３６】
図９は、プロセスの概要として意図されている。実際問題として、複数の銀行アカウント９０５、複数のカストディアン銀行９２５、複数の担保ＣＵＲアカウント９４５（図９に示される）、及び管理者／マスター９７５が取り扱うことになる複数のアカウント９８０、９８５、及び９９０がある。
【０１３７】
今説明したプロセスの代替として、９８０にＤＤＡがあってよく、管理者／マスター９７５は、照査を行うために、担保ＣＵＲアカウントへのＤＤＡインターフェースを有していてよい。
【０１３８】
図１０は一実施形態によるＦＣＦＣの作成を示す。所与の通貨での各ＦＣＦＣは、同じ法定通貨の単位で裏付けられている。例えば、１ドルのＦＣＦＣコインは、法定通貨の１ドルで裏付けられている。その結果、その１ドルのＦＣＦＣコインは、法定通貨で１ドルとしての価値を保持することになる。ドルの価値は他の法定通貨（例えば、ＧＢＰ、ＥＵＲ、ＪＰＹ等）に対して異なり、このことは、ＦＸ取引の参加者が保持する１ドルのＦＣＦＣコインが、米国法定通貨において１ドルが「ふるまう(behave)」ようにふるまうことになり、従って常に１ドルの価値があることを意味する。
【０１３９】
ＦＣＦＣを得るために、マーケット参加者は、その参加者がマーケットメイカー、プライステイカー、又は貸し手のいずれであろうと、法定通貨でのいくつかのＦＣＦＣコインとの引き換えとしてカストディアン銀行にその通貨の注文を出す。図１０は、カストディアン銀行と共にこの種の取引に加わっている各タイプのマーケット参加者を示している。異なるカストディアン銀行は異なる通貨でディールする。所与のマーケット参加者は、異なる通貨でディールしてもよい。前述のように、マーケット参加者がＦＣＦＣを購入するのに用いてよい複数の法定通貨がある。異なる法定通貨は、それらの通貨での異なるＦＣＦＣコインを意味する。
【０１４０】
図１１は、ＦＣＦＣを用いる単純なＦＸ取引の一例を示している。この描写では、１つの法定通貨に裏打ちされたＦＣＦＣは、異なる法定通貨に裏打ちされたＦＣＦＣとマーケット為替レートでトレードすることができる。本発明の態様によれば、取引の各当事者は、売買が実行される前に、売買を実行するために必要なＦＣＦＣを保持する必要がある。この要件は、本発明の「資金調達後売買」の態様の一部である。
【０１４１】
取引の終わりに資金調達するために、メイカー又はテイカーは、法定通貨を用いてＦＣＦＣを購入することができ、あるいは貸し手からＦＣＦＣを借り入れることができる。借り入れの場合、ＦＣＦＣは、典型的には、取引日中に又は取引日の終わりにその日の遅くに払い戻される。但し、以下で論じるように、融資は、借り手のニーズや要望に応じて変化する期間のものである。
【０１４２】
図１２は、月末における利息の支払い及び受領の１つの実施を示している。一実施形態では、利息は法定通貨で支払われる。一態様では、カストディアン銀行は、ＦＣＦＣを所有する実体に利息を、あたかもその実体が同じ金額のデポジットで法定通貨を保有しているかのように支払う。実体は、テイカー、メイカー、又は貸し手であり得る。
【０１４３】
ＦＣＦＣの借り手は、融資が未払いであった時間の長さ（場合によっては分単位）について予め決められたレートに基づいてＦＣＦＣの貸し手に利息を支払う。
【０１４４】
尚、図１２に関連して、この図は３つの方法で利息を得る貸し手を示している。まず、前述のように、貸し手はカストディアン銀行から、貸し手がそのカストディアン銀行で保有しているＦＣＦＣの金額に対応する利息を毎日のように得る。一実施形態では、カストディアン銀行は、前述のように、毎月利息を支払う。第２に、貸し手は、売買日を超えて貸し手にＦＣＦＣを返済するのを待つ借り手（図１２では、例えば、この当事者はメイカーであってよい）から利息を得ることができる。第３に、売買日を過ぎてもカストディアン銀行でＦＣＦＣを維持している貸し手は、そのカストディアン銀行から利息を得てよい。
【０１４５】
図１３は、ＦＣＦＣを現金化するマーケット参加者の一例を示している。一態様では、前述のように、マーケット参加者はＦＣＦＣを一晩／無期限に保持し、法定通貨で毎日の利息を得ることができる。いくつかの実装では、この選択肢は貸し手にとって魅力的である。ＦＣＦＣに資金を保持することで、貸し手がシステムに資金を入出金する場合に利用可能であろうよりも魅力的な条件で、一晩の法定利息の形態で貸し手に収入源を提供することができる。
【０１４６】
一実施形態では、マーケットメイカー及びプライステイカーは、自分のアカウントでＦＣＦＣを「売る／消却する」ことができ、カストディアン銀行又は他の金融機関に、資金を従来の法定通貨アカウントに電信送金するように指示することができる。いくつかの態様では、１つの通貨でＦＣＦＣを「消却する」マーケットメイカー及び／又はプライステイカーは、別の通貨でＦＣＦＣを得ることが可能である。
【０１４７】
図１４において、先ずメイカーは貸し手から第１の法定通貨（ＣＵＲ１）でＦＣＦＣを借りる。次いでメイカーは、テイカーとの取引を通じてＣＵＲ１ＦＣＦＣをＣＵＲ２ＦＣＦＣに変換する。この工程の後、メイカーは、別のメイカー（図１３では代替メイカーと表示）との取引を通じて、ＣＵＲ２ＦＣＦＣをＣＵＲ１ＦＣＦＣに変換し直す。次に、第１のメイカーは貸し手に融資を返済する。最後に、第１のメイカーが２つの取引で得た利益は、ＣＵＲ２ＦＣＦＣとしてカストディアン銀行に送られ、カストディアン銀行は第１のメイカーに法定通貨としてＣＵＲ２を支払う。次いでその第１のメイカーは、ＣＵＲ１ＦＣＦＣとして貸し手に利息を支払う。このような取引では、第１のメイカーは、通貨裁定取引(currency arbitrage)から得られることになる利益が、資金を貸して第１のメイカーが取引全体に加わることを可能にするための貸し手に支払われるべき利息の額を超えることに賭けることになる。
【０１４８】
図１５は、第１の法定通貨を伴う管轄区域内に居所のある企業が、第２の法定通貨を伴う別の管轄区域内のベンダーに返済することを望む取引を示している。この返済は、企業（この例ではプライステイカー）が第１のカストディアン銀行から第１の法定通貨でＦＣＦＣを購入する取引を伴う。次いでその企業は、第１の法定通貨でのＦＣＦＣを、ベンダーの法定通貨である第２の法定通貨でのＦＣＦＣと交換する取引に参入する。次いでその企業は、ＦＣＦＣを第２の法定通貨で更なるカストディアン銀行に送信することができ、そのカストディアン銀行はベンダーに法定通貨で支払うことができる。一般に、カストディアン銀行は、ベンダーへの送信のために、第１の法定通貨でのＦＣＦＣの販売、又は第２の法定通貨でのＦＣＦＣの受領のいずれかを取り扱ってよい。現在、カストディアン銀行が両方を取り扱う可能性は低いが、可能である。事実上、カストディアン銀行は取引の両サイドにあってよい。
【０１４９】
図１６は、融資取引を示している。この取引では、貸し手はＣＵＲ１ＦＣＦＣと引き換えにカストディアン（例えば銀行）にＣＵＲ１をデポジットする。次いでその貸し手は、本発明の態様に従ってブロックチェーンベースのシステムを介してＣＵＲ１ＦＣＦＣをマーケットメイカーに貸し付ける。その日の遅くに、メイカーは貸し手に融資を返済する。その日の終わりに、貸し手は２つのソース、即ち融資の利息を支払うメイカーとデポジット時に法定通貨での利息を支払うカストディアン銀行とから利息を得る。
【０１５０】
図１７はＦＸ売買を説明する図であり、プロセスを大幅に速める能力を示している。図１７においては、ＣＵＲ１〜ＣＵＲ４は異なる法定通貨を示す。一例では、ＣＵＲ１はＵＳＤでってよく、ＣＵＲ２はＥＵＲであってよく、ＣＵＲ３はＧＢＰであってよく、ＣＵＲ４はＣＡＤであってよい。
【０１５１】
図１７は、いくつかのブロックチェーンメンバーを示しており、これらは、ＣＵＲ１〜ＣＵＲ３のカストディアンノード、ＣＵＲ４銀行ノード、貸し手ノード、２つのプライステイカーノード、及びマーケットメイカーノード（具体的にはＣＵＲ４に関連付けられている）。但し、前述のように、一実施形態によれば、これらのマーケット参加者は、ブロックチェーン上にノードを有していないであろう。これらの参加者は全て、管理者又はマスターを経由してよい。従って、図１７の表現は、全ての参加者にブロックチェーン上のノードがある実施形態から、いずれの参加者にもブロックチェーン上のノードがない実施形態まで、あるいはその間の任意の実施形態まで、種々の実施形態の範囲を表していると理解されされてよい。
【０１５２】
図１７において、以下の工程は、ＣＵＲ４をＣＵＲ１に変換しようとするプライステイカーと、プライステイカーのＣＵＲ４と引き換えにＣＵＲ１を提供するための価格を申し出たいマーケットメイカーと、マーケットメイカーが取引に加わることを可能にするためにマーケットメイカーにＣＵＲ１を貸し付ける貸し手と、の間での取引を構成する。
【０１５３】
ノストロ(nostro)（１つの銀行によって異なる国の別の銀行のために保有される外貨アカウント）で利用可能なＣＵＲ４資金を有するプライステイカーは、それらの資金をＣＵＲ１に変換しようとする。
【０１５４】
プライステイカーは、ＣＵＲ４ＦＣＦＣの発行のためにカストディアン銀行に資金を電信送金するようにノストロ銀行に要求する。
【０１５５】
利用可能な資金調達がないマーケットメイカーは、プライステイカーとのＦＸ売買を実行するために価格を決めようとする。
【０１５６】
マーケットメイカーは、ＣＵＲ１ＦＣＦＣでの支払いのために資金を借り入れる。一実施形態では、貸し手は、マーケットメイカーのために事前に選択され、これまでのマーケットメイカーの信用力の表示並びに融資期間及び金利を含む将来の融資契約の種々の態様等に基づく最も有利な条件を有する。他の実施形態では、マーケットメイカーは、マーケットメイカー自身の基準を用いて、貸し手を選択することができる。
【０１５７】
マーケットメイカーは、そのＦＸ見積りを表示する。
【０１５８】
プライステイカーは、見積もりを受け入れると共にＣＵＲ４をＣＵＲ１と交換するためにマーケットメイカーとの取引に参入することを決定する。
【０１５９】
マーケットメイカー及びプライステイカーはＦＣＦＣを交換する。
【０１６０】
資金はアカウント間で交換される。
【０１６１】
マーケットメイカーは、そのＣＵＲ４ポジションを閉じ、ＣＵＲ４ＦＣＦＣを販売し、ＣＵＲ１ＦＣＦＣを受領する。
【０１６２】
マーケットメイカーは、ＣＵＲ１ＦＣＦＣを返却することによって、受領したＣＵＲ１融資を返済する。
【０１６３】
今説明した取引では、プライステイカーは既に完全に資金提供されていたが、マーケットメイカーは外に出て資金を調達しなければならなかった。当業者は、他の種類の取引では、貸し手を探す必要なしに、両当事者が既に完全に資金提供されている可能性があることを理解するはずである。代替的には、資金提供を必要とするのはテイカーである一方で、メイカーは完全に資金提供されている可能性がある。更に別の代替として、テイカーとメイカーの両方が資金を必要とする場合がある。
【０１６４】
貸し手が借り手（テイカー又はメイカー）と融資契約を締結する場合、交渉されるべき条件の１つは返済の時間である。一実施形態では、融資の期間は非常に短い場合があり、メイカー及びテイカーが取引を完了するのに要する限り、その後、借り手は貸し手に返済するための資金を得ることになる。迅速な返済を伴う短期融資は、貸し手が異なる条件で１日に複数の融資を組むことを可能にし、そのいくつかは一部の借り手に関して他の借り手に関してよりも貸し手にとって有利な場合がある。貸し手が迅速な返済を受領した場合、貸し手は同じ借り手又は同じクラス若しくはカテゴリの借り手に貸し出すことを試みる選択肢を有する。代替的には、貸し手は、異なる借り手又は異なるクラス若しくはカテゴリーの借り手に貸し出すことを試みることを決定し得る。
【０１６５】
一態様では、貸し手は、貸し手が有利な条件を引き出すことができる借り手に対して、特にその借り手が１日に複数の取引に日常的に加わる場合、より長い返済期間を提供してよい。その状況では、融資取引及び返済の数の削減による経費の削減は、借り手にとって魅力的である場合がある。同様の理由で、その経費削減シナリオは、貸し手にとってもより魅力的である場合がある。代替的には、貸し手は、特に貸し手が手数料を請求し利息を受領することができる場合、何度も繰り返して資金を貸し付けたいと思う場合がある。このような資金の再融資は、システム全体の管理者が、融資の他、売買自体に対しても取引ごとの手数料を請求することができるであろうから、その管理者にとっても魅力的であることがある。
【０１６６】
また論じられたように、ＦＣＦＣは一晩の利息を生み出し、短期的な利益を提供することができるので、貸し手は、ＦＣＦＣを取得するよりもむしろ、カストディアン銀行と共にシステムにＦＣＦＣを残してよい。貸し手が協調ベースで貸し付けに参加しようとする場合、ＦＣＦＣをシステム内において１つ以上の通貨で直ちに利用可能にすることは、貸し手にとって追加の収入源になり得る。
【０１６７】
前述のことに鑑みて、当業者は、本発明の態様によるシステムが、ＦＸ等の取引に関心のある当事者同士をまとめ、取引からのデリバリーリスクを排除することを理解するはずである。このシステムは、複数の要求を同時に取り扱うことができ、通貨の貸し手が適切な借り手を見つけてそれに応じて手数料を受領するための情報センターとして機能することができる。各貸し手は、それに応じて個々の信用状況及び価格を評価することができる。
【０１６８】
前述の実施形態は、特定のタイプの金融取引、即ち外国為替を対象とする。本発明はそのようには限定されない。無担保リスクの証券化から利益を得ることができる他のタイプの金融機関及び金融取引は、ここで説明される本発明の態様から利益を得ることができる。基本的には、裸の空売りを防ぐための取引の事前資金調達は、多くのタイプの取引に加わっている多くのタイプの金融機関に対してプロセスを迅速化することができる。そのような取引に加わるために事前認定してよい参加者のカテゴリーとしてのそのような金融機関の例としては、企業／公庫業、アセットマネージャ、商業銀行、保険会社、中央銀行、投資銀行、ヘッジファンド、投資管理会社、地方銀行、及びファミリーオフィスが挙げられる。一態様では、これらのいずれかがテイカー、メイカー、及び／又は貸し手であってよい。本発明の態様はまた、店頭(Over the Counter)（ＯＴＣ）デリバティブ（キャップ、カラー、フロア、スワップ、スワップション(Caps, Collars, Floors, Swaps, Swaptions)）、債務担保証券(Collateralized Debt Obligations)（ＣＤＯｓ）、社債、商品、又は普通株のいずれか又は全てのためのマーケットにおける適用可能性を有する。
【０１６９】
また、ここに開示された実施形態の態様によれば、特に貸し手にとってのＦＣＦＣの利用可能性が魅力的であることがある。他のアイドル通貨を伴う機関は、その通貨を用いて何らかの利益を得る方法を見つけたいと考えるであろう。システム内で資金をＦＣＦＣとして利用可能にするカストディアン銀行に資金を預けることによって、その通貨の所有者は、例えば、売買日を超えてシステムに通貨を預けることで、一晩の利息を受領することができる。
【０１７０】
当業者は、ここで説明した実施形態の種々の要素のいくつか又は全てを互いに組み合わせることができ、場合によってはそれらの要素の異なる組み合わせがいくつかの要素を省略してもよいが、それでも本発明の実施形態を構成することを理解するはずである。当業者はまた、実施形態に従ってここで説明した種々のシーケンスが多様な順序の動作を有していてよく、互いに組み合わされてよく、又は１つ以上の工程を省略してもよいが、それでも本発明の実施形態を構成することを理解するはずである。
【０１７１】
前述の説明は、本発明の態様による種々の実施形態を規定している一方で、当業者は、本発明の範囲及び精神内の他の実施形態がここに包含されることを意図していることを理解するはずである。従って、本発明は、以下の特許請求の範囲によってのみ限定されると考えられるべきである。
【図１】
2021528797.tif 000003
【図２】
2021528797.tif 000004
【図３】
2021528797.tif 000005
【図４】
2021528797.tif 000006
【図５】
2021528797.tif 000007
【図６】
2021528797.tif 000008
【図７】
2021528797.tif 000009
【図８】
2021528797.tif 000010
【図９】
2021528797.tif 000011
【図１０】
2021528797.tif 000012
【図１１】
2021528797.tif 000013
【図１２】
2021528797.tif 000014
【図１３】
2021528797.tif 000015
【図１４】
2021528797.tif 000016
【図１５】
2021528797.tif 000017
【図１６】
2021528797.tif 000018
【図１７】
2021528797.tif 000019
【国際調査報告】
2021528797.tif 000020
2021528797.tif 000021