JP3847560B2

JP3847560B2 - １日のネッティング支払い決済のためのシステムおよび方法

Info

Publication number: JP3847560B2
Application number: JP2000547569A
Authority: JP
Inventors: エム．コットン，ロバート，; エフ．トーマス，ジョージ，; エス．パウエルチク，ジョセフ，
Original assignee: ザクリアリングハウスサーヴィスカンパニーエル．エル．シー．
Priority date: 1998-05-05
Filing date: 1999-05-05
Publication date: 2006-11-22
Anticipated expiration: 2019-05-05
Also published as: CA2330341A1; EP1093625A4; US6076074A; WO1999057665A1; EP1093625A1; JP2002513975A

Description

【０００１】
【関連出願に関連する相互参照】
本出願は、本明細書で参照により援用している、米国仮出願第６０／０８４，２２３号（１９９８年５月５日出願）の恩典を請求するものである。
【０００２】
【発明の分野】
本発明は、金融機関の間で電子支払いを受信および送信し、送信時に支払いが決済されるシステムおよび方法に関するものである。
【０００３】
【関連技術の説明】
アメリカ合衆国において支払いを行う者（個人または企業）は、一連の支払い装置の中から選択することができる。ほとんどの単発の取引きは未だに現金（硬貨または紙幣）によって支払われているようである。小切手や、その他の紙の文書（トラベラーズチェック、送金為替、銀行小切手）や、自動手形交換所（”ＡＣＨ”、信用貸しおよび借記送金を支援し、主に、事前にスケジュールすることができ、時間的危機に直面していない給料や年金支払い、譲渡抵当、保険のプレミア支払いといった直接預金のような低ドル取引きで使用されている、コンピュータに基づいたバッチ処理電子支払い機構）で処理される借記および貸記がある。しかし、最も大きな支払いは、通常、口座振替えで送金される。毎日、２つの主要な口座振替えシステム、ＦｅｄｗｉｒｅとＣＨＩＰＳ（手形交換所銀行間支払い決済システム）が、２兆ドル以上に及ぶ何十万もの支払いを送金する。口座振替えの平均サイズは非常に大きく、ＣＨＩＰＳでは約６百万ドル、Ｆｅｄｗｉｒｅでは３百万ドルである。
【０００４】
口座振替えは、多くの異なる関係者と関連することができる。“ｆｅｄｆｕｎｄｓ”（銀行の連邦準備銀行への預金）の引渡しや返却のような、２つの銀行の債務を決済するために多くの振替えが行われる。これらの場合では、関係する銀行は２つのみである。さらに銀行は、顧客に代わって口座振替えを行う。これらの振替えは、同行または他行の別の個人へのものであってよい。顧客は、他行または同行に所有する２つの口座間で資金を移動することがある。例えば、請求金額の収集に使用している地元の口座から、現金集中口座または給料口座へ移動するかもしれない。
【０００５】
口座振替えは、１つの銀行（「帳簿振替え」（book transfer））または多数の銀行に関係する場合がある。多くの場合、送金者は、支払い注文の実行するための方法を特定せず、送金者の銀行が、受取人へ資金を送る最も効率的な方法を選択する。この選択には、ネットワークまた仲介銀行の選択も含まれる。
【０００６】
口座振替えシステムの仕組みの分析を簡素化するために、次の例が用いたい。顧客Ｘが自分の銀行である銀行Ａに、銀行Ｂの顧客Ｙへ１万ドルの支払い注文を行う。次に、口座振替えの異なるステップと、各ステップに設けられている関係者向けの様々なオプションについて見てみる。顧客Ｘはどのように銀行Ａに支払い注文を送信するか。銀行Ａはどのようにこの支払い注文を銀行Ｂに送信するか。銀行Ｂはどのように顧客Ｙに通知をし、彼がその資金を利用できるようにするか。銀行Ａと銀行Ｂがどのように残高を決済するか。
【０００７】
Ａ．口座振替えの起点
利用者が銀行に振替口座の送信を注文する方法はたくさんある。おそらく、最大数の口座振替えであり、最高の金銭的価値が関係していることが確実であるものは、銀行と直接コンピュータ同士がリンクした企業を起点とした銀行であろう。これらの場合、顧客は、自分のコンピュータに支払い指示を入力し、コンピュータがその支払い注文を顧客の銀行のコンピュータに直接送信する。銀行のコンピュータはその支払い注文を「編集」する。その支払い注文が編集の１つに失敗する場合、例えば、支払い注文に必須情報が入っていなかった場合、コンピュータはその支払い注文をオペレータの画面へ送り、オペレータが必要な修正を行うか、顧客からの説明を探す（または、銀行内の他の行員にその説明を探させる）。顧客が、銀行に支払いメッセージを送信するためにパーソナルコンピュータを使用している場合にも同様の手順が用いられる。
【０００８】
一般に、口座振替えサービスを利用するには、個人は銀行へ行き、用紙に記入して金額を支払わなければならない。多額の銀行口座を持つ個人と小企業は、専用の銀行員または会計士を雇っているかもしれない。これらの人達は、口座振替えを行う場合、銀行員に電話をかけ、通常、コードワードまたはコールバック手続きを通じて、その通話が本人のものであると確認された後、振替えの指示を行う。行員は、その支払い注文を自分のコンピュータ端末で銀行のコンピュータに直接入力するか、または、その注文を用紙に記入して銀行の口座振替え課に送り、ここで銀行のコンピュータにその注文を入力する。現在、多くの銀行は、個人の顧客が自分のパーソナルコンピュータによって銀行のコンピュータを直接に操作できる「ホームバンキング」製品を提供している。
【０００９】
Ｂ．送信者の銀行の支払い注文の受理
支払い注文が銀行の口座振替えコンピュータシステムに入力され、最初の編集を通過すると、これが同顧客の要求口座残高に対してチェックされる。残高が十分にあれば、銀行は、口座振替えネットワークまたは振替口座の次の銀行へ関連する支払注文を発行することにより、その支払い注文を実行する。同顧客の口座に十分な残高がない場合には、コンピュータは、同顧客が利用可能な貸出し限度を有しているかどうかを調べる。貸出し限度がある場合には、支払いが公開され、その限度がない場合には、その支払いは、その支払いをカバーする資金を受け取るまで保留される。カバーする資金が午後（通常午後２時から午後４時）までに届かなければ、その支払い注文は融資オフィサーへ回されるが、融資オフィサーは、その支払いを履行できるようにするために顧客に追加の信用貸しを行うかどうかを決定する。
【００１０】
支払い注文が実施日（銀行は送信者の注文の実施において支払い注文を発行できる適した日）の業務終了時までに送信されない場合、通常、銀行は送信者に拒否の通知を送信してその注文を拒否する。
【００１１】
Ｃ．銀行間の振替え
１つの口座振替えに２つ以上の銀行が関係している場合、１つの銀行からもう１つの銀行へ資金を移動する必要がある。アメリカ合衆国では、以下に説明する２つの大型ドル口座振替えネットワークを利用することにより、また、取引先銀行残高を調整することにより、これを実施することができる。
【００１２】
１．ＦＥＤＷＩＲＥ
Ｆｅｄｗｉｒｅは、１２行ある連邦準備銀行によって稼動される口座振替えネットワークである。これはリアルタイムの総決済システムであるが、これが意味するのは、連邦準備銀行が受信側銀行の帳簿上の口座に信用貸しを行う時点で、支払いは完了し、取り消せないということである。従って、受信側の銀行が受取人に資金を利用可能にしたが、送信側がその支払い注文の金額を連邦準備銀行に支払えない場合にも、受信側の銀行が損失を負うリスクがない。このような場合、受信側銀行ではなく、連邦準備銀行が損失を負う。
【００１３】
Ｆｅｄｗｉｒｅは、連邦準備銀行に準備金または手形交換勘定を持っているあらゆる預託機関で利用することができる。現在、このような機関は約１万ほどある。そのうちの約７千の機関が連邦準備銀行との「オンライン」接続を有している。この接続のほとんどは、ダイヤルアップ電話回線接続またはリース回線により、連邦準備銀行とリンクした「Ｆｅｄｌｉｎｅ」端末を介したものが最も多いが、約２百の最大規模の機関では、コンピュータ同士の直接インターフェースを有している。オンライン接続を備える機関は、Ｆｅｄｗｉｒｅコンピュータへ、または、Ｆｅｄｗｉｒｅコンピュータから自動的にＦｅｄｗｉｒｅ支払い注文を送受信可能であり、連邦準備銀行の行員が手動操作不要である。連邦準備銀行は、その支払い注文の受領を知らせるために、送信側へコンピュータメッセージを送信する。Ｆｅｄｗｉｒｅ振替えの約９９％は、オンライン支払い注文を起点とするものである。
【００１４】
「オフ・ライン」取引きでは、通常、送信側がその連邦準備銀行に電話をかけ、支払い注文が連邦準備銀行が確立したコードまたはその他の方法によって確認される。さらに、これらの通話はテープに録音される。確認後、連邦準備銀行の行員は、その支払い注文をＦｅｄｗｉｒｅコンピュータに入力する。手動処理が必要であるため、連邦準備銀行では、オフライン振替えの手数料がオンライン振替えの手数料よりもかなり高価である。
【００１５】
連邦準備銀行によって受信された支払い注文は、Ｆｅｄｗｉｒｅ処理コンピュータへ送られる。このコンピュータは、システム編集を実行し、支払い注文を受信側の連邦準備銀行へ送る。すると、連邦準備銀行は、受信側銀行の口座を自動的に信用貸しし、受信側銀行に通知を送信する。
【００１６】
以下の例１では、適切な口座エントリが記されたＦｅｄｗｉｒｅ支払い注文を利用した場合の口座振替えの進行を示している。連邦準備銀行の間の決済についても、以下で説明する。
【００１７】
例１
顧客Ｘが銀行Ａに銀行Ｂの顧客Ｙ宛てに１万ドルを支払う注文をする、という２つの連邦準備銀行が関与するＦｅｄｗｉｒｅ振替え。
ステップ１：顧客Ｘが銀行Ａに支払い注文を送信し、銀行Ａが顧客Ｘの口座を借記（debit）し、連邦準備銀行１にＦｅｄｗｉｒｅ支払い注文を送信する。

ステップ２：連邦準備銀行１が銀行Ａの準備金口座に借記し、支払い注文を連邦準備銀行２へ送信する。

ステップ３：連邦準備銀行２は、支払い注文を受信し、銀行Ｂの口座を信用貸しし、銀行Ｂへ、顧客Ｙへの支払いを指示する通知を送信する。

ステップ４：銀行Ｂは、顧客Ｙの口座を信用貸しし、信用貸しの通知を送信する。銀行Ｂと顧客Ｙの両方が最終資金を受領し、この支払いは終了する。

【００１８】
２．ＣＨＩＰＳ
手形交換所銀行間支払い決済システム（”ＣＨＩＰＳ”）は、手形交換所銀行間決算会社Ｌ．Ｌ．Ｃ．（「手形交換所」）によって稼動される口座振替えシステムである。これは、多者間ネット決済システムである。つまり、これは、ＣＨＩＰＳ支払いメッセージを別の参加者に送信する銀行が、受信側参加者に振替え金額を支払う義務を負うが、この義務が別の参加者の第１参加者への支払い義務に対してネッティングされ、各参加者にネット信用貸しポジションまたはネット借記ポジションを与えるということを意味する。ある参加者が別の参加者の決済を行った場合、そのポジションが、決済する別の参加者の各々のポジションに対してネッティングされ、単一の「ネットネット」ポジション（信用貸しまたは借記）が決済ＣＨＩＰＳ参加者の各々に与えられる。これらのポジションは、１業務日の終りに決済される。ネット借記ポジションを有する参加者が、その債務を決済可能になる前に失敗することは理論的にはありうるが、手形交換所は厳格な信用貸し制御および決済確約方法を設けており、開始から２５年間の間、ＣＨＩＰＳは１度も決済に失敗したことはない。
【００１９】
ＣＨＩＰＳは、アメリカ合衆国内に複数の支店を持つ商業銀行機関でも利用することができる。現在、８３の活発な参加者と１８の決済中の参加者がいる。決済中の参加者でない参加者の各々は、決済中の参加者と組み、決済中の参加者に代わって決済を行わなくてはならない。（ＣＨＩＰＳ決済の詳細については、以下で説明する。）
【００２０】
一般的なＣＨＩＰＳ振込みにおいて、銀行Ａは、自行のコンピュータからリース専用電話回線を介して、ＣＨＩＰＳコンピュータへ支払いメッセージを直接送信する。ＣＨＩＰＳコンピュータがこの支払いメッセージを確認および編集し、関連する支払メッセージを銀行Ｂへ、また、承認を銀行Ａへ送信する。例２は、適切な口座エントリを備えたＣＨＩＰＳ振込みを示す。
【００２１】
例２
顧客Ｘが銀行Ａに銀行Ｂの顧客Ｙ宛てに１万ドルを支払うように注文する、ＣＨＩＰＳ振込み。
ステップ１：顧客Ｘが銀行Ａに支払い注文を送信する。
ステップ２：銀行Ａが銀行Ｂに支払いメッセージをＣＨＩＰＳを介して送信する。

ステップ３：銀行Ｂが、自行の口座に１万ドルを受け取ったことを顧客Ｙに通知する。
注意：銀行Ｂは顧客Ｙに、資金の使用を提供することができるが、決済が実施されるまでは支払いは終了しない。
ステップ４：決済
【００２２】
３．取引き先銀行残高
銀行が受益者口座を持つ銀行と取引き関係にある場合、または、その銀行が口座振替えネットワークに直接アクセスできない場合、その銀行は、口座振替えを完了するために、様々な取引き先銀行口座に借記および信用貸しを使うことができる。銀行は、取引き先銀行残高の調整またはその他の手段を介して、送信側債務の支払いを実施しながら、国際銀行間金融通信協会（”Ｓ．Ｗ．Ｉ．Ｆ．Ｔ．”）が稼動するネットワークを介して、支払い注文を頻繁に送信する。支払い注文もテレックスまたはその他の通信媒体によって送信することができる。これらの取引きを実施する実際の手順は銀行によって異なる。
【００２３】
以下の例３、例４は、取引き先銀行口座を用いて口座振替えを完了する２つの異なる方法を示すものである。
【００２４】
例３
顧客Ｘが銀行Ａに銀行Ｂの顧客Ｙの口座に１万ドル送金するよう注文する。銀行Ａは、銀行Ｂに取引銀行先口座を持っている。
ステップ１：顧客Ｘが銀行Ａに支払い注文を送信する。
ステップ２：銀行Ａは、顧客Ｙの口座を借記し、銀行Ｂが銀行Ａの口座を借記することを承認するという支払い注文を銀行Ｂに送信する。

ステップ３：銀行Ｂは、銀行Ａの口座を借記し、顧客Ｙの口座を信用貸しする。

ステップ４：銀行Ｂは、資金が使用可能であることを顧客Ｙに通知する。
【００２５】
例４
顧客Ｘが銀行Ａに銀行Ｂの顧客Ｙの口座に１万ドルを送金するよう注文する。銀行Ａは、銀行Ｂの取引き先銀行口座を持っている。
ステップ１：顧客Ｘが銀行Ａに支払い注文を送信する。
ステップ２：銀行Ａは、顧客Ｘの口座を借記し、銀行Ｂの口座を信用貸しする。

ステップ３：銀行Ａが銀行Ｂに支払い注文を送る。
ステップ４：銀行Ｂが顧客Ｙの口座を信用貸しする。

ステップ５：銀行Ｂが資金が利用可能であることを顧客Ｙに伝える。
【００２６】
４．帳簿振替え
顧客は、自分の銀行に自分の口座からの口座振替えを依頼し、同行の帳簿上の別の勘定（account）を支払う場合がある（別の顧客の勘定または注文側の顧客の別の勘定）。これらは、１つの銀行の帳簿上で実施されるため、帳簿振替えと呼ばれる。これらの振替えの実施と簿記の配置に使用される方法は、銀行によって異なる。例５は、帳簿振替えのための口座エントリを示す。
【００２７】
例５
顧客Ｘは、銀行Ａの帳簿上の顧客Ｙの口座への口座振替えを銀行Ａに注文する。

