(57)【要約】【課題】本発明の課題は、レポ取引に要する事務負担を軽減することができる決済システムを提供することにある。【解決手段】本発明は、顧客の資金を管理する資金口座と顧客の債券を管理する債券口座とを記憶する記憶手段と、資金の取り手（ＳＣレポの場合には債券の取り手）側の端末装置からレポ取引に基づく約定情報を受信すると、受信した約定情報に基づいて約定明細及び決済明細を作成する作成手段と、作成した約定明細兼決済明細を資金の取り手と出し手（ＳＣレポの場合には債券の出し手）側の端末装置へ送信し、双方の端末装置から送信した約定明細兼決済明細に対する確認データを受信すると、約定明細兼決済明を確定する確定手段と、確定された決済明細に基づいて決済を実行する決済手段と、を備えることを特徴とする。【選択図】　図１
2004086360.tif 000002
【特許請求の範囲】
【請求項１】
顧客の資金を管理する資金口座と顧客の債券を管理する債券口座とを記憶する記憶手段と、
資金の取り手側の端末装置からレポ取引に基づく約定情報を受信すると、受信した約定情報に基づいて約定明細及び決済明細を作成する作成手段と、
作成した約定明細兼決済明細を資金の取り手側と出し手側の端末装置へ送信し、双方の端末装置から前記送信した約定明細兼決済明細に対する確認データを受信すると、約定明細兼決済明細を確定する確定手段と、
前記確定された決済明細に基づいて、資金の取り手側の債券口座から資金の出し手側の債券口座へ所定の債券残高を振り替えるとともに、資金の出し手側の資金口座から資金の取り手側の資金口座へ所定の金額を振り替えることにより決済を実行する決済手段と、
を備えることを特徴とする決済システム。
【請求項２】
資金の取り手側の債券口座に記憶された債券の銘柄の中から、所定の条件に従って、前記約定情報に基づき債券の銘柄を選定する債券銘柄選定手段をさらに備えることを特徴とする請求項１記載の決済システム。
【請求項３】
資金の取り手側の端末装置から第１の約定に対するネッティング指示を受信した場合には、第１の約定のスタート決済明細と、第１の約定のスタート決済日とエンド決済日が一致する第２の約定のエンド決済明細と、に基づいてネッティングを実行するネッティング手段をさらに備え、
前記決済手段は、前記実行されたネッティングの結果に基づいて決済を実行することを特徴とする請求項１または２記載の決済システム。
【請求項４】
約定の対象となった債券と該債券の対価として受け取った担保金とを対応付けて記憶する記憶手段と、
前記債券の時価を取得し、この取得した債券の時価を基に算出した債券価額と前記記憶手段に記憶された担保金とを比較し、この比較結果に基づいてマージンコールの発生の有無を判断するマージンコール判断手段と、
マージンコールが発生したと判断された場合には、マージンコール行使側の端末装置へマージンコールの発生を通知し、マージンコール行使側の端末装置からマージンコールを行使する旨を受信した場合には、マージンコールが行使される旨をマージンコールの被行使側の端末装置へ通知する通知手段と、
マージンコールの被行使側の端末装置からマージンコールの行使に対する確認を受信した場合には、マージンコール決済明細を作成してマージンコール決済を実行するマージンコール決済手段と、
前記マージンコール決済の実行結果に基づいて前記記憶手段の担保金を更新するとともに、前記約定のエンド決済明細を更新する更新手段と、
をさらに備えることを特徴とする請求項１から３いずれか記載の決済システム。
【請求項５】
顧客の端末装置とサーバとが通信可能に構成された決済システムにおいて、顧客間の決済を行う決済方法であって、
資金の取り手側の端末装置からレポ取引に基づく約定情報を受信すると、受信した約定情報に基づいて約定明細及び決済明細を作成し、
作成した約定明細兼決済明細を資金の取り手側と出し手側の端末装置へ送信し、双方の端末装置から前記送信した約定明細兼決済明細に対する確認データを受信すると、約定明細兼決済明細を確定し、
前記確定された決済明細に基づいて、資金の取り手側の債券口座から資金の出し手側の債券口座へ所定の債券残高を振り替えるとともに、資金の出し手側の資金口座から資金の取り手側の資金口座へ所定の金額を振り替えることにより決済を実行することを特徴とする決済方法。
【請求項６】
資金の取り手側の債券口座に記憶された債券の銘柄の中から、所定の条件に従って、前記約定情報に基づいて債券の銘柄を選定することを特徴とする請求項５記載の決済方法。
【請求項７】
資金の取り手側の端末装置から第１の約定に対するネッティング指示を受信した場合には、第１の約定のスタート決済明細と、第１の約定のスタート決済日とエンド決済日が一致する第２の約定のエンド決済明細と、に基づいてネッティングを実行し、
前記実行されたネッティングの結果に基づいて決済を実行することを特徴とする請求項５または６記載の決済方法。
【請求項８】
約定の対象となった債券と該債券の対価として受け取った担保金とを対応付けて記憶し、
前記債券の時価を取得し、この取得した債券の時価を基に算出した債券価額と前記記憶された担保金とを比較し、この比較結果に基づいてマージンコールの発生の有無を判断し、
マージンコールが発生したと判断した場合には、マージンコール行使側の端末装置へマージンコールの発生を通知し、マージンコール行使側の端末装置からマージンコールを行使する旨を受信した場合には、マージンコールが行使される旨をマージンコールの被行使側の端末装置へ通知し、
マージンコールの被行使側の端末装置からマージンコールの行使に対する確認を受信した場合には、マージンコール決済明細を作成してマージンコールの決済を実行し、
前記マージンコール決済の実行結果に基づいて前記記憶手段の担保金を更新するとともに、前記約定のエンド決済明細を更新することを特徴とする請求項５から７いずれか記載の決済方法。
【請求項９】
請求項５から８いずれか記載の決済方法をコンピュータで実行させるための情報処理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、債券の決済を代行する決済システム及び決済処理方法に関し、特に、金融機関の顧客間における債券の決済を代行する決済システム及び決済処理方法に関する。
【０００２】
【従来の技術】
従来、電子ベースの決済システムとして日本銀行金融ネットワークシステム（以下、「日銀ネット」という。）が知られている。日銀ネットは、日本銀行とその取引先金融機関との間の資金や国債の決済をオンライン処理することを目的として構築されたネットワークシステムである。この日銀ネット上では、様々な取引が行われており、いわゆるレポ取引もその対象となっている。
【０００３】
レポ取引とは、国債などに代表される信用力の高い債券と資金を、ある一定期間交換するというものである。具体的には、取引の開始日（スタート日）に、資金保有者と債券保有者との間で、約定時点における債券の時価に基づいて資金と債券を交換する。そして、取引の終了日（エンド日）に、債券保有者は、約定価格に「金利−貸借料率」と定義されるレポレート分の利子率が付された資金を資金保有者に返却し、資金保有者は、債券を債券保有者に返却する。このレポ取引のうち、「資金調達」的な性格のものは「ＧＣ（Ｇｅｎｅｒａｌ　Ｃｏｌｌａｔｅｒａｌ）レポ」、「債券貸借調達」的な性格のものは「ＳＣ（Ｓｐｅｃｉａｌ　Ｃｏｌｌａｔｅｒａｌ）レポ」と呼ばれている。ＧＣレポでは、取引される債券銘柄は特定されないが、ＳＣレポでは、債券銘柄は約定時点において決定される。
【０００４】
ここで、日銀ネットを利用した従来のＧＣレポ取引の流れについて図１９を用いて説明する。まず、資金の取り手（債券保有者）と資金の出し手（資金保有者）は、ＧＣレポ取引に関する約定を締結する。各ディーラは、例えば、「ＧＣ１００億円で」というかたちで約定する。
【０００５】
約定日において、資金の取り手側のフロントは、国債を選定する。例えば、約定金額が１００億円の場合には、５銘柄の国債を２０億円ずつ選定することができる。国債を選定すると、選定後の国債に基づいて約定内容を自社のフロントシステムに入力する。これにより、約定内容を確認するための約定コンファメーションが出力される。資金の取り手側は、この約定コンファメーションに基づいて、電話やＦＡＸにより約定内容を資金の出し手側に確認する。資金の出し手側のフロントは、国債の内容を確認すると、自社のフロントシステムに国債の銘柄ごとに約定を分割して入力する。
【０００６】
一方、資金の取り手側のバックは、フロントシステムから約定データがバックシステムへ転送される場合は確認を入力し、転送されない場合は約定内容を入力する。これにより、決済内容を確認するための個別明細書が出力される。資金の取り手側は、この個別明細書に基づいて、電話やＦＡＸにより決済内容を資金の出し手側に確認する。資金の出し手側のバックは、受取った個別明細書に基づいて決済明細を照合すると、自身のバックシステムに確認を入力する。
【０００７】
その後、取組日において、資金の取り手及び資金の出し手は、それぞれ日銀ネットに接続可能な日銀ネット用端末装置にて決済に必要なデータを入力する。もしくは、事前に決済データをバックシステムから送信している場合には、取組日当日に日銀ネットへ発信する。日銀ネットは、この入力データに基づいて、国債ＤＶＰ（Ｄｅｌｉｖｅｒｙ　Ｖｅｒｓｕｓ　Ｐａｙｍｅｎｔ）決済処理を実行する。この決済処理は、資金の取り手側による国債の準備通知、資金の出し手側による内容確認、資金の出し手側による資金準備通知、そして、国債と資金の交換という手順で行われる。
【０００８】
【発明が解決しようとする課題】
しかしながら、従来のような日銀ネットを介した決済方法では、以下に述べるような問題があった。
【０００９】
まず、従来の日銀ネットを利用した決済方法では、決済以外の処理については対象とされていないため、約定から決済に至るまでの処理、例えば、約定や決済の確認処理などは、資金の取り手側および出し手側それぞれのシステムで行われていた。よって、ディーラによる約定後、日銀ネットにて決済が実行されるまでの間に、約定内容や決済内容の各システムへの入力作業、電話やＦＡＸによる照合作業などが発生する結果、資金の取り手側および出し手側は、これらの事務作業に多大な労力や時間を要していた。
【００１０】
また、日銀ネットによる決済は、債券の銘柄単位で行うように構成されている。よって、上述したように、ディーラの約定時に「ＧＣ１００億円で」という約定をしていても、対象債券が「５銘柄２０億円ずつ」である場合には、約定が「ＧＣ２０億円×５」に分割され、実際の決済は５回行われることになることも大きな決済事務の負担となっていた。
【００１１】
そこで、本発明の課題は、レポ取引に要する事務負担を軽減することができる決済システム及び決済処理方法を提供することにある。
【００１２】
【課題を解決するための手段】
上記課題に鑑み、本発明は、資金の取り手による約定情報の入力と資金の出し手によるデータの確認入力に基づいて約定照合及び決済照合を行い、レポ取引の決済明細を自動的に作成して決済日に自動決済することを特徴とする。これによれば、資金の取り手は約定情報、資金の出し手はデータの確認をそれぞれ入力するだけで、自動的に決済が行われるので、レポ取引に要する事務作業を一挙に軽減することができるようになる。
【００１３】
また、現在、証券決済制度の見直しが行われ、決済リスクの削減のためにＳＴＰ化（ストレート・スルー・プロセッシング）や決済のＴ＋１化（約定してから決済までの期間を現状の３日間から１日間へ短縮する動き）の動きがある中で、本件システムによれば、レポ取引のＳＴＰ化を実現し、処理の迅速化を図ることにより決済のＴ＋１化を実現することができるようになる。
【００１４】
具体的には、本発明に係る決済システムは、顧客の資金を管理する資金口座と顧客の債券を管理する債券口座とを記憶する記憶手段と、資金の取り手側の端末装置からレポ取引に基づく約定情報を受信すると、受信した約定情報に基づいて約定明細及び決済明細を作成する作成手段と、作成した約定明細兼決済明細を資金の取り手側と出し手側の端末装置へ送信し、双方の端末装置から前記送信した約定明細兼決済明細に対する確認データを受信すると、決済明細の照合完了を確認し、約定明細兼決済明細を確定する確定手段と、前記確定された決済明細に基づいて、資金の取り手側の債券口座から資金の出し手側の債券口座へ所定の債券残高を振り替えるとともに、資金の出し手側の資金口座から資金の取り手側の資金口座へ所定の金額を振り替えることにより決済を実行する決済手段と、を備えることを特徴とする。
【００１５】
また、上記決済システムは、資金の取り手側の債券口座に記憶された債券の銘柄の中から、所定の条件に従って、前記約定情報に基づき債券の銘柄を選定する債券銘柄選定手段をさらに備えることを特徴とする。
【００１６】
また、上記決済システムは、資金の取り手側の端末装置から第１の約定に対するネッティング指示を受信した場合には、第１の約定のスタート決済明細と、第１の約定のスタート決済日とエンド決済日が一致する第２の約定のエンド決済明細と、に基づいてネッティングを実行する（ネッティングデータ及びネッティング明細を作成する）ネッティング手段をさらに備え、前記決済手段は、前記実行されたネッティングの結果（作成されたネッティング明細）に基づいて決済を実行することを特徴とする。
【００１７】
また、上記決済システムは、約定の対象となった債券と該債券の対価として受け取った担保金とを対応付けて記憶する記憶手段と、前記債券の時価を取得し、この取得した債券の時価を基に算出した債券価額と前記記憶手段に記憶された担保金とを比較し、この比較結果に基づいてマージンコールの発生の有無を判断するマージンコール判断手段と、マージンコールが発生したと判断した場合には、マージンコール行使側の端末装置へマージンコールの発生を通知し、マージンコール行使側の端末装置からマージンコールを行使する旨を受信した場合には、マージンコールが行使される旨をマージンコールの被行使側の端末装置へ通知する通知手段と、マージンコールの被行使側の端末装置からマージンコールの行使に対する確認を受信した場合には、マージンコール決済明細を作成してマージンコール決済を実行するマージンコール決済手段と、前記マージンコール決済の実行結果に基づいて前記記憶手段の担保金を更新するとともに、前記約定のエンド決済明細を更新する更新手段と、をさらに備えることを特徴とする。
【００１８】
また、本発明は、顧客の端末装置とサーバとが通信可能に構成された決済システムにおいて、顧客間の決済を行う決済方法であって、資金の取り手側の端末装置からレポ取引に基づく約定情報を受信すると、受信した約定情報に基づいて約定明細及び決済明細を作成し、作成した約定明細兼決済明細を資金の取り手側と出し手側の端末装置へ送信し、双方の端末装置から前記送信した約定明細兼決済明細に対する確認データを受信すると、約定明細兼決済明細を確定し、前記確定された決済明細に基づいて、資金の取り手側の債券口座から資金の出し手側の債券口座へ所定の債券残高を振り替えるとともに、資金の出し手側の資金口座から資金の取り手側の資金口座へ所定の金額を振り替えることにより決済を実行することを特徴とする。
【００１９】
また、上記決済方法は、資金の取り手側の債券口座に記憶された債券の銘柄の中から、所定の条件に従って、前記約定情報に基づいて債券の銘柄を選定することを特徴とする。
【００２０】
また、上記決済方法は、資金の取り手側の端末装置から第１の約定に対するネッティング指示を受信した場合には、第１の約定のスタート決済明細と、第１の約定のスタート決済日とエンド決済日が一致する第２の約定のエンド決済明細と、に基づいてネッティングを実行し（ネッティングデータ及びネッティング明細を作成し）、実行されたネッティングの結果（作成されたネッティング明細）に基づいて決済を実行することを特徴とする。
【００２１】
また、上記決済方法は、約定の対象となった債券と該債券の対価として受け取った担保金とを対応付けて記憶し、前記債券の時価を取得し、この取得した債券の時価を基に算出した債券価額と前記記憶された担保金とを比較し、この比較結果に基づいてマージンコールの発生の有無を判断し、マージンコールが発生したと判断した場合には、マージンコール行使側の端末装置へマージンコールの発生を通知し、マージンコール行使側の端末装置からマージンコールを行使する旨を受信した場合には、マージンコールが行使される旨をマージンコールの被行使側の端末装置へ通知し、マージンコールの被行使側の端末装置からマージンコールの行使に対する確認を受信した場合には、マージンコール決済明細を作成してマージンコールの決済を実行し、前記マージンコール決済の実行結果に基づいて前記記憶手段の担保金を更新するとともに、前記約定のエンド決済明細を更新することを特徴とする。
【００２２】
また、上記発明は、コンピュータに所定の機能を実現させるプログラムまたはそのプログラムを記録した記録媒体としても成立する。また、本明細書における手段は、ハードウェア、ソフトウェアまたはハードウェアおよびソフトウェアの組み合わせにより実現可能である。ハードウェアおよびソフトウェアの組み合わせによる実行は、例えば、所定のプログラムを有するコンピュータ・システムにおける実行が該当する。そして、１つの手段が有する機能が２つ以上のハードウェア、ソフトウェアまたはハードウェアおよびソフトウェアの組み合わせにより実現されても、２つ以上の手段の機能が１つのハードウェア、ソフトウェアまたはハードウェアおよびソフトウェアの組み合わせにより実現されても良い。
【００２３】
【発明の実施の形態】
次に、本発明の実施の形態について、図面を参照しつつ説明する。なお、本実施形態では、決済システムが、Ａ社とＢ社との間で約定されたＧＣレポ取引に適用される場合について説明する。なお、Ａ社とＢ社はともに金融機関Ｘの顧客であり、Ａ社は資金の取り手、Ｂ社は資金の出し手とする。
【００２４】
［決済システムの概略構成］
図１は、本実施形態に係る決済システムの機能及び全体スキームを説明するためのブロック図である。決済システム１０は、通信ネットワークを介してＡ社の端末装置３１及びＢ社の端末装置４１と通信可能に構成されている。また、ＩＦシステム２０、レポシステム２１、資金系システム２２、債券系システム２３等を備えている。
【００２５】
ＩＦシステム２０は、通信ネットワークを介してＡ社の端末装置３１及びＢ社の端末装置４１に対し約定データ、決済データ等を入出力可能に構成されている。
【００２６】
レポシステム２１は、レポ取引に関する決済を処理する機能を有し、約定ＤＢ２１１、決済ＤＢ２１２、ネッティングＤＢ２１３及び担保金管理ＤＢ２１４を備えている。約定ＤＢ２１１は、レポ取引に関する約定データ、例えば、原約定データとスタート時及びエンド時の決済明細を関連付けた約定明細を記憶している。決済ＤＢ２１２は、決済に関するデータ、例えば、スタート時及びエンド時の決済明細を記憶している。ネッティングＤＢ２１３は、ネッティングに関するデータ、例えば、ネッティング後の決済明細とネッティング前の原決済明細を関連付けたネッティング明細を記憶している。担保金管理ＤＢ２１４は、レポ取引の対象債券の時価と担保金を管理するためのものであり、債券と担保金とを対応付けて記憶している。なお、各ＤＢのデータ構造については、後述する。また、各ＤＢにおけるデータの管理や検索にはリレーショナルデータベース等の従来のデータベース技術を用いることができる。
【００２７】
資金系システム２２は、顧客の資金を管理する機能を有し、具体的には、Ａ社専用口座２２１とＢ社専用口座２２２とを有し、レポシステム２１から与えられる指示に従ってこれらの口座残高を増額または減額するとともに、その記録を格納する。
【００２８】
債券系システム２３は、顧客の債券を管理する機能を有し、具体的には、Ａ社債券口座２３１とＢ社債券口座２３２とを有し、レポシステム２１から与えられる指示に従ってこれらの債券残高を増額または減額するとともに、その記録を格納する。また、各債券口座２３１、２３２は、債券の銘柄、額面金額、債券の残存期間などを対応付けて記憶している。レポシステム２１は、この債券口座２３１、２３２のデータに基づいて、後述する銘柄選定処理を実行する。
【００２９】
［レポ取引の流れ］
次に、このように構成される決済システム１０における決済処理の全体の流れを説明する。図２は、決済システム１０による決済処理の全体の流れを示すフローチャートである。
【００３０】
まず、約定日（Ｈ１４．５．１５）に、資金の取り手である顧客Ａ社が、顧客Ｂ社との間の約定に基づいて端末装置３１から約定情報を入力すると、決済システム１０はこれを受け付ける（Ｓ２０１）。決済システム１０は、約定情報を受け付けると、債券銘柄の自動選定処理を実行する（Ｓ２０２）。
【００３１】
債券銘柄の自動選定処理とは、顧客Ａ社にて指定された所定の条件に従って、顧客Ａ社が保有する債券のうちＧＣレポ取引として使用可能な銘柄から担保銘柄を自動的に選定する処理である。従来、債券銘柄の選定作業においては、選定の都度、保有債券の銘柄別残高を確認して銘柄を選定する必要あった。しかし、上記担保銘柄の自動選定処理によれば、顧客は、選定条件を選択するだけでよいので、選定作業が一挙に軽減されるようになる。
【００３２】
次に、決済システム１０は、約定明細及び決済明細の作成処理とコンファメーション処理を実行する（Ｓ２０３）。具体的には、銘柄選定実施した約定データを基に決済データを作成し、約定明細兼決済明細として顧客Ａ社に通知する。顧客Ａ社から確認入力を受け取ると、顧客Ｂ社に約定明細兼決済明細として通知し、顧客Ｂ社から確認入力を受け取ると、約定成立の確認及び決済明細の照合完了を確認する。
【００３３】
コンファメーション処理が終了すると、決済システム１０は、ネッティング待ち状態へ移行する。そして、顧客Ａ社からネッティングが指定された場合には（Ｓ２０４；Ｙｅｓ）、ネッティング処理を実行する（Ｓ２０５）。なお、所定の期限までにネッティングが指定されない場合には（Ｓ２０４；Ｎｏ）、ネッティング処理を実行しない。
【００３４】
ネッティング処理とは、「決済日を同じくする債権・債務の決済金額の差額を受渡することにより、もとの債権・債務を決済することが出来たものとするペイメント・ネッティングを行うために」する処理である。ネッティング処理により、ネッティングデータが作成され、ネッティングデータをもとに作成されたネッティング明細（ネッティング後の決済明細とネッティング前の原決済明細を関連付けた明細）についてはネッティング・コンファメーションとしてＡ社とＢ社の端末装置に送信される。
【００３５】
そして、決済のスタート時（Ｈ１４．５．１８）には、スタート決済明細の自動決済処理を実行する（Ｓ２０６）。本発明では、レポの約定単位で決済処理を実行する。よって、ＧＣレポの場合、資金１００億に対して、国債５銘柄２０億円ずつが選定されている場合には、１００億円と国債５銘柄とが１回の決済として処理される。つまり、約定明細により資金調達１００億円に対してどの国債が選択されたかが紐付けされているため資金１００億円と国債５銘柄を一度に受渡処理することが可能となる。なお、ネッティング処理が実行された場合には、Ｓ２０５にて作成されたネッティングデータに基づいて作成されたネッティング後の決済明細に基づいて処理を実行する。
【００３６】
スタート時の決済処理が終了すると、決済システム１０は、マージンコールの管理を行う（Ｓ２０７）。マージンコールとは、取引期間中の債券時価の変動に応じて担保となる現金の過不足（マージン）を計算する、いわゆる値洗いを行い、マージンが拡大した場合には、追加的な担保の差入を要求することができるという制度である。マージンコール処理では、レポの対象となっている債券に対して、例えば毎営業日に値洗いを実施し、その債券価額と担保金と照合することによりマージンコールの発生を監視する。そして、マージンコールが発生した場合には、その旨を顧客に通知するとともに、マージンコールの行使が指示された場合には、マージンコール決済を実行して、その結果変動した担保金額をエンド決済明細に反映させる。従来、顧客は、自らマージンコールの発生を管理し、発生した場合には相手方へ請求するとともに、エンド決済明細の担保金額を更新、エンド決済明細の管理を実施していた。しかし、上記マージンコール処理によれば、マージンコールの発生通知に基づいて、マージンコールの実行を指示するだけでよいので、担保管理に要する作業を一挙に軽減することができるようになる。
【００３７】
そして、決済のエンド時（Ｈ１４．６．１８）には、エンド決済明細の自動決済処理を実行する（Ｓ２０８）。なお、上述したように、本発明では、ＧＣレポの約定単位で決済処理を実行する。よって、エンド決済明細の内容が１回の決済として処理される。なお、ネッティング処理が実行された場合には、ネッティング明細に基づいて処理を実行する。
【００３８】
［各ＤＢのデータ構造］
次に、各データベースのデータ構造について図３〜図６を用いて説明する。
【００３９】
図３は、約定ＤＢ２１１のデータ構造の一例を表す図である。約定ＤＢ２１１は、顧客の入力した約定情報に基づき、レポの対象となる債券銘柄を選定し、約定データとして記憶する。なお、約定データとは、図３に示したデータ項目の集合体のことをいい、約定明細は、約定データに基づいて作成された取引明細のことである。約定明細には固有の番号（Ｒｅｆ．Ｎｏ．）が割り当てられ、後述の処理により作成される決済明細等もこのＲｅｆ．Ｎｏ．により約定明細に関連づけられる。
【００４０】
図４は、決済ＤＢ２１２のデータ構造の一例を表す図である。決済ＤＢ２１２は、約定データの取引先及び取引相手先データから、顧客マスター（図示せず）にある決済口座データを抽出して作成された決済明細を記憶する。なお、決済データとは、図４に示したデータ項目の集合体のことをいい、決済明細は、決済データに基づいて作成された取引明細のことである。決済データは、決済日、自己及び相手方の決済口座（債券及び資金）及び受渡金額（債券及び資金のスタート額面及び金額とエンド額面及び金額）、を少なくとも有する。スタート決済明細及びエンド決済明細の受渡金額は、約定データにより算出される。また、決済口座データは、取引先名をキーとして、決済口座マスターを検索することで該当口座を選択することができる。
【００４１】
図５は、ネッティングＤＢ２１３のデータ構造の一例を表す図である。ネッティングＤＢ２１３は、決済ＤＢ２１２が保有している決済明細（原決済明細）のうち、同一決済日、同一銘柄のスタート決済明細とエンド決済明細をネッティングして作成されたネッティング明細を記憶する。なお、ネッティングデータとは、図５に示したデータ項目の集合体のことをいい、ネッティング明細は、ネッティングデータに基づいて作成された明細であり、既述のように「ネッティング前の原決済明細（複数）とネッティング後の決済明細（１つ）を紐付けている明細」である。ネッティング明細が両顧客によって確認されると、ネッティング後の決済明細を決済ＤＢ２１２に記憶し、原決済明細を決済ＤＢ２１２から削除する。このように、原決済明細とネッティング後の決済明細はネッティングＤＢにおいてネッティング明細として関連付けて記憶されているので、ネッティング後の明細が決済された場合には、原決済明細が決済されたものとして、約定ＤＢ２１１や顧客の端末装置３１、４１に対し、決済情報を還元することが出来る。
【００４２】
図６は、担保金管理ＤＢ２１４のデータ構造の一例を表す図である。担保金管理ＤＢ２１４は、外部システムより債券の時価を取得し、レポシステムにて管理するレポ取引の債券価額を算出するとともに、当該債券の対価として受取った（又は渡した）担保金と先に算出した債券価額を比較し、その差額をマージンとして管理するためのものである。具体的には、担保金管理ＤＢ２１４は、債券テーブルと担保金テーブルとから構成され、債券テーブルの債券価額と担保金テーブルの担保金とを比較し、その差額が一定の基準を超えた場合に、マージンコールとして行使権のある顧客側に通知がなされる。なお、債券時価とは、債券額面１００円あたりの債券価額であり、債券価額とは、額面金額×債券時価によって算出される一定額面の債券の価額である。
【００４３】
［スタート時の決済処理］
次に、決済システム１０によるＧＣレポ取引の決済処理（スタート時）の流れについて、図７を用いて詳細に説明する。まず、資金の取り手である顧客Ａ社は、レポ登録画面から約定情報を入力する。図８（Ａ）は、レポ登録画面の構成の一例を示す図である。レポ登録画面は、約定情報を入力する領域、決済口座情報を表示する領域、及び銘柄選定ロジックを選択する領域を備えている。顧客Ａ社のディーラは、約定情報を入力するとともに、ネッティングの有無や、銘柄の選定条件を指定することができる。顧客Ａ社のディーラが、「担保検索」を選択すると、顧客Ａ社の端末装置３１は、入力された約定情報及び選定条件を決済システム１０に送信する。なお、決済口座情報は、取引先名をキーに決済口座マスターを検索することで自動的に表示される。
【００４４】
図７に戻り説明を続ける。決済システム１０は、顧客Ａ社の端末装置３１から約定情報、選定条件を受け付ける（Ｓ７０１）。そして、銘柄選定ロジックが選択されている場合には（Ｓ７０２；Ｙｅｓ）、債券選定処理を実行する（Ｓ７０３）。なお、債券選定処理については、図９にて後述する。債券を選定すると、約定明細を作成し、約定ＤＢ２１１へ登録する（Ｓ７０４）。
【００４５】
決済システム１０は、約定データに決済情報を付加した決済データを基に決済明細を作成し、決済ＤＢ２１２へ仮登録する（Ｓ７０５）。その後決済システム１０は、約定明細兼決済明細として顧客Ａ社の端末装置３１へ送信する（Ｓ７０６）。顧客Ａ社の端末装置３１は、レポ明細画面に受信した約定明細兼決済明細を表示する。図８（Ｂ）は、レポ明細画面の構成の一例を示す図である。レポ明細画面は、対象約定内容を表示する領域と、選定された債券銘柄を表示する領域及び決済口座情報を表示する領域とを備えている。顧客Ａ社のディーラは、「確定／送信」を選択すると、確定データが送信され、「明細変更入力」や「更新」を選択すると、変更データが決済システム１０へ送信される。
【００４６】
決済システム１０は、顧客Ａ社の端末装置３１から確定データを受け取った場合には（Ｓ７０７；Ｙｅｓ）、約定明細兼決済明細を顧客Ｂ社の端末装置４１へ送信する（Ｓ７０８）。変更データを受け取った場合には（Ｓ７０７；Ｎｏ）、約定明細兼決済明細を修正する（Ｓ７０９）。
【００４７】
顧客Ｂ社の端末装置４１は、レポ明細画面に受信した約定明細兼決済明細を表示する。図８（Ｃ）は、レポ明細画面の構成の一例を示す図である。レポ明細画面は、対象約定内容を表示する領域と、選定された債券銘柄を表示する領域及び決済口座情報を表示する領域とを備えている。顧客Ｂ社のディーラは、「承認／送信」を選択すると、承認データが送信され、「不承認」や「自己決済口座変更入力」を選択すると、不承認データや変更データが決済システム１０へ送信される。
【００４８】
決済システム１０は、顧客Ｂ社の端末装置４１から承認データを受け取った場合には（Ｓ７１０；Ｙｅｓ）、約定成立の確認及び決済明細の照合完了を確認し（Ｓ７１１）、Ｓ７０５にて仮登録した決済明細を正式な決済明細として登録する（Ｓ７１３）。そして、決済システム１０は、約定のスタート日において、スタート決済明細に基づいてＤＶＰ処理を実行する（Ｓ７１４）。ＤＶＰ処理を実行すると、決済が完了した旨を、顧客Ａ社の端末装置３１と顧客Ｂ社の端末装置４１とへ通知する（Ｓ７１５）。
【００４９】
なお、上記処理では、決済明細の仮登録を行う場合について説明したが、決済明細を決済ＤＢに保存することなく顧客へ送信し、両方の顧客の確認入力を受けたことを確認して決済ＤＢに登録するようにしてもよい。
【００５０】
［銘柄選定処理］
次に、決済システム１０による銘柄選定の流れについて、図９を用いて詳細に説明する。図８（Ａ）にて示されたように、本実施形態の銘柄選定ロジックは、基本ロジックとオプションロジックとから構成されている。基本ロジックの選択は必須であり、オプションロジックの選択は任意である。利用者は、任意にこれらのロジックを組み合わせることができる。なお、前提条件として、売却やＳＣレポによる当日、翌日等の払出予定の銘柄については、その該当残高を予め控除して計算する。また、オプションロジックが選択された場合には、基本ロジックに優先して適用される。
【００５１】
ここで、各基本ロジックについて説明する（図８（Ａ）参照）。第１のロジックである銘柄数最小優先ロジックは、銘柄数が最小になるように残高の大きい銘柄から優先的に選定するように構成されているロジックである。第２のロジックである残高少銘柄優先ロジックは、残高の少ない銘柄から優先的に選定するように構成されているロジックである。第３のロジックである保有銘柄按分ロジックは、保有残高按分に応じて銘柄を選定するように構成されているロジックである。なお、上記ロジックにおいて、選択可能な銘柄が複数ある場合には、債券の残存期間（満期償還までの期間）が短いものを優先するように設定することができる。
【００５２】
次に、オプションロジックについて説明する。第１に、ネッティング優先ロジックは、スタート決済日付で自動作成されているエンド決済明細と最大限ペアオフ・ネッティングできるように銘柄を選定するように構成されている。第２に、一定保留分を考慮するロジックは、一定割合の残高を残して銘柄を選定するように構成されている。例えば、「最低限、各銘柄２０は残高を残す」と設定されている場合には、残高が２０よりも大きい銘柄が選定の対象となる。第３に、最割安銘柄優先ロジックは、最割安銘柄を優先的に選定するように構成されている。
【００５３】
なお、銘柄を選定するロジックは、上述したこれらのロジックに限られず、適宜これを設定することができる。
【００５４】
図９に戻り、説明を続ける。決済システム１０は、オプションロジックが指定されたか否かを判断し（Ｓ９０１）、オプションロジックが指定された場合には、資金の取り手の債券口座を参照し、指定されたロジックに従って処理を実行する（Ｓ９０２、Ｓ９０３、Ｓ９０４）。
【００５５】
続いて、決済システム１０は、基本ロジックが指定されているか否かを判断し（Ｓ９０５）、基本ロジックが指定されている場合には、資金の取り手の債券口座を参照し、指定された基本ロジックに従って処理を実行する（Ｓ９０６、Ｓ９０７、Ｓ９０８）。基本ロジックが指定されていない場合には、エラー処理を実行する。なお、オプションロジックの処理を実行した場合には、オプションロジックの処理結果に基づいて基本ロジックを実行する。
【００５６】
図１０は、銘柄選定処理の実行結果の一例を表す図である。同図によれば、選定されたロジックによって、選択された銘柄が異なることがわかる。ここでは、資金の取り手であるＡ社の債券口座に保有されている銘柄Ａ〜Ｒより債券２００を選択する場合について例示する。よって、例えば、基本ロジック１の場合には、基本ロジック１の条件を満たす銘柄Ａ、Ｂ、Ｃ、Ｄのうち、債券の残存期間が一番短い銘柄Ｃが選択されている（同図（＊１）参照）。他のロジックの場合にも、選択可能な銘柄が複数ある場合には、債券の残存期間が一番短い銘柄が選択されている（同図（＊２）（＊４）参照）。また、オプションロジック１と基本ロジック１の組み合わせの場合にも、選択可能な銘柄Ａ〜Ｉのうち債券の残存期間が一番短い銘柄Ｅが選択されている（同図（＊４）参照）。なお、オプションロジック２（図（＊５）参照）について「最低限、各銘柄２０は残高を残す」と設定されている場合には、銘柄Ｏ〜Ｒは対象外となる。また、ここでは、銘柄Ｆが最割安銘柄であるので、オプションロジック３について、銘柄Ｆが選択されている（図（＊６）参照）。
【００５７】
［ネッティング処理］
次に、決済システム１０によるネッティング処理の流れについて、図１１を用いて詳細に説明する。決済システム１０は、顧客Ａ社の端末装置３１から約定入力を受け付けると（Ｓ１１０１）、ネッティング指定がされたか否かを判断する（Ｓ１１０２）。ネッティング指定がされたと判断した場合には、ネッティング処理を実行する（Ｓ１１０３）。ここで、ネッティング処理の概要について図１２及び図１３を用いて説明する。
【００５８】
図１２及び図１３は、ネッティング処理の概要を説明するための図である。まず、図１２は、（１）Ａ社がＢ社よりＧＣレポで１００億円を調達する。この場合、スタート決済明細（Ｒｅｆ．０００１）は、資金の取り手であるＡ社から４銘柄（Ａ、Ｂ、Ｃ、Ｄ）計１００億円が、資金の出し手であるＢ社から資金１００億円が、それぞれ受け渡される内容となる。そして、エンド決済明細（Ｒｅｆ．０００１）は、資金の取り手であるＡ社から資金１０４億円が、資金の出し手であるＢ社から４銘柄（Ａ、Ｂ、Ｃ、Ｄ）計１００億円が、それぞれ受け渡される内容となる。
【００５９】
次に、上記約定のエンド決済日に、（２）Ａ社がＢ社よりＧＣレポで１００億円を再調達したものとする。この場合のスタート決済明細（Ｒｅｆ．００９９）は、資金の取り手であるＡ社から４銘柄（Ａ、Ｃ、Ｄ、Ｅ）計１００億円が、資金の出し手であるＢ社から資金１００億円が、それぞれ受け渡される内容となる。そして、エンド決済明細（Ｒｅｆ．００９９）は、資金の取り手であるＡ社から資金１０５億円が、資金の出し手であるＢ社から４銘柄（Ａ、Ｃ、Ｄ、Ｅ）計１００億円が、それぞれ受け渡される内容となる。
【００６０】
Ａ社がスタート決済明細（Ｒｅｆ．００９９）に対してネッティングを入力すると、エンド決済明細（Ｒｅｆ．０００１）とスタート決済明細（Ｒｅｆ．００９９）とがネッティング処理の対象となる。
【００６１】
そして、図１３は、ネッティング処理の結果を示している。エンド決済明細（Ｒｅｆ．０００１）とスタート決済明細（Ｒｅｆ．００９９）とがネッティングされ、その結果に基づいて、ネッティング明細が作成される。ネッティング明細では、資金の取り手であるＡ社から資金４億円と、２銘柄（Ｃ、Ｅ）計４０億円が、資金の出し手であるＢ社から２銘柄（Ａ、Ｂ）計４０億円が、それぞれ受け渡される内容となっていることがわかる。
【００６２】
図１１に戻り説明を続ける。決済システム１０は、ネッティング処理を実行すると、ネッティング明細を顧客Ａ社の端末装置３１に通知する（Ｓ１１０４）。顧客Ａ社の端末装置３１は、ネッティング・コンファメーション画面に受信したネッティング明細を表示する。図１４は、ネッティング・コンファメーション画面の構成の一例を示す図である。ネッティング・コンファメーション画面は、ネッティング後の決済明細を表示する領域と、原決済明細を表示する領域とを備えている。顧客Ａ社の担当者は、「確認」を選択すると、確認データが決済システム１０へ送信される。
【００６３】
決済システム１０は、顧客Ａ社の端末装置３１から確認データを受け取った場合には（Ｓ１１０５；Ｙｅｓ）、ネッティング明細を顧客Ｂ社の端末装置４１へ送信する（Ｓ１１０７）。顧客Ｂ社の端末装置４１は、図１４に示したようなネッティング・コンファメーション画面に受信したネッティング明細を表示する。顧客Ｂ社の担当者は、「確認」を選択すると、承認データが決済システム１０へ送信される。決済システム１０は、顧客Ｂ社の端末装置４１から確認データを受け取った場合には（Ｓ１１０８；Ｙｅｓ）、ネッティングの成立を確認し（Ｓ１１０９）、ネッティング明細をネッティングＤＢに登録するとともに（Ｓ１１１１）、ネッティング後の決済明細を決済ＤＢに登録し、原決済明細を決済ＤＢより削除する（Ｓ１１１２）。そして、決済システム１０は、決済日に、ＤＶＰ（ＦＯＰ（Ｆｒｅｅ　Ｏｆ　Ｐａｙｍｅｎｔ））処理を実行する（Ｓ１１１３）。なお、ＦＯＰ処理とは、例えばネッティングをした結果として資金の受渡がゼロとなった場合に、債券の受渡のみを行い、資金の受渡を伴わない債券の振替処理のことをいう。
【００６４】
［マージンコール処理］
次に、決済システム１０によるマージンコール処理の流れについて、図１５を用いて詳細に説明する。
【００６５】
決済システム１０は、債券の時価を管理する債券時価データベース（図示せず）から債券の時価情報を取得し、取得した時価情報に基づいて担保金管理ＤＢ２１４の債券テーブルの債券価額を更新する（Ｓ１５０１）。そして、債券テーブルの債券価額と、担保金テーブルの担保金とを比較する（Ｓ１５０２）。この比較結果に基づいて、マージンコールの発生の有無を判断し（Ｓ１５０３）、マージンコールが発生したと判断する場合には、マージンコールが発生した旨をマージンコールの行使権者側顧客へ通知する（Ｓ１５０４）。
【００６６】
マージンコール発生の通知を受けた端末装置は、マージンコールの発生をメッセージによりリアルタイムで通知することができる。図１６（Ａ）は、マージンコール発生の通知を受けた端末装置の画面の例を示す図である。端末装置は、メッセージの確認が選択されると、マージンコールの明細を決済システム１０から取得してマージンコール対象一覧画面に表示する。マージンコール対象一覧画面は、マージンコールの明細内容を表示する領域を備えている。マージンコール行使権者側顧客は、「マージンコール実行」を選択すると、実行指示データが決済システム１０に送信される。
【００６７】
決済システム１０は、実行指示データを受け付けると（Ｓ１５０５）、マージンコールの実行を被行使権者側顧客へ通知する（Ｓ１５０６）。マージンコール実行の通知を受けた端末装置は、マージンコールの実行をメッセージによりリアルタイムで通知することができる。
【００６８】
図１６（Ｂ）は、マージンコール実行の通知を受けた端末装置の画面の例を示す図である。端末装置は、メッセージの確認が選択されると、マージンコールの明細を決済システム１０から取得してマージンコール実行通知画面に表示する。マージンコール実行通知画面は、マージンコールの実行内容を表示する領域を備えている。マージンコール被行使権者側顧客は、「マージンコール確認」を選択すると、確認データが決済システム１０に送信される。
【００６９】
決済システム１０は、確認データを受け付けると（Ｓ１５０７）、マージンコール決済明細を作成し、決済明細ＤＢへ登録する（Ｓ１５０８）。そして、決済システム１０は、マージンコール決済処理を実行する（Ｓ１５１０）。つまり、債券の価額と担保金とが一致するように、債券の価額と担保金との差額分が、被行使権者側顧客の資金口座から行使権者側顧客の資金口座へ振り替えられる。
マージンコール決済処理が終了すると、マージンコール決済完了を行使権者側顧客と被行使権者側顧客へそれぞれ通知する（Ｓ１５１１）。そして、担保金管理ＤＢ２１４の担保金を更新する（Ｓ１５１２）。また、決済明細ＤＢ２１２のエンド決済明細を更新する（Ｓ１５１３）。つまり、エンド決済明細のエンド金額を更新する。
【００７０】
図１７は、マージンコール決済処理の結果の例を示す図である。まず、（１）取引前の状態として、Ａ社の債券残高は額面５００円（時価５００円）、Ｂ社の資金口座は１０００円となっている。ここで、「ＧＣレポ５００円」で約定され、取引が開始されたものとする。
【００７１】
（２）取引のスタート時には、Ｂ社の資金口座からＡ社の資金口座へ５００円が、Ａ社の債券口座からＢ社の債券口座へ債券額面５００円が、それぞれ移動している。
【００７２】
その後、（３）債券の時価が額面５００円から４５０円に下がることにより、マージンコールが発生し、Ｂ社がマージンコールを行使している。その結果、Ａ社の資金口座からＢ社の資金口座へ５０円が移動している。なお、マージンコールの発生は、Ｂ社に自動的に通知されるので、Ｂ社は、マージンコールを行使するか否かを決定するだけでよい。
【００７３】
さらにその後、（３）債券の時価が額面４５０円から５５０円に上がることにより、再度マージンコールが発生し、Ａ社がマージンコールを行使している。その結果、Ｂ社の資金口座からＡ社の資金口座へ１００円が移動している。この際、マージンコールの発生は、Ａ社に自動的に通知されるので、Ａ社もまた、マージンコールを行使するか否かを決定するだけでよい。
【００７４】
そして、（５）取引のエンド時には、Ａ社の資金口座からＢ社の資金口座へ５５０円が、Ｂ社の債券口座からＡ社の債券口座へ債権額面５５０円が、それぞれ移動している。なお、マージンコールが行使されるたびに、エンド決済明細は自動的に更新されているので、Ａ社及びＢ社は、エンド決済明細を管理することなく取引を完了させることができる。
【００７５】
［エンド時の決済処理］
次に、決済システム１０によるエンド時の決済処理の流れについて、図１８を用いて詳細に説明する。決済システム１０は、処理日がエンド決済明細のエンド日に該当する場合には（Ｓ１８０１；Ｙｅｓ）、そのエンド決済明細がネッティングされているか否かを判断する（Ｓ１８０２）。そして、ネッティングされている場合には（Ｓ１８０２；Ｙｅｓ）、既述のネッティング処理を実行し（Ｓ１８０３）、ネッティングされていない場合には（Ｓ１８０１；Ｎｏ）、エンド決済明細に従ったグロス処理を実行する（Ｓ１８０４）。そして、決済が終了すると、決済が完了した旨を、資金の取り手と資金の出し手にそれぞれ通知する。
［その他の実施形態］
上記各実施形態は、本発明を説明するための例示であり、本発明をこれらの実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱しない限り、さまざまな形態で実施することができる。また、上記フローチャートでは、リクエストメッセージの受信処理をシーケンシャルに説明したが、動作に矛盾が生じない限り、処理の順序を入れ替えまたは並行動作するように構成しても良い。
【００７６】
例えば、上記実施形態では、本発明をＧＣレポに適用する場合について説明したが、ＳＣレポに適用してもよい。この場合、自動銘柄選定機能はＧＣの場合だけ使用する機能とし、ＳＣの場合にはＳＣ（銘柄入力）等とすることにより手入力で銘柄を選定可能に構成してもよい。また、ＧＣレポに適用する上記実施形態では、資金の取り手が約定入力するものとしたが、ＳＣレポの場合には、債券の取り手（資金の出し手）が約定入力するように構成してもよい。
【００７７】
【発明の効果】
本発明によれば、レポ取引における約定から決済までの一連の事務をＳＴＰ化し、約定入力，約定明細兼決済明細の確認、マージンコールの行使、ネッティングの実行・確認など都度の確認入力を行うのみで処理することが可能となり、事務処理の効率化、オペレーションリスクの削減が図れるとともに、決済制度改革により指向されている証券決済のＴ＋１化へも対応できるようになる。
【図面の簡単な説明】
【図１】本実施形態に係る決済システムの機能及び全体スキームを説明するためのブロック図である。
【図２】決済システム１０による決済処理の全体の流れを示すフローチャートである。
【図３】レポＤＢ２１１のデータ構造の一例を表す図である。
【図４】決済ＤＢ２１２のデータ構造の一例を表す図である。
【図５】ネッティングＤＢ２１３のデータ構造の一例を表す図である。
【図６】担保金管理ＤＢ２１４のデータ構造の一例を表す図である。
【図７】決済システム１０による決済処理（スタート時）の流れを示すフローチャートである。
【図８】ＧＣレポ登録画面等の構成の一例を示す図である。
【図９】決済システム１０による銘柄選定の流れを示すフローチャートである。
【図１０】銘柄選定処理の実行結果の一例を表す図である。
【図１１】決済システム１０によるネッティング処理の流れを示すフローチャートである。
【図１２】ネッティング処理の概要を説明するための図である。
【図１３】ネッティング処理の概要を説明するための図である。
【図１４】ネッティング・コンファメーション画面の構成の一例を示す図である。
【図１５】決済システム１０によるマージンコール処理の流れを示すフローチャートである。
【図１６】マージンコール発生の通知を受けた端末装置の画面の例を示す図である。
【図１７】マージンコール決済処理の結果の例を示す図である。
【図１８】決済システム１０によるエンド時の決済処理の流れを示すフローチャートである。
【図１９】日銀ネットを利用した従来のＧＣレポ取引の流れを示す図である。
【符号の説明】
１０…決済システム
２０…ＩＦシステム
２１…レポシステム
２２…資金系システム
２３…債券系システム
３０…顧客Ａ社
４０…顧客Ｂ社
【図１】
2004086360.tif 000003
【図２】
2004086360.tif 000004
【図３】
2004086360.tif 000005
【図４】
2004086360.tif 000006
【図５】
2004086360.tif 000007
【図６】
2004086360.tif 000008
【図７】
2004086360.tif 000009
【図８】
2004086360.tif 000010
【図９】
2004086360.tif 000011
【図１０】
2004086360.tif 000012
【図１１】
2004086360.tif 000013
【図１２】
2004086360.tif 000014
【図１３】
2004086360.tif 000015
【図１４】
2004086360.tif 000016
【図１５】
2004086360.tif 000017
【図１６】
2004086360.tif 000018
【図１７】
2004086360.tif 000019
【図１８】
2004086360.tif 000020
【図１９】
2004086360.tif 000021