【００２８】
Ｄ．受益者への支払い
口座振替えの処理の最終ステップは受益者への支払いである。数は少ないものの全ての場合において、これは、受益者の銀行が帳簿上の受益者の口座に信用貸しを行い、その受益者に資金の使用を許可した際に達成される。連邦準備制度理事会規制の下で、銀行は、最終支払いを受理した翌業務日の始業時間までに、口座振替えを受益者に利用可能にしなければならない。Ｆｅｄｗｉｒｅ支払いでは、最終支払いが生じるのは、支払い注文の金額が連邦準備銀行における受信側銀行の口座に信用貸しされた時、または、信用貸しが生じたあらゆる場合において、入金通知書が送信された時である。ＣＨＩＰＳ振込みについて、決済が完了した際に最終振込みを行う。送信側が受信側の銀行の帳簿に口座を信用貸しする取引銀行口座を利用した振込みについては（例４）、最終支払いは、信用貸しが引き出された時、また、引き出されない場合には、信用貸しが引き出し可能になる日であり、受信側の銀行がその件について認識する日の午前１２時に実施される。受信側銀行が送信側口座を借記する際は（例３）、最終支払いが生じるのは、口座内の引き出し可能な信用貸しによって借記がカバーされる範囲にまで借記が行われる時である。
【００２９】
非常に少数の支払いについて、受益者の銀行は、受益者の口座への信用貸し以外の方法を使用しても良い。例えば、銀行は、自分の身分証明書を提示した上で、受益者に支払われるべき資金を保有することができ、また、銀行は、受益者に小切手を送って支払いを行うこともできる。
【００３０】
Ｅ．銀行間決済
上述のアメリカ合衆国における主要な口座振替えシステムの双方は、決済に備える。すなわち、決済資金における額面の実際の振替えをもって、最終支払いとなる。決済が終わると、支払いは取消しが不可能になる（２重支払いや間違った支払いの場合を除く）。ＦｅｄｗｉｒｅとＣＨＩＰＳでは実際の決済方法は異なり、中央銀行によって稼動されるリアルタイムの総決済システムと多者間ネッティングシステムとの間の違いが反映されている。
【００３１】
１．ＦＥＤＷＩＲＥ
連邦準備銀行へ支払い注文を送信する銀行と、連邦準備銀行から支払い注文を受信する銀行の観点から見ると、Ｆｅｄｗｉｒｅ口座振替えはその作成時に終了する。連邦準備銀行がその支払い注文に取りかかった時点から、送信側の連邦準備銀行が送信側の口座を借記する。受信側銀行は、連邦準備銀行が口座を信用貸しするか、または入金通知書を送信するか、いずれか早い方の処置をとった時に、最終支払いを受ける。この時点で、受益者は支払いを受け、起点となる受益者への支払い義務が解消する。受信側の銀行は、その準備金口座または手形交換勘定に引き出し可能な決済資金を持っているが、これは、銀行が要求する準備金残高を充足する上でプラスになる。
【００３２】
しかし、内側からみると、Ｆｅｄｗｉｒｅは、１２の決済銀行が関与したネット決済システムであり、決済銀行の各々は、独自のバランスシートを持った個別の企業であり、取引きはこれらの銀行間で決済されなければならない。この目的のために、連邦準備制度理事会は、連邦準備銀行のための管轄間の決済口座を維持している。この口座は、各連邦準備銀行のバランスシート上に現れる。連邦準備銀行間の各取引きの結果、ある連邦準備銀行の管轄間決済口座への信用貸しが生じ、また、これに対応するその他への借記が生じる。借記と信用貸しが累積した結果、各連邦準備銀行は、借記または信用貸しである累積したポジションを持つことになり、全１２行の連邦準備銀行を１つにまとめたバランスシート上で、これらの借地および信用貸しがゼロにネットする。年に１度、各連邦準備銀行の管轄間決済口座は、全ての連邦準備銀行の政府発行有価証券の統合された保有物であるシステム・オープン・マーケット・アカウントに関した連邦準備銀行の所有権の再割当てによってゼロにされる。
【００３３】
Ｆｅｄｗｉｒｅの１つの欠点は、システム内の優良状態にある全ての参加者が大きな日中当座貸越しポジションを招いてしまうことである。このような当座貸越しを招いてしまう銀行には、連邦準備によって料金が課される。
【００３４】
２．ＣＨＩＰＳ
反対に、ＣＨＩＰＳは、現在構築されているとおり、真の多者間ネット決済システムである。上述したように、支払いメッセージの公開は、受信側参加者の送信した支払いを決済する義務に対して、ネッティングされた決済する義務を生じる。従って、各銀行は、借記または信用貸しのいずれかの総体的なネットポジションを有している。
【００３５】
１業務日の終了時に、各参加者は、送られた全ての支払いメッセージの合計額、受信された全ての支払いメッセージの合計額、差を示す正味の数字（借記または信用貸し）を示すレポートを受け取る。各決済参加者は、その位置に加えて、決済される各参加者のネットポジションと、決済参加者自身のポジションと決済される各参加者のポジションを含む総体的なネットポジションを示す累計残高を示したレポートを受け取る。次に、各決済参加者に４５分間が与えられ、この時間内に、参加者は、指定された決済参加者である１つまたはそれ以上の決済参加者に決済しないと決定した場合には、手形交換所に知らせなければならない。レポートに基づいて決済するという合意が各々の決算参加者から受理されると、手形交換所は、ニューヨーク連邦準備銀行に、全てのＣＨＩＰＳ決算参加者を代表して収容するＣＨＩＰＳ決済口座を開くように指示し、また、決済が開始される旨の通知を全ての決済参加者に送信する。この通知が送信されると、総ネット借記ポジションを有する決済参加者の各々は、１５分間の間に、その借記ポジションの金額をニューヨーク連邦準備銀行のＣＨＩＰＳ決済口座へＦｅｄｗｉｒｅ口座振替えしなければならない。これらのＦｅｄｗｉｒｅがすべて完了したら、手形交換所は、口座内の残高を調べ、続いて、決済口座からネット信用貸しポジションにある決済参加者の口座へＦｅｄｗｉｒｅ支払い注文を送る。全てのＦｅｄｗｉｒｅ支払い注文が送信されたら、決済が完了し、その日になされた全てのＣＨＩＰＳ支払いが最終的に支払われる。
【００３６】
１日の業務終了時に決済に備える多者間ネット決済システムは、ネット借記ポジション（「借り主参加者」）にある参加者がその決済債務を支払いたくなかったり、支払うことができないというリスクに曝される。借り主参加者の失敗を補填する何らかの措置がないと、このタイプの失敗が意味するかもしれないのは、システムが決済に失敗したこと、すなわち、その失敗の日にネッティングシステムによって処理された口座振替えは完了されないということである。この口座振替えシステムが扱う支払いの数と金額次第では、このような失敗は、存続参加者と世界金融市場全体に深刻な有害結果をもたらしかねない。
【００３７】
ＣＨＩＰＳは、決済失敗のリスクを制御するために、多数のステップをとっている。１９８４年に、それぞれの参加者には、他の参加者が受け入れることができる信用貸しのリスクの基準として、互いの参加者に「２者間信用貸し限度」を確立することが要求された。１９８６年には、ＣＨＩＰＳは、各参加者に、他の参加者によって確立された総合的な２者間限度の割合としての「送信側ネット借記キャップ」を確立することにより、さらに段階に進んだ。この制御は、参加者がシステムに引き起こす可能性のあるリスクの量を制御する。
【００３８】
１９９０年には、ＣＨＩＰＳはさらに、その参加者の各々に失敗した参加者の決済義務の一部を支払わせる合意を要求する段階に進んだ。この「追加決済義務」は、この目的のために担保され、また、ニューヨーク連邦準備銀行に保管された財務省証券によって担保保証された。この担保保証された損失シェアリング協定により、最も高い借記キャップを持つ参加者がそのありうべき最大の借記ポジションにおいて失敗したとしても、ＣＨＩＰＳが決済できることが保証された。（この基準は、アレキサンダー・ランファルシーが会長を務める国際決済銀行のワーキンググループによって明確にされたため「ランファルシー基準」と呼ばれる。事実、ＣＨＩＰＳは、ランファルシー基準を先取りし、国際決済銀行のレポートが発行される以前から、このリスク制御方法を採用していた。）
【００３９】
１９９４年に、ＣＨＩＰＳはそのリスク制御を強化し始め、その結果、１９９７年までには、最高の借記キャップを有する２つの銀行がその最大限の借記ポジションにおいて同時に失敗しても、ＣＨＩＰＳは決済することが可能になった（「ランファルシー＋１基準」と呼ばれる）。多数の小規模銀行が失敗するのであれば、同じ損失シェアリング公式により、ＣＨＩＰＳの決済が許可される
【００４０】
これらの処置にも関わらずまだリスクが存在し、ある重大な金融危機によってＣＨＩＰＳの決済の失敗が生じる可能性があり、その結果、全ての公開された支払いメッセージが「巻き戻される」、すなわち、全ての支払いメッセージが受信側参加者から回収されて送信側参加者に戻され、送信側参加者が自己の支払いを送るか否かを自由に決定することができるようになる可能性がある。
【００４１】
３．ジャーマンＥＡＦ２システム
グロス決算とネット決算システムの両方の要素を使用する第３タイプのシステムは、ドイツの中央銀行である、フランクフルトのＤｅｕｓｃｈｅＢｕｎｄｅｓｂａｎｋが稼動する電子清算フランクフルト（ＥＡＦ２）システムである。
【００４２】
ＥＡＦ２の稼動日には２つの段階がある。段階１（８：００ａ．ｍ〜１２：４５ｐ．ｍ．）では、金融機関から受信した支払い注文がシステムに入力され、２者間で相殺される。約２０分間の規則的な間隔で、最終支払いが、総決済システムと同じように、段階１の受信側信用貸し機関に利用可能になる。その後、支払い注文は、受信側銀行への信用貸しリスクを生じることなく、受益者に利用可能にすることができる。次の段階２（１：００ｐ．ｍ．〜２：１５ｐ．ｍ．）では、第１段階中に、２者間的にネッティングされなかった残りの支払いの２段階の多者間清算を実施する試みがなされる。多者間清算からの重大な違いは、現在存在するものとしては、体系的リスクの回避である。カバーされていない借記残高がある場合、参加者の排除と、排除された参加者に関連する全ての支払いの戻しを伴う巻き戻しは実施されず、代わりに、個別支払いのみが戻される。これらの個別支払いは、総決済システムと同じように、カバーされていない支払いとして扱われる。
【００４３】
段階１において、ＥＡＦ２は、カバーが利用可能になった後に、個別の支払いが実施される総決済システムと非常に類似している。それは、２者間関係において、決済が完了する２０分サイクル内で互いに相殺することにより、出ていく支払いのカバーとしての口座残高を使用する代わりに、入ってくる支払いを使用することが好ましいという原理に基づいている。流動資金を運転残高として、口座残金の形で使用することは、純粋な総決算システムと比較して、限定された範囲のみにおいて必要であり、そのため、相殺手順に含まれているカウンター支払いの量が正確にマッチングすることはない。ＥＡＦ２では、ネット決済システムとは反対に、その量の点で可能な限りマッチングされた入っていくる支払いと出ていく支払いが互いに相殺される。相殺手順には含まれていない支払いが、次に、待ち行列内に移動され、次の処理サイクルを待つ。これに反して、ネット決済システムにおいて、ネット残高が、全ての入ってくる支払いと出ていく支払いの間の差として計算されるが、ＣＨＩＰＳの場合では、１日の業務終了時に、口座への借記または信用貸しによって決済される。
【００４４】
ＥＡＦ２において、懸念される特定の２者間関係にある相殺に含まれる支払い間に残存する差をクリアするために、いわゆる最大送信側量の形式において、どの程度の流動性または運転残高を利用可能にしたいかを参加者が自分自身で決定する。この方法で、参加者は、相手側から受け取った過剰な資金に頼ろうとする程度を制限することができる。これら最大の送信側金額は、流動性の、参加者の特定の口座への移動によってカバーされ、この参加者の信用貸し残高は、懸案の２者間側に指定されている。これとは別に、システムは、流動性を保護するために、高レベルの２方向支払いを利用している。段階１の最後において、会計を簡略化するために、各々の参加者の全ての２者間借記残高が１つの全体的な信用貸し残高にまとめられ、両方の全体残高がジーロ口座（ドイツ小切手口座）に記帳され、また、指定された金額が公開される。
【００４５】
段階２の初めでは（ほぼ１：００ｐ．ｍ．）、段階１で相殺されていない支払いの初回の多者間清算処理が実施される。借記残高がカバーされない場合、残存する支払いの最大量、つまり、ジーロ口座の流動性がカバーする最大量が、個々の支払いを分類するためのアルゴリズムに基づいて計算される。次に、これらの残存する支払いは、すぐに最終のものになる。アルゴリズムによって既に定義している客観的な選択基準の補助を得て、カバーされていない借記残高を生じた個人の支払いが識別される。カバーされていないと考えられる個人の支払いは、第２多者間清算の実行を一時的に保留しながら破棄され、修正された残高がドイツ連邦銀行のジーロ口座に記帳される。
【００４６】
その後、カバーを入手するために４５分が参加者に許可される。技術的には、これは、以下に示す２つの異なる方法で入手することができる。
・ＥＩＬ−ＺＶ（ドイツ連邦銀行による総決済システム）からの支払い入力が口座残高を増し、次に、これがネット残高をカバーするために使用される。
・ＥＡＦ２自体における支払い入力（借記残高を持つ参加者に有利）が参加者間のネット残高を変更する。ジーロ口座の流動性は変化しない。
【００４７】
次の第２多者間清算から生じるネット残高が依然カバーされない場合には、ある参加者の排除が関与する巻き戻しは実行されない。代わりに、上述のアルゴリズムの手段により、個人の支払いは、ジーロ口座のカバー資金が十分になるまで、引き出されつづける。従って、ＥＡＦ２清算および決済は常に完了され、ネット決済手順に一般的な体系的リスクが、高額の支払いの非巻き戻しを除外することにより回避される。カバーされていないものとして扱われる個人の支払いは、取り消され、実行されないものと見なされる。段階１では２者間的に相殺され、段階２では多者間的に清算および決済される支払いの完了は、これによって影響されることはない。この手順はまた、総決済システムで使用されているものと同じであるが、ここで、待ち行列内に残っているカバーされていない支払いが既に実行されている支払いの完了に影響することなく戻される。実行されていない支払いは、同日に総決済システム、すなわちドイツＥＩＬ−ＺＶシステムに入力されるか、または、次の日にＥＡＦ２に再入力されてもよい。ドイツＥＩＬ−ＺＶは、この理由のために稼働時間を若干のばしている。
【００４８】
ＥＡＦ２システムには欠点がいくつかある。第１に、最終決済は１日を通して生じるが、発生の間隔は２０分間である。また、システムは、プレファンドされた口座が個々の機関によってセットアップされることを許可するが、各口座は、支払いを予め選択された金融機関へ相殺するために作成される。例えば、銀行Ａは、銀行Ｂに関する、そして銀行Ｂのみの支払いと領収を相殺するために口座をセットアップし、また、銀行Ａの銀行Ｃとの関連において、銀行Ａの別の口座することができる。
【００４９】
従って、この背景を仮定すると、他の全ての参加者に対して、支払いと領収を相殺するために使用される参加の金融機関のプレファンド口座の手段によって、支払いの、連続的な１日の最終決済を許可するシステムが必要である。
【００５０】
【発明の要約】
従来技術についての上述の説明を考慮すると、本発明の目的は、支払いが送信時に最終的に決済されるように、システムが支払い注文を金融機関から受信し、また、システムが金融機関に支払い注文を送信する銀行間の支払い注文の、連続した１日の最終決済システムおよび方法を提供することである。このシステムでは、必要とされるのは最小の補助ファンディングであり、その遅延は支払いの大きさで変化するが許容できる程度まで少なく、合計ドル出来高の高い割合いが相殺まえに公開される。
【００５１】
本発明のこの目的またその他のさらなる目的は、各々の金融機関（参加者）が支払い注文の電子送信の操作可能な関連した衛星コンピュータステーションを備えた、各々の金融機関が支払い受信参加者および支払い送信参加者としての機能が操作可能な複数の金融機関の連続的な１日の支払い注文の最終決済のためのシステムであって、前記システムは、（ａ）中央制御エージェントを有し、前記中央制御エージェントが、支払い注文を受信するべく、また、参加者間の支払い注文の公開を制御するべく、該参加者の衛星コンピュータステーションと電子通信を行うために操作可能な中央コンピュータを備えており、（ｂ）プレファンド残高口座内の複数のプレファンド残高を記憶するための手段を有し、各々の残高は、該参加者の１つのプレファンド残高口座からの支払いを行う権利を示し、また、各参加者の、各業務日毎の開始時における初回プレファンド残高を含んでいる。（１）送信側参加者として操作する該参加者の１つからの該中央制御エージェントによって、該参加者とは別の、受信側参加者としての参加者への支払い注文を受信すると、受信した支払い注文の各々を、関連する送信側参加者の該初回プレファンド残高の１つと、関連する受信側参加者の該初回プレファンド残高の所定の割合未満であれば小型に、それ以外であれば大型に分類するために、（２）前記受信した支払い注文を、該中央コンピュータによって維持される待ち行列内に記憶するために、（３）既に記憶されている小型支払い注文用に該待ち行列を、即座に公開する支払いの候補として監視するために、（４）支払いの候補の小型支払い注文の公開の結果、該候補小型支払い注文に関連した該送信参加者と該受信参加者の両方の利用可能残高が、各々の所定の限度内に収まるかどうかを決定するために、（５）ステップ（４）における決定が正である場合に、前記送信側参加者の該利用可能残高を借記することによって、また、該関連する候補小型支払い注文の金額により、該受信参加者の前記利用可能残高を信用貸しすることによって、該候補小型支払い注文を公開するために、（６）送信側参加者から受信側参加者への支払いのための、既に記憶されているターゲット大型支払い注文について、前記待ち行列を監視するために、（７）（ｉ）前記ターゲット大型支払い注文の該送信側参加者とは別の少なくとも１つの送信側参加者からの、該ターゲット支払い注文と、必要であれば、該ターゲット支払い注文の送信側参加者に向かうヘルパー支払い注文とを備えた第１ツリーを形成することにより、（ｉｉ）前記ターゲット支払い注文と、必要であれば、該大型ターゲット支払い注文の受信参加者から離れ、該ターゲット支払い注文の受信参加者とは別の少なくとも１つの受信側参加者へ向かうヘルパー支払い注文とを備えた第２ツリーを形成することにより、（ｉｉｉ）各々の支払い注文の金額によって、前記第１、第２ツリーの前記ターゲットおよびヘルパー支払い注文を有する多者間バッチ内の該ターゲット大型支払い注文の送信側参加者の、および、該ヘルパー支払い注文の送信側参加者の該利用可能残高を借記することにより、（ｉｖ）各々の支払い注文の金額によって、該多者間バッチ内の前記ターゲット大型支払いおよび該ヘルパー支払い注文の受信側参加者の残高を信用貸しすることにより、多者間バッチングを実行することで、該待ち行列に記憶されたターゲット大型支払い注文公開するために、前記コンピュータは、連続ベースでの操作可能であり、該多者間バッチは、第１および第２ツリーを有する支払い注文が公開された後に、該多者間バッチングに関連する各参加者の前記利用可能残高内のポジションが所定の限度内に収まるように選択される。
【００５２】
好ましくは、コンピュータシステムは、２者間バッチにおいて、該ターゲット大型支払い注文の関連する受信参加者からの、既に待ち行列登録されている第２支払い注文について前記待ち行列を検索することにより、ターゲット大型支払い注文の金額を選択的に相殺するために、また、該ターゲット大型支払い注文と第２支払い注文の間の正味差額の金額の擬似支払い注文を生成するために、また、前記擬似支払い注文を該待ち行列内に記憶するために操作可能である。
【００５３】
本発明の更なる目的は、中央制御エージェントにより、各々の金融機関参加者が支払い注文の電子送信の操作が可能な関連した衛星コンピュータステーションを備え、各々の金融機関参加者が支払い受信参加者および支払い送信参加者としての機能の操作可能な複数の金融機関参加者間の連続的な１日の支払い注文の最終決済のための方法を提供することであって、前記中央制御エージェントは、支払い注文を受信するべく、また、複数の参加者に対する支払い注文の公開を制御するべく、該複数の参加者の衛星コンピュータステーションと電子通信を行うために操作可能な中央コンピュータを備えており、プレファンド残高口座内の複数のプレファンド残高を記憶するための手段を有し、各々の残高は、該参加者の１つのプレファンド残高口座からの支払いを行う権利を示し、また、各参加者の、各業務日毎の開始時における初回プレファンド残高を含んでいる。前記方法は、（１）送信側参加者として操作する該参加者の１つからの該中央制御エージェントによって、該参加者とは別の、受信側参加者として操作する金融機関への支払い注文を受信すると、受信した支払い注文の各々を、関連する送信側参加者の該初回プレファンド残高の１つと、関連する受信側参加者の該初回プレファンド残高の所定の割合未満であれば小型に、それ以外であれば大型に分類するステップと、（２）前記受信した支払い注文を、該中央コンピュータによって管理される待ち行列内に記憶するステップと、（３）既に記憶されている小型支払い注文用に該待ち行列を、即座に公開する支払いの候補として監視するステップと、（４）支払いの候補の小型支払い注文の公開が、該候補小型支払い注文に関連した該送信参加者と該受信参加者の両方の利用可能残高が、各々の所定の限度内に収まるかどうかを決定するステップと、（５）ステップ（４）における決定が正である場合に、前記送信側参加者の該利用可能残高を借記することによって、また、該関連する候補小型支払い注文の金額により、該受信参加者の前記利用可能残高を信用貸しすることによって、該候補小型支払い注文を公開するステップと、（６）送信側参加者から受信側参加者への支払いのための、既に記憶されているターゲット大型支払い注文について、前記待ち行列を監視するステップと、（７）（ｉ）前記ターゲット大型支払い注文の該受信側参加者とは別の少なくとも１つの送信側参加者からの、該ターゲット支払い注文と、必要であれば、該ターゲット支払い注文の送信側参加者に向かうヘルパー支払い注文とを備えた第１ツリーを形成することにより、（ｉｉ）前記ターゲット支払い注文と、必要であれば、該大型支払い注文の受信参加者から離れ、該ターゲット支払い注文の受信参加者とは別の少なくとも１つの受信側参加者へ向かうヘルパー支払い注文とを備えた第２ツリーを形成することにより、（ｉｉｉ）各々の支払い注文の金額によって、前記第１、第２ツリーの前記ターゲットおよびヘルパー支払い注文を有する多者間バッチ内の該ターゲット大型支払い注文の送信側参加者の、および、該ヘルパー支払い注文の送信側参加者の該利用可能残高を借記することにより、（ｉｖ）各々の支払い注文の金額によって、該多者間バッチ内の前記ターゲット大型支払いおよび該ヘルパー支払い注文の受信側参加者の残高を信用貸しすることにより、多者間バッチングを実行することで、該待ち行列に記憶されたターゲット大型支払い注文公開するステップと、を有し、該多者間バッチは、第１および第２ツリーを有する支払い注文が公開された後に、該多者間バッチングに関連する各参加者の前記利用可能残高内のポジションが所定の限度内に収まるように選択される。
【００５４】
好ましくは、この方法は、２者間バッチにおいて、該ターゲット大型支払い注文の関連する受信参加者からの、既に待ち行列登録されている第２支払い注文について前記待ち行列を検索することにより、ターゲット大型支払い注文の金額を選択的に相殺するステップと、該ターゲット大型支払い注文と第２支払い注文の間の正味差額の金額の擬似支払い注文を生成するステップと、前記擬似支払い注文を該待ち行列内に記憶するステップとをさらに有する。
【００５５】
本発明のこの目的またその他のさらなる目的において、中央コンピュータによって実行可能なコードを記憶するコンピュータ読み出し可能媒体が提供され、複数の金融機関参加者間における連続的な１日の支払い注文の最終決済するための方法を実行するために、前記コードが該中央コンピュータを制御し、各々の金融機関参加者が支払い注文の電子的な送信の操作可能であり、各々の金融機関参加者が支払い受信側参加者および支払い送信側参加者としての機能の操作可能である。該中央コンピュータは、中央制御エージェントの一部を形成し、また、複数の参加者の支払い注文の公開を制御するために、また、プレファンド残高口座内の複数のプレファンド残高を記憶する手段を制御するために、支払い注文を受信するべく該複数の参加者の該衛星コンピュータステーションとの電子的な通信の操作が可能であり、各々の残高は、該参加者の１つのプレファンド残高口座からの支払いを行う権利を示し、また、各参加者の、各業務日毎の開始時における初回プレファンド残高を含んでいる。前記方法は、（１）送信側参加者として操作する該参加者の１つからの該中央制御エージェントによって、該参加者とは別の、受信側参加者として操作する参加者への支払い注文を受信すると、受信した支払い注文の各々を、関連する送信側金融機関の該初回プレファンド残高の１つと、関連する受信側金融機関の該初回プレファンド残高の所定の割合未満であれば小型に、それ以外であれば大型に分類するステップと、（２）前記受信した支払い注文を、該中央コンピュータによって管理される待ち行列内に記憶するステップと、（３）既に記憶されている小型支払い注文用に該待ち行列を、即座に公開する支払いの候補として監視するステップと、（４）支払いの候補の小型支払い注文の公開の結果、該候補小型支払い注文に関連した該送信参加者と該受信参加者の両方の利用可能残高が、各々の所定の限度内に収まるかどうかを決定するステップと、（５）ステップ（４）における決定が正である場合に、前記送信側参加者の該利用可能残高を借記することによって、また、該関連する候補小型支払い注文の金額により、該受信参加者の前記利用可能残高を信用貸しすることによって、該候補小型支払い注文を公開するステップと、（６）送信側参加者から受信側参加者への支払いのための、既に記憶されているターゲット大型支払い注文について、前記待ち行列を監視するステップと、（７）（ｉ）前記ターゲット大型支払い注文の該送信側参加者とは別の少なくとも１つの送信側参加者からの、該ターゲット支払い注文と、必要であれば、該ターゲット支払い注文の送信側参加者に向かうヘルパー支払い注文とを備えた第１ツリーを形成することにより、（ｉｉ）前記ターゲット支払い注文と、必要であれば、該大型支払い注文の受信参加者から離れ、該ターゲット支払い注文の受信参加者とは別の少なくとも１つの受信側参加者へ向かうヘルパー支払い注文とを備えた第２ツリーを形成することにより、（ｉｉｉ）各々の支払い注文の金額によって、前記第１、第２ツリーの前記ターゲットおよびヘルパー支払い注文を有する多者間バッチ内の該ターゲット大型支払い注文の送信側参加者の、および、該ヘルパー支払い注文の送信側参加者の該利用可能残高を借記することにより、（ｉｖ）各々の支払い注文の金額によって、該多者間バッチ内の前記ターゲット大型支払いおよび該ヘルパー支払い注文の受信側参加者の利用可能残高とを信用貸しすることにより、多者間バッチングを実行することで、該待ち行列に記憶されたターゲット大型支払い注文公開するステップと、を有し、該多者間バッチは、第１および第２ツリーを有する支払い注文が公開された後に、該多者間バッチングに関連する各参加者の前記利用可能残高内のポジションが所定の限度内に収まるように選択される。
【００５６】
好ましくは、コンピュータ読み出し可能媒体は、２者間バッチにおいて、該ターゲット大型支払い注文の関連する受信参加者からの、既に待ち行列登録されている第２支払い注文について前記待ち行列を検索することにより、ターゲット大型支払い注文の金額を選択的に相殺するステップと、ターゲット大型支払い注文と第２支払い注文の間の正味差額の金額の擬似支払い注文を生成するステップと、前記擬似支払い注文を該待ち行列内に記憶するステップとをさらに含む方法を前記中央コンピュータに実行させるためのコードを記憶する。
【００５７】
【好適な実施形態の詳細な説明】
Ｉ．システムの概観
本発明は、参加の金融機関と通信するべく構築された中央コンピュータを備えた中央制御エージェントを含むシステムに関するものである。上記システムは、参加の金融機関に関連した、プレファンド残高口座（prefunded balance account）を制御および更新するためのハードウェアを備えており、また、これらの口座を所定の規制内で信用貸しおよび借記する（debit）手段によって、上記システムは、参加金融機関の間での支払いの解除および決済を制御する。このシステムは、決済サービスを提供する連邦準備銀行や参加金融機関を含む銀行と電子的に通信する機能を備え、また、銀行から受信した支払い注文を、関連した支払いが解除可能になるまで一時的に記憶しておくための待ち行列を保持するのに十分な記憶容量を持ったコンピュータシステムを用いて実現することが好ましい。また、このシステムは、現在のＣＨＩＰＳシステムハードウェアのある特徴を用いて実現することもできる。しかし、ＣＨＩＰＳハードウェアを用いて実現した場合、このシステムでは、全解除の１日の支払い完了性を提供することにより、現在のＣＨＩＰＳの実施に対して著しい改善を達成する。しかしながら、本発明のシステムは、この実現に限定されることがなく、また、ＣＨＩＰＳシステム内に使用されているものから独立した、あるいは異なるハードウェアおよびソフトウェアを用いて実現することが可能である。
【００５８】
現在のＣＨＩＰＳシステムの詳細な説明は、The Clearing House Service Company L.L. C.発行の「CHIPS Systems and Operations Manual」に記されており、本明細書中でも参照することで援用している。
【００５９】
本発明のシステムの目的は、従来のＣＨＩＰＳシステムで必要な特定の義務を保証するために現在入れられている担保額よりも小さなプレファンドされた残高を用いながら、１日の支払い完了性を達成することである。
【００６０】
本発明のシステムは、終日にわたり参加金融機関（「参加者」）間の個別の、２者間の、あるいは多者間のバイアスにおける支払いメッセージを連続的にマッチングさせ、ネッティングし、公開する（release）ソフトウェアを採用したコンピュータ制御された装置を備えている。このシステムでは、（ａ）送信・受信側の参加者によって確立されたプレファンドされた残高に、支払いメッセージの額面（value）が同時に請求されるか、または信用貸しされないかぎり、または（ｂ）その支払いメッセージが、１つまたはそれ以上の他の支払いメッセージにネッティングおよび相殺され、その結果、プレファンド残高に対して残高が同時に請求および信用貸しされないかぎり、参加者に支払いメッセージが公開されることはない。この方法により、送信側参加者の、受信側参加者への支払いメッセージに示された金額の支払いの義務を、ニューヨーク統一商事法典の４−Ａ−４０３項（１）（ａ）または４−Ａ−４０３（２）項の下で「最終決済」することになる。
【００６１】
このシステムは、１業務日中に、１つまたはそれ以上の参加者が決済の失敗に陥った場合でも、その失敗に伴ういかなる危険を排除する。現在のＣＨＩＰＳシステムに対する著しい改善は、各参加者が連邦準備銀行の口座（プレファンド残高口座）に所定の金額を入れ、その額面、または、ネッティグと相殺を含む残高が、参加者の口座内の利用可能残高を超えない限り、支払いメッセージの公開を禁止することで達成される。
【００６２】
このシステムは、１業務日中に、支払いメッセージの合計額面の９６％よりも多い額面が記された多数の支払いメッセージの内の９９％以上の公開を許容するように期待されている。ＣＨＩＰＳ内で利用すると、本発明のシステムは、ＣＨＩＰＳシステム内に残っている決済危険の最後の要素を除去するであろう。
【００６３】
さらに、本発明のシステムを使用することにより、支払いシステムにおける全般的な危険を、従来のシステムと比べて著しく減少させる。この新規システムは、支払いが公開され次第、外国為替取引きの１部であるドル払いの終了を許可することにより、決済に伴う危険性を減少させるであろう。例えば、ドル−ユーロ取引きのドル側を、その日の初めに、最終支払いをもって終了し、同時に、ユーロ支払いを、ＥＡＦ−２システムがあるドイツのフランクフルトで決済することができる。
【００６４】
本発明のシステムの好ましい１つの実施形態において、例えば、ＣＨＩＰＳ規則下において、債務を保証するために米国財務セキュリティに担保を入れる代わりに、各参加者は、ニューヨーク連邦準備銀行（“ＦＲＢＮＹ”）の帳簿上の金額（「プレファンド残高額（prefunded balance account）」）に対する最終的な取り消し不能の支払いを送ることにより、所定の金額（「初回プレファンド残高（initial prefunded balance）」）を預託することが求められる。このシステムは、各参加者の初回の預託をプレファンド残高口座、すなわち、例えば、ＣＨＩＰＳで実現している場合にはＣＨＩＰＳの帳簿および記憶装置に記録し、また、支払いメッセージが公開される際に、１日の内に参加者に生じる借記または信用貸しを全て記憶する。全ての借記および信用貸しを反映するために調整した各参加者のプレファンド残高の１日の記録は、参加者の「利用可能残高」と呼ばれ、終日の任意の時間において、各参加者に属するプレファンドされた残高口座の１部を確立する。
【００６５】
いかなる参加者も、初回プレファンド残高をプレファンドされた残高口座に預託しない限り、支払いメッセージの送受信を行うことはできない。プレファンドされた残高口座への預託は、午前１２時３０分にＦｅｄｗｉｒｅが始業し次第行うことができる。全ての参加者は、初回プレファンド残高を午前９時（連邦準備銀行が従う祝日の次の日は午前７時）までに預託していなければならない。多くの参加者が、プレファンドされた残高口座への要求された預託を、自分の準備口座または手形交換口座にＦｅｄｗｉｒｅ支払い注文を送ることによって行うことが予想されるが、自分の代わりに、連邦準備銀行に口座を持っていない参加者も、取引き先銀行にＦｅｄｗｉｒｅへ支払い注文を送ってもらうことができる。
【００６６】
各参加者に要求される初回プレファンド残高は、システムの最良のパフォーマンスを得るために構成された公式を用いて決定される。初回プレファンド残高は、各週の最後に再計算されて、次週の初回プレファンド残高要求が決定される。参加者の初回プレファンド残高の要求は、現在のＣＨＩＰＳ下におけるその参加者の担保要求とほぼ同額になる。
【００６７】
システムが支払いメッセージの受付を終了するまで、参加者は、１日の間に、プレファンド残高口座へ追加の預託を行うことや、プレファンド残高口座から引き出しを行うことはできない。その結果、この処理中は、プレファンド残高口座内の残高は連邦準備銀行の帳簿上では減少しない。しかし、各参加者の利用可能なプレファンド残高は、支払いメッセージの公開および受信に基づいて、その日の内に変更される。支払いメッセージが、次に述べる手順に従って同時にネッティング、相殺、公開される場合、システムは、送信側、受信側の参加者の利用可能な残高に対して適切な借記および信用貸しを行う。従って、各参加者の利用可能な残高は、１日の内に、支払いメッセージが公開および受信される度に調整および再調整される。好ましい実施形態において、参加者の利用可能な残高がゼロ未満（参加者の「最小利用可能残高」）または要求された初回プレファンド残高の２倍よりも大きな金額（参加者の「最大利用可能残高」）になることは許されないが、しかし、本発明は、異なる規制を利用して実現することができ、また、この好ましい実施形態に制限されるものではない。
【００６８】
本発明は、支払いメッセージの公開を規制するためのコンピュータプログラムを備えたコンピュータベースのシステムに関するものである。このプログラム（「帳尻を合わせた公開エンジン」（balanced released engine））は、１日を通して、支払いメッセージを連続的にマッチング、ネッティング、相殺、公開する。入ってくる全ての支払いメッセージは、システムによって受信され、コンピュータプログラムの準備ができた際に公開するべく、１つまたは好ましくは複数の待ち行列に登録される。プログラムは、大型の（送信側参加者の初回プレファンド残高および受信側参加者の初回プレファンド残高の内の１つの８０％に等しいかまたはこれよりも大きな、または好ましくはこれ未満の現在のモデリングにおいて）または小型の（初回プレファンド残高の１つの８０％、または好ましくはこれ未満）各支払いメッセージを幅広く分類する。
【００６９】
この明細書全体を通じて、「大型」という言葉は、初回プレファンド残高の８０％に等しい、またはこれよりも大きな支払い注文のカテゴリーを参照するべく使用されている。しかし、発明者は、本記載で幅広く「小型」と呼んでいる８０％未満の支払い注文が、さらに、その初回プレファンド残高の２０％〜８０％に当てはまる金額である「中型」支払い注文、「小型」、２０％またはそれ未満の金額に当てはまる「超小型」に分割された場合、本システムの効率にいくつかの改善が見られることを発見した。これ以降の記載で、支払い注文を小型、中型、大型と説明する方法を使用している場合には、参照した上述の３つの分類に基づいている。以降の記載の、中型支払い注文を使用していない部分では、より幅広い「小型」という用語が示すのは、初回プレファンド残高の８０％未満の全ての支払い注文であることが意図されている。好ましい実施形態について選択された割合は、任意のものであることに注意すべきである。重要な特徴は、分類が１つまたは複数の初回プレファンド残高に関連した支払い注文の大きさによって行われていることである。
【００７０】
このプログラムは、支払いを、２者間バッチまたは多者間バッチにおいて個々に公開し、送信側参加者に対して公開通知を送信し、受信側参加者に対して受信通知を送信する。この一般的な支払いプロセスの流れを図１に示す。
【００７１】
大型支払いを個々に公開することは、通常、送信側の参加者の残高をその最小利用可能残高未満にするか、または受信側の参加者の残高をその最大利用可能残高以上にしてしまう。従って、帳尻を合わせた公開エンジンは支払いを公開せず、バッチ内に含むことができ、また、大型支払いメッセージにネッティングすることができる支払いを検索する。必要であれば、別の参加者からの別の「ヘルパー」支払いメッセージが、次の方法でそのバッチに追加される。その方法とは、そのバッチ内の全ての支払いメッセージが互いにネッティングおよび相殺されて、バッチに支払いメッセージを持った各参加者の利用可能残高へのネットの変更が、いかなる参加者の利用可能残高がゼロ未満にならない、または最大値を超えないようにするものである。このバッチングについて以下に詳細に説明する。
【００７２】
発明者は、本発明のシステムによって、送信側参加者が送信する支払いメッセージの９９％以上の公開が許可され（全ての支払いメッセージの額面の９６％）、ＣＨＩＰＳハードウェアを使用してシステムを実現している場合には、これと同時に、ＣＨＩＰＳがさらなる支払いメッセージの受信を終了した際に少数の支払いが公開されずに残ることを示すと信じている。業務終了前にこれらの支払いメッセージを公開および決済するために以下の手続きを使用する。
【００７３】
支払いメッセージ受信の終了時間後に、残っている支払いメッセージを、いかなる参加者の最大利用残高にも関連することなく、できるだけ多くマッチング、ネッティング、相殺、公開するために、帳尻を合わせた公開エンジンが使用される。この手続きの後に、残っている未公開支払いメッセージに基づいて、これらの支払いメッセージを実際にネッティング、相殺または公開することなく、各参加者についてのネット残高を計算するために、帳尻を合わせた公開エンジンが使用される。
【００７４】
ある参加者についての結果の数がマイナスになった場合、その参加者は「最終プレファンド残高要求」を有し、また、ある参加者についての結果の数がプラスになった場合、その参加者は「最終プレファンド残高権利」を得る。次に、各参加者は、その最終プレファンド残高要求または最終プレファンド残高権利についてアドバイスする管理メッセージを受信する。
【００７５】
最終プレファンド残高要求を得た各参加者は、最終プレファンド残高要求にある金額を、プレファンド残高口座に３０分以内にＦｅｄｗｉｒｅ口座振替えで送らなければならない。これらの口座振替えの全てが完了したら、残りの未公開支払いメッセージの全てがネッティング、相殺、公開され、同時に、システムが、最終プレファンド残高権利を得た各参加者に対して、その最終プレファンド残高権利にある金額をＦｅｄｗｉｒｅ口座振替えで送る。
【００７６】
最終プレファンド残高要求を得た参加者がプレファンドされた残高口座に対して要求されたＦｅｄｗｉｒｅ口座振替えを送ることを拒否したり、同振替えを行うことが不可能な場合には、最終ファンディングステップにおいて、受信された最終プレファンド残高要求を追加した上で調整された利用可能な残高を使って、帳尻を合わせた公開エンジンが再び動作する。これにより、追加の支払いメッセージの公開が許可される。送信側の参加者は、この手続きに従って、未公開のまま残っているあらゆる支払いメッセージに関して通知される。送信側の参加者は、システムが終了する前に、あらゆる未公開支払いメッセージをＦｅｄｗｉｒｅを介して再び送ることができる。
【００７７】
ＩＩ．支払い完了性の法的基準
現在のＣＨＩＰＳ支払いメッセージの各々は、ニューヨーク統一商事法典の４−Ａ−１０３項の趣旨範囲における支払い注文である。現在、ＣＨＩＰＳ規則２の下には、「支払いメッセージの公開は、送信側参加者に、その支払いメッセージ上の金額を受信側参加者へ支払う義務を生じる」とある。The Clearing House Service Company L.L.C発行の「CHIPS Rules and Administrative Procedures」を参照されたい。かかる義務は、ＣＨＩＰ支払いメッセージが公開されると、ＣＨＩＰ支払いメッセージについては存在しなくなる。ＣＨＩＰＳ規則２にはさらに、「送信側参加者の受信側参加者への支払い義務は、規則１２に従ってネッティングされ、規則１３に従って決済される」ともある。
【００７８】
規則１２は、ＣＨＩＰＳ支払いメッセージが互いに連続的にネッティングおよび相殺されると述べており、規則１３（ｃ）（１）は、このネッティングおよび相殺手続きの結果生じた多者間のネッティング残高は、ニューヨーク連邦準備銀行（“ＦＲＢＮＹ”）において決済される、と述べている。規則１３（ｃ）（２）の下には、決済は、要求されたその決済口座への、またはここからの支払いがなされた際に完了する、とある。
【００７９】
ＣＨＩＰＳ規則の参照した条項とニューヨーク統一商事法典との間の相互作用の効果は、送信側参加者の受信側参加者への支払い義務は、その日の終わりに、決済が終了するまで完了したことにはならないことである。
【００８０】
本発明によるシステムの主な利点は、送信側参加者が受信側参加者への支払い義務を果たすことができ、同時に、その支払いメッセージが受信側参加者に公開されることである。これは、統一商事法典の条項でも認められている。ニューヨーク統一商事法典の４−Ａ−４０３（２）項には、（現在のＣＨＩＰＳが行うように）参加者間で多者間的に義務をネッティングする口座振替えシステムのメンバー間で、「システムの規則に従って決済が完了すると、受信側の銀行は最終決済を受信する」とある。４−Ａ−４０３項には、
「送信側の、口座振替えを介して送信された支払い注文の金額を支払う義務は、受信側の銀行によって口座振替えシステムを介して送信側へ送信されたその他のあらゆる支払い注文の金額を、受信側の銀行から受信する送信側の権利を送信側の義務に対して相殺および適用することにより、システムの規則によって許可される範囲まで満たすことができる。口座振替えシステムにおいて各送信側が受信側の各銀行に負っている義務の累計残高は、システムの他のメンバーが送信側に負っている義務の累積残高をその残高に対して相殺および適用することにより、システムの規則によって許可される範囲まで満たすことができる。」
とある。
【００８１】
さらに、ニューヨーク統一商事法典４−Ａ−４０３（１）（ａ）項には、送信側の義務の支払いは「受信側の銀行が…義務の最終決済を口座振替えシステムを介して受信した際に生じる」とある。
【００８２】
上述したように、本発明のシステムでは、支払いメッセージは個別に、またはバッチで公開される。支払いメッセージが個別に公開された場合、これは同時に決済され、送信側参加者の義務が、借記また信用貸しによって送信側および受信側参加者の利用可能な残高に支払われる。事実上、これは、ニューヨーク統一商事法典の４−Ａ−４０３（１）（ａ）項によって即座に終了し認可される、口座振替えシステムを介した「総決済」である。支払いメッセージがバッチで公開される場合、各支払いメッセージは送信側および受信側参加者の相互への義務をネッティングすることにより決済され、また、２つよりも多い数の参加者がバッチにおける支払いメッセージを有する場合、同バッチ内の全ての参加者の２者間ネット残高が、やはりネッティングすることにより決済される。このネッティングの結果生じる各参加者の残高は（２者間ネット残高または多者間ネット残高のいずれの場合でも）、その利用可能残高への借記または信用貸しを介して同時に決済される。これが終了すると、これらの支払いメッセージの決済が、本発明のシステムを制御するべく提案された規則に従って、完了される。この利用可能残高のネッティングおよび調整によって、４−Ａ−４０３（２）と４−Ａ−４０３（１）（ａ）項の下で最終決済と支払いが生じる。
【００８３】
この手続きにより、支払いメッセージに関連した支払い義務が、支払いメッセージが受信側参加者に公開された時の利用可能残高のネッティングおよび調整を介して決済される。さらに、現在のＣＨＩＰＳシステムでのように「逆戻し」に備える必要がない（すなわち、ＣＨＩＰＳが決済と、全ての支払いメッセージを記憶装置へ戻すこととに失敗したと宣言するための、ＣＨＩＰＳ規則２、１３（ｋ）下における役員会の権限）。同様に、ＣＨＩＰＳ規則１３の下で備えられている担保物権で保証された損失分担装置を備える必要もない。
【００８４】
ＩＩＩ．帳尻を合わせた公開エンジン
上述したように、帳尻を合わせた公開エンジンは、銀行間の支払いを目的の受信側にいつ公開することができるかを決定をする。本発明において、支払いの公開は、以下に説明するように、異なるドルサイズクラスでの支払いとは違う形で進行する。
【００８５】
システム内の各参加者は、所定の金額または初回のプレファンド残高をプレファンド残高口座に預託しなければならない。初期プレファンド残高の２倍の信用貸し限度（最大利用可能残高）が上限または「キャップ」（上限金利）として設定されるが、使用可能残高はゼロ以下（借記または「キャップ」限度）に達することができず、本発明のシステムにおいては最小利用可能残高と呼ばれる。初期プレファンド残高の０．８倍と独断的に定義された「フローキャップ」が、「小型」支払いと「大型」支払いを区別するために幅広く使用されており、フローキャップよりも小さなものは「小型」、それ以外は「大型」と定義される。
【００８６】
Ａ．小型支払いの公開
帳尻を合わせた公開エンジンは、小型支払い、すなわち送信側参加者と受信側参加者の初期プレファンド残高の低い方の８０％未満を、中央コンピュータ記憶装置に常住する２者間の先入れ先出し待ち行列から（バッチすることなく）個別に公開する。中央コンピュータ記憶装置は、入ってくる支払い注文が、送信側参加者と受信側参加者の許可ポジションとして、その受信後に保管される場所である。支払いの公開後は、上述した最小および最大利用可能残高のいずれも超えることはできない。優先権は常に、待ち行列に最も早く登録された支払いの公開に与えられる。しかし、「最も早い」という言葉の意味は送信側と受信側では異なるので、ある意味で最も可能性がある送信者と受信者の最適なマッチングを見つけるために、以下に詳細に説明する、ゲール・シャプレイのアルゴリズムに基づいたマッチング技術が使用される。
【００８７】
Ｂ．大型支払いの公開
帳尻を合わせた公開エンジンは、多者間および／または２者間のバッチの補助を得て支払いを公開する。ここでは、２者間バッチングを説明する。
【００８８】
１．２者間バッチング
待ち行列に登録された大型の支払いは、以下に示すように２者間的にバッチングされる。銀行Ａから銀行Ｂへの大型の支払い注文が待ち行列に登録された場合、銀行Ｂから銀行Ａへの、第１の支払い注文の半分から２倍までの大きさの別の支払い注文が既に待ち行列に登録されていないかどうかがチェックされる。既に登録されている場合には、第２の支払い注文が選択され、第１の支払い注文とバッチングされる。その結果、金額がオリジナルの２つの支払い注文の間の差額である「擬似支払い」となる。この差額は、バッチ内の２つの支払い注文の金額の各々よりも小さいか、または等しいものになることに注意されたい。この擬似支払いの行き先は、高い方の支払い注文の行き先である。
【００８９】
擬似支払いが形成されると、利用可能な適切な「第２」支払い注文がなくなるまで、この処理が反復的に繰り返される。各ステップにおいて、擬似支払いの大きさは小さくなっていくか、あるいは最悪の場合にはそのままの大きさに留まる。従って、２者間バッチングの総体的な効果は、公開される支払いの大きさと数を減少させることである。次に、これらの擬似支払いは、以下に説明する多者間バッチングを用いて、上述したような小型支払いとして、または大型支払いとして公開される。システムは、擬似支払いを「公開」する際に、ある１つの取引きにおける擬似支払い内にリンクされたバッチングした支払いを全て公開する。
【００９０】
２．多者間バッチング
多者間バッチングは、フローキャップよりも大きな支払い（および擬似支払い）、さらに、借記および信用貸しキャップよりもずっと大きな支払いの公開手段を提供するべく本発明のシステムにおいて利用される。
【００９１】
ある大型支払いが待ち行列に登録されると、２者間バッチングが終了した後に、その待ち行列上にある任意の大型支払いを今公開することができるかどうかのチェックが行われる。
【００９２】
銀行Ａから銀行Ｂへの所与の大型支払いＰの公開を考慮した場合、通常、このような公開は、銀行Ａのポジションをその借記キャップの下に下げ、また、銀行Ｂのポジションをその信用貸しキャップの上に上げる。そのため、規定の限定内において銀行Ａでのネットポジションを生じるために、現在信用貸しポジションにある第３者側の参加者から銀行Ａにヘルパー支払いが用いられる。ヘルパー支払いはまず、銀行Ａでのポジションのみを考慮して選択される。
【００９３】
多者間のバッチの構成の各ステップにおいて、ルート参加銀行Ａに下方向に向かう支払いのツリーが存在する。このツリーの１例が図２に示されている。図２については以下により詳細に説明する。例えば、図２の銀行Ｂのようにツリーのノードにある、入ってくるブランチと出て行くブランチの両方を備えた参加者は、その限度制約を満たす。ツリーのリーフ（末端）ノードは、借記キャップを超えることができる、従って、自身がヘルパー支払いを必要とする参加者である。該ツリー上の、このタイプのヘルプを必要とするあらゆる参加者は、その後、ヘルプが提供されるか、またはツリーを縮小するために削除される。
【００９４】
構築が成功すると、以前、信用貸しポジションにあった参加者間の支払いのツリーが得られ、これにより、ツリーにおける参加銀行Ａを含む全ての参加者のポジションは規定の借記および信用貸し限度内に収まる。
【００９５】
上述のツリーが構築されると、以前、借記ポジションにあった参加者への支払いを用いて、銀行Ｂにおいて類似した状況を作る試みがなされる。可能であれば別のツリーが構築され、これにより、第２ツリーにおける全ての参加者ポジションが限度内に収まる。この全てが成功すると、一緒に行われた支払いの全てが多者間のバッチを構成し、これが単一の処理において公開される。
【００９６】
ＩＶ．システムハードウェア
本発明のシステムを駆動するプログラムを実行するためのコンピュータシステムの１例を図１Ａに示す。このシステムは、処理機能を実行するＣＰＵ３１を備えている。また、オペレーティングシステムまたは基本入出力システム（ＢＩＯＳ）の部分のような、ＣＰＵ３１によって実行されるプログラム指示の少なくともいくつかを記憶する読み出し専用メモリ３２（ＲＯＭ）と、データを一時的に記憶するために使用されるランダムアクセスメモリ（ＲＡＭ）３３をさらに備えている。コンピュータはさらに、参加金融機関に配置されたコンピュータのような外部装置との通信を可能にするネットワークインターフェース７２を備えている。また、データの記憶を行うためにデータ記憶装置３４を備えている。データ記憶装置３４は、ＣＰＵ３１への書き込みと読み出しが可能である。データ／アドレスバス３７はＲＯＭ３２、ＲＡＭ３３、データ記憶装置３４をＣＰＵと接続する。操作者からの入力を受信するために、キーボードを設けることが好ましい。しかし、操作者入力の従来のあらゆる方法を使用することが可能である。また、コンピュータの操作者に情報を伝えるためにディスプレイを設けることが好ましい。
【００９７】
Ｖ．帳尻を合わせた公開エンジンの詳細な説明
本発明のコンピュータシステム上で実行されるプログラムは、ある特定の基本的な規準を利用する。
【００９８】
１．各参加者によってプレファンド残高口座に支払われたファンドは、その支払い注文を支払うために使用される。
２．１参加者の利用可能な残高がマイナス、すなわちゼロ未満のドル（「最小利用可能残高」）になることは許されない。
３．既述の好適な実施形態においては、初回プレファンド残高要求の２倍の大きさに等しい最大利用可能残高が、各参加者に課される。１参加者の、初期プレファンド残高を含む利用可能残高は、その信用貸し限度を超えてはならない。この上限は、危険を制限するためには必要ないが、発明者が実行したシミュレーションは、このような制限が、システムを十分に機能させる上で必要であることを示した。上述したように、この制限は、１日の会計締め切りの終了に、処理のために除去される。
４．以下の項目５で述べられる、処理の最高点において、このプログラムは支払いメッセージを「公開する」決定を行う。この時点で、システムは、送信側参加者と受信側参加者の利用可能残高を変更するための指示を発行し、注文の指示を反映する。
【００９９】
５．常に支払い注文をその受信後に公開する代わりに、支払い注文をいつ公開するかについての決定が、本発明の１つの実施形態に従って以下の通りに行われる。
【０１００】
まず、入ってきた支払い注文が、「小型」（すなわち、「フローキャップ」よりも少ない、好ましくは、送信側参加者と受信側参加者の初期プレファンド残高の要求金額の少ない方の８０％）、または「大型」（すなわち「小型」でない）に分類されされる。その公開が上述の項目２または項目３を違反しないものであるならば、ワークフローのほとんどを有する小型の支払い注文が、即座に公開するべく待ち行列に登録される。待ち行列内への入力は、「先入れ先出し」（ＦＩＦＯ）待ち行列規律のバージョンに従って処理される。しかし、送信側参加者の待ち行列内で最も早い支払い注文は、受信側参加者の待ち行列内でも最も早い支払いよりも早いかもしれないし、そうでないかもしれない。従って、どの支払い注文を最初に処理するかを選択するためにマッチング技術が用いられる。この技術の詳細は、どの支払い注文をどのような順番で公開するかについての効率的なポリシー決定である。このアルゴリズムの詳細な説明を以下に述べる。
【０１０１】
「大型」支払い注文が、ネッティングされた支払い注文の「バッチ」の１部分として公開される。多者間の、または任意で上述した２者間バッチングについて「ヘルパー注文」となるのに適している場合、１日の処理のほとんどについて、これらの大型支払い注文が「遅延」待ち行列内の最初に配置される。遅延待ち行列を通過した直後に、大型支払い注文が、多者間バッチング手続きにおいてヘルパー支払い注文として包含するのに適したまま維持される。さらに、この支払い注文を２者間バッチの１部として包含する試みがなされる。
【０１０２】
送信側参加者の利用可能残高がゼロから十分に遠く、受信側参加者の最大利用可能残高が違反されることがない場合、フローキャップよりも大きいが、送信側参加者の初回プレファンド残高よりも小さな支払い注文の、自身によるこの時点での公開が可能である。しかし、送信側参加者の初回プレファンド残高要求金額の１６０％未満の支払い注文は、２者間バッチングの呼び出しをトリガすることはない。
【０１０３】
２者間バッチングにおける試みが失敗した場合、支払い注文は、２者間バッチング手続きと多者間バッチング手続きの両方にとって利用可能なヘルパー注文として待ち行列内に残る。さらに、多者間バッチング手続きは、多者間バッチング手続きの各々の「ターゲットの支払い注文」を作成しながら、タイムスタンプ（システムが支払い注文を受信した時間の表示）によって分類された、待ち行列登録された大型支払い注文のリストを走査する。２者間および多者間バッチングの詳細を以下に述べる。
【０１０４】
Ａ．２者間バッチング
参加者１から参加者２への大型支払い注文が、２者間バッチングされるべく待ち行列に登録された場合、大型支払い注文は、つい先程待ち行列登録された大型支払い注文の半分から２倍までの大きさである、参加者２から参加者１へ最も早く待ち行列に登録された支払い注文と共にネッティングされる。上述したように、参加者２から参加者１へのネッティング可能な支払い注文の大きさに課せられるこの規制によって、結果として生じる、ネッティングされた擬似支払い注文が、両方のオリジナル支払い注文よりも小さいか、またはこれと等しくなることが保証される。この処理は、参加者２から参加者１への待ち行列または参加者１から参加者２への待ち行列において、参加者１の初回プレファンド残高要求金額の２０％の「小型支払いキャップ」よりも大きなネッティング可能な支払い注文が見つからなくなるまで反復的に繰り返される。発明者は、この任意の選択により、効率的なオペレーションを伴う優れたパフォーマンスを得られることを発見した。本発明のオペレーションに２者間バッチングは必要なく、また、このシステムは、本明細書を通じて説明している多者間バッチングと個別公開技術との組み合わせを使用するだけで効率的に機能することができる点に留意するべきである。
【０１０５】
以下に示す例は、この処理を理解する上で有用である。ＡとＢへの初回プレファンド残高要求金額が両方とも１千万ドルであり、最初はどちらの待ち行列にも何もないと仮定する。次に、ＡがＢに対して１億ドルの支払いを行いたいと思った場合、これは、Ａの初回プレファンド残高要求金額とＢの最大利用可能残高を超える金額であるため、これをＡからＢへの支払い注文の待ち行列に記憶しなければならない。同様に、ＢからＡへの８億ドルの支払い注文は、ＡからＢへの注文をネッティングすることなく、ＢからＡへの注文の待ち行列に記憶されなければならない。次に、ＡからＢへの６億ドルの支払い注文が、ＢからＡへの支払い注文とネッティングされ、ＢからＡへの２億ドルの擬似注文が生じ、これは単発の注文として待ち行列に登録される。続いて、この擬似支払い注文が、その前に待ち行列登録されたＡからＢへの１億ドルの支払い注文とネッティングされる。この一方で、８億ドルと６億ドルの支払い注文が最初にシステムに入力された場合には、これらは即座に単発の２億ドルの擬似支払い注文へとネッティングされ、ＢからＡへの待ち行列に配置される。
【０１０６】
結果生じた擬似支払い注文が、次に、実際の支払い注文と同一に扱われる。言い換えれば、このネッティング処理によって参加者１から参加者２への擬似支払い注文が生じた場合、これは参加者１の参加者２への支払い待ち行列に待ち行列登録され、また、ネッティング処理によって参加者２から参加者１への擬似支払い注文が生じた場合、これは参加者２の参加者１への支払い待ち行列に待ち行列登録される。また、実際の支払い注文の場合と同様に、送信側参加者の最大利用可能残高または受信側参加者の最大利用可能残高のどちらも超えることがなければ、擬似支払い注文は公開される。
【０１０７】
Ｂ．多者間バッチング
この手続きは、ネッティング可能な大型支払い注文（上で定義した通り）の２重ツリーを識別しようと試み、これらを１つのバッチとして処理する。この手続きは、「ターゲット支払い注文」として識別された特定の大型支払い注文から開始する。目的は、ターゲット支払い注文とネッティングすることができる「ヘルパー注文」のリストを識別し、これにより、ネット注文が全ての最大および最小利用可能残高規制を満たすようになることである。
【０１０８】
例えば、ターゲット支払い注文が参加者１から参加者２への金額Ａ₁₂の大型支払い注文であると仮定する。支払い注文が公開された場合、初回プレファンド残高要求金額Ｆ₁を含む１の利用可能残高のポジションＰ₁はマイナスになるか、または、記号で
Ｐ₁−Ａ₁₂＜０（１）
となる。
【０１０９】
しかし、参加者３から参加者１への、金額がＡ₃₁の別の支払い注文がある場合があるかもしれず、そのため、
２Ｆ₁≧Ａ₃₁＋Ｐ₁−Ａ₁₂≧０；（２）
となる。
【０１１０】
言い換えれば、１の利用可能残高がゼロ未満にならないように、利用可能残高を十分に増加させる、「ヘルパー支払い」を１に送信する注文があるということである。多者間バッチングプログラムの第１ステップは、このようなヘルパー注文について１への支払い注文の待ち行列を検索するものであるが、これは、ゼロよりも大きな利用可能残高を持つ参加者の間においてのみ行われる（この制約の説明については、以下を参照のこと）。２つ以上の可能性が見つかった場合には、それ自体がヘルプの最少額を要求する支払い注文が使用される。これらの制約を満たす支払い注文が１つも見つからない場合には、潜在的な残高赤字を部分的に相殺することが可能な最大の支払い注文が使用され、注文、すなわち、他の小型支払い注文と共に増大する。
【０１１１】
通常の場合のように、選択したヘルパー注文（１つまたは複数）についてＰ₃−Ａ₃₁＜０であれば、その支払い注文についてヘルパー注文を探す試みがなされる。すなわち、さらに別の参加者４からの支払い注文が、
２Ｆ₃≧Ａ₄₃＋Ｐ₃−Ａ₃₁≧０（３）
等となる。
【０１１２】
理想的には、各参加者の利用可能残高が最大および最小利用可能残高限度内に留まるようにするために支払い注文の多者間バッチが生成される。そうでなければ、適切なツリーを完成することができない（すなわち、プログラムが「エンプティハンド状態」で終了する）。ゼロよりも大きな（すなわちＰ＞０）利用可能残高を持ったこれらの参加者に、ヘルパー支払い注文の作成を認めると、各ステップで必要なヘルパー注文がより小さくなっていく傾向があり、バッチングの成功を容易にする。これは、１と３の利用可能残高の各々が、Ａ₃₁、Ａ₄₃の各々に必要な大きさを減少させる助けをする（２）、（３）から明白である。
【０１１３】
Ｐ₂＋Ａ₁₂＞２Ｆ₂、すなわち、銀行２の利用可能残高と、１から２へのオリジナル支払い注文の合計とが２の最大利用可能残高を超える場合、２が待ち行列登録した支払い注文を有する参加者について、できれば、それらの参加者が、待ち行列登録された支払い注文を持つ参加者へとのびる同様のツリーが構築される。
【０１１４】
上述したように、多者間バッチングの例を図２に示している。図２はターゲット支払いを補助するヘルパー支払いのツリーを示す。この図中で、銀行Ａから銀行Ｂへの、迅速な公開または２者間公開の基準を満たさないターゲット支払いが、どのくらい長く待ち行列内に存在しているかということに部分的に基づいて、多者間バッチングのターゲットとして選択される。太い水平線の上に示されている全ての参加者は、現在、初回プレファンド残高要求金額よりも大きな利用可能残高を持っている。線より下に示されている参加者は、初回プレファンド残高要求金額よりも少ない利用可能残高を有している。
【０１１５】
利用可能残高をゼロ未満に減少することなく指定された大型支払い注文を送信する上で送信側参加者（Ａ）を補助するべく、ゼロよりも大きな利用可能残高を持つ銀行間の支払いのツリーを構成するために、線より上のヘルパー支払いをグループ化する試みがなされる。支払いの第２ツリーは、最大利用可能残高を超えることなく、指定の大型支払いに応じる上で受信側銀行を補助するために、借記ポジションにある（すなわち、線よりも下にある）銀行間で構成される。
【０１１６】
ツリーの構成において、相当大型ヘルパー支払いがＣからＡに示されているが、これは、Ｂの預金を転送した結果、Ａのポジションがその借記キャップを超えないようにするためのものである。Ｃの利用可能残高がゼロ未満にならないようにするために、Ｄからの支払いがＣに供給される。次に、Ｄが、銀行Ｅ、Ｆ、Ｇからヘルパー支払いを受ける。
【０１１７】
線の下では、Ｂにその最大利用可能残高を超えさせてしまう過剰な預金を放出させるために、ＢからＹ、Ｗへの支払いがグループ化され、ここで、Ｙは、その最大利用可能残高の超過を防ぐために、さらにヘルプ支払いを提供している。
【０１１８】
図３は、帳尻を合わせた公開エンジンの全体的な処理の流れを示している。この図では、支払いが同時に２つ以上の待ち行列にリンクされることを示すために、待ち行列構造を行列形式で表している。
【０１１９】
入ってくる支払い注文は、その支払い注文の大きさによって、最初に、複数の待ち行列ＢＩＬＡＴ、ＧＲＯＵＰＯＲＤＳＥＮＤ、ＧＲＯＵＰＯＲＤＲＥＣＶ、ＤＥＬＡＹ（ＳＹＳ）、ＳＹＳＬＡＲＧＥ、ＳＹＳＳＭＡＬＬ、ＢＩＬＡＴＯＲＤに配置される。図３の説明において、また、本発明の好適な実施形態において、小型支払い注文、すなわち、ドル価値が、送信側と受信側の初回プレファンド残高の少ない方の８０％未満である支払い注文が、さらに２つのカテゴリーに細分される。この２つのカテゴリーとは、中型支払い注文、すなわち、初回プレファンド残高要求金額の少ない方の２０％〜８０％の間の支払い注文と、小型、またはより詳細には「超小型」支払い注文、すなわち、初回プレファンド残高要求金額の少ない方の２０％以下の支払い注文である。なお、「小型」という用語は、支払い注文の大きさを示すために「中型」という用語と共に使用され、小型は「超小型」の支払い注文に言及する際に使用される。他方で、小型と大型が説明されている幅広いカテゴリーにおいて、「小型」とは、送信側参加者と受信側参加者の初回プレファンド残高要求金額の少ない方の８０％未満の支払い注文を全て指すものである。
【０１２０】
小型、また、より正確には超小型と特徴付けされた支払い注文は、ＢＩＬＡＴ待ち行列とＳＹＳＳＭＡＬＬ待ち行列の両方に配置される。中型サイズの支払い注文は、ＢＩＬＡＴ待ち行列、ＧＲＯＵＰＯＲＤＳＥＮＤ待ち行列、ＧＲＯＵＰＯＲＤＲＥＣＶ待ち行列、ＳＹＳＳＭＡＬＬ待ち行列、ＢＩＬＡＴＯＲＤ待ち行列に同時に配置される。大型入金支払い注文は、最初、ＤＥＬＡＹ（ＳＹＳ）待ち行列、ＧＲＯＵＰＯＲＤＳＥＮＤ待ち行列、ＧＲＯＵＰＯＲＤＲＥＣＶ待ち行列、ＢＩＬＡＴＯＲＤ待ち行列に配置される。このような支払い注文は全てヘルパーとして使用することができる。最後に、遅延待ち行列を通過した大型支払い注文は、擬似支払いと同様に、ＧＲＯＵＰＯＲＤＳＥＮＤ待ち行列、ＧＲＯＵＰＯＲＤＲＥＣＶ待ち行列、ＳＹＳＬＡＲＧＥ待ち行列、ＢＩＬＡＴＯＲＤ待ち行列に配置される。
【０１２１】
次に、フローチャートに示されている待ち行列について説明する。ＧＲＯＵＰＯＲＤＲＥＣＶやＧＲＯＵＰＯＲＤＳＥＮＤのように語尾に”ＯＲＤ”と付いている待ち行列は全て注文された待ち行列であり、ドルサイズの注文で配置され、最大の支払い注文が待ち行列の最初にきている。その他の待ち行列はＦＩＦＯ待ち行列である。例えば、ＢＩＬＡＴＯＲＤは、特定の１対の２者間参加者の中型および大型支払い注文のみを記憶する注文された待ち行列である。ＢＩＬＡＴは、特定の１対の２者間参加者の中型および小型支払い注文を記憶するＦＩＦＯ待ち行列である。
【０１２２】
語頭にＧＲＯＵＰが付いた待ち行列は全て、ある特定の参加者の支払い注文のみを含んでいる。この接頭辞の後にＳＥＮＤが付いている場合には、特定の参加者による支払い注文を含み、また、ＲＥＣＶが付いている場合には、特定の参加者への支払い注文を含んでいる。従って、ＧＲＯＵＰＯＲＤＲＥＣＶは、ある特定の参加者への支払い注文を含んだ注文された待ち行列であるのに対し、ＧＲＯＵＰＯＲＤＳＥＮＤは、特定の参加者により送信された支払い注文を含んだ注文された待ち行列である。接頭辞ＳＹＳは、全ての参加者への支払い注文を含んだ待ち行列を示している。この取り決めに従うと、ＳＹＳＬＡＲＧＥ待ち行列は、全ての大型支払い注文を含み、ＳＹＳＳＭＡＬＬは全ての小型支払い注文を含む。ＤＥＬＡＹ（ＳＹＳ）は、最近待ち行列登録された大型支払い注文を全て含んだＦＩＦＯ待ち行列である。
【０１２３】
個別待ち行列の機能を、以下に示す表ＶＩでさらに説明する。
【０１２４】
小型および中型支払い注文（すなわち、フローキャップの８０％未満の全ての支払い注文）は、バッチングを要さない公開に適している。この公開は、後に詳細に説明するステップＳ４０に示したゲール・シャプレイのアルゴリズムを用いて実行される。ステップＳ１０に示したように、ＤＥＬＡＹ待ち行列の長さは連続的にチェックされる。最大ＤＥＬＡＹ待ち行列の長さが、例えば４００支払い注文と設定された場合、別の大型支払い注文を挿入することにより、最も古い支払い注文がＤＥＬＡＹから除去される。適切な遅延の後に、ＤＥＬＡＹ待ち行列上の支払い注文がＳＹＳＬＡＲＧＥ待ち行列上に配置される。
【０１２５】
上述したように、２者間バッチングは、ＳＹＳＬＡＲＧＥ待ち行列内のターゲット支払いをＢＩＬＡＴＯＲＤ待ち行列からのヘルパー支払いと組み合わせるために使用することができる。
【０１２６】
図に示すように、ステップＳ２０において、２者間バッチングが達成可能であると決定されると、ターゲット支払いとヘルパー支払いの間の差額と等しく、２つのうちのより大きな方へと向かう擬似支払いが形成される。形成された擬似支払いは、その大きさによって、適切な１つまたは複数の待ち行列内へ戻される。
【０１２７】
多者間バッチングは、フローキャップよりも大きな、また、フローキャップよりもずっと大きな大型支払い注文を公開するために使用することができる。図３に示すように、２者間でバッチングすることができないターゲット支払い注文が、ステップＳ３０の多者間バッチングの手続きへと送られる。既に詳細に説明したように、多者間バッチング手続きは、ターゲット支払い注文をヘルパー支払い注文で相殺することにより、支払い注文の１つまたは複数のツリーを構築しようと試みる。図３に示すように、ヘルパー支払い注文は、ＧＲＯＵＰＯＲＤＳＥＮＤ待ち行列とＧＲＯＵＰＯＲＤＲＥＣＶ待ち行列から送ることができる。多者間バッチングが完全に終了すると、全てのバッチングされた支払いがステップＳ５０における単一の処理によって公開される。支払い注文が公開されると、その支払い注文は全ての待ち行列から削除される。図３は、２者間バッチングと多者間バッチングの両方を使用した際の１つの実施形態を示すものであるが、本発明は、多者間バッチング手続きにより、最大の支払い注文でさえ相殺および多者間バッチングすることが可能であるため、２者間バッチングを全く使用することなく、この機能を実行することができる。従って、本発明は、最良の２者間バッチング手続きを含む実施形態に限定されるものではない。
【０１２８】
ＶＩ．シミュレーション結果の再検討
本発明のシステムのシミュレーションと、これによって実施される処理のその実行は、その日のシステム活動が何らかの理由で注目すべきものであったため、または典型的な活動のベースラインを確立するためのいずれかの理由で選択された、様々な日付の取引きデータに基づいて行われる。本発明の好適な実施形態は、例えばＣＨＩＰＳコンピュータハードウェアとの併用に適しているため、シミュレーションにＣＨＩＰＳデータを使用した。日付と、その日付の選択理由を以下の表に示す。
【０１２９】
【表１】

【０１３０】
使用した実際の処理のクオリティの測定は、公開された、送信されたドルの実際の割合である。上述の日付の各々の結果を、以下の表ＩＩに示す。
【０１３１】
【表２】

【０１３２】
これらの結果から、即座に２つの結論が得られる。
１．公開することができる支払い注文のほとんど全てが実際に公開された。ほとんどの加重を受ける支払い注文は、プレファンドの金額よりもずっと大きく、最も扱いが難しい注文であるため、ドル加重の基準は厳格なものになる。
２．シミュレーションを行ったように、システムは、その「理論上の限度、帳尻を合わせた公開可能ドル、割合」数字に最も近いという意味で、最も量が多い日に最良に動作した。このシミュレーションの経験は、締め切り後の未公開支払いのドルの量が１日のドルの量とほとんど関係ないものであることを示している。そのため、締め切り後の未公開支払いのドルの量は、１日のドルの量が増加すると、１日のドルの量の割合として減少する。「理論上の限度」は、小額のドルの支払いにおいて、各銀行によりドル合計が公開された場合に、既に公開されているドル割合を示すべく設定されている。
【０１３３】
数字的な実験は、システムの成功の理由を指摘している。ある参加者から別の参加者への支払いが、第２の参加者から第３の参加者への支払いをトリガする傾向などが非常に頻繁に見られる。この点は、６月１８日のデータを用いて、まず、各参加者から、また各参加者への実際の支払いをネッティングし、これらの参加者の利用可能残高におけるネットの変更を、無作為に選んだ受信側に支払いを行った場合に生じる変更と比較することにより確立された。一般的な実行において、ポジションの実際の変更は、関連する無作為に行われた変更よりも、数百倍、または数千倍小さくなければ、ほとんど常に数十倍小さい。有利には、これらの支払いパターンは、ＣＨＩＰＳを使用する方法に固有のもののようであるため、このようなパターンへのプログラムの依存性は問題を生じるものであってはならない。
【０１３４】
しかし、上記の統計は、全てのサイズの支払い、全てのサイズの参加者、１日の全ての時間の平均である。特定の参加者のシステムに対する理解は、参加者の、システムに特定の時間における特定の量の支払い注文を処理させる能力によって決定される。
【０１３５】
シミュレーション結果の詳細な説明は、ほとんどの個別の参加者は、システムによって集合数の予測とほぼ同様に扱われることを示している。しかし、ある日の終わり、それがたとえ、シミュレーションが示すようにシステムが最良に動作した１９９７年１１月２８日であっても、少数の参加者の支払い注文の著しい割合が未処理のまま残った。
【０１３６】
システムのスループットの特に著しい数値は、シミュレーションでは公開されなかった、各参加者からの支払い注文のドル加重された割合である。例えば、プログラムモデルが１９９７年３月２７日のワークフローを実際に処理したとすると、行ったドル加重支払いの流れの５０％より多くがその日の終わりまで待ち行列に残っている参加者は、４つである。これらの参加者は、ＡＢＡ（アメリカ銀行協会）ナンバーＡ、Ｂ、Ｃ、Ｄによって識別された参加者である。関連する幾つかの統計を以下の表ＩＩＩ、表ＩＶに示す。
【０１３７】
【表３】

【０１３８】
【表４】

【０１３９】
システムによって良好に扱われた参加者と、良好に扱われなかった参加者との間の差は、受け取ったドルと送金したドルの割合における顕著な差であると考えられる。無作為に選ばれた上記の４つの参加者を含むほとんどの参加者について、この比率は１に非常に近い。しかし、これは全ての参加者に該当するものではない。このタイプのシステムはこのような不均衡を効率的に扱うことができないのが明らかであるため、この結果によって決定できる限りでは、このタイプのシステムだけが、小額の固定ファンディングの１日の支払い完了性を許容することができる。従って、小額ファンディングによる１日の支払い完了性については、送信および受信注文の不均衡を持った少数の参加者が、その日の終りにこれらの注文の処理が終了するまで待たなければならないという犠牲を払う必要があることが明白である。
【０１４０】
送信側と受信側の初回プレファンド残高の内の金額の少ない方の８０％未満であるという意味で、ほとんどの支払い注文は「小型」である。このような場合に伴う障害は、ゲール・シャプレイのアルゴリズムである。後に説明するように、このアルゴリズムの最悪の場合のパフォーマンスは、システム内における参加者の数の３乗に比例する。
【０１４１】
シミュレーションは、ほとんどのバッチが単一の支払いしか含まないことを示している（シミュレーションコードが、４００，０００の支払い注文の全ての処理を３０分以内に完了することができるとすれば、１つの注文にかかる時間は０．００５秒未満となる。その一方で、支払い注文が４００，０００あり、午前９時の締め切り前にはログオンしている参加者がいないと仮定した場合、１つの注文に利用可能な時間は０．０６秒より大きくなる。
【０１４２】
大型支払い注文を受信した際にシステムが即座に実行しなければならないのは、この注文を遅延待ち行列に配置することだけであり、これは明らかに障害ではない。支払いは、遅延待ち行列から公開された際に、大型支払い待ち行列と適切な２者間待ち行列に配置される。この作業にかかる時間は、これら待ち行列の現在のサイズにより変化する。待ち行列サイズは、ワークフローの詳細な構成、支払い注文が公開される比率、待ち行列の実施の詳細の複雑な相関関係である。それにもかかわらず、待ち行列オペレーションに必要なのは、その待ち行列の長さに比例するＣＰＵ時間程度である。シミュレーションコードにおいて、待ち行列は、待ち行列オペレーションは障害ではないようなので、よりＣＰＵ効率的なデータ構造とは逆に、簡単にリンクされたリストとして実現される。これらのより効率的なデータ構造は、実際にはさらにずっと効率的であるため、この領域のさらなる問題を容易に解決することができる。
【０１４３】
多者間バッチング手続きには、信用貸しポジションにある参加者を含んだツリーと、借記ポジションにある参加者を含んだツリーの構築が必要であり、ここで、信用貸しと借記は、１日の最初のポジションに関連している。モデルコードの実施形態において、ノード毎の金融機関の数と、これらツリーの深さとの両方はハードコードした限度を超えることはできないため、これらを構築するために必要な時間における唯一の変数は、ここでも、待ち行列オペレーションを実行するのに必要な時間である。ツリーの構築における試行の失敗に次いで生じるバックトラッキングの量は、作業全体のかなり一定な割合であると考えられる。従って、他者間バッチングシステムは障害ではないと思われる。
【０１４４】
この分析は、シミュレーション結果によってある程度限定される。３月３１日のワークフローを処理するために必要なＣＰＵ時間と、１１月２８日のワークフローを処理するために必要なＣＰＵ時間とは、１１月２８日の支払い注文が３月３１日の支払い注文の４倍以上だったにもかかわらず、大幅に違うということはなかった。
【０１４５】
このシミュレーションは、各参加者が支払ったプレファンド残高の金額がＣＨＩＰＳ担保口座に現在支払われている担保と等しいと仮定する。しかし、なぜこれが事実でなければならないという理由はない。実際、システム内には担保要求の専断的な設定を妨害するものは何もない。
【０１４６】
ＶＩＩ．結論
１．シミュレーション結果は以下の事実を示す。
ａ．システムは、ほとんど全ての参加者のほぼすべての支払い注文を処理することができる。
ｂ．システムは、量が最も多い日に最良に動作する。
ｃ．時として、参加者への、または、参加者からの、「送信」および「受信」支払い注文間の不均衡を伴った未公開支払いが連続的に発生する。これは不可避であると考えられる。
【０１４７】
２．システムの成功は、支払い注文の混合の２つの統計的特徴に基づく。
ａ．参加者Ａから参加者Ｂへの支払い注文は、後続する参加者Ｂから参加者Ｃへの支払い注文を作成することが多いようである。
ｂ．支払い注文のほとんどは、最大の参加者によってなされる。
【０１４８】
３．ゲール・シャプレイのアルゴリズムを介した支払いの公開には、より簡単なアプローチと比較して３つの利点がある。
ａ．２者間の待ち行列に小型の支払いを保持し、現在どちらの参加者が公開可能な支払いを持っているかを識別するためにビットマスクを使用することにより、公開すべき最も古い支払いを見つけるために必要なプロセッサ時間が大幅に短縮される。
ｂ．ゲール・シャプレイのアルゴリズムは、以下で定義している意味において、支払いのバッチを、「ほぼバラバラな状態の（nearly disjoint）」送信側／受信側の対に識別することができる。一般に、支払いを公開する決定は、同時に公開されているその他全ての支払いの効果を考慮されなければならない。そうでなければ、ある１つの支払いの公開によって、第２の支払いが公開された際にファンディング制約を犯してしまうことになりかねない。これは、第２の支払いが隔離状態で公開されていた場合にファンディング制約を侵していなくても、起こる可能性がある。しかし、バラバラな状態の送信側と受信側のバッチにとって、これは明らかに問題ではない。実際、参加者が厳密に１つの支払いを送受信できる「ほぼバラバラな状態」は、問題を回避するのに適している。これは、ファンディング制約を犯すことなく、所与の支払いを送ることができるか、または、所与の第２支払いを受信することができる参加者は、これらの支払いを、ファンディング制約を侵すことなく送受信できるためである。
ｃ．バッチ内の複数の支払いを個別且つ連続的に公開するのではなく、支払いのほぼバラバラな状態のバッチを一度に公開することにより、システムのスループットが向上する。これは、複数の支払いの公開後の処理を、異なる参加者の支払いシステムによって並行して行うことができるためであるが、どの支払いを公開するかの決定は固有の直列処理である。
【０１４９】
４．上述を仮定し、発明者は、本発明のシステムは、最新フォームのＣＨＩＰＳと共に実現することができると結論付けている。
【０１５０】
ＶＩＩＩ．修正されたゲール・シャプレイのアルゴリズム
本発明のシステムで使用するこのようなアルゴリズムの必要性についてはＶＩＩの３項において説明した。次に、この特定のアルゴリズムのパフォーマンス上の特徴について述べる。特に、このアルゴリズムは、先入れ先出し（ＦＩＦＯ）待ち行列規律の自然な一般化であることが示される。
【０１５１】
タイムスタンプが独特であるため、すなわち、支払い注文が受信された時間はその支払い注文だけのものであるため、従来は全体を通して１つだけを使用していたが、支払い注文とそのタイムスタンプを相互変換可能に使用できる。そこで、スケジューリングの目的で、必要な追加情報は、参加者のセットＩＩからの参加者Ｐ１、Ｐ２、Ｐ３、Ｐ４についての、表Ｖに示すものと類似した行列だけである。横列に示す参加者は送信側であり、縦列に示す参加者は受信側である。記入されている数字は、「公開可能な支払い注文」のタイムスタンプであり、記載の送信側から受信側への仮説的な支払い注文の最初のものは、プレファンドまたは信用貸し制約を満たす注文である。タイムスタンプの記載がなく空白になっているボックスは、その送信側受信側の対に対しての支払いがなかったか、または、この対に対する第１支払い注文が公開不可能であったかのいずれかである。
【０１５２】
【表５】

【０１５３】
既に述べたように、これらの支払い注文の２つ以上を同時に公開することが可能であり、また、そうするべきである。しかし、各参加者がバッチについて多くても１つの支払いを送信および／または受信すべき支払い注文の「ほぼバラバラな状態」のバッチのみを、ファンディング制約を再計算することなく、処理することができる。このほぼバラバラな状態では、行列内に支払い注文を示したタイムスタンプが選択され、１つの横列につき最大で１つのセルを、また、１つの縦列につき最大で１つのセルを占めることが必要である。さらに、どの支払い注文も、行列の対角線上のセルと関連することはできない。これは、このような対角線セルは、自身に支払いを送信する参加者と関連しているためである。
【０１５４】
タイムスタンプ行列内の対角線セルのみが空白である特別の場合において（すなわち、任意の送信側参加者が、任意の受信側参加者への公開可能な支払い注文を有する場合）、所定のバッチ内に含まれる注文の選択として、送信側の設定を受信側の設定の上にマッピングする機能の選択を見ることができる。このような機能の各々は、整数１、２、…、Ｎの混乱を表す。この機能は、これら整数の置換であり、どの整数もそれ自体にマッピングされることができない。大型Ｎの限度内にはＮ！／ｅという混乱があり、ここでｅ＝２．７１８（自然対数のベース）である。この数量は、Ｎの増加に伴って非常に急速に増加する。例えば、Ｎ＝１０である時には既に約１３０万になっている。
【０１５５】
幸いにも、このタイプに特有の問題、すなわち「結婚問題」への明快な解決法が、D. GaleとL.S. Shapleyによる”American Mathematical Monthly”の１９６２年１月号に記されている。ゲール・シャプレイのアルゴリズムとして知られている彼らのアルゴリズムは、それぞれ男性、女性の好みを与えた男性Ｎと女性Ｎとを結婚したカップルとして１組にする。このアルゴリズムは、男性と女性のそれぞれの好みを与えられているが、実生活では、特定の男性が最も結婚したいと思う女性が必ずしも他の男性ではなくその男性と結婚するとは限らない。この問題を解決するべく、該アルゴリズムは以下のように進行する。
【０１５６】
１．複数の男性が、最も望ましい配偶者から最も望ましくない配偶者へと、順番に求婚しながら下方向へ向かって進んでいく。
２．求婚された女性は、求婚者として見た目が好ましい男性を意のままに操るか操らないか（「多分状態」）に従って、「ノー」または「多分」のどちらかを各々の男性に答える。女性に「ノー」と言われたら、その男性は他の女性に求婚することができる。女性に「多分」と言われたら、その男性は、他の女性に求婚することができない。女性が、別の男性を待たせておきながらも、新しい男性に「多分」と答えた場合、その待たせておいた男性にさらに「ノー」と答えなければならない。
３．求婚が全て終わったら、各々の女性は、まだ「多分」状態においたままの男性に「ＹＥＳ」と答える。
【０１５７】
この結果生じるカップルは、以下に示す望ましい特性を備える。
１．彼らは、お互いに指定された配偶者を好ましいと思う「不義」な男性・女性のカップルは生じ得ないという意味で「安定」している。当然、男性が自分の妻よりも別の女性を好ましく思った場合には、ゲール・シャプレイのアルゴリズムは、彼が妻に求婚する前に、他の女性に求婚して失敗していると保証する。
２．彼らは、他の安定した対を望む男性はいないという意味で、安定した対の中でも「最適」である。
【０１５８】
支払い送信側と支払い受信側の対の支払いの問題は、出版されているゲール・シャプレイのアルゴリズムから、以下の方法で異なる。
１．アルゴリズムは、女性の手を「競る」のは男性であるが、送信側または受信側のどちらが競るべきかは明白ではない。
２．各参加者は、支払いの送信側と受信側の両方になることができ、従って、「競り手」と「売り手」になることができる。そのため、参加者は、互いに結婚することができない兄１人、姉１人を含んだファミリーに類似している。所定の銀行が送信者として最高１回現れ、また、受信者として最高１回現れる支払いの１組が、これ以降、ほぼバラバラな状態と呼ばれる。
３．所定の存在は、所定の場合において売り手または競り手でなくても構わない。
【０１５９】
それにもかかわらず、このプログラムコードは、ゲール・シャプレイのアルゴリズムの以下に示すバージョンを実現する。このバージョンの最適性特徴について、簡潔に探求する。
１．このアルゴリズムを交互に呼び出しながら、送信側と受信側は競り手として指定される。この交互スキームは、プロセッサ効率を増加するための、後に述べる特徴の１部である。この特徴は、ＳＥＮＤＥＲＳＴＡＴＥおよびＲＥＣＥＩＶＥＲＳＴＡＴＥビットマスクを使用する。
２．各々の競り手によってなされたこの競りは、以下に示す公開支払い注文の中で、最小のタイムスタンプを有する支払い注文を見つけることにより決定される。
ａ）競り手が適宜、送信側または受信側である２者間待ち行列の先頭に現れる支払い注文。
ｂ）前回拒否された競りに関係していない支払い注文。
【０１６０】
発行されたアルゴリズムにあるように、関連する「売り手」は、その競りが売り手の最初の競りであるか、または現在の競りよりも向上されたものである場合、その競りを一時的に受ける。そうでなければ、その競りは拒否され、この時点で、競り手は再び自由に競りを行うことができる。
【０１６１】
全ての競り手が１人の売り手と一致したか、または残っている全ての競り手について一致するものがなかったために、全ての競りが終了した場合、一時的な指定が決定的になる。
【０１６２】
例として、表Ｖに見られる行列を考慮する。送信側が競る場合、その理由は各々の横列に沿って（水平な線で印されている）最も早いタイムスタンプを備えた支払いを行うためである。受信側が競る場合、その理由は、各々の縦列に沿って（垂直線で印されている）最も早いタイムスタンプを備えた支払いを行うためである。
【０１６３】
競りは以下のように進行する。
送信側の競り
１．Ｐ１が、Ｐ３への支払いを送信するために競りを行い、これがＰ３によって「多分状態」に置かれる。
２．Ｐ２が、Ｐ１への支払いを送信するために競りを行い、これがＰ１によって「多分状態」に置かれる。
３．Ｐ３が、Ｐ４への支払いを送信するために競りを行い、これがＰ４によって「多分状態」に置かれる。
４．Ｐ４が、Ｐ３への支払いを送信するために競りを行う。この支払いは、Ｐ１からＰ３への支払いのタイムスタンプよりも早いタイムスタンプを有するため、Ｐ１からＰ３への支払いが落とされる。
【０１６４】
第２ラウンドにおいて、Ｐ１はＰ２へ送信するために競りを行い、Ｐ２はこれ以外の競りを受けない。
【０１６５】
従って、公開された支払いは２→１、３→４、４→３、１→２となる。４つの参加者全てが支払いを送信し、受信する。
【０１６６】
受信側の競り
反対に、受信側が競る場合には以下のようになる。
１．Ｐ１は、Ｐ２からの支払いを受信するために競りを行い、これがＰ２によって「多分」状態に置かれる。
２．Ｐ２は、Ｐ１からの支払いを受信するために競りを行い、これがＰ１によって「多分」状態に置かれる。
３．Ｐ３は、Ｐ４からの支払いを受信するために競りを行い、これがＰ４によって「多分」状態に置かれる。
４．Ｐ４は、Ｐ３からの支払いを受信するために競りを行い、これがＰ３によって「多分」状態に置かれる。
【０１６７】
従って、公開された支払いは２→１、１→２、４→３、３→４となる。これは、送信側の競りで得た際の支払いの組と同じであるが、この場合は、競りの第２ラウンドは必要ない。なぜ同じ組を得るのかは後に説明する。
【０１６８】
アルゴリズムは、最大で０（Ｎ³）ステップで終了しなければならず、ここで、Ｎは参加者の数である。これは、アルゴリズム自体の性質からきている。
１．各々の競りは、最大でＮ個のタイムスタンプを調べることにより決定される。
２．各競り手につき、最大Ｎ個の競りが存在する。
３．ｎ個の競り手が存在する。
【０１６９】
各売り手につき最大で１つの競りを受けることができ、各競り手が１度に最大で１つの競りを行うことができるため、このアルゴリズムがほぼバラバラな状態のバッチを生成することが容易にわかる。
【０１７０】
改良したゲール・シャプレイのアルゴリズムは、「先入れ先出し」（ＦＩＦＯ）処理の一般法則化であり、その特性は、発行されたアルゴリズムの「安定性」と類似している。このＦＩＦＯ一般法則化の正確な性質は以下に示すとおりである。
【０１７１】
定義：Ｔ₀を現在公開可能な支払いの組とする。バッチＲに含まれていない各々の支払いＴ₀の内のｔ_pqについて、送信側ｐがそのバッチ内のより早い支払いを有するか、または、受信側ｑがそのバッチ内のより早い支払いを有する場合、支払い注文のほぼバラバラな状態のバッチＲ、Ｔ₀のサブセットは一般法則化されたＦＩＦＯである。
【０１７２】
そこで、以下のことが得られる。
定理：ｔ_ijを、送信側Ｉおよび受信側ｊに関係する公開可能な支払い注文の（独特な）時間スタンプとし、Ｔ₀を、全ての現在公開可能な支払い注文の組、または同等に、全ての可能なｔ_ijの組とし、Ｒ⊂Ｔ₀を、実際に公開するべく選択された支払い注文のタイムスタンプの組とする。すると、Ｒは一般法則化されたＦＩＦＯとなる。
【０１７３】
証明：受信側が競り手である場合には、最も明白な方のみにおいて推論を変更する必要があるため、送信側が競り手であると仮定する。Ｔ₀とＲがこの推論仮定内にあるとする。Ｒが一般法則化されたＦＩＦＯであることを証明するために、ｔ_pq はＴ₀内にあるが、Ｒ内にはないと仮定する。以下の２つの場合が可能である。
（１）送信側ｐは、受信側ｑへの競りを絶対に行わない。次に、アルゴリズムにより、ｐは任意の受信側ｊと共に「多分」状態にあるはずである。しかしこれは、ｔ_pj＜ｔ_pqであることを意味する。
（２）送信側ｐは、その競りのある時点で受信側ｑを競る。すると、ｔ_pqは、その待ち行列の先頭にあるため支払い競りであるということになる。ｑは、もっと良いもののためにこの競りを拒否しなくてはならならず、これにより、ｑはより良いオファーｔ_jq＜ｔ_pqを得たか、あるいは後に受けなければならないことが明白である。
そのため、一般法則化されたＦＩＦＯ条件が満たされる。
【０１７４】
競り手に発行されたアルゴリズムの最適特性は、以下に示すように改良されたアルゴリズムが適用され続ける。
定理：競り手の支払い注文が、一般法則化されたＦＩＦＯバッチを生じる他のアルゴリズムを用いるのと同様に、少なくとも改良したゲール・シャプレイのアルゴリズムを用い次第すぐに公開される。
見解：ここでの「一般法則化されたＦＩＦＯ」はゲール・シャプレイの論文の「安定の指定」と関連するため、この定理は、アルゴリズムから生じた指定が競り手にとって最適であるという、その結果からの直接的推論（ｃｏｒｏｌｌａｒｙ）である。各々の使用において、これが真実であることの証明は、帰納法によるアルゴリズムの一連の使用の証明にまでおよぶ。
【０１７５】
ゲール・シャプレイの論文にあるように、男性と女性をマッチングする場合、各人が独自の方法で異性の人達をランク付けする。この状況において、論文にあるように、男性が競りを行った結果生じる安定した指定は、女性が競りを行った結果生じる指定とは異なる可能性がある。しかし、ここで、全ての送信側と全ての受信側が、２者間待ち行列の先頭にある支払いタイムスタンプに基づいて、お互いをランク付けし、古い支払いを最近の支払いよりも高いランク付けすることについて詳細に述べた。この状況において、最大限の安定した指定はたった１つしかないことがわかった。従って、ゲール・シャプレイのアルゴリズムは、送信側が競ろうと、受信側が競ろうと、この同じ指定を常に見つけなければならない。ここでは、この主張を証明しないが、これは難しいものではない。ゲール・シャプレイのアルゴリズムを用いない、独特な最大限の安定した指定の直接的な構造のみについて述べている。この構造を用いれば、証明の詳細を提供することは難しくない。
【０１７６】
Ｔ₀を、特定の時間において公開可能な支払いの組とする。各支払いは、２者間待ち行列の先頭にあるため、Ｔ₀内の２つの支払いが同一の送信側と受信側によるものであることはない。Ｔ₀は空白でないと仮定する。（Ｓ₀、Ｒ₀）を、Ｔ₀における最も早く支払いであるとし、ここで、Ｓ₀は送信側を示し、Ｒ₀は受信側を示す。
【０１７７】
次に、Ｔ_kと（Ｓ_kＲ_k）が、あるｋについて定義されたと仮定する。Ｔ_k+1について、以下のようにすすめる。Ｔ_k+1を、Ｔ_k内に存在する、送信側としてのＳ_k、または受信側としてのＲ_kを持つ支払いを除いた全ての支払いの組であるとする。すると、Ｔ_k+1が空白である場合には停止する。そうでなければ、（Ｓ_k+1、Ｒ_k+1）を、Ｔ_k+1内の最も早い支払いとして、この後を続ける。
【０１７８】
独特な最大限の安定の指定は、そのように選択された全ての支払い（Ｓ_k、Ｒ_k）から成る組である。
【０１７９】
（Ｓ₀、Ｒ₀）は、Ｔ₀内の最も早い支払いであることに注意されたい。そのため、（主張が請求の通りに正しいと仮定すると）ゲール・シャプレイのアルゴリズムは、最も古い公開可能な支払いを常に見つける。これが、本発明にゲール・シャプレイのアルゴリズムを使用する主な理由である。これは、この最も早い支払いを見つけるための効率的な方法を提供する。支払いのシステム待ち行列全体を通る１つの単純なループが最も早い公開可能な支払いを探している場合、この検索は長い時間かかるかもしれない。２者間待ち行列をゲール・シャプレイのアルゴリズムと共に使用することで、同様のことをずっと迅速に達成することができる。
【０１８０】
ＩＸ．ＵＮＩＳＹＳＡＬＧＯＬにおけるプログラムモデルの実現の書類
このセクションでは、プログラムモデルの実現の主な入力、内部変数、処理ステップについて説明する。ここでは、機能の公開を実現するコードのこのような部分についてのみ述べる。モデルコードの説明は本発明の好適な実施形態に関連するが、本発明が説明した実現に限定されることはない。
【０１８１】
第１に、入力および処理ステップの概要について述べる。第２に、様々な待ち行列の実現方法について、また、ＩＮＳＥＲＴ手順がどのようにそれらを占領するかについてより詳細に説明する。第３に、ＭＡＫＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨ、２者間バッチング手順、多者間バッチング手順、ＣＨＥＣＫＢＡＴＣＨＥＳ、ＢＡＴＣＨＲＥＬＥＡＳＥＡＢＬＥ、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴ、ＣＨＥＣＫＲＥＣＶＰＡＹＭＴがどのようにそれぞれのバッチを作成するかについて説明する。第４に、そして最後に、ＢＡＴＣＨＲＥＬＥＡＳＥ（多者間バッチング用）とＲＥＬＥＡＳＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨ（２者間バッチング用）、またはＧＡＬＥＳＨＡＰＬＥＹとＲＥＬＥＡＳＥＬＯＯＰ（単発の支払い注文のためのもの）のいずれかによって、処理ために、支払い注文がどのように公開されるかについて説明する。
【０１８２】
Ａ．概観
各支払い注文は、記録として入力され、公開時間によって記憶され、
・送信側参加者用のコードと、
・受信側参加者用のコードと、
・処理のために支払い注文が公開された時間をマーキングするタイムスタンプ、またはＳＳＮ（システムシリアル番号）と、
・量と、から成っている。
【０１８３】
これらを入力し、支払い注文の処理は、以下に示す擬似コードと同様に進行する。
ＲＥＡＤｃｏｌｌａｔｅｒａｌａｍｏｕｎｔｓＦＲＯＭｃｏｌｌａｔｅｒａｌｆｉｌｅ，ＳＯＲＴＩＮＧＢＹＡＢＡＮｕｍｂｅｒＩＦＮＯＴＡＬＲＥＡＤＹＳＯＲＴＥＤ
ｎｏｔｆｉｎａｌ ← ＴＲＵＥ
ＷＨＩＬＥＮＯＴＥＮＤ−ＯＦ−ＦＩＬＥ（ｐａｙｍｅｎｔｏｒｄｅｒｆｉｌｅ）ＯＲｎｏｔｆｉｎａｌ
％入ってくる支払い注文を処理するためにここをループする。
ＲＥＡＤｐａｙｍｅｎｔｏｒｄｅｒＦＲＯＭｐａｙｍｅｎｔｏｒｄｅｒｆｉｌｅ
ＩＦＮＯＴＥＮＤ−ＯＦ−ＦＩＬＥ（ｐａｙｍｅｎｔｏｒｄｅｒｆｉｌｅ）ＴＨＥＮＩＮＳＥＲＴｐａｙｍｅｎｔｏｒｄｅｒＩＮＴＯｑｕｅｕｅｓ
％注意：以前に待ち行列登録した支払いを備えた任意の２者間バッチングは、挿入処理の１部として行われた。２者間バッチングは、丁度読み出したばかりの注文の１／２〜２倍の大きさの待ち行列上の支払い注文が既に存在する際にのみ可能である。さらに、シミュレーション時間は、支払いの時間に改善された。
ＥＬＳＥ
ｎｏｔｆｉｎａｌ ←ＦＡＬＳＥ
ｎｏ＿ｃｒｅｄｉｔ＿ｌｉｍｉｔｓ←ＴＲＵＥ
ｅｍｐｔｙｄｅｌａｙｑｕｅｕｅ
％相殺の後、信用貸し限度制約が除去される
ＥＮＤＩＦ
ＩＦｌａｒｇｅｆｌａｇＴＨＥＮ
％すなわち、支払い注文＞今読み出した注文のための０．８＊プレファンド金額
ＩＦｃｈｅｃｋｂａｔｃｈｅｓＴＨＥＮ
％大型支払い注文が多者間バッチ１部として公開されると、ＴＲＵＥになる手続きチェックバッチが、同じ名称のブールを戻す。これにより、大型支払いがまだ未処理であることを示す大型フラグが、以下のようにリセットされる：
ｌａｒｇｅｆｌａｇ：＝ＦＡＬＳＥ
ＥＮＤＩＦ
ＩｆｌａｒｇｅｆｌａｇＯＲｓｍａｌｌ＿ｐａｙｍｅｎｔＯＲｎｏ＿ｃｒｅｄｉｔ＿ｌｉｍｉｔｓＴＨＥＮＤＯ
％現在公開可能な支払いをループオーバーする。ｎｏ＿ｃｒｅｄｉｔｌｉｍｉｔｓｉｓＴＲＵＥである場合、他の公開可能な支払いがあるかもしれない。ブールは大型フラグを定量化し、新規の支払いが大型であるか否かによって、ＩＮＳＥＲＴ手順においてｓｍａｌｌ＿ｐａｙｍｅｎｔがｔｒｕｅに設定される。
ＩＦｓｍａｌｌ＿ｐａｙｍｅｎｔＴＨＥＮ
ＩＦｔｒｙ＿ｔｏ＿ｒｅｌｅａｓｅＴＨＥＮ
％全ての小型支払いを公開する際のみにｔｒｙ＿ｔｏ＿ｒｅｌｅａｓｅがＴＲＵＥを戻す。
ｓｍａｌｌ＿ｐａｙｍｅｎｔ：＝ＦＡＬＳＥ
ＥＮＤＩＦ
ＥＮＤＩＦ
ＩＦｎｏ＿ｃｒｅｄｉｔｌｉｍｉｔｓＴＨＥＮ
ＩＦＮＯＴｃｈｅｃｋｂａｔｃｈｅｓＴＨＥＮ
ｓｍａｌｌ＿ｐａｙｍｅｎｔ：＝ＴＲＵＥ
ＥＮＤＩＦ
ＵＮＴＩＬｓｍａｌｌｐａｙｍｅｎｔ＝ＦＡＬＳＥ
ＥＮＤＷＨＩＬＥ％注文ファイル内のループオーバー支払い注文の終り
ＦＩＮＡＬＲＥＬＥＡＳＥＳ％１日の最後に、待ち行列上に残っている支払いを公開する
ＰＲＩＮＴＳＵＭＭＡＲＹ％シミュレーションの結果を印刷する
ＰＭＴＤａｔａＳｔｒｕｃｔｕｒｅ，ＱｕｅｕｅＯｐｅｒａｔｏｒ，ａｎｄｔｈｅＩＮＳＥＲＴＰｒｏｃｅｄｕｒｅ
【０１８４】
上述のコードスケッチが示すように、支払い注文を処理する上で重要な最初のステップは、待ち行列を適切に設定することであり、ＩＮＳＥＲＴ手続きで実行されたタスクである。表ＶＩと付属の注意書きは、この待ち行列を詳細に説明する。
【０１８５】
ＡＬＧＯＬは順序配列をサポートするだけなので、これが、待ち行列が完全に実現する方法である。しかし、実現の詳細は、標準の待ち行列オペレーションを実行するＤＥＦＩＮＥ'ｓによって、これら待ち行列を用いる手続きから注意深く隠されている。従って、この手続きは、これらの待ち行列を、先頭と末尾に個別に維持された標準のダブルリンクリストとして扱うことができる。しかし、中間ノードを挿入または削除するのに適切であるようにオープン状態であり、その他はＦＩＦＯであるため、待ち行列のいくつかは注文されている。
【０１８６】
その下にある、全ての支払い待ち行列のための配列は、以下の宣言を有する。
ＡＲＲＡＹＰＡＹＭＥＮＴＱＵＥＵＥ［０：９９９０００］
これは、ベーシックＤＥＦＩＮＥによって参照され、
ＤＥＦＩＮＥ
ＰＡＹＭＴＳＺ＝９＃
，ＰＭＴ（ＬＩＮＫ，Ｉ）＝ＰＡＹＭＥＮＴＱＵＥＵＥ［ＰＡＹＭＴＳＺ＊（ＬＩＮＫ）÷（Ｉ）］＃
【０１８７】
これは、サブスクリプトＬＩＮＫによって参照することができる、待ち行列ノード、９ワード（１ワードにつき４８ビットを有する）の各々を作成する効果を持っている。その他のサブスクリプトＩは、待ち行列を、実際に使用された際に取り扱うＤＥＦＩＮＥ'ｓの次のレベルにのみ使用される。
例えば、次のようである。
ＤＥＦＩＮＥ
ＳＮＤＲ（ＬＩＮＫ，ＰＭＴ）＝ＰＭＴ［ＬＩＮＫ，０］．［４７：１２］＃
【０１８８】
これは送信側の待ち行列のＤＥＦＩＮＥであり、ノードの第１ワードの４７を介してビット３６（すなわち４７−１２＋１）を割り当てる（ＡＬＧＯＬインデックスは、一般に０で始まり、表記”．［４７：１２］”は、ビット４７を有する１２ビット、すなわち最大のビットを最初の（または左端の）ビットとして特定するためのＵｎｉｓｙｓＡＬＧＯＬ慣用である）。その他の待ち行列用の、これと類似したＤＥＦＩＮＥが存在し、その結果、表ＶＩに示す割り当てが得られる。
【０１８９】
【表６】

【表７】

【０１９０】
ノードは、ＰＭＴ配列内の現在使用されていないポジションを、その論法ＬＩＮＫにおいて戻すＧＥＴＳＹＳＬＩＮＫＤＥＦＩＮＥによって追加される。過去に使用されたことのある全てのポジションが現在もまだ使用されている場合には（すなわち、ＡＶＡＩＬＬＩＮＫ＝０）、ＧＥＴＳＹＳＬＩＮＫは、ＰＭＴ配列内の第１空白ポジションにＬＩＮＫを設定するだけでよい。ＧＥＴＳＹＳＬＩＮＫは、現在使用中の最終リンクであるＬＥＦＴＯＦＦＬＩＮＫを増加することにより、この設定動作を実施し、以下を代入するだけでよい。
ＬＩＮＫ ← ＬＥＦＴＯＦＦＬＩＮＫ
【０１９１】
そうでなければ、ＧＹＴＳＹＳＬＩＮＫは、ＡＶＡＩＬＬＩＮＫで示されるＰＭＴ配列内のポジションにＬＩＮＫを設定する。
【０１９２】
ノードは、その論法ＬＩＮＫによって示されるＰＭＴ配列内に該ポジション内の全てのワードを０に設定するＦＯＲＧＥＴＳＹＳＬＩＮＫＤＥＦＩＮＥによって、この構造から削除される。代入は以下の通りである。
ＳＹＳＬＩＮＣＫ（ＬＩＮＫ） ← ＡＶＡＩＬＬＩＮＫ
ＡＶＡＩＬＬＩＮＫ ← ＬＩＮＫ
【０１９３】
表ＶＩＩＩに示すように、基本待ち行列のオペレーションの各々は、基本ＤＥＦＩＮＥによってサポートされている。この表において、ＬＩＮＫは、上述のデータ構造内のノードへの基準である。ＮＥＸＴＬＩＮＫとその次のリンク基準は、ＤＥＦＩＮＥが実際に使用される際に置き換えられる仮パラメータである。例えば、ＳＹＳＩＮＳＥＲＴは、未処理の支払い注文全ての待ち行列（ＳＹＳ待ち行列）内にリンクを挿入するためにＩＮＳＥＲＴＤＥＦを呼び出すＤＥＦＩＮＥである。ＳＹＳＩＮＳＥＲＴがＩＮＳＥＲＴＤＥＦを呼び出すと、ＮＥＸＴＬＩＮＫがＳＹＳＬＩＮＣＫと置き換えられ、ＩＮＳＥＲＴＤＥＦにおける基準、例えばＮＥＸＴＬＩＮＫ（ＬＩＮＫ，ＰＭＴ）がＳＹＳＬＩＮＣＫ［ＬＩＮＫ，ＰＭＴ］と置き換えられ、次いで、上記のように、ＰＭＴ［ＬＩＮＫ，３］．［４７：２４］等と置き換えられる。これらのＤＥＦＩＮＥが呼び出されると、１つまたはそれ以上のＡＬＧＯＬ文が、仮パラメータＱＮＯＮＥＭＰＴＹとＱＥＭＰＴＹで代用される。名称が示すように、ＱＮＯＮＥＭＰＴＹは、待ち行列が空白でなくなった際に実行される文で代用され、また、ＱＥＭＰＴＹは、待ち行列が空白になった際に実行される文で代用される。
【０１９４】
【表８】

【表９】

【０１９５】
これらのＤＥＦＩＮＥは、特定の待ち行列について、関連する待ち行列の先頭、末尾等を用いることによってカストマイズされる。例えば、ＢＩＬＡＴＯＲＤＩＮＳＥＲＴは、以下のようにＯＲＤＩＮＳＥＲＴを呼び出す別のＤＥＦＩＮＥである。
ＯＲＤＩＮＳＥＲＴ（ＮＥＷＬＩＮＫ，ＰＭＴ，ＢＩＬＡＴＯＲＤＬＩＮＫ，ＢＩＬＡＴＯＲＤＢＡＣＫＬＩＮＫ，ＢＩＬＡＴＯＲＤＨＥＡＤ（ＳＧＲＰ，ＲＧＲＰ），ＢＩＬＡＴＯＲＤＴＡＩＬ（ＳＧＲＰ，ＲＧＲＰ），ＱＮＯＮＥＭＰＴＹ，ＬＩＮＫ１，ＤＡＭＴ，ＴＥＭＰ）；
【０１９６】
ＩＮＳＥＲＴＤＥＦＩＮＥ’ｓは、プログラムによって直接使用されるが、ＲＥＭＯＶＥＤＥＦＩＮＥ’ｓは全て、ＲＥＭＯＶＥルーチンにおいて呼び出される。ＲＥＭＯＶＥは、２つのパラメータ、すなわちＬＩＮＫとＱＦＳと共に呼び出される。ＬＩＮＫは、除去するノードの場所であり、ＱＦＳは、どの待ち行列ＬＩＮＫが除去されるべきではないかを示すフラグのビットマスクである。ＱＦＬＡＧＳ（ＬＩＮＫ，ＰＭＴ）は、ノードが属する待ち行列を示す支払いノードの各々におけるフラグのビットマスクであることを思い出されたい。従って、除去すべきＬＩＮＫを含む待ち行列は、ＱＦＬＡＧＳ（ＬＩＮＫ，ＰＭＴ）とＮＯＴＱＦＳのビットワイズＡＮＤであるＱＦＬＡＧＢの関連するビットである待ち行列であり、すなわち、
ＱＦＬＡＧＢ：＝ＢＯＯＬＥＡＮ（ＱＦＬＡＧＳ（ＬＩＮＫ，ＰＭＴ））ＡＮＤＮＯＴＢＯＯＬＥＡＮ（ＱＦＳ）；
である。
【０１９７】
ＱＦＬＡＧＳ（ＬＩＮＫ，ＰＭＴ）も更新する必要があることが明らかである。これは、ＬＩＮＫのＱＦＬＡＧＳビットを、ＱＦＳ内のＦＡＬＳＥである偽に設定することで行える。すなわち、
ＱＦＬＡＧＳ（ＬＩＮＫ，ＰＭＴ）：＝
ＲＥＡＬ（ＢＯＯＬＥＡＮ（ＱＦＳ）ＡＮＤＢＯＯＬＥＡＮ（ＱＦＬＡＧＳ（ＬＩＮＫ，ＰＭＴ）））；
となる。
【０１９８】
フラグ代入を表ＶＩＩＩに示す。
【表１０】

【０１９９】
従って、ＱＦＳ＝ ”Ｃ１”ヘックスを有するＲＥＭＯＶＥを呼び出すことにより、ＳＹＳＱＵＥＵＥ、ＳＹＳＳＭＡＬＬＱＵＥＵＥ、ＳＹＳＬＡＲＧＥＱＵＥＵＥを除く全ての待ち行列からノードが除去される。しかし、ノードは、ＦＯＲＧＥＴＳＹＳＬＩＮＫが呼び出されない限りＰＭＴ配列から消去されることはない点に注意されたい。これは、ＱＦＳのサインビットがＦＡＬＳＥに設定された場合にのみ起こる（すなわち、浮動小数点数として解釈された場合、ＱＦＳは正である）。
【０２００】
支払い注文は、まず、以下の文を介してモデルを入力する。
ＷＨＩＬＥＮＯＴ（ＥＯＲ：＝ＲＥＡＤ（ＳＯＲＴＥＤＰＡＹＭＥＮＴＳＩＮ，３，ＲＥＣ））
【０２０１】
このコードフラグメントは、ＳＯＲＴＥＤＰＡＹＭＥＮＴＳＩＮから３ワードを読み出そうとするとファイルの終端状態になるかどうかによって、ＢＯＯＬＥＡＮ変数ＥＯＦをＴＲＵＥまたはＦＡＬＳＥのいずれかに設定する。そうでない場合には、各々が６バイトのこれらの３ワードは、ＲＥＣに記憶される。
【０２０２】
新規の支払い注文を待ち行列に挿入する処理は、以下に示す手続き呼び出しで始まる。
ＦＯＲＭＡＴＰＡＹＭＴ（ＲＥＣ，ＰＡＹＭＴ）：
【０２０３】
この手続きは、支払いデータを、上述したタイプの待ち行列ノード内にＲＥＣに記憶されているように再フォーマットする。ＰＡＹＭＴは、ノードの一時的な記憶に使用される９ワードのグローバル配列である。各々がＨＥＸディジット（HEX digit）である、入力記録内の個々のフィールドは、ＲＥＣをＨＥＸ配列と等しくするアドレス、ＲＥＣＨによって読み出される。
【０２０４】
ＩＮＳＥＲＴ自体が扱う第１のタスクは、ＧＥＴＳＹＳＬＩＮＫを呼び出すことにより、一番最近処理された支払いのための恒常的な場所の作成である。ＲＥＣＥＩＶＥＲＳＴＡＴＥビットとＳＥＮＤＥＲＳＴＡＴＥビット、フローキャップと小型キャップを設定すると、ＩＮＳＥＲＴはシミュレーション時間を支払いのシミュレーション時間へと進める。
【０２０５】
先行の支払いがＤＥＬＡＹＱＵＥＵＥ上に押しやられることで、最大サイズを超えてしまうケースがある。ある日の午前中には、この最大サイズは定数ＭＡＸＤＥＬＡＹＱＬＥＮＧＴＨであるが、シミュレーション開始の数秒後にＢＥＧＩＮＳＨＲＩＮＫＱＳＥＣＯＮＤＳがシミュレーションされると、この最大サイズは、ＢＥＧＩＮＳＨＲＩＮＫＱＳＥＣＯＮＤＳから、経過したシミュレーション時間間隔の小数部と比例して縮小する。これは、以下に示す擬似コードと等しい、複雑なループ状態（すなわち、状態がＴＲＵＥである場合にのみ、ループが継続する）を持つＷＨＩＬＥループを介して、コード中には現れない変数ｍｕｌｔを用いて実現される。
ＩＦｄｅｌａｙｑｕｅｕｅｉｓｅｍｐｔｙ
ＴＨＥＮｃｏｎｄｉｔｉｏｎ ← ＦＡＬＳＥ
ＥＬＳＥ
ＩＦｃｕｒｒｅｎｔｔｉｍｅ＜ｔｉｍｅｔｏｂｅｇｉｎｓｈｒｉｎｋｉｎｇｄｅｌａｙｑｕｅｕｅ
ＴＨＥＮｍｕｌｔ ← １
ＥＬＳＥＩＦｃｕｒｒｅｎｔｔｉｍｅ＞ｔｉｍｅｔｏｓｔｏｐｓｈｒｉｎｋｉｎｇ
Ｄｅｌａｙｑｕｅｕｅ
ｔｈｅｎｍｕｌｔ ← ０
ＥＬＳＥ
ｍｕｌｔ ← ｆｒａｃｔｉｏｎｏｆｐｅｒｉｏｄｔｏｓｈｒｉｎｋｄｅｌａｙｑｕｅｕｅｔｈａｔｈａｓｅｌａｓｐｅｄ
ＥＮＤＩＦ
ＩＦｄｅｌａｙｑｕｅｕｅｌｅｎｇｔｈ＞ｐｒｅｄｅｔｅｒｍｉｎｅｄｍａｘｉｍｕｍ＊
ｍｕｌｔＴＨＥＮｃｏｎｄｉｔｉｏｎ ← ＴＲＵＥ
ＥＬＳＥ
ｃｏｎｄｉｔｉｏｎ ← ＦＡＬＳＥ
ＥＮＤＩＦ
ＥＮＤＩＦ
【０２０６】
ループの本体は以下のステップを備えている。
１．遅延待ち行列の長さを減少するステップ
２．遅延待ち行列の先頭に支払いを出し、これを、支払いサイズによって順序付けられた大型支払い待ち行列と適切な２者間待ち行列上に配置するステップ。大型支払いのみが第１場所の遅延待ち行列上に配置されることに注意されたい。
３．「出された」支払いのサイズが十分に大きな場合には、ＭＡＫＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨを呼び出すことにより、これを２者間バッチ内に含む試みがなされるステップ。「大型支払い」は、送信側参加者と受信側参加者の内の初回プレファンド残高の小さい方の８０％と定義されるが、これらの支払いは、その初回プレファンド残高の少なくとも１６０％でなければならない。
【０２０７】
遅延待ち行列から出される必要のある支払いが全て処理されたら、今呼び出している支払い注文を処理することができる。図３を参照して上述したように、支払い注文は、小型と大型に幅広く分類されることができる。すなわち、小型は、好ましくは初回プレファンド残高要求金額の小さい方の８０％未満であり、大型は、すなわち小型以外のものである。しかし、本発明者は、フローキャップの８０％未満の「小型」支払い注文のカテゴリーを、さらに３つのカテゴリー、「小型」または「超小型」（初回プレファンド残高要求金額の２０％またはそれ未満）、中型（初回プレファンド残高要求金額の２０〜８０％の間）、大型（初回プレファンド残高要求金額の８０％よりも大きな金額）に細分することが有利であることに気付いた。これらの関連で言えば、中型は、前述で定義した「小型」カテゴリーのサブカテゴリーであることに注意されたい。このモデルコードにおいて、上述した小型のサブカテゴリーである中型支払いと、大型支払いは、多者間バッチングのためのヘルパー支払いとしての使用に適切しており、また、この目的のためにＧＲＯＵＰＯＲＤＳＥＮＤＱＵＥＵＥとＧＲＯＵＰＯＲＤＥＲＣＶＱＵＥＵＥ内に挿入される。さらに、中間および大型支払いはＳＹＳＬＡＲＧＥＱＵＥＵＥとＢＩＬＡＴＯＲＤＱＵＥＵＥ内にも挿入され、ここで２者間バッチングのためにも使用されることが可能である。支払いがフローキャップよりも大きい場合（すなわち、「大型支払い」である場合）、そのように示され（ＬＡＲＧＥＡＭＯＵＮＴビットが設定される）、ＤＥＬＡＹＱＵＥＵＥ内に挿入される。大型支払いは、ＤＥＬＡＹＱＵＥＵＥから公開されるまでターゲット支払いとして処理されないので、ＬＡＲＧＥＦＬＡＧは設定されないことに注意されたい。
【０２０８】
Ａ．２者間バッチと多者間バッチの作成方法
１．ＭＡＫＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨ、２者間バッチルーチン
ＭＡＫＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨのタスクは、ＢＩＬＡＴＯＲＤＱＵＥＵＥ上にＬＩＮＫで示されおり、「非小型」（つまり、中型または大型）支払いである現在の支払いを用いて、２者間バッチの作成を試みることである。ＬＩＮＫ１と、現在の支払いの半分から２倍までの大きさの、最小のＳＳＮを備えた反対方向にある支払いとを見つけるために、ＢＩＬＡＴＯＲＤＱＵＥＵＥの先頭からリンクに従ってチェックが行われる。このような支払いが見つからない場合には、そのアルゴリズムはＭＡＫＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨフラグをＦＡＬＳＥのそのデフォルト値から変更することなく終了する。ＬＩＮＫ１が見つかった場合には、ＬＩＮＫ１とＬＩＮＫ内の量がネッティングされ、そのネット支払いが反対方向にある際には送信側と受信側が逆転する。次に、検索は、その待ち行列上の、ＬＩＮＫおよびＬＩＮＫ１のネット量の半分から２倍の大きさの第２支払いについて繰り返され、続いて、結果と共にネッティングすることが可能な、その待ち行列上の第３支払いについても繰り返される。このような支払いが見つかると、制御がラベルＡＧＡＩＮにループバックして再挑戦する。見つからない場合には、制御はラベルＸＩＴへ進む。
【０２０９】
各ネッティングが通過すると、ネッティングされるその支払いはその待ち行列から除去され、擬似支払いのＰＳＥＵＤＯＱＵＥＵＥに追加されなければならない。最初のネッティング通過（ＨＡＶＥＰＳＥＵＤＯ＝ＴＵＲＥ）については、新規のＰＳＥＵＤＯＱＵＥＵＥを開始する必要がある。この待ち行列の構築の第１ステップは、ＰＳＥＵＤＯＬＩＮＫの作成することであり、新規リンクはＧＥＴＳＹＳＬＩＮＫを介して作成され、また、この支払い範囲が、実際に、２者間バッチの開始点であることを示すために、ＰＳＥＵＤＯＬＩＮＫで示された支払い範囲内に適切なエントリを設定することである。これは以下の処理を含む。
１．ＴＲＵＥの擬似支払いにＢＩＬＡＴＥＲＡＬＢＡＴＣＨフラグを設定する。
２．過去に１度も使用されていないリンクがすでにゼロに初期化されているために、擬似支払い内のＰＳＥＵＤＯＨＥＡＤとＰＳＥＵＤＯＴＡＩＬをゼロ、すなわち防御基準（defensive measure）に初期化し、ＦＯＲＧＥＴＳＹＳＬＩＮＫが「再請求された」リンクをゼロに再初期化する。
３．現在の支払い（ＬＩＮＫにあるもの）をＳＹＳＬＡＲＧＥＭＥＤＱＵＥＵＥ内のＰＳＥＵＤＯＬＩＮＫと置き換える。しかし、ＰＳＥＵＤＯＬＩＮＫはネッティングされた情報を含んでいるため、ＬＩＮＫは、その送信側、受信側用、量的な情報のために保持される必要がある。したがって、リンクは、ＲＥＭＯＶＥルーチンを介して、全ての待ち行列から除去される。これにより、ＬＩＮＫにある支払いが、多者間バッチルーチンまたは公開ルーチンのいずれにも確実に利用不可能になる。支払い公開の優先順位、すなわち一番最初を決定するためにＳＳＮが使用されるため、また、擬似支払いのＳＳＮはその擬似待ち行列内の最小の支払いのＳＮＮとなるため、このような支払いの各々は少なくとも過去にバッチングされた順番と同じ優先順位が付けられる。
４．ＰＳＥＵＤＯＱＵＥＵＥにＬＩＮＫを追加する。
上述したステップのサブセットは、その２者間バッチに含まれる後続の支払いについても実行される必要がある。支払いのＳＳＮが、ＰＳＥＵＤＯＬＩＮＫ内のＳＳＮの現在の金額よりも低い場合には、ＰＳＥＵＤＯＬＩＮＫはＳＹＳＬＡＲＧＥＱＵＥＵＥ内でＬＩＮＫ１の代わりをする必要がある。次に、ＬＩＮＫ１は、前と同様に、ＲＥＭＯＶＥと同種の呼び出しを介してその待ち行列から除去される。そうでない場合は、どの待ち行列上にもＬＩＮＫ１を保持する必要はないので、ＲＥＭＯＶＥがＱＦＳ＝０と共に呼び出される。言い換えれば、ＲＥＭＯＶＥは、ＦＯＲＧＥＴＳＹＳＬＩＮＫの呼び出すことなく、全ての待ち行列からＬＩＮＫ１を除去する。次に、ＬＩＮＫ１は、ＰＳＥＵＤＯＩＮＳＥＲＤＥＦＩＮＥを介してＰＳＥＵＤＯＱＵＥＵＥに追加される。
【０２１０】
最終的にＸＩＴラベルに達すると、擬似支払い（すなわち、ＨＡＶＥＰＳＥＵＤＯ＝ＴＲＵＥ）がある場合にはクリーンアップ作業が行われる。この時点で、例えば、送信側、受信側、擬似支払いの量が設定される。さらに、ネット量がわかるのはこの時点においてだけなので、擬似支払い内のＬＡＲＧＥＡＭＯＵＮＴフラグを設定することができるのもこの時点以外にはない。ネット量が多い場合には、ＢＩＬＡＴＯＲＤＩＮＳＥＲＴを介してＢＩＬＡＴＯＲＤＱＵＥＵＥ内に配置され、また、多くない場合には、ＢＩＬＡＴＭＥＤＩＵＭＰＵＳＨを介してＢＩＬＡＴＭＥＤＳＭＡＬＬＱＵＥＵＥ内に配置される。擬似支払いのＳＳＮは、待ち行列内で最も大きいものではないことがほぼ確実であるため、擬似支払を、単純にＢＩＬＡＴＭＥＤＳＭＡＬＬＱＵＥＵＥ内にＩＮＳＥＲＴｅｄすることはできないことに注意されたい。
【０２１１】
２．ＣＨＥＣＫＢＡＴＣＨＥＳ、ＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥ、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴ、ＣＨＥＣＫＲＥＣＶＰＡＹＭＴ、多者間バッチルーチン
ａ．ＣＨＥＣＫＢＡＴＣＨＥＳ
このルーチンは、同時公開が可能な支払いのバッチ内に含むことにより、また、ＣＨＥＣＫＢＡＴＣＨＥＳフラグが成功であればこれをＴＲＵＥに、成功でなければＦＡＬＳＥに設定することにより、大型支払いを公開しようと試みる。当然、バッチに含まれる全ての参加者はバッチの公開後はその最大または最小利用残高を超えてはならないという制約を満たす唯一のバッチは、これをその他の支払い注文の適切なバッチと共に含むことにより、許容可能である。
【０２１２】
バッティング処理は、送信側の利用可能な残高がプレファンド残高に関連して正であり、受信側の利用可能な残高がプレファンド残高に関連して負である所定の大型「ターゲット」支払いについて最も成功し、これと反対の場合に最も失敗するようである。従って、ＣＨＥＣＫＢＡＴＣＨＥＳが、ＧＲＯＵＰＭＤＬＰＯＳＩＴＩＯＮ（ＳＧＲＰ）とＧＲＯＵＰＭＤＬＰＯＳＩＴＩＯＮ（ＲＧＲＰ）のサインビットの可能な値と、送信側と受信側の各々のポジションとに関連して、値０と１のみを仮定できる２つの変数、すなわち、ＳＴＯＧとＲＴＯＧにかかるループの対である。このループは、最も望ましいケース（送信側が信用貸しポジションにあり、受信側が借記ポジションにある）に関連してＳＴＯＧ＝０とＲＴＯＧ＝１で始まり、次に、中間ケース（送信側と受信側が信用貸しポジションにあり、次に、送信側と受信側が借記ポジションにある）に進み、最後に、送信側が借記ポジション、受信側が信用貸しポジションにある状態で終了する。
【０２１３】
各ループ内で、ＳＹＳＬＡＲＧＥＱＵＥＵＥ内にある全ての大型支払い（ＬＡＲＧＥＡＭＯＵＮＴフラグを介して識別されたもの）がターゲット支払いとなる。実際にバッチを作成するルーチンであるＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥは、そのバッチ内の全ての参加者がそのポジション限度内に残る方法で、以下に示す理由のいずれかによって失敗することがある。すなわち、そのターゲット支払いの受信側を基とする支払いのツリーを構築することができないため、または、そのターゲット支払いの受信側を基とする支払いのツリーを構築することができないため、である。第１の場合において、名目上のブールＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥフラグが、ビットストリング”１０”にＤＥＦＩＮＥ’ｄされたＳＦＡＩＬに設定され、第２の場合において、ＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥフラグは、ビットストリング“１００”にＤＥＦＩＮＥ’ｄされたＲＦＡＩＬに設定される。いずれの場合においても、最も有意でないビットは０値を有するため、ＲＳＬＴ：＝ＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥへのテストはＦＡＬＳＥである。前回失敗した、特定の参加者をターゲットとした送信側または受信側のバッチを作成する試みは、その参加者のビットをＳＦＡＩＬＡＭＴＭＡＳＴとＲＦＡＩＬＡＭＴＭＡＳＫの各々に設定することによって記録される。このような試みがなされている場合、その後に、参加者が同額またはそれよりも大きな額を送受信しようとすると確実に失敗する。そのため、送受信する金額が、ＳＦＡＩＬＡＭＴとＲＦＡＩＬＡＭＴ配列にそれぞれ記憶されているこれら失敗の金額を超える場合には、バッチ作成を試みることはない。その他全ての場合において、多者間バッチを識別するためにＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥが呼び出され、また、第１バッチファンドを公開するためにＢＡＴＣＨＲＥＬＥＡＳＥが呼び出される。
【０２１４】
ｂ．ＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥ
ＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥのゴールは、ＢＡＴＣＨＬＩＮＫ配列をターゲット支払いを含む有効な多者間バッチを有するノードで占めることである。ＢＡＴＣＨＬＩＮＫ配列内の第１エントリは、常にターゲット支払いでなければならないため、代入文ＢＡＴＣＨＬＩＮＫ［０］：＝ＬＡＲＧＥＬＩＮＫである。借記および信用貸し限度制約を満たすべく、後続するいくつかの文はＳＭＩＮＰＭＴＳＺ、ＳＭＡＸＰＭＴＳＺ、ＲＭＩＮＰＭＴＳＺ、ＲＭＡＸＰＭＴＳＺ、すなわち、ＬＩＮＫにあるターゲット支払いの送信側によって受信され、ターゲット支払いの受信側によって送信されなければならない最小、最大支払いの各々のサイズを計算する。これらの最小値および最大値はＣＨＥＣＫＳＥＮＤＰＡＹＭＴとＣＨＥＣＫＲＥＣＶＰＡＹＭＴを呼び出す上で必要であり、また、この各々には、現在のターゲット支払いの送信側と受信側も必要である。
【０２１５】
ｃ．ＣＨＥＣＫＳＥＮＤＰＡＹＭＴとＣＨＥＣＫＲＥＣＶＰＡＹＭＴ
送信側のバッチを作成する処理は、受信側のバッチを作成する処理と本質的に同一であるため、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴについてのみ詳細に説明する。ＣＨＥＣＫＳＥＮＤＰＡＹＭＴの作業は、送信側のバッチを、ターゲット支払いの受信者を基部にしたツリーとして考え、送信側への支払いを第１レベルブランチ、第１レベル上の送信側（１つまたは複数）への支払いを第２レベルブランチ、等として考えることにより最良に説明することができる。ＣＨＥＣＫＳＥＮＤＰＡＹＭＴへの帰納的な呼び出しの各々は、単一の送信側ノードがポジション制約を満たすか、手順が失敗して出るかするまで、単一の送信側ノード上にＭＡＸＢＲＡＮＣＨＥＳリーフノードを追加する。
【０２１６】
ＣＨＥＣＫＳＥＮＤＰＡＹＭＴは、これが既に終了しているかどうかをチェックすることにより作業を開始する。この可能性が考慮されなければならないのは、大型支払いのための相殺を上回る金額である、送信側と受信側の初回プレファンド残高要求金額の最小金額と同じ金額の支払いが、送信側と受信側の利用可能残高によって、バッチングを要することなく公開されると考えられるためである。これは、通過したパラメータＳＭＩＮＰＭＴＳＺ、送信側のツリーから要求される最小寄与が、ゼロと等しいか、これ未満である場合に当てはまるものである。
【０２１７】
次に、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴがＤＥＰＴＨ＞ＭＡＸＤＥＰＴＨであるかを調べ、そうであれば、ツリーはそれ以上のびることができないため、誤（失敗）へと戻らなければならない。
【０２１８】
非ヌル送信側ツリーを構築しなければならない場合（すなわち、ＳＭＩＮＰＭＴＳＺ＞０）、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴはまず、有効に働く単発支払いを見つけるための試みを行い（ＰＨＡＳＥ０）、これが失敗すると、有効に働く一連の支払いを見つけるための試みを行う（ＰＨＡＳＥ１）。これらの支払いを見つけるために、以下の条件を満たすターゲット支払いの、送信者宛ての支払いを識別するべく、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴが、その支払いがＭＩＮＡＣＣＥＰＴＡＢＬＥよりも小さくなるまでＧＲＯＵＰＯＲＤＥＲＣＶＱＵＥＵＥを介してループを続ける。
【０２１９】
１．支払いが、まだ送信側ツリーまたは受信側ツリーのいずれにも含まれていない（すなわちＢＡＴＣＨＬＩＮＫＳ配列にＬＩＮＫが見つからない）。
２．ＣＨＥＣＫＳＥＮＤＰＡＹＭＴが、このレベルでこのリーフノードの組を構築する上で該参加者と出会っていない（すなわち、この参加者用のローカルＧＲＰＭＡＳＫフラグがまだ設定されていない）。または、この該参加者が、現在のノードを含んだツリーのブランチの下で発生していない。
３．送信側が、１日の最初におけるポジションと同等かそれよりも大きいポジションにいる。
４．支払い金額は、ＭＡＸＡＣＣＥＰＴＡＢＬＥと同額かそれ未満である。ＰＨＡＳＥ０において、これは、受信側の最大利用可能残高を乱すことのない最大支払いサイズである。このフェイズにおいて、ＮＯＣＲＥＤＩＴＬＩＭＩＴＳ＝ＴＲＵＥであり、信用貸し限度が引き上げられると、ＭＡＸＡＣＣＥＰＴＡＢＬＥが９，０００，０００ドルに設定され、適切な大きさの金額が表示される。ＰＨＡＳＥ１において、ＭＡＸＡＣＣＥＰＴＡＢＬＥは、プログラムに、ターゲット受信側への支払いを２つ以上見つけさせ、これによりツリー内でブランチを生じるＳＭＩＮＰＭＴＳＺに設定される。
【０２２０】
これらの制約が全て満たされると、この支払い注文は、ツリーノードとして含まれる候補になる。このような候補は２つ以上存在していてもよい。その場合には、トライアル支払い未満の最小の損失の結果、送信側の最小利用可能残高（すなわち、最小のＤＮＥＸＴＭＩＮＰＭＴＳＺ）がＢＥＳＴＬＩＮＫとして示され、関連するＧＲＰＤＯＮＥフラグが設定される。ＤＢＥＳＴＭＩＮＰＭＴＳＺ ≦ ０である場合、送信側の最小利用可能残高未満の損失はないので、このノードはいかなる子供を備えている必要はない（従って、バッチに支払い注文を追加する必要もない）。あるいは、ツリーの深さがまだＭＡＸＤＥＰＴＨでない場合は、これらの追加支払い注文を識別し、現在のノードの子供として含むために、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴへの帰納的な呼び出しを行う必要がある。
【０２２１】
候補支払いの送信側がその最小利用可能残高を下回らないようにするために、ＤＮＥＸＴＰＯＳ − ＤＡＭＴ ≧ＤＮＥＸＴＣＡＰを持っていなければならず、ここで、ＤＡＭＴ、ＤＮＥＸＴＣＡＰ、ＤＮＥＸＴＰＯＳはそれぞれ、候補支払いの金額、その送信側の最小利用可能残高、送信側のポジションである。計算ＤＮＥＸＴＭＩＮＰＭＴＳＺ：＝ＤＡＭＴ＋ＤＮＥＸＴＣＡＰ − ＤＮＥＸＴＰＯＳの正確さは、不等が正（true）であることを確実にするために送信側へ送信される必要がある追加の金額として、ＤＮＥＸＴＭＩＮＰＭＴＳＺの定義から続いている。
【０２２２】
ＤＢＥＳＴＭＩＮＰＭＴＳＺ ≦０である場合、または、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴ帰納的呼び出しがＴＲＵＥに戻る場合、候補ノードＢＥＳＴＬＩＮＫが、ＱＵＥＵＥ手続きを介して、実際にツリーに追加される。この手続きは、ＢＥＳＴＬＩＮＫをＢＡＴＣＨＬＩＮＫ配列、ＢＡＴＣＨＬＩＮＫ［ＢＡＴＣＨＬＩＮＫＳ］内の第１空白配列要素にコピーし、同じように、それぞれ送信側、受信側、関連支払の金額をＢＡＴＣＨＳＧＲＰ［ＢＡＴＣＨＬＩＮＫＳ］、ＢＡＴＣＨＲＧＲＰ［ＢＡＴＣＨＬＩＮＫＳ］、ＤＢＡＴＣＨＡＭＯＵＮＴ［ＢＡＴＣＨＬＩＮＫＳ］の中に記憶する。ＱＵＥＵＥ手続きは、ＢＡＴＣＨＬＩＮＫ、ＢＡＴＣＨＳＧＲＰ、ＢＡＴＣＨＲＧＲＰ、ＤＢＡＴＣＨＡＭＯＵＮＴ配列内の第１空白配列要素が以前よりも１大きいという事実を反映するために、ＢＡＴＣＨＬＩＮＫＳをインクリメントした後に、制御をＣＨＥＣＫＳＥＮＤＰＡＹＭＴへ戻す。
【０２２３】
次に何が続くかはＰＨＡＳＥによる。ＰＨＡＳＥ０において、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴが、両送信側の利用可能残高がその最小利用可能残高を超えないようにするために、ターゲット支払いの送信側へ送信できる単発の支払いを見つけようと試みたことを思い出されたい。上述のＰＨＡＳＥ＝０を伴う計算を全て終えたら、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴは、このような支払いが見つかった場合にＴＲＵＥに戻るか、または、このジョブを実行するための複数の支払いを探すべくＣＨＥＣＫＳＥＮＤＰＡＹＭＴを許容するためにＰＨＡＳＥ＝１を設定する。フェーズ１の最中に新規のブランチがツリーに追加されるたびに、ＭＡＸＡＣＣＥＰＴＡＢＬＥとＭＩＮＡＣＣＥＰＴＡＢＬＥの値が再計算される。ＣＨＥＣＫＳＥＮＤＰＡＹＭＴは、このような支払いのグループが見つかった場合にＴＲＵＥに戻るか、または、ＭＡＸＢＲＡＮＣＨ支払いを試した後に単純に検索を停止するかのいずれかを行う。
【０２２４】
ほぼ同一の手続きを使用して、ＣＨＥＣＫＲＥＣＶＰＡＹＭＴ内に受信側のツリーを構築する。事実、違いは次のような明白なものばかりである。ＧＲＯＵＰＯＲＤＳＥＮＤＱＵＥＵＥがＧＲＯＵＰＯＲＤＲＥＣＶＱＵＥＵＥの代わりに参照される；受信側ツリーに含まれている参加者は借記ポジションになくてはならない；ＤＮＥＸＴＭＩＮＰＭＴＳＺの計算はＤＮＥＸＴＭＩＮＰＭＴＳＺ：＝ＤＡＭＴ−ＤＮＥＸＴＣＡＰ＋ＤＮＥＸＴＰＯＳに変更される。
【０２２５】
最大利用可能残高内に留まるという必要性から、状態ＤＮＥＸＴＰＯＳ＋ＤＡＭＴ≦ＤＮＥＸＴＣＡＰに関連した、受信側への制約が生じる。再び、この不等を正（true）にするために、受信側がＤＮＥＸＴＭＩＮＰＭＴＳＺの支払いを受信する必要がある場合、このテキストにおける計算は適切なものである。
【０２２６】
図４は、手続きＣＨＥＣＫＳＥＮＤＰＡＹＭＴの基本的な流れを示している。手続きＣＨＥＣＫＳＥＮＤＰＡＹＭＴへの呼び出しが正に戻ると、ツリーの構築が成功したということになる。この呼び出しが誤に戻ると、手続きが支払い注文のツリーの構築に失敗したということになる。
【０２２７】
図に示すように、手続きを呼び出したら、ＳＧＲＰ、ＳＭＡＸＰＭＴＳＺ、ＳＭＩＮＰＭＴＳＺ、ＴＲＥＥが、ステップＳ１０１において、通過したパラメータとして渡される（ｐａｓｓｉｎ）。ＳＧＲＰは、ツリー構築内の任意の特定のポイントにおける現在のエンドノードを示す送信側参加者の参加者数である。ＳＭＡＸＰＭＴＳＺは、利用可能残高を考慮して、ＳＧＲＰへのヘルパー支払いとして使用できる、最大サイズの支払い注文を表す。ＳＭＩＮＰＭＴＳＺは、このような支払い注文の最小のものを示す。ＴＲＥＥは、特定の参加者がそのツリーのあらゆる特定のブランチ上に１度以上現れることを防ぐための、内部的に使用されるビットマスクである。ステップＳ１０２では、ＳＭＩＮＰＭＴＳＺがゼロと等しいか、またはそれ未満であるかが決定される。ＹＥＳの場合には、Ｓ１０３において、手続きは出て、正（true）へ戻る。これは、ＳＭＩＮＰＭＴＳＺがゼロ未満である場合にはツリーが完成し、これ以上ツリーを構築する必要がないためである。ＳＭＩＮＰＭＴＳＺがゼロよりも大きい場合には、流れは、ＤＥＰＴＨがＭＡＸＤＥＰＴＨと等しいかそれよりも大きいかを決定するＳ１０４へ続く。ＤＥＰＴＨは、ツリーの最長のブランチの長さと同様、帰納の深さに等しい。ＭＡＸＤＥＰＴＨは所定の定数である。答えがＹＥＳの場合、手続きは出て、誤へ戻る。ＮＯの場合は、流れはステップ１０６へ続く。ステップ１０６では、ＰＨＡＳＥが０に設定され、ＤＥＰＴＨがインクリメントされ、ＢＬＳＡＶＥがＢＡＴＣＨＬＩＮＫＳの値に指定される。ＰＨＡＳＥは、０または１の値を持つことができる。０の現在値は、単発のヘルパー支払い注文を探すための試みがなされていることを示す。値が１である場合、手続きは、ツリーのブランチングを生じる、段階的に小さくなるヘルパー支払いのリストを探そうと試みる。次に、流れはステップＳ１０７へ進む。ステップＳ１０７では、支払いサイズ限度ＭＩＮＡＣＣＥＰＴＡＢＬＥとＭＡＸＡＣＥＰＴＡＢＬＥがフェーズに依存して計算される。次に、ステップＳ１０８において、サイズが、送信側のポジションＢＥＳＴＧＲＰにおいて最もヘルプを必要としない、ＭＩＮＡＣＣＥＰＴＡＢＬＥとＭＡＸＡＣＣＣＥＰＴＡＢＬＥの間の大きさであるＳＧＲＰのためのＧＲＯＵＰＯＲＤＲＥＣＶＱＵＥＵＥから支払いが選択される。
【０２２８】
このような支払いが見つからない場合には、流れはステップＳ１０８からステップＳ１１６へと進み、ここで、ＰＨＡＳＥが１と等しいかどうかが決定される。ＰＨＡＳＥが１と等しくない場合には、上述したように、ステップＳ１１７においてＰＨＡＳＥが１に設定され、流れがステップＳ１０７へ入るためにループバックする。他方で、ステップＳ１１６でＰＨＡＳＥが１と等しいことがわかった場合には、流れはステップＳ１１８へ進む。ステップＳ１１８では、ＢＡＴＣＨＬＩＮＫＳがＢＬＳＡＶＥの値を得て、ＤＥＰＴＨが決定され、手続きが誤の結果と共に出る。
【０２２９】
ステップＳ１０８において支払いが見つかると、ステップＳ１０９において、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴへの帰納的呼び出しについて新規のパラメータが計算され、ＢＥＳＴＧＲＰがパラメータＳＧＲＰとして入れられる（pass in）。さらに、帰納的呼び出しにおいて、ＭＩＮＡＣＣＥＰＴＡＢＬＥがパラメータＳＭＩＮＰＭＴＳＺとして入れられ（pass in）、ＭＡＸＡＣＣＥＰＴＡＢＬＥがＳＭＡＸＰＭＴＳＺとして入れられる（pass in）。次に、ステップＳ１１０において、ＣＨＥＣＫＳＥＮＤＰＡＹＭＴの帰納的呼び出しが実行される。ＣＨＥＣＫＳＥＮＤＰＡＹＭＴの帰納的呼び出しが誤に戻ると、処理の流れが上述のステップＳ１１６へと進む。帰納的呼び出しが正に戻ると、流れはステップＳ１１１へ進む。ステップＳ１１１において、ＢＡＴＣＨＬＩＮＫＳがインクリメントされ、ＢＥＳＴ支払いが配列ＢＡＴＣＨＬＩＮＫ［ＢＡＴＣＨＬＩＮＫＳ］において待ち行列登録される。ＢＡＴＣＨＬＩＮＫは、ツリー内の試験的な支払いへのリンクを含んだ配列である。次に、ステップＳ１１２において、ＰＨＡＳＥが１と等しい場合に、ＭＩＮＡＣＣＥＰＴＡＢＬＥおよびＭＡＸＡＣＣＥＰＴＡＢＬＥが更新される。次いでステップＳ１１３で、ＳＧＲＰの利用可能残高が許容可能であるかどうかが決定される。許容可能であれば、手続きＣＨＥＣＫＳＥＮＤＰＡＹＭＴは正へ戻るへ出る。許容可能でなければ、流れはステップＳ１１５へ進む。ステップＳ１１５では、最大ブランチングが限度を超えているかどうかが決定される。超えていなければ、手続きはステップＳ１０８へループバックする。超えていれば、手続きの流れは、上述したようにステップＳ１１８へと進み、誤へ戻るへ出る。
【０２３０】
Ｂ．支払いの公開方法
シミュレーション目的のために、支払いの「公開」は、送信側の利用可能残高から支払い金額を減じ、受信側の利用可能な残高に関連する金額を足すだけであり、つまり、ＲＥＬＥＡＳＥ手続きで実行されるタスクである（この手続きは上述の擬似コードでは示されていないが、しかし、そこにリストアップされているルーチンのいくつかによって呼び出される。詳細は以下の説明を参照のこと。）。
【０２３１】
支払いは、それが多者間バッチの一部、２者間バッチ、または個別の小型支払いのいずれであるかによって、いくつかある方法のうちの１つによってＲＥＬＥＡＳＥ手続きへと渡される。多者間バッチの一部である支払いは、ＣＨＥＣＫＢＡＴＣＨＥＳに呼び込まれたＢＡＴＣＨＲＥＬＥＡＳＥを介して、ＲＥＬＥＡＳＥへ送信される。ＣＨＥＣＫＢＡＴＣＨＥＳは、多者間バッチの制約を監視するルーチンであるので、多者間バッチが制約され次第、ＢＡＴＣＨＲＥＬＥＡＳＥが呼び出される。ＢＡＴＣＨＲＥＬＥＡＳＥは、１つの多者間バッチが１つのユニットとして公開されるようにコード付けされている。
【０２３２】
小型支払いと、小型の２者間バッチングされた支払いは、両方ともＴＲＹＴＯＲＥＬＥＡＳＥを介して処理される。この公開モードの主な特徴は、ルーチンＧＡＬＥＳＨＡＰＬＥＹを用いた、同時に公開することが可能な複数の小型支払いのバッチを識別する試みである。これらの支払いが知られると、実際にＲＥＬＥＡＳＥを呼び出すために、ＲＥＬＥＡＳＥＬＯＯＰルーチンが呼び出される。
【０２３３】
これら公開機構の各々は、ＭＡＳＫＬＯＯＰＤＥＦＩＮＥを使用して、どの参加者が潜在的な公開可能支払いを持っているかを決定する。ＭＡＳＫＬＯＯＰは、パラメータＭＡＳＫ、ＧＲＰ、ＬＯＯＰＸと共に呼び出される。ＭＡＳＫは、関連する参加者（または「グループ」）が潜在的に公開可能な支払いをもっている場合、ビットがＴＲＵＥに設定される複数ワードビットマスクである。ＧＲＰは、グループ数であるＧＲＯＵＰＳＦＯＵＮＤと１の間の整数である。ＬＯＯＰＸは、初期設定でゼロに設定されているワークスペースである。各時間ＭＡＳＫＬＯＯＰが呼び出され、ＧＲＰは初期設定ではＦＩＲＳＴＯＮＥ（ＲＥＡＬ（ＭＡＳＫ［ＬＯＯＰＸ］））−１に設定されている。最も大きくないＭＡＳＫ［ＬＯＯＰＸ］のビットはビット１であり、その２番目はビット２、等であり、ビルトイン機能ＦＩＲＳＴＯＮＥは、ＭＡＳＫ［ＬＯＯＰＸ］のＭＡＳＫ［ＬＯＯＰＸ］の最大のビット数（例えば、１＋ＭＡＳＫ［ＬＯＯＰＸ］のベース２ログか、または、ＭＡＳＫ［ＬＯＯＰＸ］＝０であればゼロを戻す。ＭＡＳＫ［ＬＯＯＰＸ］＝０である場合、ＬＯＯＰＸは１によってインクリメントされるため、そのマスクの次のワードを「１」ビットについて検索することができる。そうでなければ、（すなわちＭＡＳＫ［ＬＯＯＰＸ］≠０）、ＭＡＳＫ［ＬＯＯＰＸ］の最大ビットがゼロに設定され、現在検索されているワードのポジションを考慮するためにＧＲＰに４８＊ＬＯＯＰＸが加算され、制御が呼び出し手続きに戻される。
【０２３４】
１．ＢＡＴＣＨＲＥＬＥＡＳＥ
多者間バッチを公開するＢＡＴＣＨＲＥＬＥＡＳＥは、公開方法の中でも最も簡単なものある。これは単純に、ＢＡＴＣＨＬＩＮＫ配列内にあるエントリの各々にかかるループである。これらのエントリは、公開される支払いと、その支払いが実際に擬似支払いの一部であるかどうかを示すフラグとを含んでいる。従って、ループが、各支払いについてＲＥＬＥＡＳＥを呼び出し、その後、その支払いを記憶しているノードが、引数”０”でＲＥＭＯＶＥを呼び出すことによってシステムから削除される（この引数は、指摘された待ち行列からノードが除去されてしまうことを防ぐマスクであること思い出されたい。“０”は、「全ての待ち行列からこのノードを除去せよ」ということを意味する。）。
【０２３５】
ＣＨＩＰＳに採用された場合、ＢＡＴＣＨＲＥＬＥＡＳＥは、そのバッチ内の全ての支払いを１つの処理で公開させる。
【０２３６】
２．ＴＲＹＴＯＲＥＬＥＡＳＥ
小型支払いと小型擬似支払いを公開するＴＲＹＴＯＲＥＬＥＡＳＥは、正確なＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫとＧＲＯＵＰＢＩＤＤＥＥＭＡＳＫ、また、どの参加者が競り手で、どの参加者が売り手であるかを示すフラグを含んだＧＡＬＥＳＨＡＰＬＥＹを呼ぶ。ＧＡＬＥＳＨＡＰＬＥＹの稼働時間は、競り手と売り手の数に伴って少なくとも二次的に増加してまうので、これらの各々の数を可能な限り少数にすることが重要である。特に、送信側が競り手である際には、送信側への支払いを有する参加者（この参加者についてはＧＲＯＵＰＳＥＮＤＱＮＯＴＮＵＬＬフラグがＴＲＵＥである）のみに競りが許可されなくてはならない。おそらく、これはそれほど明白なことではないが、新規に到着した支払い注文の結果、また、公開された支払いの結果として状況が変更した可能性のある参加者のみ、この競りに参加する必要がある。
【０２３７】
ＴＲＹＴＯＲＥＬＥＡＳＥはＧＡＬＥＳＨＡＰＬＥＹを２度呼び出す。１度目は、送信側が競り手（すなわち、通過したパラメータＳＥＮＤＥＲＢＩＤＳ＝ＴＲＵＥ）であり、２度目は受信者が競り手（すなわち、通過したパラメータＳＥＮＤＥＲＢＩＤＳ＝ＦＡＬＳＥ）である。どちらの場合も、ＧＡＬＥＳＨＡＰＬＥＹは、競り手の数（送信者が競る場合はＢＩＤＤＥＲＣＯＵＮＴ１、受信者が競る場合はＢＩＤＤＥＲＣＯＵＮＴ２である）が０よりも大きい際にのみ呼び出される。１度目の呼び出しでは、状態が変更したために追加の支払いを送信することができるようになった参加者（すなわち、その参加者のＳＥＮＤＥＲＳＴＡＴＥフラグがＴＲＵＥ）が競り手である。従って、ＴＲＹＴＯＲＥＬＥＡＳＥは、ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫを計算するためにＭＡＳＫＡＮＤを呼び出し、どの参加者が競り手であるかを示すフラグのセットは、
ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫ ← ＳＥＮＤＥＲＳＴＡＴＥ＆ＧＲＯＵＰＳＥＮＤＱＮＯＴＮＵＬＬである。
【０２３８】
次に、ＢＩＤＤＥＲＣＯＵＮＴ１が次に示す手続き呼び出しにおいて計算される。
ＣＯＵＮＴＢＩＴＳ（ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫ、ＢＩＤＤＥＲＣＯＵＮＴ１、ＴＥＭＰ）
【０２３９】
１度目のＧＡＬＥＳＨＡＰＬＥＹへの呼び出しは、ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫフラグのこのセットと、現在のＧＲＯＵＰＲＥＣＶＱＮＯＴＮＵＬＬフラグのコピーであるＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫフラグのセットで行われる。２度目のＧＡＬＥＳＨＡＰＬＥＹへの呼び出しは、
ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫ ← ＲＥＣＥＩＶＥＲＳＴＡＴＥ＆ＧＲＯＵＰＲＥＣＶＱＮＯＴＮＵＬＬ
で行われるが、しかし、
ＣＯＵＮＴＢＩＴＳ（ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫ、ＢＩＤＤＥＲＣＯＵＮＴ２、ＴＥＭＰ）
で計算されたＢＩＤＤＥＲＣＯＵＮＴ２でが正である場合のみである。
【０２４０】
ＧＡＬＥＳＨＡＰＬＥＹの生成文は、ＧＲＯＵＰＳＥＮＤＳＴＯとＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭの整数配列の対である。ＧＲＯＵＰＳＥＮＤＳＴＯのｉ番目のエントリは、ｊが送信しなければならない支払いの（唯一の）受信側の参加者（「グループ」）数であり；同様に、ＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭのｊ番目のエントリは、ｊが受信する支払いの（唯一の）送信側のの参加者（「グループ」）数である。後でより詳細に説明するように、これは、どの支払いがＲＥＬＥＡＳＥに送信されるべきかの決定が可能な、ＧＡＬＥＳＨＡＰＬＥＹの直後に呼び出されるＲＥＬＥＡＳＥＬＯＯＰによる機構である。
【０２４１】
受信側が競り手である場合のＧＡＬＥＳＨＡＰＬＥＹの呼び出しについては、状況が変更したため追加の支払いを受けることができるようになった（すなわち、その参加者のＲＥＣＥＩＶＥＲＳＴＡＴＥフラグがＴＲＵＥである）参加者は競り手である。従って、ＴＲＹＴＯＲＥＬＥＡＳＥが、ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫを計算するためにＭＡＳＫＡＮＤを呼び出し、どの参加者が競り手であるかを示すフラグのセットが次のようになる。
ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫ ← ＲＥＣＥＩＶＥＲＳＴＡＴＥ＆ＧＲＯＵＰＲＥＣＶＱＮＯＴＮＵＬＬ
【０２４２】
使用されるＧＲＯＵＰＢＩＤＤＥＥＲＭＡＳＫフラグは、現在のＧＲＯＵＰＳＥＮＤＱＮＯＴＮＵＬＬフラグのコピーである。さらに、次に、実際に支払いを公開するためにＲＥＬＥＡＳＥＬＯＯＰが呼び出される。
【０２４３】
ＧＡＬＥＳＨＡＰＬＥＹへの最初の呼び出しにおいて支払いを送信するために競る参加者がなく、かつ、支払いを受けるために競る参加者がない場合において、また、その場合のみにおいて、ＴＲＹＴＯＲＥＬＥＡＳＥが正である同名のフラグを戻す。記号的には次のように表される。
ＴＲＹＴＯＲＥＬＥＡＳＥ ← （ＢＩＤＤＥＲＣＯＵＮＴ１＝０）ＡＮＤ（ＢＩＤＤＥＲＣＯＵＮＴ２＝０）
【０２４４】
上述した擬似コードから明らかであるように、ＴＲＹＴＯＲＥＬＥＡＳＥがＴＲＵＥに戻ると、ＴＲＹＴＯＲＥＬＥＡＳＥが呼び出されるループが終了する。
【０２４５】
３．ＧＡＬＥＳＨＡＰＬＥＹ
上述したように、このルーチンは、一般法則化されたＦＩＦＯ待ち行列規則において、支払いの送信側と受信側の対をつくる試みをする。従って、各競り手について、「競り手」は、ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫのＴＲＵＥ値によってそのように示されている参加者である。競り手は、全ての競り手が１つの支払いと独特に関係する時点において、入札が拒否されなくなるまで入札を提出する（ＲＥＪＥＣＴＣＯＵＮＴ＝０）。
【０２４６】
競りの各ラウンドの始めには、競り手に関連した、最も早いタイムスタンプ（ＳＳＮ）を持つ支払いが識別される（この計算で使用されＳＳＮは独特のものであるため、「引き分け」の可能性を省略していることに注意）。これには２つのネスティングされたＤＯＵＮＴＩＬループ、すなわち１つは競り手、もう１つは売り手にかかるもの、が関与している。外側ループは、実際の競り手への処理を規制するために、ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ上のＭＡＳＫＬＯＯＰＤＥＦＩＮＥ、ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫのコピーを使用する。このような競り手の各々について、ＭＡＳＫＬＯＯＰＤＥＦＩＮＥは、ＧＲＰＡにおける（正）参加者の証明番号か値−１のいずれかを記憶する。内部ループは、どちらの潜在的な競り手が最も早いタイムスタンプを持った支払いと関連しているかを決定するために、ＧＲＯＵＰＢＩＤＤＥＥＭＡＳＫ３上のＭＡＳＫＬＯＯＰＤＥＦＩＮＥ、ＧＲＯＵＰＢＩＤＤＥＥＭＡＳＫのコピーを使用する。このような売り手の各々について、ＭＡＳＫＬＯＯＰＤＥＦＩＮＥは、ＧＲＰＢにおける（正の）参加者証明番号か、または値−１のいずれかを記憶する。
【０２４７】
支払いへの競りは、その支払いが全てのファンディング制約を満たす場合にのみ有効である。これらのチェックは、計算の一部が外部ループにおいて行うことができ、また、この部分が、送信側が競っているか受信側が競っているかによって行われるため、例えばＣＨＥＣＫＳＥＮＤＰＡＹＭＴでのチェックよりも幾分複雑である。
【０２４８】
この計算について上記で説明したが、制約が満たされた場合にはフラグＦＩＴＴＯＧがＴＲＵＥに設定され、逆の場合にはＦＡＬＳＥに設定される。ＦＩＴＴＯＧがＴＲＵＥである場合にのみ、それまでに見つかった最も早いタイムスタンプＳＡＶＥＳＳＮと、ＧＲＰＡとＧＲＰＢ１に関連した支払いのＳＳＮとの間の比較が成される。このＧＲＰＡとＧＲＰＢ１に関連した支払いが最も早いタイムスタンプを有する場合、ＧＲＰＢ１の内容がＧＲＰＢへコピーされ、ＳＡＶＥＳＳＮが、今見つかった最も早いタイムスタンプに更新される。次に、内部ループの終端では、ＳＡＶＥＳＳＮが、この方法で見つかった最も早いタイムスタンプを持ち、ＧＲＰＡとＧＲＰＢの対は関連する支払い送信者と受信者を有する。ＳＥＮＤＥＲＢＩＤＳ＝ＴＲＵＥである場合、ＧＲＰＡとＧＲＰＢは各々、その支払いの送信者と受信者となる。そうでなければ、ＧＲＰＢが送信者、ＧＲＰＡが受信者になる。
【０２４９】
入札が受諾されるのは次の場合である。売り手にとってそれが最初の入札である場合（すなわち、ＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭ（ＧＲＰＢ）ＩＳ０ｉｆＳＥＮＤＥＲＢＩＤＳ＝ＴＲＵＥｏｒＧＲＯＵＰＳＥＮＤＳＴＯ（ＧＲＰＢ）ＩＳ０ｉｆＳＥＮＤＥＲＢＩＤＳ＝ＦＡＬＳＥ）と、前回受諾された入札のものよりも早いタイムスタンプに関連した入札である場合（すなわち、ｉｆＳＥＮＤＥＲＢＩＤＳ＝ＴＲＵＥ，
ＳＳＮ（ＢＩＬＡＴＭＥＤＩＵＭＨＥＡＤ（ＧＲＰＡ，ＧＲＰＢ），ＰＭＴ）＜
ＳＳＮ（ＢＩＬＡＴＭＥＤＩＵＭＨＥＡＤ（ＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭ（ＧＲＰＢ），ＧＲＰＢ），
ＰＭＴ）
および、
ＳＳＮ（ＢＩＬＡＴＭＥＤＩＵＭＨＥＡＤ（ＧＲＰＢ，ＧＲＰＡ），ＰＭＴ）＜
ＳＳＮ（ＢＩＬＡＴＭＥＤＩＵＭＨＥＡＤ（ＧＲＰＢ，ＧＲＯＵＰＳＥＮＤＳＴＯ（ＧＲＰＢ），ＰＭＴ）
ｉｆＳＥＮＤＥＲＢＩＤＳ＝ＦＡＬＳＥ）
である。
【０２５０】
受諾された入札は、ＳＥＮＤＥＲＢＩＤＳ＝ＴＲＵＥとＳＥＮＤＥＲＢＩＤＳ＝ＦＡＬＳＥの各々の場合を網羅する２つのＤＥＦＩＮＥＳ，ＴＥＮＴＡＴＩＶＥＤＡＴＥＡとＴＥＮＴＡＴＩＶＥＤＡＴＥＢを用いて、入力される。ここでは、ＴＥＮＴＡＴＩＶＥＤＡＴＥＡにのみ注目する。
ＴＥＮＴＡＴＩＶＥＤＡＴＥＢも同様に働くが、呼び出される際に受信側が競り手であるという事実のために調整されている。その入札が競り手、ＧＲＰＢにとって最初のものでない場合（すなわち、ＲＥＪＥＣＴ＝ＴＲＵＥ）、ＴＥＮＴＡＴＩＥＶＥＤＡＴＥＡは、拒否された競り手が再び競りを行えるようにするために必要なコードを含んでいる。まず、拒否された競り手（ＧＲＰＡ以外でなければならない）が、ＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭ（ＧＲＰＢ）になるように計算され、また、この競り手が送信側であるため、関連するＧＲＯＵＰＳＥＮＤＳＴＯエントリが０に設定される。この送信側が再び競りを行えるようにするには、その送信側のＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ２フラグがＴＲＵＥに設定される（この実現については、以下の説明を参照のこと）。最後に、拒否された入札のカウントであるＲＥＪＥＣＴＣＯＵＮＴがインクリメントされる。前回の入札が拒否されたか否かに関わらず、ＴＥＮＴＡＴＩＶＥＤＡＴＥＡが、配列エントリ、ＧＲＰＡから送信された支払いの受信側であるＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭ（ＧＲＰＡ）と、ＧＲＰＢによって受信された支払いの送信側であるＧＲＯＵＰＳＥＮＤＳＴＯ（ＧＲＰＢ）をＧＲＰＢとＧＲＰＡに各々設定する。
【０２５１】
メイン（ＲＥＪＥＣＴＣＯＵＮＴ＝０）ループにおける最後の命令は以下の通りである。
ＭＯＶＥＭＡＳＫ（ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ２，ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ）
【０２５２】
この命令は、ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ２を、次のループ通過に備えるＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫにコピーする。ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ２において拒否された競り手に対応する入札のみがＴＲＵＥに設定される点を思い出されたい。従って、初回後のメインループの各通過は、前回の通過で入札が拒否された送信側のみが関連している。
【０２５３】
図５は、バッチングを用いることなく小型支払いの公開を最適にするために使用される、手順ＧＡＬＥＳＨＡＰＬＥＹの処理の全体的な流れを示すものである。ステップＳ２０１では、ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫがＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫへ移動される。ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫは、既述の手続きＴＲＹＴＯＲＥＬＥＡＳＥによって設定されたマスクであり、手順ＧＡＬＥＳＨＡＰＬＥＹの現在の呼び出しにおいて競り手として機能する各参加者のビットを含んでいる。ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫは、受諾されなかった全参加者のビットを含んだマスクである。この手続きの実行が始まると、参加者は受諾されなかった。従って、全ての競り手参加者は、ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫに配置され、これらが受諾されると、ここから除去される。次に、ステップＳ２０２で、ループを通る特定のループの通過において何人の競り手が拒否されたかを示すＲＥＪＥＣＴＣＯＵＮＴと、このような拒否された競り手を含むマスクであるＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ２との各々がゼロに設定される。ステップＳ２０３において、現在考慮中の入札参加者であるＧＲＰＡが、ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫに設定された初回入札のビット数に設定される。言い換えれば、初回の競り手が選択されるということである。次に、このビットが、この競りがＳ２０３を通る後続のパスで選択されないようにリセットされる。ステップＳ２０４では、ＧＲＰＡが、ゼロよりも大きいか否か、すなわち、競り手が見つかったか否か（ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫにビットが設定されているか）の決定がなされる。ゼロよりも大きくない場合には、処理の流れはステップＳ２１４へ進み、ここで、ＲＥＪＥＣＴＣＯＵＮＴがゼロよりも大きいかどうかの決定がなされる。大きくない場合には、手続きは終了して出る。大きい場合には、ステップＳ２１６において、ＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ２がＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫへ移動され、流れがステップＳ２０２へループする。
【０２５４】
競り手が見つかったら、競り手が何に入札するのかが決定されなければならない。手続きは、その２者間待ち行列内に、ＧＲＰＡによって送信された支払いを有する受信側参加者を見つける必要がある。従って、ＧＲＰＡがゼロよりも大きいと決定された場合には、ＧＲＯＵＰＢＩＤＤＥＥＭＡＳＫ２、すなわち、ループの現在のパスにおける候補売り手を示すマスクが、ＢＩＬＡＴＳＥＮＤＱＮＯＴＮＵＬＬ［ＧＲＰＡ］ＡＮＤＧＲＯＵＰＢＩＤＤＥＥＭＡＳＫを得る。つまり、ＧＲＯＵＰＢＩＤＤＥＥＭＡＳＫ２に、フラグＢＩＬＡＴＳＥＮＤＱＮＯＴＮＵＬＬ［ＧＲＰＡ］の論理ＡＮＤが指定され、このフラグは、正の場合に、ＧＲＰＡと売り手の間の２者間待ち列内に支払い注文があることを示すフラグであり、また、このＧＡＬＥＳＨＡＰＬＥＹの呼び出しの候補売り手を含んだ手続きＴＲＹＴＯＲＥＬＥＡＳＥに既に設定されているマスクであるＧＲＯＵＰＢＩＤＤＥＥＭＡＳＫが指定される。次に、処理の流れはステップＳ２０６へと進む。ここでは、ＧＲＰＡからＧＲＰＢへの一番最初の支払いを有するＧＲＯＵＰＢＩＤＤＥＥＭＡＳＫ２から参加者ＧＲＰＢが選択される。これが見つからない場合、ＧＲＰＢは−１が指定される。次に、ステップＳ２０７において、ＧＲＰＢがゼロよりも大きいかどうかが決定される。０よりも大きければ、売り手が見つかったことを示す。ゼロ未満であれば、流れはステップＳ２０３にループバックし、再エントリする。
【０２５５】
ＧＲＰＢがゼロよりも大きい場合、ステップＳ２０８において、ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫ２内のビットＧＲＰＢがリセットされ、この売り手が再び使われることがないようにされる。ステップＳ２０９では、ＧＲＰＢが既に入札を有するか否かが決定される。有さない場合、流れは、試験的なマッチまたは「日付（ｄａｔｅ）」が作成されるステップＳ２１３へと進み、次にステップＳ２０３へループバックし、再エントリする。ＧＲＰＢが既に入札を有している場合には、次にステップＳ２１０において、我々の入札、すなわち現在考慮中の入札がよりよいものかどうかが決定される。そうであれば、流れはステップＳ２１２へ進む。ステップＳ２１２では、拒否された参加者の入札がＧＲＯＵＰＲＥＪＥＣＴＭＡＳＫ２に設定され、ＲＥＪＥＣＴＣＯＵＮＴがバンプされる（インクリメントされる）。次に、処理の流れは、上述したステップＳ２１３へ進む。我々の入札がよりよいものでない場合には、処理の流れはステップＳ２０６へループし、再エントリする。
【０２５６】
４．ＲＥＬＥＡＳＥＬＯＯＰ
この手続きが呼び出されるまでには、公開されるべき小型支払い「ほぼバラバラな状態」のバッチは識別され、また、この手続きのタスクはこれらをＲＥＬＥＡＳＥ手続きへ送ることである。ＲＥＬＥＡＳＥＬＯＯＰは、その名前を、ＧＲＯＵＰＢＩＤＤＥＲＭＡＳＫにおける送信側または受信側としてフラグ付けされた参加者にかかるループから得る。このループは、このような参加者各々のＩＤを変数ＧＲＰＡに指定するＭＡＳＫＬＯＯＰＤＥＦＩＮＥを用いて実現される。このような参加者が送信側であるか受信側であるか明白でないため、正値を含んでいるかどうか知るために、まずＧＲＯＵＰＳＥＮＤＳＴＯ（ＧＲＰＡ）が、次にＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭ（ＧＲＰＡ）がチェックされる。ＧＲＯＵＰＳＥＮＤＳＴＯ（ＧＲＰＡ）が正値を含んでいる場合、ゲール・シャプレイのアルゴリズムが、送信側としてＧＲＯＵＰＳＥＮＤＳＴＯ（ＧＲＰＡ）を、また、受信側としてＧＲＰＡを持った支払いが存在するはずであると保証し、同様に、ＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭ（ＧＲＰＡ）が正値を含んでいる場合、送信側としてＧＲＰＡを、また、受信側としてＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭ（ＧＲＰＡ）を持った支払いが存在するはずであると保証する。これは、最も早いタイムスタンプを持った２参加者間の支払いでなければならないため、対応するＢＩＬＡＴＭＥＤＩＵＭＨＥＡＤポインタが指定する支払いノードでなければならない。
【０２５７】
ＲＥＬＥＡＳＥへの呼び出しを介してこの支払いが公開された後、呼び出し
ＲＥＭＯＶＥ（ＬＩＮＫ，０）
が、全ての待ち行列から、関連するノードを除去する。次に、送信側と受信側が初回プレファンド限度内に留まるようにするために、送信側と受信側の両方についてＰＯＳＩＴＩＯＮＣＨＥＫＣルーチンが呼び出される。最後に、ＧＲＯＵＰＲＥＣＥＩＶＥＳＦＲＯＭとＧＲＯＵＰＳＥＮＤＳＴＯ配列内の適切なエントリが、無効な参加者ＩＤであるゼロにリセットされる。
【０２５８】
Ｘ．システムの特徴のリキャップ（recap）
リキャップにおいて、本発明の重要な特徴を以下に示す。
（１）支払いは、送信側参加者によってシステム内に記憶され、待ち行列登録される。続いて、システム内の利用可能残高によって、また、大型支払いの適当なバッチを形成するためのシステム機能によって許可されると、支払いは受信側参加者に公開される。
【０２５９】
（２）各参加者の利用可能残高は、ゼロ（「最小利用可能残高」）によって下限を、また、最大利用可能残高によって上限を決められている。最大利用可能残高限度は、可能な限り効率的なオペレーションの実行を助ける設計の重要な特徴である。
【０２６０】
最大利用可能残高の使用は、所定の時間において公開可能な、待ち行列登録された支払いの割合が増す毎に増加する。効率的なシステムオペレーションを得るため、また、支払いの公開において注文を制御する単なる公開可能性以上の基準を許可するために、この割合を最大化することが重要である。最も長く待ち行列登録されているこれらの支払いに優先権を与えることが望ましく、また、この優先権は可能な限り多くの効果を有することが望ましく、重要である。
【０２６１】
優先権の考慮と実験の両方は、プレファンド金額と、最小、最大利用可能残高との間の等しい差の対称性は、ほぼ最適な状況を表していることを証明した。
【０２６２】
（３）システムに入力された支払いは、そのサイズによって、即座に、２つの幅広いカテゴリーに分類される。小型支払いは、そのためのバッチングを試みることのない支払いである。大型支払いは、通常、公開するために、他の支払いとバッチングされなければならない支払いである。
【０２６３】
どちらの処理も連続的に進行し、また、どちらのタイプの公開の間にも最短時間間隔はない。サイズによる分類は、その支払いの送信側と受信側の１日の初めのファンディング残高に関連した公式を用いて行う。
【０２６４】
（４）効率的なオペレーションの補助として、小型支払いは２者間待ち行列に入れられる。送信側−受信側の対の各々について異なった２者間待ち行列がある。これは、トライアル・アンド・エラーを最小にしながら、ある特定の時間に公開可能な支払いを見つける上で助けとなる。さらに、小型支払いの公開にＦＩＦＯ規則を提供する。
【０２６５】
（５）効率的なオペレーションは、各々の金融機関が、そのプレファンディング金額に関連した１ビットポジションをその中に割り当てられるビットマスクの使用によっても促進される。使用されるこのようなマスクの２つは、（ａ）待ち行列が空でないことを示すマスク；（ｂ）銀行が最近、支払いを待ち行列登録したか、または、ポジション変更を行ったために支払いを送信または受信できるポジションに再び戻っているかもしれないことを示すマスクである。
【０２６６】
（６）次にどの支払いを送信するかを決定する上で、支払い受信側の関心、ならびに支払い送信側の関心を考慮する特徴が採用されている。このアルゴリズムはゲールおよびシャプレイの方法に基づいている。
【０２６７】
（７）２つのオリジナル支払いが２：１の割合未満で異なっているドルサイズを有する場合に、対向する方向に伝達するために待ち行列登録された２つの支払いを１つの擬似支払いバッチに組み合わせることができる多者間バッチングの方法を使用している。この大きさ規制の結果、２つのオリジナル支払い間の大きさの差を額とした擬似支払いの大きさが、２つのオリジナル支払いの小額の方よりも小さくなる。次に、これによって得られた擬似支払い自体が、他の支払いまたは擬似支払いと各々組み合わされる。
【０２６８】
２者間バッチングを、大きさがそれほど変わらない支払いどうしの組み合わせに限定することにより、この技術は、幅広い支払いサイズの分類をより好ましく収容することができる。
【０２６９】
この規則を考慮した別の方法に、正しくマッチングされなかった支払いの未熟バッチングを、２者間バッチングにしきい値規則を課することによって防止するものもある。
【０２７０】
（８）多者間バッチングの新しい方法を採用している。送信側銀行の借記キャップ（ゼロ）を超えることなく、指定の大型支払いを送信する際に、送信側銀行を補助するように、信用貸しポジションにある銀行の間で支払いのツリーが構築される。また、受信側の銀行の最大利用可能残高を超えることなく、指定の大型支払いを受信する際に、受信側銀行を補助するように、借記ポジションにある銀行の間で支払いの第２ツリーが構築される。
【０２７１】
ツリーを構築しながら、銀行を２つの別々のクラスに分類することは、この技術の成功において重要な要素である。
【０２７２】
（９）上述したツリーの構築において、構築の各ステップに、所与のノード（バンク）からのびる単一ブランチ（支払い）を使用するための優先順位が与えられる。この結果、補助される支払いに近い大きさの「ヘルパー」支払いを使用することになる。このような方法により、システムは、システム内での支払いサイズの分類の変更に対して、この方法を用いない場合よりも敏感でなくなる。
【０２７３】
（１０）ターゲットの支払い送信側および受信側は、間違ったポジションにあることもある。つまり、そのプレファンディング金額によって、送信側参加者が借記ポジションにある場合もあり、および／または受信側銀行が信用貸しポジションにある場合もある。しかしながら、このようなミスマッチが起こらなかったり、最小限化されている場合には、バッチ作成に優先権が与えられる。これらの例外的状況は、支払いの遅延を最小にするという主要な目的を検討するために許可され、システムは、送信側と受信側のポジションサインが好ましいポジションサインになるまで必ずしも待つ必要はない。
【０２７４】
（１２）多者間バッチ内における支払いのツリーの構築において、同一の銀行は同一のバッチに２回現れることはできない。しかし、ツリーには同一の銀行が２回以上現れることが許可される。この許可が有益なものであるということを予想するのは難しいが、経験的に、これが合計のスループットを増加することがわかっている。
【０２７５】
（１３）大型支払いの遅延待ち行列を採用している。遅延待ち行列内にある間、大型支払いは、多者間および２者間バッチングのヘルパー支払いとして使用されることができる。この最終的な効果は、より多くのヘルパー支払いを提供することであり、これにより、なんらかの形で遅延の経験を幾分増やしながら、スループットとシステム効率が増加する。
【０２７６】
（１４）システムのオペレーションを補助して定義するために、多数の幾分任意のパラメータを使用する。これらは、最大スループットまたはその他の設計的目的を達成するために、実験的に調整される。
【０２７７】
（１５）単純な慣例によって、１日の終りに、待ち行列に残っている支払いをクリアにする。この慣例は、送信側参加者と受信側参加者の間での支払いが最終的に決済するまで、いかなる支払いも公開されることはないという原則と一致する。この方法は、一日の終りに、待ち行列登録された未公開支払いのみの決済を実行するためのものである。機能上、これはあらゆる手形交換所決済として進行する。ＣＨＩＰＳは、記憶装置に残っている支払いメッセージに基づいて、これらの支払いメッセージのいずれも実際に公開することなく、全ての参加者について多者間のネット残高を計算する。このネット残高は、各々の参加者の利用可能残高に適用される。ある参加者についての結果がマイナス数字である場合、その参加者は最終プレファンド残高要求を有し、ある参加者についての結果がプラスである場合、その参加者は最終プレファンド残高権利を有することになる。最終プレファンド残高要求を有する参加者は、プレファンド残高口座にＦｅｄｗｉｒｅ支払い注文を送信することにより、その金額を支払う。要求されたＦｅｄｗｉｒｅが全て受信されると、ＣＨＩＰＳが、今度は、最終的なプレファンド残高額権利を有する他の参加者に、Ｆｅｄｗｉｒｅを送信する。
【０２７８】
（１６）このシステムを効率的に運用するには、採用しているそれぞれ異なる方法、すなわち、小型支払い用の２者間待ち行列登録、２者間バッチング、多者間バッチングターゲット支払い、多者間バッチングヘルパー支払いがシステムが使用しているデータ構造の形で反映される必要がある。この理由のために、待ち行列登録された支払い記録内には、複数のリンキングが存在していなければならない。待ち行列登録された支払い内の個別のリンクセットの各々は、その支払いに、特定の待ち行列内におけるポジションを与える機能をする。個別の待ち行列の各々は、バッチングするためまたは支払いを公開するために使用するある特定の機能を実現するように設計されている。
【０２７９】
（１７）連続した改良を介してシステムの活発性と信頼性を確実にするために、常に、特定の正確性を調べるためのチェック機能を適所に備えることが望ましい。その１つにポジションチェックがある。公開またはバッチ公開を実行した後に、規定の限度内にあるバッチ残高に関与する全ての銀行の最大および最小利用可能残高がチェックされる。
【０２８０】
（１８）このシステムを最初に実現する際に、全ての待ち行列がダブルリンクリストとして実現される。これらの待ち行列には、注文された挿入を実行する必要があるものもある。これは、長い待ち行列のための非効率なオペレーションである。この理由のため、ある大きさ以上の支払いのみを含むべくいくつかの待ち行列を規制するために、システムパラメータ（上述の（１４）を参照）が使用されている。
【０２８１】
（１９）あるポイントを明らかにするために、１つの大型支払いを、ある支払いの多者間バッチとして公開することができる。従って、理論的には、多者間バッチはあらゆる大きさであってよい。
【０２８２】
（２０）継続システムとして機能するためには、各参加者の初回プレファンド残高要求金額を決定する方法が必要である。このような数字を客観的な方法で計算するために唯一利用可能なデータは、支払いデータの経歴である。従って、このような使用に許可される公式を１つまたはそれ以上開発することが必要である。
【０２８３】
ＸＩ．公開の支払い完了性を備えたシステムのためのモデル技術
Ａ．序文
上述したように、本システムは全ての公開の支払い完了性を達成する。以下の説明において、セクションＢは機能面について述べている。セクションＣは、自動公開に関する技術的な説明である。セクションＤは、モデルコードの機能についてより詳しく説明する。
【０２８４】
Ｂ．機能面
本発明の好適な実施形態では、ＣＨＩＰＳを用いて本発明が実現する場合、その日１日にＣＨＩＰＳを介して送信された全ての支払いメッセージと、ニューヨーク連邦準備銀行の帳簿に記された決済口座を介した結果的な残高の決済との１日の最後におけるネッティングによって、支払い完了性が得られる。借り主参加者がその決済義務の支払を怠る可能性は、他の参加者の失敗から生じた損失を生き残っている参加者がシェアするという損失シェアリング協約に、全ての参加者の合意を要求することにより対処される。この義務は、参加者が担保に入れ、ニューヨーク連邦準備銀行のＣＨＩＰＳプレファンディング口座に保管されているファンドによって保証されている。本発明の利点は、支払いメッセージの１日の支払い完了性がその公開時に達成される一方で、現在のＣＨＩＰＳシステムの下で転記した担保を著しく超えないプレファンド残高の転記を参加者に要求する点である。これは、実際には、参加者が、現在のＣＨＩＰＳシステム下での借記キャップよりも実質的に低い借記キャップと同額の金額を有すということである。この有益な結果を達成するために、３つの主要な原則が挙げられる。
【０２８５】
（１）ほとんどの支払いを清算するのに小型キャップで十分であるような形で支払いが公開される注文を変更するために、記憶装置、続いて自動公開を使用する。
（２）必要であれば大型支払いを他の支払いとバッチングし、１つのステップで公開することができるバッチ正味金額を生じる。このシステムは、ＥＡＦ−２とは異なり、２者間バッチングに限定されるものではない。
（３）相殺前に公開されなかった支払いは、付加的に要求されたファンドが最初に提供されれば、相殺後に公開することができる。
【０２８６】
実現すべき特徴は少なくとも以下を含む。
・記憶および待ち行列登録オペレーションを生じる支払いメッセージ。
・参加者が、自分のポジションが、待ち行列登録された未公開支払いに関連していることを知ることができるように、新規の問合せメッセージが提供される。
・現在ＣＨＩＰＳに使用されている２者間の規制機能が不要である。
・特定の送信側と受信側を持つより小型（バッチされない）の支払いについて、依然、ＦＩＦＯプロトコルが支払い公開注文を決定し、一般に、バッチの形成では、正確な公開注文はシステムによってなされた特定の選択に依存する。
【０２８７】
Ｃ．自動公開とその他の技術的問題
１．概観
過去の実施と異なる本システムの１つの態様は、借記キャップに加えて信用貸しキャップを適用していることである。担保保証された借記キャップによって支払い完了性が保証されているので、信用貸しキャップは何のためのものかと思う人も当然いるだろう。事実、これはリスクの回避を目的としたものではない。信用貸しキャップとは、なにも公開されないようにするべくシステムのポジションが借記キャップで留まらないようにする状態で、支払いを強制的に公開する自然な方法を提供する助けとなる。我々は、そのプレファンド残高の２倍の金額である各参加者の利用可能残高に最大利用可能残高を指定する。
【０２８８】
２．公開プログラムの概要：小型支払い
公開は、ドルサイズクラスが異なる支払いに対して、それぞれ異なる形で進行する。借記キャップの０．８倍であると独断的に定義された「フローキャップ」が、小型支払いを大型支払いから区別するために使用される。フローキャップよりも小さな支払いは小型であり、その他は大型である。
【０２８９】
小型支払いは、送信および受信参加者のポジションが許可されると、２者間ＦＩＦＯ待ち行列から、（バッチングすることなく）個別に公開される。支払いの公開後は、借記限度、信用貸し限度のいずれも超えることはできない。常に、最も早く待ち行列登録された支払いの公開に優先権が与えられる。しかし、「最も早い」は、送信側と受信側とでは意味が異なるため、送信側と受信側の最適な、つまり、送信側と受信側の両方にとってある意味で可能な限り最適なマッチを見つけるために、マッチングアルゴリズム、すなわちゲール・シャプレイのアルゴリズムが用いられる。
【０２９０】
大型支払いは、多者間および／または２者間バッチングの補助を得て公開される。２者間バッチングについて説明する。
【０２９１】
大型の待ち行列登録された支払いは、次に示すように２者間的にバッチングされる。銀行Ａから銀行Ｂへの大型支払い注文が待ち行列登録されると、銀行Ｂから銀行Ａへの、第１の支払い注文の半分から２倍の大きさの別の支払い注文が既に待ち行列登録されていないかどうかを調べるためにチェックが実施される。ある場合には、第２の支払い注文が選択され、これが第１の支払い注文とバッチングされる。その結果、金額が、オリジナルの２つの支払い注文の差額である「擬似支払い」が生じる。この差額は、そのバッチ内の２つの支払い注文の各々の金額よりも小さいか、これと等しくなることに注意されたい。擬似支払いの行き先は、大型支払い注文の行き先と同じである。
【０２９２】
擬似支払いが形成されると、適切な「第２の」支払い注文が利用可能にならなくなるまで、同じ処理が反復して繰り返される。各ステップにおいて、擬似支払いの大きさは小さくなっていくか、最悪の場合でも同じ大きさのまま留まる。従って、２者間バッチングの全体的な効果は、公開される支払いのサイズと数を減少させることである。次に、これらの擬似支払いは、上述したように小型支払いとして、または、次に説明する多者間バッチングを用いて大型支払いとして公開される。
【０２９３】
システムが擬似支払いを「公開」する場合は、その擬似支払いにリンクされているバッチングされた全ての支払いを１つの処理によって公開する。
【０２９４】
３．多者間バッチング
多者間バッチングの目的は、フローキャップよりも大きな支払い、さらに、借記キャップと信用貸しキャップよりもずっと大きな支払い（および擬似支払い）を公開する手段を提供することである。
【０２９５】
あらゆる２者間バッチングが終了した後に大型支払いが待ち行列登録されると、チェックが大型支払いがもはや公開されうるかどうかを調べ始める。任意の１つの参加者からの大型支払いは、最も古い１番最初の支払いと考慮される。
【０２９６】
ＡからＢへの所定の大型支払いＰの公開について考慮した場合、通常、このような公開により、Ａのポジションがその最小利用可能残高を下回ってしまい、また、Ｂのポジションがその最大利用可能残高を上回ってしまう。そのため、Ａにおいて、指定された限度内に入るネットポジションを作るために、現在信用貸しポジションにある第３者側参加者からＡへのヘルパー支払いが使用される。ヘルパー支払いは、最初はＡにおけるポジションのみを考慮して選択される。
【０２９７】
構築の各ステップにおいて、根幹にある参加者Ａへ下方向に向かう支払いのツリーを設ける。入ってくるブランチと出て行くブランチの両方を備えたこのツリーのノードにある参加者は、その限度制約を満たす。ツリーのリーフ（末端）ノードは、その借記キャップを超える可能性があり、そのため、ヘルパー支払いの助けを必要とする可能性のある参加者である。ツリー内の、この種の助けを必要とするあらゆる参加者には助けが提供されるか、または削除されてツリーが縮小される。
【０２９８】
構築が成功した場合、既に信用貸しポジションにある参加者間の支払いのツリーが得られ、これにより、参加者Ａを含む、ツリーにおける全ての参加者のポジションが、その規定の借記および信用貸し限度内に収まる。
【０２９９】
システムは、この支払いツリーの構築に成功すると、次に、Ｂから既に借記ポジションにある参加者への支払いを用いて、Ｂにおいて同様の状態を達成しようと試みる。可能であれば別のツリーが構築され、これにより、第２ツリーにある全ての参加者ポジションが限度内に収まる。
【０３００】
これが全て首尾よく成し遂げられると、１つにまとめられた支払いの全てが多者間バッチを構成し、これが１つの処理で公開される。
【０３０１】
Ｄ．モデルコードの説明
本発明のシステムのシュミレーションのために使用されるモデルはＵｎｉｓｙｓＡｌｇｏｌプログラムである。上述したように、その入力ファイルは、１日の業務の終了後にＣＨＩＰＳによって生成されたいくつかのオフラインファイルから成っている。主な入力ファイルはＲＥＬＥＡＳＥＤＡＴＡファイルであり、このファイル記録には、その日にＣＨＩＰＳを介して公開され各支払いからの少数の抽出されたデータが含まれている。このデータは、送信側銀行および受信側銀行の数、公開時間、金額を含む。
【０３０２】
プログラムが使用するこの他のファイルは、その日に実施された２者間限度を提供するファイルである。このファイルを設ける理由は、これらの限度から、プログラムは、その日の各銀行による、預託している担保の金額の控えめな見積もりを計算することができるためである。これらの担保の金額は、モデルによって借記キャップ金額として使用される。モデリングの行使の主な目的は、これらの大幅に減少された借記キャップを用いて、１日のどれだけの作業（work）を公開することができるかを知ることである。
【０３０３】
プログラムは、ＲＥＬＥＡＳＥＤＡＴＡファイルを公開時間順に分類し、次に、１業務日中の参加銀行からの支払いの受信をシミュレーションするために、この分類されたファイルを読み出す。
【０３０４】
プログラムの出力は、モデルによってどの支払いが公開されたか、遅延の発生、どの支払いが公開されなかったかについての詳細が記載された長い要約レポートである。
【０３０５】
Ａｌｇｏｌプログラミング言語において、慣習よりも宣言が優先する。従って、必要とされる宣言が、後で、プログラムの開始付近において現れる。同様に、リスティングの終りにおいてプログラムの外側ブロックが生じる。そこでは、駆動論理が使用されていると理解して構わない。
【０３０６】
定義によって与えられた、待ち行列登録された支払いのレイアウトは、待ち行列登録された支払いの各々に関連して何が記憶されているかを示している。初めの３ワードは、ＲＥＬＥＡＳＥＤＡＴＡ記録からのフィールド、支払いが読まれた順番を示すシーケンスナンバーＳＳＮ、後に説明する２つの特別な目的フィールドＱＦＬＡＧＳとＬＡＲＧＥＡＭＯＵＮＴを含んでいる。
【０３０７】
各支払い内には、たくさんのリンクの組が存在する。これらは、いくつかのダブルリンクリストによって要求され、対、前向き、後ろ向きの形をとる。全ての銀行からからの支払いを１つのリストにリンクするためにＳＹＳＬＩＮＫが使用される。これにより、最も古い未公開の支払いを容易に見つけることができる。
【０３０８】
各銀行に対する異なったリストによってＧＲＯＵＰＯＲＤリンクが使用される（ＣＨＩＰＳ内の「グループ」とも呼ばれる）。これらのリストは、支払いドルサイズによって注文され、また、より大型の支払いのみを含んでいる。これらは、特定の銀行から、または特定の銀行への特定の大きさの支払いを見つけるために、ツリー構築でのヘルパー支払いとして使用されるべく、多者間バッチングにおいて使用される。
【０３０９】
支払いを「擬似支払い」にリンクするために、２者間バッチングにおいて擬似先頭と擬似末尾が使用される。これらの擬似支払いは、多者間バッチングコードによって、実際の支払いとほぼ同じように扱われる。
【０３１０】
２者間バッチ内に配置される支払いを選択する際に、ＢＩＬＡＴＯＲＤＬＩＮＫが使用される。
【０３１１】
ＦＩＦＯ注文で、この順番での公開のために、小型支払いを所定の送信側および受信側とリンクさせる際にＢＩＬＡＴＬＩＮＫが使用される。
【０３１２】
注文された挿入構成に使用される定義は簡単なものである。これらは、順次リンキングのみを使用し、Ｂ−ツリーやその他の洗練された方法は使用しない。これが適切な効率を生じながら十分である理由は、注文された待ち行列内に「より大型の」支払いのみが保持されるためであり、また、任意の１回で待ち行列登録されたものはそれほど多くないためである。
【０３１３】
１．外側ブロック
プログラムの最後を見ながら、ＴＲＡＮファイルの存在テストに注目する。所定の日付のＴＲＡＮファイルまたはＲＥＬＥＡＳＥＤＡＴＡファイルのどちらを使用してもよい。ＴＲＡＮファイルは、実行パラメータに特定された日付に利用可能である場合に使用される。そうでない場合は、ずっと小さなＲＥＬＥＡＳＤＡＴＡファイルが探される。必要とされる他のファイルは、上述したカレントリミットファイルと、ＭＩＮＩＧファイルである。この最後の小型ファイルは、単に、参加者に指定されたＣＨＩＰＳの４桁ＡＢＡ番号と、ＧＲＰまたはＲＧＮとも呼ばれる順次関連グループ番号との間の通信を提供するだけである。
【０３１４】
「メインループ」における外側ブロックに注目すると、メインループが、公開の分類されたファイルを読み出すことによって実行される。分類は、公開時間の順序で公開のファイルを生成する初期化時に実行される。ＴＲＡＮファイルが使用されると、このファイルは、ＴＲＡＮファイル記録にリンクを提供するための実ＳＮＮ番号も含む。そうでなければ、単純に処理および報告目的のために擬似ＳＳＮが生成される。
【０３１５】
次の動作は、支払いをフォーマットし、待ち行列登録することである。手続きＦＯＲＭＡＴＰＡＹＭＴとＩＮＳＥＲが呼び出される。ＩＮＳＥＲＴはかなり大きな重要な手続きである。その主要な機能は、支払いを、そのサイズに合った方法で待ち行列に登録し、次に、この支払いが大型であり、状況が許す場合には、２者間バッチングを開始することである。
【０３１６】
外側ブロックループの後半において、その他の２つの重要な手順が呼び出されているのがわかる。ＴＲＹＴＯＲＥＬＥＡＳＥは、より小さなサイズの、待ち行列登録された支払いの「公開」を試みる。手続きＣＨＥＣＫＢＡＴＣＨＥＳは、この時点で多者間バッチングが可能であるかどうかを調べる。
【０３１７】
Ｅ．メイン手順の階層
以下の概要に示すように、最も重要な手順は互いを呼び出す。
ＯＵＴＥＲＢＬＯＣＫ
ＦＯＲＭＡＴＰＡＹＭＴ
ＩＮＳＥＲＴ
ＭＡＫＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨ
ＲＥＭＯＶＥ
ＴＲＹＴＯＲＥＬＥＡＳＥ
ＧＡＬＥＳＨＡＰＬＥＹ
ＲＥＬＥＡＳＥＬＯＯＰ
ＲＥＬＥＡＳＥ
ＲＥＭＯＶＥ
ＰＯＳＩＴＩＯＮＣＨＥＣＫ
ＣＨＥＣＫＢＡＴＣＨＥＳ
ＢＡＴＣＨＲＥＬＥＡＳＥＡＢＬＥ
ＣＨＥＣＫＳＥＮＤＰＡＹＭＴ
ＣＨＥＣＫＳＥＮＤＰＡＹＭＴ
ＣＨＥＣＫＲＥＣＶＰＡＹＭＴ
ＣＨＥＣＫＲＥＣＶＰＡＹＭＴ
ＢＡＴＣＨＲＥＬＥＡＳＥ
ＲＥＬＥＡＳＥ
ＲＥＬＥＡＳＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨ
ＲＥＬＥＡＳＥＢＩＬＡＴＥＲＡＬＢＡＴＣＨ
ＲＥＬＥＡＳＥ
ＲＥＭＯＶＥ
ＲＥＭＯＶＥ
ＰＯＳＩＴＩＯＮＣＨＥＣＫ
ＰＲＩＮＴＳＵＭＭＡＲＹ
【０３１８】
Ｆ．重要な定義の概要
おそらく、最も重要な定義は、待ち行列挿入と除去に関するものであろう。
【０３１９】
ＧＥＴＳＹＳＬＩＮＫとＦＯＲＧＥＴＳＹＳＬＩＮＫは、ＰＡＹＭＥＮＴＱＵＥＵＥ配列内に実インデックスとして使用されるリンク値を作成および破棄するための定義である。従って、これらはＰＡＹＭＥＮＴＱＵＥＵＥ用のメモリ管理コードを表している。
【０３２０】
参加者の組のサブセットにかけて、効率的な方法でルーピングを行うために、様々なＭＡＳＫ定義が使用される。従って、これらの主な貢献は、プロセッサ時間を、より単純なコードを用いた場合よりも短縮することである。
【０３２１】
ＴＲＥＥＧＲＰ定義は、多者間バッチング中に構築された支払いのツリーにおいて、どのグループがその下に現れるかを追跡するためのものである。
【０３２２】
Ｇ．さらなる特徴
（１）バッチング遅延待ち行列。手続きＩＮＳＥＲＴ内で、大型支払いを遅延待ち行列内に挿入することにより、大型支払いの２者間バッチングが遅延する。この待ち行列の長さは公証４００支払いに維持される。
【０３２３】
多者間バッチングにおいて、大型支払いは、この遅延待ち行列内にある一方で、ヘルパー支払いとして使用されるが、その時点で、多者間でバッチングされるターゲット支払いとして用いられることはない。
【０３２４】
（２）ＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥおよびＣＨＥＣＫＢＡＴＣＨＥＳ内のＳＦＡＩＬ、ＲＦＡＩＬ。これは別の効率的な装置である。ＢＡＴＣＨＲＥＬＥＡＳＡＢＬＥ内の異なるターゲット支払い上で類似したツリー構築が実行されることを避けるために、構築が失敗した支払いのサイズに対する、ツリー構築の失敗の記録が保持される。ある支払いについて、所定の時間におけるヘルパー支払いのツリーが見つからない場合は、同じ時間において、より大型の支払いに対するツリーを探すことは意味がないということである。この前提は１００％有効ではないかもしれないが、ほぼ１００％有効であり、実質的に処理を減らすものである。
【０３２５】
（３）ＣＨＥＣＫＳＥＮＤＰＡＹＭＴとＣＨＥＣＫＲＥＣＶＰＡＹＭＴにおいて、ヘルパー支払いのツリーの構築は、各ＧＲＰ（参加者）におけるポジションがその参加者の限度内に収まる方法で進まなければならない。これは、所定のＧＲＰがツリー内に最大で１度生じることを要求することで最も簡単に行えるが、これで終りではない。より優れた結果を得るためには、規制をある程度緩和する。
（ａ）ＧＲＰは、所定のツリーブランチに、最高で１度現れることができる。この規制は、ＴＲＥＥＧＲＰ定義の使用によって実施される。
（ｂ）量ＤＮＥＸＴＰＯＳは、ＤＢＡＴＣＨＡＭＯＵＮＴからの値を用いて計算される。この配列は、提案されたバッチ内にある他の支払いの値を含んでいる。この方法で、所定のＧＲＰのポジション上にあるバッチの総合的な効果を事前に計算することができる。
【０３２６】
（４）ＣＨＥＣＫＳＥＮＤＰＡＹＭＴとＣＨＥＣＫＲＥＣＶＰＡＹＭＴにおいて、そのツリー内の次のブランチの選択は２つの局面において進行する。第１局面、フェーズゼロにおいて、ノードを残している（leaving）単一のブランチのみが試される。これは、ヘルパー支払いが後にターゲット支払いになるのであれば、最も公開が難しいという理論に基づいて、ヘルパー支払いを保護するためのものであり、また、最大限のヘルパー支払いを使用するためのものである。
【０３２７】
フェーズ０が失敗すると、フェーズ１が現れる。ここで、１つにまとめれば、当該のノードにおいてヘルパー支払いとして機能するのに十分なドル出来高を有する、いくつかのより小型の支払いを見つけようとする試みがなされる。このフェーズでは、連続的な支払いは、先行する支払いの大きさの半分よりも小さい（ＰＨＡＳＥ１ＦＡＣＴＯＲを参照）。これは、支払いサイズより幅広い範囲にかかるグループの衝撃を拡散させるためである。
【０３２８】
（５）ＢＩＬＡＴＢＡＴＣＨＦＡＣＴＯＲ。現在２と等しいこの要素は、「大型」支払いの２者間バッチングの開始を、ＢＩＬＡＴＢＡＴＣＨＦＡＣＴＯＲによって、フローキャップを超えるものに限定する。その結果、サイズが、フローキャップとその２倍のフローキャップの間の大きさを有するより多くの支払いが、多者間バッチングにおけるヘルパー支払いのサービスとして利用可能になる。あらゆる場合において、この要素が約２と等しい際に、スループットがピークに達するようである。
【０３２９】
（６）ゲール・シャプレイのアルゴリズム。小型支払いの公開は、バッチングを用いることなく進行する。送信側と受信側のポジションが許可すると、最も古い支払いに優先権を与えながら、支払いが公開される。所定の送信側と受信側を持つ小型支払いは、２者間待ち行列から、厳密なＦＩＦＯ注文において公開される。
【０３３０】
公開されるどの支払いが最も古いかに関する判断は、受信側と送信側の観点において異なる。この理由のために、送信側と受信側の両方にとって最適な、公開される支払いの選択を行うべく、ゲール・シャプレイのアルゴリズムが使用される。
【０３３１】
単純に最も古く最初のシステム待ち行列から支払いを公開しようと試みることにより、ほぼ同様の結果が得られる一方で、発明者達には、本方法は、プロセッサ時間がより経済的であるという信じるべき理由がある。
【０３３２】
（７）支払いの混乱。ゲール・シャプレイのアルゴリズム（上述）は、関連する支払いと限度のサイズに対して、送信側と受信側のポジションを実際に調べることにより、その支払いが公開されるかどうかを調べる。関連する間接費を削減するために、手段を考案するのは実行には十分に高額である。ＳＥＮＤＥＲＳＴＡＴＥマスクとＲＥＣＥＩＶＥＲＳＴＡＴＥマスクは、どの参加者が、送信または受信する支払いを持っているかを示す。現在可能な全ての公開が実施されてしまっているため、システムが新規の支払いの待ち行列登録を静かに待っている際に、ＳＥＮＤＥＲＳＴＡＴＥとＲＥＣＥＩＶＥＲＳＴＡＴＥの両方はゼロまたはヌルである。新規の支払いが待ち行列登録されると、送信側銀行を表すＳＥＮＤＥＲＳＴＡＴＥのビットが設定される。同様に、受信側銀行を表すＲＥＣＥＩＶＥＲＳＴＡＴＥのビットも設定される。
【０３３３】
ＧＡＬＥＳＨＡＰＬＥＹ手順が支払いに公開の印を付けると、さらなる支払いの公開を可能にするべく働く。この支払いの公開により、受信側銀行のポジションが上がるため、この手続きは、受信側銀行に関連してＳＥＮＤＥＲＳＴＡＴＥのビットを設定する。同様に、この手続きは、送信側銀行に関連してＲＥＣＥＩＶＥＲＳＴＡＴＥのビットも設定する。外側ブロックコードが、追加の支払い注文の待ち行列登録をする必要のない公開がなくなるまで、ＧＡＬＥＳＨＡＰＬＥＹを繰り返し呼び出す。この方法において、ある新規の支払いは、設定されたこれらの「状態」マスク内に多数のビットが存在する状態になり、外側ブロックコードが、新規の支払いを待ち行列登録するよう頼む前に、支払いが一斉に公開される。新しい支払いを待ち行列登録しようと試みる直前に、ＳＥＮＤＥＲＳＴＡＴＥとＲＥＣＥＩＶＥＲＳＴＡＴＥの両方がゼロにリセットされ、（もしあれば）混乱が終了する。
【０３３４】
本発明を、その好適な実施形態に関連して説明してきた。本発明の変形において、最小残高の値、オープニング残高、最大残高を、公開アルゴリズムのオペレーションに著しく影響せずに、各参加者について上方または下方に変更することが可能である。特に、各参加者についてのオープニング残高がゼロであった場合、アルゴリズムのオペレーションは同一であり、最小残高はプレファンド金額を下回り、最大残高はプレファンド金額と同額になる。このような場合、利用可能残高は、各々の場合において、残高とプレファンド金額の合計金額に等しくなる。従って、本発明は、残高、その最大および最小限度に関連した上述の規定に限定されるものではない。なぜなら、公開アルゴリズムのオペレーションを考慮する限り、これらは付加定数の範囲内において無関係なためである。本発明は、いかなる形でも好適な実施形態によって限定されることはない。
【０３３５】
当然、本発明がこれら特定に説明された形態以外の形態をとることも可能であり、本発明の範囲は請求項によってのみ決定される。
【図面の簡単な説明】
【図１】本発明の公開手順支払い処理の流れを示す。
【図１Ａ】本発明を実現するためのコンピュータシステムのブロック線図を示す。
【図２】本発明の多者間バッチングのツリー支払い構造を示す。
【図３】帳尻を合わせた公開エンジンの全体的な支払いメッセージの流れを示すフローチャートである。
【図４】手続きＣＨＥＣＫＳＥＮＤＰＡＹＭＴの処理フローを示すフローチャートである。
【図５】手続きＧＡＬＥＳＨＡＰＬＹの処理の流れを示すフローチャートである。

Claims

複数の金融機関参加者間の連続的な１日の支払い注文の最終決済処理のためのシステムであって、前記参加者の各々は支払い注文を電子的に送信するよう動作する関連した衛星コンピュータステーションを有し、そして前記衛星コンピュータステーションの各々は支払い受信側参加者および支払い送信側参加者として機能するよう動作するものであり、前記システムは、
（ａ）前記複数の参加者の衛星コンピュータステーションと電子的に通信を行って支払い注文を受信する中央コンピュータプロセッサと、
（ｂ）プレファンド残高口座内の複数の利用可能な残高を記憶する記憶デバイスとを有し、前記プレファンド残高口座の各々はある業務日の開始時における参加者の初回利用可能残高を含んでおり、
前記中央コンピュータプロセッサは、
送信側参加者として動作する前記衛星コンピュータステーションの１つから前記中央コンピュータプロセッサが支払い注文を受信すると、受信した支払い注文が、関連する送信側参加者の初回利用可能残高または当該支払い注文と関連する受信側参加者の初回利用可能残高の所定の割合未満のときには、当該支払い注文を「小型」に、それ以外であれば「大型」に分類し、
前記小型または大型支払い注文を、前記中央コンピュータプロセッサが管理する待ち行列に記憶し、
前記待ち行列に記憶されている小型支払い注文に対し、関連する送信側参加者と受信側参加者双方の利用可能残高がそれぞれの所定の限度内になったときには、前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記小型支払い注文の総額を、前記関連する送信側参加者の利用可能残高から引き落とし、そして前記関連する受信側参加者の利用可能残高へ入金し、そして
前記待ち行列に記憶されている大型支払い注文に対し、（ｉ）前記大型支払い注文と、前記大型支払い注文の送信側参加者の利用可能残高から引き落とすことで所定の最小限度よりも少ない利用可能残高になったときには前記大型支払い注文の送信側参加者とは別の少なくとも１つの送信側参加者からの、前記大型支払い注文の前記送信側参加者が前記受信側参加者であるヘルパー支払い注文であって、関連する送信側参加者および受信側参加者の双方の利用可能残高がそれぞれの所定の限度内にあるという、前記ヘルパー支払い注文の各々に対する決定に基づいて前記待ち行列から選択された前記ヘルパー支払い注文とを備えた第１の支払い注文の集合を形成することにより、（ii）前記大型支払い注文と、前記大型支払い注文の受信側参加者の利用可能残高に入金することで所定の最大限度よりも多い利用可能残高になったときには前記大型支払い注文の受信側参加者とは別の少なくとも１つの受信側参加者への、前記大型支払い注文の前記受信側参加者が前記送信側参加者であるヘルパー支払い注文であって、関連する送信側参加者および受信側参加者の双方の利用可能残高がそれぞれの所定の限度内にあるという、前記ヘルパー支払い注文の各々に対する決定に基づいて前記待ち行列から選択された前記ヘルパー支払い注文とを備えた第２の支払い注文の集合を形成することにより、そして（iii）前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記第１及び第２の支払い注文の集合の前記大型支払い注文と前記ヘルパー支払い注文とを有する多者間バッチ処理において、前記大型支払い注文の送信側参加者と前記ヘルパー支払い注文の送信側参加者の利用可能残高から各々の支払い注文の総額を引き落とし、そして、前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記多者間バッチ処理において、前記大型支払い注文の受信側参加者と前記ヘルパー支払い注文の受信側参加者の残高に各々の支払い注文の総額を入金することによって、多者間バッチ処理を連続的に行う、
よう動作するようプログラムされていることを特徴とするシステム。
前記中央コンピュータプロセッサが、
２者間バッチ処理において、前記大型支払い注文の関連する受信側参加者からの、前記大型支払い注文の総額に対して所定の範囲内の総額である、既に待ち行列登録されている第２支払い注文について前記待ち行列を検索することにより、大型支払い注文の金額を相殺し、
前記大型支払い注文と第２支払い注文の間の正味差額の金額の擬似支払い注文を生成し、そして
前記擬似支払い注文を前記待ち行列内に記憶する、
ようプログラムされていることを特徴とする請求項１に記載のシステム。
前記中央コンピュータプロセッサが、前記２者間バッチ処理の前記大型支払い注文の半分の大きさと前記大型支払い注文の２倍の大きさとの間の範囲内で、前記２者間バッチ処理において前記第２支払い注文を選択するようプログラムされていることを特徴とする請求項２に記載のシステム。
前記中央コンピュータプロセッサが、先入先出し待ち行列規則に従って前記待ち行列から公開する小型支払い注文を選択するようプログラムされており、前記公開された小型の支払い注文は、前記待ち行列から取り除かれて受信側参加者へ送られる小型支払い注文であることを特徴とする請求項１に記載のシステム。
前記中央コンピュータプロセッサが、ゲール・シャプレイのアルゴリズムに従って前記待ち行列から公開する小型支払い注文を選択するようプログラムされており、前記公開された小型支払い注文は、前記待ち行列から取り除かれて受信側参加者へ送られる小型支払い注文であることを特徴とする請求項４に記載のシステム。
前記中央コンピュータプロセッサが、支払い注文を小型または大型として分類する前記所定の割合を、前記関連する送信側参加者の初回利用可能残高と前記関連する受信側参加者の初回利用可能残高との小さい方の８０％に選択するようプログラムされていることを特徴とする請求項１に記載のシステム。
前記中央コンピュータプロセッサが、あらゆるプレファンド残高口座の利用可能残高が初回利用可能残高の２００％を越えないかゼロを下回らないように、所定の限度を設定するようプログラムされていることを特徴とする請求項１に記載のシステム。
前記小型支払い注文のカテゴリーが「中型」及び「超小型」支払い注文のサブカテゴリーに分割され、大型と中型支払い注文のみがヘルパー支払い注文になることができることを特徴とする請求項１に記載のシステム。
前記待ち行列は複数の待ち行列を有し、超小型、中型及び大型支払い注文が、各々の支払い注文のサイズに基づいて、前記複数の待ち行列のそれぞれに記憶されることを特徴とする請求項８に記載のシステム。
複数の金融機関参加者間の連続的な１日の支払い注文の最終決済処理のシステムを動作させる方法であって、前記参加者の各々は支払い注文を電子的に送信するよう動作する関連した衛星コンピュータステーションを有し、そして前記衛星コンピュータステーションの各々は支払い受信側参加者および支払い送信側参加者として機能するよう動作するものであり、前記システムは、前記複数の参加者の衛星コンピュータステーションと電子的に通信を行って支払い注文を受信する中央コンピュータプロセッサと、プレファンド残高口座内の複数の利用可能な残高を記憶する記憶デバイスとを有し、前記プレファンド残高口座の各々はある業務日の開始時における初回利用可能残高を含んでおり、前記中央コンピュータプロセッサが、
送信側参加者として動作する前記衛星コンピュータステーションの１つから前記中央コンピュータプロセッサが支払い注文を受信すると、受信した支払い注文が、関連する送信側参加者の初回利用可能残高または当該支払い注文と関連する受信側参加者の初回利用可能残高の所定の割合未満のときには、当該支払い注文を「小型」に、それ以外であれば「大型」に分類するステップと、
前記小型または大型支払い注文を、前記中央コンピュータプロセッサが管理する待ち行列に記憶するステップと、
前記待ち行列に記憶されている小型支払い注文に対し、関連する送信側参加者と受信側参加者双方の利用可能残高がそれぞれの所定の限度内になったときには、前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記小型支払い注文の総額を、前記関連する送信側参加者の利用可能残高から引き落とし、そして前記関連する受信側参加者の利用可能残高に入金する、前記送信するステップと、
前記待ち行列に記憶されている大型支払い注文に対し、（ｉ）前記大型支払い注文と、前記大型支払い注文の送信側参加者の利用可能残高から引き落とすことで所定の最小限度よりも少ない利用可能残高になったときには前記大型支払い注文の受信側参加者とは別の少なくとも１つの送信側参加者からの、前記大型支払い注文の前記送信側参加者が前記受信側参加者であるヘルパー支払い注文であって、関連する送信側参加者および受信側参加者の双方の利用可能残高がそれぞれの所定の限度内にあるという、前記ヘルパー支払い注文の各々に対する決定に基づいて前記待ち行列から選択された前記ヘルパー支払い注文とを備えた第１の支払い注文の集合を形成することにより、（ii）前記大型支払い注文と、前記大型支払い注文の受信側参加者の利用可能残高に入金することで所定の最大限度よりも多い利用可能残高になったときには前記大型支払い注文の受信側参加者とは別の少なくとも１つの受信側参加者への、前記大型支払い注文の前記受信側参加者が前記送信側参加者であるヘルパー支払い注文であって、関連する送信側参加者および受信側参加者の双方の利用可能残高がそれぞれの所定の限度内にあるという、前記ヘルパー支払い注文の各々に対する決定に基づいて前記待ち行列から選択された前記ヘルパー支払い注文とを備えた第２の支払い注文の集合を形成することにより、そして（iii）前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記第１及び第２の支払い注文の集合の前記大型支払い注文と前記ヘルパー支払い注文とを有する多者間バッチ処理において、前記大型支払い注文の送信側参加者と前記ヘルパー支払い注文の送信側参加者の利用可能残高から各々の支払い注文の総額を引き落とし、そして、前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記多者間バッチ処理において、前記大型支払い注文の受信側参加者と前記ヘルパー支払い注文の受信側参加者の残高に各々の支払い注文の総額を入金することによって、多者間バッチ処理を連続的に行うステップと、
を実行するようプログラムされていることを特徴とする方法。
前記中央コンピュータプロセッサが、
２者間バッチ処理において、前記大型支払い注文の関連する受信側参加者からの、前記大型支払い注文の総額に対して所定の範囲内の総額である、既に待ち行列登録されている第２支払い注文について前記待ち行列を検索することにより、大型支払い注文の金額を相殺するステップと、
前記大型支払い注文と第２支払い注文の間の正味差額の金額の擬似支払い注文を生成するステップと、
前記擬似支払い注文を前記待ち行列内に記憶するステップと、
を実行するようさらにプログラムされていることを特徴とする請求項１０に記載の方法。
前記中央コンピュータプロセッサが、前記２者間バッチ処理の前記大型支払い注文の半分の大きさと前記大型支払い注文の２倍の大きさとの間の範囲内で、前記２者間バッチ処理における前記第２支払い注文を選択するステップを実行するようさらにプログラムされていることを特徴とする請求項１１に記載の方法。
前記中央コンピュータプロセッサが、先入先出し待ち行列規則に従って前記待ち行列から公開する小型支払い注文を選択するステップを実行するようさらにプログラムされており、前記公開された小型支払い注文は、前記待ち行列から取り除かれて受信側参加者へ送られる小型支払い注文であることを特徴とする請求項１０に記載の方法。
前記中央コンピュータプロセッサが、ゲール・シャプレイのアルゴリズムに従って前記待ち行列から公開する小型支払い注文を選択するステップを実行するようさらにプログラムされており、前記公開された小型支払い注文は、前記待ち行列から取り除かれて受信側参加者へ送られる小型支払い注文であることを特徴とする請求項１３に記載の方法。
前記中央コンピュータプロセッサが、支払い注文を小型または大型として分類する前記所定の割合を、前記関連する送信側参加者の初回利用可能残高と前記関連する受信側参加者の初回利用可能残高との小さい方の８０％に選択するステップを実行するようさらにプログラムされていることを特徴とする請求項１０に記載の方法。
前記中央コンピュータプロセッサが、あらゆるプレファンド残高口座の利用可能残高が初回利用可能残高の２００％を越えないかゼロを下回らないように、所定の限度を設定するステップを実行するようさらにプログラムされていることを特徴とする請求項１０に記載の方法。
前記小型支払いの注文カテゴリーが、「中型」及び「超小型」のサブカテゴリーに分割され、大型と中型支払い注文のみがヘルパー支払い注文になることができることを特徴とする請求項１０に記載の方法。
前記待ち行列は複数の待ち行列を有し、超小型、中型及び大型支払い注文が、各々の支払い注文のサイズに基づいて、前記複数の待ち行列のそれぞれに記憶されることを特徴とする請求項１７に記載の方法。
実行されると、複数の金融機関参加者間における連続的な１日の支払い注文を最終決済処理の方法を遂行するシステムとなるプログラムコードを記憶するコンピュータ読み取り可能媒体であって、前記金融機関参加者の各々は支払い注文を電子的に送信するよう動作する関連した衛星コンピュータステーションを有し、そして前記衛星コンピュータステーションの各々は支払い受信側参加者および支払い送信側参加者として機能するよう動作するものであり、前記システムは前記プログラムコードを実行する中央コンピュータプロセッサを含み、前記中央コンピュータプロセッサは前記複数の参加者の衛星コンピュータステーションと電子的に通信を行って支払い注文を受信するものであり、前記システムはさらにプレファンド残高口座に複数の利用可能な残高を記憶する記憶デバイスを含み、前記プレファンド残高口座の各々はある業務日の開始時における初回利用可能な残高を含んでおり、前記方法は、
送信側参加者として動作する前記衛星コンピュータステーションの１つから前記中央コンピュータプロセッサが支払い注文を受信すると、受信した支払い注文が、関連する送信側参加者の初回利用可能残高または当該支払い注文と関連する受信側参加者の初回利用可能残高の所定の割合未満のときには、当該支払い注文を「小型」に、それ以外であれば「大型」に分類するステップと、
前記小型または大型支払い注文を、前記中央コンピュータプロセッサが管理する待ち行列に記憶するステップと、
前記待ち行列に記憶されている小型支払い注文に対し、関連する送信側参加者と受信側参加者双方の利用可能残高がそれぞれの所定の限度内になったときには、前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記小型支払い注文の総額を、前記関連する送信側参加者の利用可能残高から引き落とし、そして前記関連する受信側参加者の利用可能残高に入金する、前記送信するステップと、
前記待ち行列に記憶されている大型支払い注文に対し、（ｉ）前記大型支払い注文と、
前記大型支払い注文の送信側参加者の利用可能残高から引き落とすことで所定の最小限度よりも少ない利用可能残高になったときには前記大型支払い注文の受信側参加者とは別の少なくとも１つの送信側参加者からの、前記大型支払い注文の前記送信側参加者が前記受信側参加者であるヘルパー支払い注文であって、関連する送信側参加者および受信側参加者の双方の利用可能残高がそれぞれの所定の限度内にあるという、前記ヘルパー支払い注文の各々に対する決定に基づいて前記待ち行列から選択された前記ヘルパー支払い注文とを備えた第１の支払い注文の集合を形成することにより、（ii）前記大型支払い注文と、前記大型支払い注文の受信側参加者の利用可能残高に入金することで所定の最大限度よりも多い利用可能残高になったときには前記大型支払い注文の受信側参加者とは別の少なくとも１つの受信側参加者への、前記大型支払い注文の前記受信側参加者が前記送信側参加者であるヘルパー支払い注文であって、関連する送信側参加者および受信側参加者の双方の利用可能残高がそれぞれの所定の限度内にあるという、前記ヘルパー支払い注文の各々に対する決定に基づいて前記待ち行列から選択された前記ヘルパー支払い注文とを備えた第２の支払い注文の集合を形成することにより、そして（iii）前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記第１及び第２の支払い注文の集合の前記大型支払い注文と前記ヘルパー支払い注文とを有する多者間バッチ処理において、前記大型支払い注文の送信側参加者と前記ヘルパー支払い注文の送信側参加者の利用可能残高から各々の支払い注文の総額を引き落とし、そして、前記中央コンピュータプロセッサから前記記憶デバイスへメッセージを送信して、前記多者間バッチ処理において、前記大型支払い注文の受信側参加者と前記ヘルパー支払い注文の受信側参加者の残高に各々の支払い注文の総額を入金することによって、多者間バッチ処理を連続的に行うステップと、
を含むことを特徴とするコンピュータ読み出し可能媒体。
前記方法がさらに、
２者間バッチ処理において、前記大型支払い注文の関連する受信側参加者からの、前記大型支払い注文の総額に対して所定の範囲内の総額である、既に待ち行列登録されている第２支払い注文について前記待ち行列を検索することにより、大型支払い注文の金額を相殺するステップと、
前記大型支払い注文と第２支払い注文の間の正味差額の金額の擬似支払い注文を生成するステップと、
前記擬似支払い注文を該待ち行列内に記憶するステップとを含むことを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
前記選択的に相殺するステップにおいて、前記中央コンピュータプロセッサは、前記該２者間バッチ処理の前記大型支払い注文の半分の大きさと前記大型支払い注文の２倍の大きさとの間の範囲内で、前記２者間バッチ処理における前記第２支払い注文を選択することを特徴とする請求項２０に記載のコンピュータ読み取り可能媒体。
前記方法はさらに、前記中央コンピュータプロセッサが、先入先出し待ち行列規則に従って公開する小型支払い注文を選択するステップをさらに含み、前記公開された小型支払い注文は、前記待ち行列から取り除かれて受信側参加者へ送られる小型支払い注文であることを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
前記方法はさらに、前記中央コンピュータプロセッサが、ゲール・シャプレイのアルゴリズムに従って、前記待ち行列から公開する小型支払い注文を選択するステップをさらに含み、前記公開された小型支払い注文は、前記待ち行列から取り除かれて受信側参加者へ送られる小型支払い注文であることを特徴とする請求項２２に記載のコンピュータ読み取り可能媒体。
前記方法はさらに、前記中央コンピュータプロセッサが、支払い注文を小型または大型として分類するための所定の割合を、前記関連する送信側参加者の初回利用可能残高と前記関連する受信側参加者の初回利用可能残高との小さい方の８０％に選択するステップを含むことを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
前記方法はさらに、前記中央コンピュータプロセッサが、あらゆるプレファンド残高口座の利用可能残高が初回利用可能残高の２００％を越えないかゼロを下回らないように、所定の限度額を設定するステップを含むことを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
前記小型支払い注文のカテゴリーが、「中型」及び「超小型」のサブカテゴリーに分割され、大型と中型支払い注文のみが、ヘルパー支払い注文になることができることを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
前記待ち行列は複数の待ち行列を有し、超小型、中型及び大型支払い注文が、各々の支払い注文のサイズに基づいて、前記複数の待ち行列のそれぞれに記憶されることを特徴とする請求項２６に記載のコンピュータ読み取り可能媒体。