JP2004086360A

JP2004086360A - Settlement system and settlement processing method

Info

Publication number: JP2004086360A
Application number: JP2002244075A
Authority: JP
Inventors: Hiroyuki Nakamura; 中村　裕之; Taichi Miura; 三浦　太一
Original assignee: UFJ Bank Ltd
Current assignee: MUFG Bank Ltd
Priority date: 2002-08-23
Filing date: 2002-08-23
Publication date: 2004-03-18

Abstract

<P>PROBLEM TO BE SOLVED: To provide a settlement system for lightening clerical workload needed for a repurchase transaction. <P>SOLUTION: This system is characterized by having a storage means for storing a fund account for managing funds of a customer and a bond account for managing bonds of the customer, a preparation means for preparing agreement details and settlement details based on received agreement information when the agreement information based on a repurchase transaction is received from a terminal device on the side of a fund taker (a bond taker in the case of a special colateral (SC) repurchase), a determination means for transmitting the prepared agreement details-cum-settlement details to terminal devices on the sides of the taker and offerer of the fund (a bond offerer in the case of SC repurchase) and determining the agreement details-cum-settlement details on receiving confirmation data on the agreement details-cum-settlement details transmitted from the terminal devices on both sides, and a settlement means for executing settlement based on the determined settlement details. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、債券の決済を代行する決済システム及び決済処理方法に関し、特に、金融機関の顧客間における債券の決済を代行する決済システム及び決済処理方法に関する。
【０００２】
【従来の技術】
従来、電子ベースの決済システムとして日本銀行金融ネットワークシステム（以下、「日銀ネット」という。）が知られている。日銀ネットは、日本銀行とその取引先金融機関との間の資金や国債の決済をオンライン処理することを目的として構築されたネットワークシステムである。この日銀ネット上では、様々な取引が行われており、いわゆるレポ取引もその対象となっている。
【０００３】
レポ取引とは、国債などに代表される信用力の高い債券と資金を、ある一定期間交換するというものである。具体的には、取引の開始日（スタート日）に、資金保有者と債券保有者との間で、約定時点における債券の時価に基づいて資金と債券を交換する。そして、取引の終了日（エンド日）に、債券保有者は、約定価格に「金利−貸借料率」と定義されるレポレート分の利子率が付された資金を資金保有者に返却し、資金保有者は、債券を債券保有者に返却する。このレポ取引のうち、「資金調達」的な性格のものは「ＧＣ（Ｇｅｎｅｒａｌ　Ｃｏｌｌａｔｅｒａｌ）レポ」、「債券貸借調達」的な性格のものは「ＳＣ（Ｓｐｅｃｉａｌ　Ｃｏｌｌａｔｅｒａｌ）レポ」と呼ばれている。ＧＣレポでは、取引される債券銘柄は特定されないが、ＳＣレポでは、債券銘柄は約定時点において決定される。
【０００４】
ここで、日銀ネットを利用した従来のＧＣレポ取引の流れについて図１９を用いて説明する。まず、資金の取り手（債券保有者）と資金の出し手（資金保有者）は、ＧＣレポ取引に関する約定を締結する。各ディーラは、例えば、「ＧＣ１００億円で」というかたちで約定する。
【０００５】
約定日において、資金の取り手側のフロントは、国債を選定する。例えば、約定金額が１００億円の場合には、５銘柄の国債を２０億円ずつ選定することができる。国債を選定すると、選定後の国債に基づいて約定内容を自社のフロントシステムに入力する。これにより、約定内容を確認するための約定コンファメーションが出力される。資金の取り手側は、この約定コンファメーションに基づいて、電話やＦＡＸにより約定内容を資金の出し手側に確認する。資金の出し手側のフロントは、国債の内容を確認すると、自社のフロントシステムに国債の銘柄ごとに約定を分割して入力する。
【０００６】
一方、資金の取り手側のバックは、フロントシステムから約定データがバックシステムへ転送される場合は確認を入力し、転送されない場合は約定内容を入力する。これにより、決済内容を確認するための個別明細書が出力される。資金の取り手側は、この個別明細書に基づいて、電話やＦＡＸにより決済内容を資金の出し手側に確認する。資金の出し手側のバックは、受取った個別明細書に基づいて決済明細を照合すると、自身のバックシステムに確認を入力する。
【０００７】
その後、取組日において、資金の取り手及び資金の出し手は、それぞれ日銀ネットに接続可能な日銀ネット用端末装置にて決済に必要なデータを入力する。もしくは、事前に決済データをバックシステムから送信している場合には、取組日当日に日銀ネットへ発信する。日銀ネットは、この入力データに基づいて、国債ＤＶＰ（Ｄｅｌｉｖｅｒｙ　Ｖｅｒｓｕｓ　Ｐａｙｍｅｎｔ）決済処理を実行する。この決済処理は、資金の取り手側による国債の準備通知、資金の出し手側による内容確認、資金の出し手側による資金準備通知、そして、国債と資金の交換という手順で行われる。
【０００８】
【発明が解決しようとする課題】
しかしながら、従来のような日銀ネットを介した決済方法では、以下に述べるような問題があった。
【０００９】
まず、従来の日銀ネットを利用した決済方法では、決済以外の処理については対象とされていないため、約定から決済に至るまでの処理、例えば、約定や決済の確認処理などは、資金の取り手側および出し手側それぞれのシステムで行われていた。よって、ディーラによる約定後、日銀ネットにて決済が実行されるまでの間に、約定内容や決済内容の各システムへの入力作業、電話やＦＡＸによる照合作業などが発生する結果、資金の取り手側および出し手側は、これらの事務作業に多大な労力や時間を要していた。
【００１０】
また、日銀ネットによる決済は、債券の銘柄単位で行うように構成されている。よって、上述したように、ディーラの約定時に「ＧＣ１００億円で」という約定をしていても、対象債券が「５銘柄２０億円ずつ」である場合には、約定が「ＧＣ２０億円×５」に分割され、実際の決済は５回行われることになることも大きな決済事務の負担となっていた。
【００１１】
そこで、本発明の課題は、レポ取引に要する事務負担を軽減することができる決済システム及び決済処理方法を提供することにある。
【００１２】
【課題を解決するための手段】
上記課題に鑑み、本発明は、資金の取り手による約定情報の入力と資金の出し手によるデータの確認入力に基づいて約定照合及び決済照合を行い、レポ取引の決済明細を自動的に作成して決済日に自動決済することを特徴とする。これによれば、資金の取り手は約定情報、資金の出し手はデータの確認をそれぞれ入力するだけで、自動的に決済が行われるので、レポ取引に要する事務作業を一挙に軽減することができるようになる。
【００１３】
また、現在、証券決済制度の見直しが行われ、決済リスクの削減のためにＳＴＰ化（ストレート・スルー・プロセッシング）や決済のＴ＋１化（約定してから決済までの期間を現状の３日間から１日間へ短縮する動き）の動きがある中で、本件システムによれば、レポ取引のＳＴＰ化を実現し、処理の迅速化を図ることにより決済のＴ＋１化を実現することができるようになる。
【００１４】
具体的には、本発明に係る決済システムは、顧客の資金を管理する資金口座と顧客の債券を管理する債券口座とを記憶する記憶手段と、資金の取り手側の端末装置からレポ取引に基づく約定情報を受信すると、受信した約定情報に基づいて約定明細及び決済明細を作成する作成手段と、作成した約定明細兼決済明細を資金の取り手側と出し手側の端末装置へ送信し、双方の端末装置から前記送信した約定明細兼決済明細に対する確認データを受信すると、決済明細の照合完了を確認し、約定明細兼決済明細を確定する確定手段と、前記確定された決済明細に基づいて、資金の取り手側の債券口座から資金の出し手側の債券口座へ所定の債券残高を振り替えるとともに、資金の出し手側の資金口座から資金の取り手側の資金口座へ所定の金額を振り替えることにより決済を実行する決済手段と、を備えることを特徴とする。
【００１５】
また、上記決済システムは、資金の取り手側の債券口座に記憶された債券の銘柄の中から、所定の条件に従って、前記約定情報に基づき債券の銘柄を選定する債券銘柄選定手段をさらに備えることを特徴とする。
【００１６】
また、上記決済システムは、資金の取り手側の端末装置から第１の約定に対するネッティング指示を受信した場合には、第１の約定のスタート決済明細と、第１の約定のスタート決済日とエンド決済日が一致する第２の約定のエンド決済明細と、に基づいてネッティングを実行する（ネッティングデータ及びネッティング明細を作成する）ネッティング手段をさらに備え、前記決済手段は、前記実行されたネッティングの結果（作成されたネッティング明細）に基づいて決済を実行することを特徴とする。
【００１７】
また、上記決済システムは、約定の対象となった債券と該債券の対価として受け取った担保金とを対応付けて記憶する記憶手段と、前記債券の時価を取得し、この取得した債券の時価を基に算出した債券価額と前記記憶手段に記憶された担保金とを比較し、この比較結果に基づいてマージンコールの発生の有無を判断するマージンコール判断手段と、マージンコールが発生したと判断した場合には、マージンコール行使側の端末装置へマージンコールの発生を通知し、マージンコール行使側の端末装置からマージンコールを行使する旨を受信した場合には、マージンコールが行使される旨をマージンコールの被行使側の端末装置へ通知する通知手段と、マージンコールの被行使側の端末装置からマージンコールの行使に対する確認を受信した場合には、マージンコール決済明細を作成してマージンコール決済を実行するマージンコール決済手段と、前記マージンコール決済の実行結果に基づいて前記記憶手段の担保金を更新するとともに、前記約定のエンド決済明細を更新する更新手段と、をさらに備えることを特徴とする。
【００１８】
また、本発明は、顧客の端末装置とサーバとが通信可能に構成された決済システムにおいて、顧客間の決済を行う決済方法であって、資金の取り手側の端末装置からレポ取引に基づく約定情報を受信すると、受信した約定情報に基づいて約定明細及び決済明細を作成し、作成した約定明細兼決済明細を資金の取り手側と出し手側の端末装置へ送信し、双方の端末装置から前記送信した約定明細兼決済明細に対する確認データを受信すると、約定明細兼決済明細を確定し、前記確定された決済明細に基づいて、資金の取り手側の債券口座から資金の出し手側の債券口座へ所定の債券残高を振り替えるとともに、資金の出し手側の資金口座から資金の取り手側の資金口座へ所定の金額を振り替えることにより決済を実行することを特徴とする。
【００１９】
また、上記決済方法は、資金の取り手側の債券口座に記憶された債券の銘柄の中から、所定の条件に従って、前記約定情報に基づいて債券の銘柄を選定することを特徴とする。
【００２０】
また、上記決済方法は、資金の取り手側の端末装置から第１の約定に対するネッティング指示を受信した場合には、第１の約定のスタート決済明細と、第１の約定のスタート決済日とエンド決済日が一致する第２の約定のエンド決済明細と、に基づいてネッティングを実行し（ネッティングデータ及びネッティング明細を作成し）、実行されたネッティングの結果（作成されたネッティング明細）に基づいて決済を実行することを特徴とする。
【００２１】
また、上記決済方法は、約定の対象となった債券と該債券の対価として受け取った担保金とを対応付けて記憶し、前記債券の時価を取得し、この取得した債券の時価を基に算出した債券価額と前記記憶された担保金とを比較し、この比較結果に基づいてマージンコールの発生の有無を判断し、マージンコールが発生したと判断した場合には、マージンコール行使側の端末装置へマージンコールの発生を通知し、マージンコール行使側の端末装置からマージンコールを行使する旨を受信した場合には、マージンコールが行使される旨をマージンコールの被行使側の端末装置へ通知し、マージンコールの被行使側の端末装置からマージンコールの行使に対する確認を受信した場合には、マージンコール決済明細を作成してマージンコールの決済を実行し、前記マージンコール決済の実行結果に基づいて前記記憶手段の担保金を更新するとともに、前記約定のエンド決済明細を更新することを特徴とする。
【００２２】
また、上記発明は、コンピュータに所定の機能を実現させるプログラムまたはそのプログラムを記録した記録媒体としても成立する。また、本明細書における手段は、ハードウェア、ソフトウェアまたはハードウェアおよびソフトウェアの組み合わせにより実現可能である。ハードウェアおよびソフトウェアの組み合わせによる実行は、例えば、所定のプログラムを有するコンピュータ・システムにおける実行が該当する。そして、１つの手段が有する機能が２つ以上のハードウェア、ソフトウェアまたはハードウェアおよびソフトウェアの組み合わせにより実現されても、２つ以上の手段の機能が１つのハードウェア、ソフトウェアまたはハードウェアおよびソフトウェアの組み合わせにより実現されても良い。
【００２３】
【発明の実施の形態】
次に、本発明の実施の形態について、図面を参照しつつ説明する。なお、本実施形態では、決済システムが、Ａ社とＢ社との間で約定されたＧＣレポ取引に適用される場合について説明する。なお、Ａ社とＢ社はともに金融機関Ｘの顧客であり、Ａ社は資金の取り手、Ｂ社は資金の出し手とする。
【００２４】
［決済システムの概略構成］
図１は、本実施形態に係る決済システムの機能及び全体スキームを説明するためのブロック図である。決済システム１０は、通信ネットワークを介してＡ社の端末装置３１及びＢ社の端末装置４１と通信可能に構成されている。また、ＩＦシステム２０、レポシステム２１、資金系システム２２、債券系システム２３等を備えている。
【００２５】
ＩＦシステム２０は、通信ネットワークを介してＡ社の端末装置３１及びＢ社の端末装置４１に対し約定データ、決済データ等を入出力可能に構成されている。
【００２６】
レポシステム２１は、レポ取引に関する決済を処理する機能を有し、約定ＤＢ２１１、決済ＤＢ２１２、ネッティングＤＢ２１３及び担保金管理ＤＢ２１４を備えている。約定ＤＢ２１１は、レポ取引に関する約定データ、例えば、原約定データとスタート時及びエンド時の決済明細を関連付けた約定明細を記憶している。決済ＤＢ２１２は、決済に関するデータ、例えば、スタート時及びエンド時の決済明細を記憶している。ネッティングＤＢ２１３は、ネッティングに関するデータ、例えば、ネッティング後の決済明細とネッティング前の原決済明細を関連付けたネッティング明細を記憶している。担保金管理ＤＢ２１４は、レポ取引の対象債券の時価と担保金を管理するためのものであり、債券と担保金とを対応付けて記憶している。なお、各ＤＢのデータ構造については、後述する。また、各ＤＢにおけるデータの管理や検索にはリレーショナルデータベース等の従来のデータベース技術を用いることができる。
【００２７】
資金系システム２２は、顧客の資金を管理する機能を有し、具体的には、Ａ社専用口座２２１とＢ社専用口座２２２とを有し、レポシステム２１から与えられる指示に従ってこれらの口座残高を増額または減額するとともに、その記録を格納する。
【００２８】
債券系システム２３は、顧客の債券を管理する機能を有し、具体的には、Ａ社債券口座２３１とＢ社債券口座２３２とを有し、レポシステム２１から与えられる指示に従ってこれらの債券残高を増額または減額するとともに、その記録を格納する。また、各債券口座２３１、２３２は、債券の銘柄、額面金額、債券の残存期間などを対応付けて記憶している。レポシステム２１は、この債券口座２３１、２３２のデータに基づいて、後述する銘柄選定処理を実行する。
【００２９】
［レポ取引の流れ］
次に、このように構成される決済システム１０における決済処理の全体の流れを説明する。図２は、決済システム１０による決済処理の全体の流れを示すフローチャートである。
【００３０】
まず、約定日（Ｈ１４．５．１５）に、資金の取り手である顧客Ａ社が、顧客Ｂ社との間の約定に基づいて端末装置３１から約定情報を入力すると、決済システム１０はこれを受け付ける（Ｓ２０１）。決済システム１０は、約定情報を受け付けると、債券銘柄の自動選定処理を実行する（Ｓ２０２）。
【００３１】
債券銘柄の自動選定処理とは、顧客Ａ社にて指定された所定の条件に従って、顧客Ａ社が保有する債券のうちＧＣレポ取引として使用可能な銘柄から担保銘柄を自動的に選定する処理である。従来、債券銘柄の選定作業においては、選定の都度、保有債券の銘柄別残高を確認して銘柄を選定する必要あった。しかし、上記担保銘柄の自動選定処理によれば、顧客は、選定条件を選択するだけでよいので、選定作業が一挙に軽減されるようになる。
【００３２】
次に、決済システム１０は、約定明細及び決済明細の作成処理とコンファメーション処理を実行する（Ｓ２０３）。具体的には、銘柄選定実施した約定データを基に決済データを作成し、約定明細兼決済明細として顧客Ａ社に通知する。顧客Ａ社から確認入力を受け取ると、顧客Ｂ社に約定明細兼決済明細として通知し、顧客Ｂ社から確認入力を受け取ると、約定成立の確認及び決済明細の照合完了を確認する。
【００３３】
コンファメーション処理が終了すると、決済システム１０は、ネッティング待ち状態へ移行する。そして、顧客Ａ社からネッティングが指定された場合には（Ｓ２０４；Ｙｅｓ）、ネッティング処理を実行する（Ｓ２０５）。なお、所定の期限までにネッティングが指定されない場合には（Ｓ２０４；Ｎｏ）、ネッティング処理を実行しない。
【００３４】
ネッティング処理とは、「決済日を同じくする債権・債務の決済金額の差額を受渡することにより、もとの債権・債務を決済することが出来たものとするペイメント・ネッティングを行うために」する処理である。ネッティング処理により、ネッティングデータが作成され、ネッティングデータをもとに作成されたネッティング明細（ネッティング後の決済明細とネッティング前の原決済明細を関連付けた明細）についてはネッティング・コンファメーションとしてＡ社とＢ社の端末装置に送信される。
【００３５】
そして、決済のスタート時（Ｈ１４．５．１８）には、スタート決済明細の自動決済処理を実行する（Ｓ２０６）。本発明では、レポの約定単位で決済処理を実行する。よって、ＧＣレポの場合、資金１００億に対して、国債５銘柄２０億円ずつが選定されている場合には、１００億円と国債５銘柄とが１回の決済として処理される。つまり、約定明細により資金調達１００億円に対してどの国債が選択されたかが紐付けされているため資金１００億円と国債５銘柄を一度に受渡処理することが可能となる。なお、ネッティング処理が実行された場合には、Ｓ２０５にて作成されたネッティングデータに基づいて作成されたネッティング後の決済明細に基づいて処理を実行する。
【００３６】
スタート時の決済処理が終了すると、決済システム１０は、マージンコールの管理を行う（Ｓ２０７）。マージンコールとは、取引期間中の債券時価の変動に応じて担保となる現金の過不足（マージン）を計算する、いわゆる値洗いを行い、マージンが拡大した場合には、追加的な担保の差入を要求することができるという制度である。マージンコール処理では、レポの対象となっている債券に対して、例えば毎営業日に値洗いを実施し、その債券価額と担保金と照合することによりマージンコールの発生を監視する。そして、マージンコールが発生した場合には、その旨を顧客に通知するとともに、マージンコールの行使が指示された場合には、マージンコール決済を実行して、その結果変動した担保金額をエンド決済明細に反映させる。従来、顧客は、自らマージンコールの発生を管理し、発生した場合には相手方へ請求するとともに、エンド決済明細の担保金額を更新、エンド決済明細の管理を実施していた。しかし、上記マージンコール処理によれば、マージンコールの発生通知に基づいて、マージンコールの実行を指示するだけでよいので、担保管理に要する作業を一挙に軽減することができるようになる。
【００３７】
そして、決済のエンド時（Ｈ１４．６．１８）には、エンド決済明細の自動決済処理を実行する（Ｓ２０８）。なお、上述したように、本発明では、ＧＣレポの約定単位で決済処理を実行する。よって、エンド決済明細の内容が１回の決済として処理される。なお、ネッティング処理が実行された場合には、ネッティング明細に基づいて処理を実行する。
【００３８】
［各ＤＢのデータ構造］
次に、各データベースのデータ構造について図３〜図６を用いて説明する。
【００３９】
図３は、約定ＤＢ２１１のデータ構造の一例を表す図である。約定ＤＢ２１１は、顧客の入力した約定情報に基づき、レポの対象となる債券銘柄を選定し、約定データとして記憶する。なお、約定データとは、図３に示したデータ項目の集合体のことをいい、約定明細は、約定データに基づいて作成された取引明細のことである。約定明細には固有の番号（Ｒｅｆ．Ｎｏ．）が割り当てられ、後述の処理により作成される決済明細等もこのＲｅｆ．Ｎｏ．により約定明細に関連づけられる。
【００４０】
図４は、決済ＤＢ２１２のデータ構造の一例を表す図である。決済ＤＢ２１２は、約定データの取引先及び取引相手先データから、顧客マスター（図示せず）にある決済口座データを抽出して作成された決済明細を記憶する。なお、決済データとは、図４に示したデータ項目の集合体のことをいい、決済明細は、決済データに基づいて作成された取引明細のことである。決済データは、決済日、自己及び相手方の決済口座（債券及び資金）及び受渡金額（債券及び資金のスタート額面及び金額とエンド額面及び金額）、を少なくとも有する。スタート決済明細及びエンド決済明細の受渡金額は、約定データにより算出される。また、決済口座データは、取引先名をキーとして、決済口座マスターを検索することで該当口座を選択することができる。
【００４１】
図５は、ネッティングＤＢ２１３のデータ構造の一例を表す図である。ネッティングＤＢ２１３は、決済ＤＢ２１２が保有している決済明細（原決済明細）のうち、同一決済日、同一銘柄のスタート決済明細とエンド決済明細をネッティングして作成されたネッティング明細を記憶する。なお、ネッティングデータとは、図５に示したデータ項目の集合体のことをいい、ネッティング明細は、ネッティングデータに基づいて作成された明細であり、既述のように「ネッティング前の原決済明細（複数）とネッティング後の決済明細（１つ）を紐付けている明細」である。ネッティング明細が両顧客によって確認されると、ネッティング後の決済明細を決済ＤＢ２１２に記憶し、原決済明細を決済ＤＢ２１２から削除する。このように、原決済明細とネッティング後の決済明細はネッティングＤＢにおいてネッティング明細として関連付けて記憶されているので、ネッティング後の明細が決済された場合には、原決済明細が決済されたものとして、約定ＤＢ２１１や顧客の端末装置３１、４１に対し、決済情報を還元することが出来る。
【００４２】
図６は、担保金管理ＤＢ２１４のデータ構造の一例を表す図である。担保金管理ＤＢ２１４は、外部システムより債券の時価を取得し、レポシステムにて管理するレポ取引の債券価額を算出するとともに、当該債券の対価として受取った（又は渡した）担保金と先に算出した債券価額を比較し、その差額をマージンとして管理するためのものである。具体的には、担保金管理ＤＢ２１４は、債券テーブルと担保金テーブルとから構成され、債券テーブルの債券価額と担保金テーブルの担保金とを比較し、その差額が一定の基準を超えた場合に、マージンコールとして行使権のある顧客側に通知がなされる。なお、債券時価とは、債券額面１００円あたりの債券価額であり、債券価額とは、額面金額×債券時価によって算出される一定額面の債券の価額である。
【００４３】
［スタート時の決済処理］
次に、決済システム１０によるＧＣレポ取引の決済処理（スタート時）の流れについて、図７を用いて詳細に説明する。まず、資金の取り手である顧客Ａ社は、レポ登録画面から約定情報を入力する。図８（Ａ）は、レポ登録画面の構成の一例を示す図である。レポ登録画面は、約定情報を入力する領域、決済口座情報を表示する領域、及び銘柄選定ロジックを選択する領域を備えている。顧客Ａ社のディーラは、約定情報を入力するとともに、ネッティングの有無や、銘柄の選定条件を指定することができる。顧客Ａ社のディーラが、「担保検索」を選択すると、顧客Ａ社の端末装置３１は、入力された約定情報及び選定条件を決済システム１０に送信する。なお、決済口座情報は、取引先名をキーに決済口座マスターを検索することで自動的に表示される。
【００４４】
図７に戻り説明を続ける。決済システム１０は、顧客Ａ社の端末装置３１から約定情報、選定条件を受け付ける（Ｓ７０１）。そして、銘柄選定ロジックが選択されている場合には（Ｓ７０２；Ｙｅｓ）、債券選定処理を実行する（Ｓ７０３）。なお、債券選定処理については、図９にて後述する。債券を選定すると、約定明細を作成し、約定ＤＢ２１１へ登録する（Ｓ７０４）。
【００４５】
決済システム１０は、約定データに決済情報を付加した決済データを基に決済明細を作成し、決済ＤＢ２１２へ仮登録する（Ｓ７０５）。その後決済システム１０は、約定明細兼決済明細として顧客Ａ社の端末装置３１へ送信する（Ｓ７０６）。顧客Ａ社の端末装置３１は、レポ明細画面に受信した約定明細兼決済明細を表示する。図８（Ｂ）は、レポ明細画面の構成の一例を示す図である。レポ明細画面は、対象約定内容を表示する領域と、選定された債券銘柄を表示する領域及び決済口座情報を表示する領域とを備えている。顧客Ａ社のディーラは、「確定／送信」を選択すると、確定データが送信され、「明細変更入力」や「更新」を選択すると、変更データが決済システム１０へ送信される。
【００４６】
決済システム１０は、顧客Ａ社の端末装置３１から確定データを受け取った場合には（Ｓ７０７；Ｙｅｓ）、約定明細兼決済明細を顧客Ｂ社の端末装置４１へ送信する（Ｓ７０８）。変更データを受け取った場合には（Ｓ７０７；Ｎｏ）、約定明細兼決済明細を修正する（Ｓ７０９）。
【００４７】
顧客Ｂ社の端末装置４１は、レポ明細画面に受信した約定明細兼決済明細を表示する。図８（Ｃ）は、レポ明細画面の構成の一例を示す図である。レポ明細画面は、対象約定内容を表示する領域と、選定された債券銘柄を表示する領域及び決済口座情報を表示する領域とを備えている。顧客Ｂ社のディーラは、「承認／送信」を選択すると、承認データが送信され、「不承認」や「自己決済口座変更入力」を選択すると、不承認データや変更データが決済システム１０へ送信される。
【００４８】
決済システム１０は、顧客Ｂ社の端末装置４１から承認データを受け取った場合には（Ｓ７１０；Ｙｅｓ）、約定成立の確認及び決済明細の照合完了を確認し（Ｓ７１１）、Ｓ７０５にて仮登録した決済明細を正式な決済明細として登録する（Ｓ７１３）。そして、決済システム１０は、約定のスタート日において、スタート決済明細に基づいてＤＶＰ処理を実行する（Ｓ７１４）。ＤＶＰ処理を実行すると、決済が完了した旨を、顧客Ａ社の端末装置３１と顧客Ｂ社の端末装置４１とへ通知する（Ｓ７１５）。
【００４９】
なお、上記処理では、決済明細の仮登録を行う場合について説明したが、決済明細を決済ＤＢに保存することなく顧客へ送信し、両方の顧客の確認入力を受けたことを確認して決済ＤＢに登録するようにしてもよい。
【００５０】
［銘柄選定処理］
次に、決済システム１０による銘柄選定の流れについて、図９を用いて詳細に説明する。図８（Ａ）にて示されたように、本実施形態の銘柄選定ロジックは、基本ロジックとオプションロジックとから構成されている。基本ロジックの選択は必須であり、オプションロジックの選択は任意である。利用者は、任意にこれらのロジックを組み合わせることができる。なお、前提条件として、売却やＳＣレポによる当日、翌日等の払出予定の銘柄については、その該当残高を予め控除して計算する。また、オプションロジックが選択された場合には、基本ロジックに優先して適用される。
【００５１】
ここで、各基本ロジックについて説明する（図８（Ａ）参照）。第１のロジックである銘柄数最小優先ロジックは、銘柄数が最小になるように残高の大きい銘柄から優先的に選定するように構成されているロジックである。第２のロジックである残高少銘柄優先ロジックは、残高の少ない銘柄から優先的に選定するように構成されているロジックである。第３のロジックである保有銘柄按分ロジックは、保有残高按分に応じて銘柄を選定するように構成されているロジックである。なお、上記ロジックにおいて、選択可能な銘柄が複数ある場合には、債券の残存期間（満期償還までの期間）が短いものを優先するように設定することができる。
【００５２】
次に、オプションロジックについて説明する。第１に、ネッティング優先ロジックは、スタート決済日付で自動作成されているエンド決済明細と最大限ペアオフ・ネッティングできるように銘柄を選定するように構成されている。第２に、一定保留分を考慮するロジックは、一定割合の残高を残して銘柄を選定するように構成されている。例えば、「最低限、各銘柄２０は残高を残す」と設定されている場合には、残高が２０よりも大きい銘柄が選定の対象となる。第３に、最割安銘柄優先ロジックは、最割安銘柄を優先的に選定するように構成されている。
【００５３】
なお、銘柄を選定するロジックは、上述したこれらのロジックに限られず、適宜これを設定することができる。
【００５４】
図９に戻り、説明を続ける。決済システム１０は、オプションロジックが指定されたか否かを判断し（Ｓ９０１）、オプションロジックが指定された場合には、資金の取り手の債券口座を参照し、指定されたロジックに従って処理を実行する（Ｓ９０２、Ｓ９０３、Ｓ９０４）。
【００５５】
続いて、決済システム１０は、基本ロジックが指定されているか否かを判断し（Ｓ９０５）、基本ロジックが指定されている場合には、資金の取り手の債券口座を参照し、指定された基本ロジックに従って処理を実行する（Ｓ９０６、Ｓ９０７、Ｓ９０８）。基本ロジックが指定されていない場合には、エラー処理を実行する。なお、オプションロジックの処理を実行した場合には、オプションロジックの処理結果に基づいて基本ロジックを実行する。
【００５６】
図１０は、銘柄選定処理の実行結果の一例を表す図である。同図によれば、選定されたロジックによって、選択された銘柄が異なることがわかる。ここでは、資金の取り手であるＡ社の債券口座に保有されている銘柄Ａ〜Ｒより債券２００を選択する場合について例示する。よって、例えば、基本ロジック１の場合には、基本ロジック１の条件を満たす銘柄Ａ、Ｂ、Ｃ、Ｄのうち、債券の残存期間が一番短い銘柄Ｃが選択されている（同図（＊１）参照）。他のロジックの場合にも、選択可能な銘柄が複数ある場合には、債券の残存期間が一番短い銘柄が選択されている（同図（＊２）（＊４）参照）。また、オプションロジック１と基本ロジック１の組み合わせの場合にも、選択可能な銘柄Ａ〜Ｉのうち債券の残存期間が一番短い銘柄Ｅが選択されている（同図（＊４）参照）。なお、オプションロジック２（図（＊５）参照）について「最低限、各銘柄２０は残高を残す」と設定されている場合には、銘柄Ｏ〜Ｒは対象外となる。また、ここでは、銘柄Ｆが最割安銘柄であるので、オプションロジック３について、銘柄Ｆが選択されている（図（＊６）参照）。
【００５７】
［ネッティング処理］
次に、決済システム１０によるネッティング処理の流れについて、図１１を用いて詳細に説明する。決済システム１０は、顧客Ａ社の端末装置３１から約定入力を受け付けると（Ｓ１１０１）、ネッティング指定がされたか否かを判断する（Ｓ１１０２）。ネッティング指定がされたと判断した場合には、ネッティング処理を実行する（Ｓ１１０３）。ここで、ネッティング処理の概要について図１２及び図１３を用いて説明する。
【００５８】
図１２及び図１３は、ネッティング処理の概要を説明するための図である。まず、図１２は、（１）Ａ社がＢ社よりＧＣレポで１００億円を調達する。この場合、スタート決済明細（Ｒｅｆ．０００１）は、資金の取り手であるＡ社から４銘柄（Ａ、Ｂ、Ｃ、Ｄ）計１００億円が、資金の出し手であるＢ社から資金１００億円が、それぞれ受け渡される内容となる。そして、エンド決済明細（Ｒｅｆ．０００１）は、資金の取り手であるＡ社から資金１０４億円が、資金の出し手であるＢ社から４銘柄（Ａ、Ｂ、Ｃ、Ｄ）計１００億円が、それぞれ受け渡される内容となる。
【００５９】
次に、上記約定のエンド決済日に、（２）Ａ社がＢ社よりＧＣレポで１００億円を再調達したものとする。この場合のスタート決済明細（Ｒｅｆ．００９９）は、資金の取り手であるＡ社から４銘柄（Ａ、Ｃ、Ｄ、Ｅ）計１００億円が、資金の出し手であるＢ社から資金１００億円が、それぞれ受け渡される内容となる。そして、エンド決済明細（Ｒｅｆ．００９９）は、資金の取り手であるＡ社から資金１０５億円が、資金の出し手であるＢ社から４銘柄（Ａ、Ｃ、Ｄ、Ｅ）計１００億円が、それぞれ受け渡される内容となる。
【００６０】
Ａ社がスタート決済明細（Ｒｅｆ．００９９）に対してネッティングを入力すると、エンド決済明細（Ｒｅｆ．０００１）とスタート決済明細（Ｒｅｆ．００９９）とがネッティング処理の対象となる。
【００６１】
そして、図１３は、ネッティング処理の結果を示している。エンド決済明細（Ｒｅｆ．０００１）とスタート決済明細（Ｒｅｆ．００９９）とがネッティングされ、その結果に基づいて、ネッティング明細が作成される。ネッティング明細では、資金の取り手であるＡ社から資金４億円と、２銘柄（Ｃ、Ｅ）計４０億円が、資金の出し手であるＢ社から２銘柄（Ａ、Ｂ）計４０億円が、それぞれ受け渡される内容となっていることがわかる。
【００６２】
図１１に戻り説明を続ける。決済システム１０は、ネッティング処理を実行すると、ネッティング明細を顧客Ａ社の端末装置３１に通知する（Ｓ１１０４）。顧客Ａ社の端末装置３１は、ネッティング・コンファメーション画面に受信したネッティング明細を表示する。図１４は、ネッティング・コンファメーション画面の構成の一例を示す図である。ネッティング・コンファメーション画面は、ネッティング後の決済明細を表示する領域と、原決済明細を表示する領域とを備えている。顧客Ａ社の担当者は、「確認」を選択すると、確認データが決済システム１０へ送信される。
【００６３】
決済システム１０は、顧客Ａ社の端末装置３１から確認データを受け取った場合には（Ｓ１１０５；Ｙｅｓ）、ネッティング明細を顧客Ｂ社の端末装置４１へ送信する（Ｓ１１０７）。顧客Ｂ社の端末装置４１は、図１４に示したようなネッティング・コンファメーション画面に受信したネッティング明細を表示する。顧客Ｂ社の担当者は、「確認」を選択すると、承認データが決済システム１０へ送信される。決済システム１０は、顧客Ｂ社の端末装置４１から確認データを受け取った場合には（Ｓ１１０８；Ｙｅｓ）、ネッティングの成立を確認し（Ｓ１１０９）、ネッティング明細をネッティングＤＢに登録するとともに（Ｓ１１１１）、ネッティング後の決済明細を決済ＤＢに登録し、原決済明細を決済ＤＢより削除する（Ｓ１１１２）。そして、決済システム１０は、決済日に、ＤＶＰ（ＦＯＰ（Ｆｒｅｅ　Ｏｆ　Ｐａｙｍｅｎｔ））処理を実行する（Ｓ１１１３）。なお、ＦＯＰ処理とは、例えばネッティングをした結果として資金の受渡がゼロとなった場合に、債券の受渡のみを行い、資金の受渡を伴わない債券の振替処理のことをいう。
【００６４】
［マージンコール処理］
次に、決済システム１０によるマージンコール処理の流れについて、図１５を用いて詳細に説明する。
【００６５】
決済システム１０は、債券の時価を管理する債券時価データベース（図示せず）から債券の時価情報を取得し、取得した時価情報に基づいて担保金管理ＤＢ２１４の債券テーブルの債券価額を更新する（Ｓ１５０１）。そして、債券テーブルの債券価額と、担保金テーブルの担保金とを比較する（Ｓ１５０２）。この比較結果に基づいて、マージンコールの発生の有無を判断し（Ｓ１５０３）、マージンコールが発生したと判断する場合には、マージンコールが発生した旨をマージンコールの行使権者側顧客へ通知する（Ｓ１５０４）。
【００６６】
マージンコール発生の通知を受けた端末装置は、マージンコールの発生をメッセージによりリアルタイムで通知することができる。図１６（Ａ）は、マージンコール発生の通知を受けた端末装置の画面の例を示す図である。端末装置は、メッセージの確認が選択されると、マージンコールの明細を決済システム１０から取得してマージンコール対象一覧画面に表示する。マージンコール対象一覧画面は、マージンコールの明細内容を表示する領域を備えている。マージンコール行使権者側顧客は、「マージンコール実行」を選択すると、実行指示データが決済システム１０に送信される。
【００６７】
決済システム１０は、実行指示データを受け付けると（Ｓ１５０５）、マージンコールの実行を被行使権者側顧客へ通知する（Ｓ１５０６）。マージンコール実行の通知を受けた端末装置は、マージンコールの実行をメッセージによりリアルタイムで通知することができる。
【００６８】
図１６（Ｂ）は、マージンコール実行の通知を受けた端末装置の画面の例を示す図である。端末装置は、メッセージの確認が選択されると、マージンコールの明細を決済システム１０から取得してマージンコール実行通知画面に表示する。マージンコール実行通知画面は、マージンコールの実行内容を表示する領域を備えている。マージンコール被行使権者側顧客は、「マージンコール確認」を選択すると、確認データが決済システム１０に送信される。
【００６９】
決済システム１０は、確認データを受け付けると（Ｓ１５０７）、マージンコール決済明細を作成し、決済明細ＤＢへ登録する（Ｓ１５０８）。そして、決済システム１０は、マージンコール決済処理を実行する（Ｓ１５１０）。つまり、債券の価額と担保金とが一致するように、債券の価額と担保金との差額分が、被行使権者側顧客の資金口座から行使権者側顧客の資金口座へ振り替えられる。
マージンコール決済処理が終了すると、マージンコール決済完了を行使権者側顧客と被行使権者側顧客へそれぞれ通知する（Ｓ１５１１）。そして、担保金管理ＤＢ２１４の担保金を更新する（Ｓ１５１２）。また、決済明細ＤＢ２１２のエンド決済明細を更新する（Ｓ１５１３）。つまり、エンド決済明細のエンド金額を更新する。
【００７０】
図１７は、マージンコール決済処理の結果の例を示す図である。まず、（１）取引前の状態として、Ａ社の債券残高は額面５００円（時価５００円）、Ｂ社の資金口座は１０００円となっている。ここで、「ＧＣレポ５００円」で約定され、取引が開始されたものとする。
【００７１】
（２）取引のスタート時には、Ｂ社の資金口座からＡ社の資金口座へ５００円が、Ａ社の債券口座からＢ社の債券口座へ債券額面５００円が、それぞれ移動している。
【００７２】
その後、（３）債券の時価が額面５００円から４５０円に下がることにより、マージンコールが発生し、Ｂ社がマージンコールを行使している。その結果、Ａ社の資金口座からＢ社の資金口座へ５０円が移動している。なお、マージンコールの発生は、Ｂ社に自動的に通知されるので、Ｂ社は、マージンコールを行使するか否かを決定するだけでよい。
【００７３】
さらにその後、（３）債券の時価が額面４５０円から５５０円に上がることにより、再度マージンコールが発生し、Ａ社がマージンコールを行使している。その結果、Ｂ社の資金口座からＡ社の資金口座へ１００円が移動している。この際、マージンコールの発生は、Ａ社に自動的に通知されるので、Ａ社もまた、マージンコールを行使するか否かを決定するだけでよい。
【００７４】
そして、（５）取引のエンド時には、Ａ社の資金口座からＢ社の資金口座へ５５０円が、Ｂ社の債券口座からＡ社の債券口座へ債権額面５５０円が、それぞれ移動している。なお、マージンコールが行使されるたびに、エンド決済明細は自動的に更新されているので、Ａ社及びＢ社は、エンド決済明細を管理することなく取引を完了させることができる。
【００７５】
［エンド時の決済処理］
次に、決済システム１０によるエンド時の決済処理の流れについて、図１８を用いて詳細に説明する。決済システム１０は、処理日がエンド決済明細のエンド日に該当する場合には（Ｓ１８０１；Ｙｅｓ）、そのエンド決済明細がネッティングされているか否かを判断する（Ｓ１８０２）。そして、ネッティングされている場合には（Ｓ１８０２；Ｙｅｓ）、既述のネッティング処理を実行し（Ｓ１８０３）、ネッティングされていない場合には（Ｓ１８０１；Ｎｏ）、エンド決済明細に従ったグロス処理を実行する（Ｓ１８０４）。そして、決済が終了すると、決済が完了した旨を、資金の取り手と資金の出し手にそれぞれ通知する。
［その他の実施形態］
上記各実施形態は、本発明を説明するための例示であり、本発明をこれらの実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱しない限り、さまざまな形態で実施することができる。また、上記フローチャートでは、リクエストメッセージの受信処理をシーケンシャルに説明したが、動作に矛盾が生じない限り、処理の順序を入れ替えまたは並行動作するように構成しても良い。
【００７６】
例えば、上記実施形態では、本発明をＧＣレポに適用する場合について説明したが、ＳＣレポに適用してもよい。この場合、自動銘柄選定機能はＧＣの場合だけ使用する機能とし、ＳＣの場合にはＳＣ（銘柄入力）等とすることにより手入力で銘柄を選定可能に構成してもよい。また、ＧＣレポに適用する上記実施形態では、資金の取り手が約定入力するものとしたが、ＳＣレポの場合には、債券の取り手（資金の出し手）が約定入力するように構成してもよい。
【００７７】
【発明の効果】
本発明によれば、レポ取引における約定から決済までの一連の事務をＳＴＰ化し、約定入力，約定明細兼決済明細の確認、マージンコールの行使、ネッティングの実行・確認など都度の確認入力を行うのみで処理することが可能となり、事務処理の効率化、オペレーションリスクの削減が図れるとともに、決済制度改革により指向されている証券決済のＴ＋１化へも対応できるようになる。
【図面の簡単な説明】
【図１】本実施形態に係る決済システムの機能及び全体スキームを説明するためのブロック図である。
【図２】決済システム１０による決済処理の全体の流れを示すフローチャートである。
【図３】レポＤＢ２１１のデータ構造の一例を表す図である。
【図４】決済ＤＢ２１２のデータ構造の一例を表す図である。
【図５】ネッティングＤＢ２１３のデータ構造の一例を表す図である。
【図６】担保金管理ＤＢ２１４のデータ構造の一例を表す図である。
【図７】決済システム１０による決済処理（スタート時）の流れを示すフローチャートである。
【図８】ＧＣレポ登録画面等の構成の一例を示す図である。
【図９】決済システム１０による銘柄選定の流れを示すフローチャートである。
【図１０】銘柄選定処理の実行結果の一例を表す図である。
【図１１】決済システム１０によるネッティング処理の流れを示すフローチャートである。
【図１２】ネッティング処理の概要を説明するための図である。
【図１３】ネッティング処理の概要を説明するための図である。
【図１４】ネッティング・コンファメーション画面の構成の一例を示す図である。
【図１５】決済システム１０によるマージンコール処理の流れを示すフローチャートである。
【図１６】マージンコール発生の通知を受けた端末装置の画面の例を示す図である。
【図１７】マージンコール決済処理の結果の例を示す図である。
【図１８】決済システム１０によるエンド時の決済処理の流れを示すフローチャートである。
【図１９】日銀ネットを利用した従来のＧＣレポ取引の流れを示す図である。
【符号の説明】
１０…決済システム
２０…ＩＦシステム
２１…レポシステム
２２…資金系システム
２３…債券系システム
３０…顧客Ａ社
４０…顧客Ｂ社[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a settlement system and a settlement processing method acting for settlement of bonds, and more particularly to a settlement system and settlement processing method acting for settlement of bonds between customers of financial institutions.
[0002]
[Prior art]
2. Description of the Related Art Conventionally, the Bank of Japan Financial Network System (hereinafter referred to as “BOJ Net”) has been known as an electronic-based settlement system. BOJ-NET is a network system built for online processing of settlement of funds and government bonds between the Bank of Japan and its financial institutions. Various transactions are conducted on the BOJ-NET, including so-called repo transactions.
[0003]
In repo transactions, funds are exchanged for a certain period of time with high-credit bonds, such as government bonds. Specifically, at the start date of the transaction (start date), the fund holder and the bond holder exchange funds and bonds based on the market value of the bond at the time of execution. At the end date (end date) of the transaction, the bond holder returns the fund with the contract price plus the repo rate defined as “interest rate – loan rate” to the fund holder, and holds the fund. Returns the bond to the bondholder. Of these repo transactions, those with a “financing” nature are called “GC (General Collateral) repos”, and those with a “bond borrowing / financing” nature are called “SC (Special Collateral) repos”. In the GC repo, the security issue to be traded is not specified, but in the SC repo, the security issue is determined at the time of execution.
[0004]
Here, a flow of a conventional GC repo transaction using the BOJ-NET will be described with reference to FIG. First, the fund taker (bond holder) and the fund provider (fund holder) conclude a contract regarding GC repo transactions. Each dealer makes an agreement, for example, in the form of "GC 10 billion yen".
[0005]
On the trade day, the front of the fund collector selects government bonds. For example, if the contract amount is 10 billion yen, five government bonds can be selected for 2 billion yen. When a government bond is selected, the contract details are entered into the company's front system based on the selected government bond. As a result, a contract confirmation for confirming the contract content is output. The fund taker confirms the contents of the contract with the fund taker by telephone or FAX based on the contract confirmation. After confirming the contents of the government bonds, the front desk on the side of issuing the funds divides and enters the contract for each government bond brand into its own front system.
[0006]
On the other hand, when the contract data is transferred from the front system to the back system, a confirmation is input, and when the transfer is not transferred, the contents of the contract are input. As a result, an individual statement for confirming the settlement contents is output. The fund taker confirms the settlement contents to the fund taker by telephone or FAX based on the individual statement. When the payment source's back checks the settlement details based on the received individual statement, the back enters the confirmation into its own back system.
[0007]
Thereafter, on the initiative date, the fund taker and the fund taker input data necessary for settlement with the BOJ-NET terminal device connectable to the BOJ-NET, respectively. Alternatively, if the settlement data has been transmitted from the back system in advance, the data is transmitted to the BOJ-NET on the day of the initiative. The BOJ-NET executes a government bond DVP (Delivery Versus Payment) settlement process based on the input data. This settlement process is carried out by the following procedures: a notice of the preparation of the government bond by the fund taker, a confirmation of the content by the fund issuer, a notice of the fund preparation by the fund issuer, and exchange of the fund with the government bond.
[0008]
[Problems to be solved by the invention]
However, the conventional settlement method via the BOJ-NET has the following problems.
[0009]
First, in the conventional payment method using the BOJ-NET, processing other than payment is not covered, so processing from execution to settlement, for example, processing of confirmation of settlement and payment, etc. This was done on both the side and the outgoing side systems. Therefore, after the contract is executed by the dealer and before the payment is executed on the BOJ-NET, the work of inputting the contents of the contract and the contents of the settlement into each system, the collation work by telephone or facsimile, etc., occur, and as a result, the fund collector The side and the outgoing side required a great deal of labor and time for these office work.
[0010]
In addition, the settlement by BOJ-NET is configured to be performed for each bond issue. Therefore, as described above, even if the contract is executed at “GC 10 billion yen” at the time of the contract of the dealer, if the target bond is “5 issues at 2 billion yen”, the contract is “GC 2 billion yen × 5”. , And the actual settlement would have to be performed five times, which was a heavy burden on the settlement affairs.
[0011]
Therefore, an object of the present invention is to provide a settlement system and a settlement processing method that can reduce the administrative burden required for repo transactions.
[0012]
[Means for Solving the Problems]
In view of the above problems, the present invention performs contract matching and settlement matching based on input of contract information by a fund taker and confirmation input of data by a fund issuer, and automatically creates a settlement statement of a repo transaction. It is characterized by automatic settlement on the settlement date. According to this, since the fund taker only enters the contract information and the fund issuer enters the data confirmation only, the settlement is automatically performed, so that the clerical work required for the repo transaction can be reduced at once. Become like
[0013]
At the same time, the securities settlement system is currently being reviewed, and the use of STP (straight-through processing) and the settlement of T + 1 (to reduce the settlement time from the current three days to one day) have been implemented to reduce settlement risk. According to the present system, a repo transaction can be realized in STP, and the processing can be speeded up to realize T + 1 in settlement.
[0014]
Specifically, the settlement system according to the present invention is a storage means for storing a fund account for managing a customer's fund and a bond account for managing a customer's bond, and a repo transaction from a terminal device on the fund taker side. Receiving the contract information based on the received contract information, creating means for creating a contract statement and a settlement statement based on the received contract information, and transmitting the created contract statement and settlement statement to the terminal device on the fund-taker side and the sender side, and both When receiving the confirmation data for the executed contract statement and settlement statement from the terminal device, confirms the completion of the settlement of the settlement statement, and a decision means for fixing the contract statement and settlement statement, based on the decided settlement statement, Transfer the specified bond balance from the bond account of the fund taker to the bond account of the fund taker, and transfer the predetermined amount from the fund account of the fund taker to the fund account of the fund taker. And settlement means for performing settlement by replacing it Ri, characterized in that it comprises a.
[0015]
Further, the settlement system further includes a bond issue selecting means for selecting a bond issue based on the contract information according to a predetermined condition from among the issue issues stored in the bond account of the fund taker. It is characterized by.
[0016]
In addition, when the settlement system receives a netting instruction for the first contract from the terminal device on the fund taker side, the start settlement statement of the first contract, the start settlement date of the first contract, and the end Further comprising netting means for executing netting (creating netting data and netting details) based on the second settlement end settlement statement having the same settlement date, wherein the settlement means executes a result of the executed netting. The settlement is executed based on (the created netting details).
[0017]
Further, the settlement system obtains a market value of the bond, and stores a market value of the bond, in association with a bond subject to the contract and a collateral received as a consideration for the bond, and stores the market value of the obtained bond. The bond value calculated based on the base value is compared with the collateral stored in the storage unit, and a margin call determination unit that determines whether a margin call has occurred based on a result of the comparison, and determines that a margin call has occurred. In such a case, the terminal device on the margin call exercising side is notified of the occurrence of the margin call, and when it is received from the terminal device on the margin call exercising side that the margin call is to be exercised, it is determined that the margin call is exercised. Notification means for notifying the exercised terminal of the call and confirmation of the exercise of the margin call received from the exercised terminal of the margin call A margin call settlement means for preparing a margin call settlement statement and executing the margin call settlement, and updating the collateral of the storage means based on the execution result of the margin call settlement, and executing the end settlement of the contract. Updating means for updating the statement.
[0018]
Further, the present invention is a settlement method for performing settlement between customers in a settlement system in which a terminal device and a server of a customer can communicate with each other, wherein a contract based on a repo transaction is performed from a terminal device on a fund collecting side. When the information is received, a contract statement and a settlement statement are created based on the received contract information, and the created contract statement and settlement statement are transmitted to the terminal devices on the fund taker side and the issuer side. When the confirmation data for the sent contract statement and settlement statement is received, the contract statement and settlement statement are determined, and based on the decided settlement statement, from the fund account of the fund taker to the bond account of the fund issuer. The settlement is performed by transferring a predetermined bond balance and transferring a predetermined amount of money from a fund account on a fund issuing side to a fund account on a fund collecting side.
[0019]
Further, the above settlement method is characterized in that a brand of the bond is selected from the brands of the bond stored in the bond account of the fund taker based on the contract information in accordance with predetermined conditions.
[0020]
Further, the above settlement method, when receiving a netting instruction for the first contract from the terminal device on the fund taker side, the first settlement start settlement statement, the first settlement start settlement date and end Netting is executed based on the second settlement end settlement statement whose settlement date matches (creation of netting data and netting statement), and settlement is performed based on the executed netting result (created netting statement). Is performed.
[0021]
Further, the settlement method associates and stores the bond subject to the contract and the collateral received as consideration for the bond, obtains the market value of the bond, and calculates the market value based on the market value of the obtained bond. The determined bond value is compared with the stored collateral, the presence or absence of a margin call is determined based on the comparison result, and if it is determined that a margin call has occurred, the terminal device on the margin call exerciser side is determined. When a margin call is issued from the terminal device on the margin call exercising side, the terminal device on the margin call exercised side is notified that the margin call is to be exercised. If a confirmation regarding the exercise of the margin call is received from the terminal device on the exercise side of the margin call, a margin call settlement statement is created to settle the margin call. And row updates the collateral of the storage means based on the execution result of the margin calls payment, and updates the end open items of the contract.
[0022]
Further, the above-described invention is also realized as a program for causing a computer to realize a predetermined function or a recording medium on which the program is recorded. The means in the present specification can be realized by hardware, software, or a combination of hardware and software. Execution by a combination of hardware and software corresponds to, for example, execution in a computer system having a predetermined program. And even if the function of one means is realized by two or more hardware, software or a combination of hardware and software, the function of two or more means is realized by one hardware, software or hardware and software. It may be realized by a combination.
[0023]
BEST MODE FOR CARRYING OUT THE INVENTION
Next, embodiments of the present invention will be described with reference to the drawings. In the present embodiment, a case will be described in which the settlement system is applied to a GC repo transaction executed between Company A and Company B. It should be noted that both Company A and Company B are customers of financial institution X, Company A is a fund taker, and Company B is a fund taker.
[0024]
[Schematic configuration of payment system]
FIG. 1 is a block diagram for explaining functions and an overall scheme of the settlement system according to the present embodiment. The settlement system 10 is configured to be able to communicate with a terminal device 31 of company A and a terminal device 41 of company B via a communication network. Further, an IF system 20, a repo system 21, a fund system 22, a bond system 23, and the like are provided.
[0025]
The IF system 20 is configured to be able to input and output contract data, settlement data, and the like to and from a terminal device 31 of company A and a terminal device 41 of company B via a communication network.
[0026]
The repo system 21 has a function of processing settlement related to repo transactions, and includes a contract DB 211, a settlement DB 212, a netting DB 213, and a collateral management DB 214. The contract DB 211 stores contract data relating to repo transactions, for example, contract statements in which the original contract data is associated with the start and end settlement statements. The payment DB 212 stores payment-related data, for example, payment details at the start and end. The netting DB 213 stores data relating to netting, for example, a netting statement that associates a settlement statement after netting with an original settlement statement before netting. The collateral management DB 214 is for managing the market value and the collateral of the bond subject to the repo transaction, and stores the bond and the collateral in association with each other. The data structure of each DB will be described later. Further, a conventional database technology such as a relational database can be used for data management and search in each DB.
[0027]
The funding system 22 has a function of managing the customer's funds, and specifically has a company A dedicated account 221 and a company B dedicated account 222, and these account balances are in accordance with instructions given from the repo system 21. Is increased or decreased, and the record is stored.
[0028]
The bond system 23 has a function of managing the bond of the customer, and specifically has a bond account 231 of the company A and a bond account 232 of the company B, and according to an instruction given from the repo system 21, these bond balances are set. Is increased or decreased, and the record is stored. In addition, each bond account 231 and 232 stores the name of the bond, the face value, the remaining period of the bond, and the like in association with each other. The repo system 21 executes a brand selection process described later based on the data of the bond accounts 231 and 232.
[0029]
[Flow of repo transactions]
Next, the overall flow of the payment process in the payment system 10 configured as described above will be described. FIG. 2 is a flowchart showing the overall flow of the settlement process by the settlement system 10.
[0030]
First, on the contract day (H14.5.15), the customer A, which is the fund provider, enters contract information from the terminal device 31 based on the contract with the customer B, and the settlement system 10 Is received (S201). When the settlement system 10 receives the contract information, the settlement system 10 executes an automatic selection process of the bond brand (S202).
[0031]
The bond issue automatic selection process is a process for automatically selecting a collateral issue from among the bonds held by the customer A from among the issues available as a GC repo transaction, according to predetermined conditions specified by the customer A. is there. Conventionally, in selecting a bond issue, it is necessary to check the balance of each held bond and to select the issue each time the issue is selected. However, according to the automatic security brand selection process, the customer only needs to select the selection conditions, so that the selection work can be reduced at once.
[0032]
Next, the settlement system 10 executes a process for creating a contract statement and a settlement statement and a confirmation process (S203). Specifically, the settlement data is created based on the contract data for which the brand selection has been performed, and the customer A is notified as the contract statement and the settlement statement. When the confirmation input is received from the customer A, the customer B is notified as a contract statement and a settlement statement. When the confirmation input is received from the customer B, the confirmation of the execution of the contract and the completion of the collation of the settlement statement are confirmed.
[0033]
When the confirmation process ends, the settlement system 10 shifts to a netting waiting state. Then, when the netting is designated by the customer A (S204; Yes), the netting process is executed (S205). If no netting is specified by the predetermined time limit (S204; No), the netting process is not executed.
[0034]
The netting process is "to perform payment netting which assumes that the original receivables and debts have been settled by delivering the difference between the settlement amounts of receivables and debts with the same settlement date" Processing. Netting data is created by the netting process, and the netting details (association of the settlement details after the netting and the original settlement details before the netting) based on the netting data are provided by the companies A and B as the netting confirmation. Is sent to the company's terminal device.
[0035]
Then, at the start of settlement (H14.5.18), an automatic settlement process of the start settlement statement is executed (S206). In the present invention, the settlement process is executed in contract units of the repo. Therefore, in the case of the GC repo, if 5 billion government bonds and 2 billion yen are selected for 10 billion funds, 10 billion yen and 5 government bonds are processed as one settlement. In other words, since the contract statement links which government bond was selected with respect to the fund procurement of 10 billion yen, it is possible to process the 10 billion yen of the fund and the five government bonds at once. When the netting process is executed, the process is executed based on the settlement details after the netting created based on the netting data created in S205.
[0036]
When the settlement process at the start is completed, the settlement system 10 manages a margin call (S207). Margin call is a so-called mark-to-market, which calculates the excess or deficiency (margin) of cash as collateral in response to changes in the market value of bonds during the transaction period. It is a system that can require entry. In the margin call processing, for example, a mark-to-market is performed on the bond subject to repo every business day, and the occurrence of a margin call is monitored by comparing the bond value with the collateral. Then, when a margin call occurs, the customer is notified of the fact, and when the execution of the margin call is instructed, the margin call settlement is executed, and the collateral amount that has changed as a result is changed to the end settlement statement. To reflect. Conventionally, a customer has managed the occurrence of a margin call by himself / herself, billed to the other party when it occurred, updated the collateral amount of the end settlement statement, and managed the end settlement statement. However, according to the margin call processing, it is only necessary to instruct the execution of the margin call based on the notification of the occurrence of the margin call, so that the work required for security management can be reduced at once.
[0037]
Then, at the end of the settlement (H14.6.18), the automatic settlement processing of the end settlement details is executed (S208). As described above, in the present invention, the settlement processing is executed in the contract unit of the GC repo. Therefore, the contents of the end settlement statement are processed as one settlement. When the netting process is executed, the process is executed based on the netting details.
[0038]
[Data structure of each DB]
Next, the data structure of each database will be described with reference to FIGS.
[0039]
FIG. 3 is a diagram illustrating an example of a data structure of the deal DB 211. The contract DB 211 selects a bond brand to be repo based on the contract information input by the customer and stores it as contract data. The contract data refers to a set of data items shown in FIG. 3, and the contract statement is a transaction statement created based on the contract data. A unique number (Ref. No.) is assigned to the contract statement, and the settlement statement and the like created by the processing described later are also assigned to this Ref. No. Is associated with the contract specification.
[0040]
FIG. 4 is a diagram illustrating an example of a data structure of the settlement DB 212. The payment DB 212 stores payment details created by extracting payment account data in a customer master (not shown) from the business partner and business partner data of the contract data. Note that the payment data refers to an aggregate of data items shown in FIG. 4, and the payment details are transaction details created based on the payment data. The settlement data includes at least the settlement date, the settlement account (bond and fund) of the own and the other party, and the transfer amount (start and par value and end par value and amount of the bond and fund). The delivery amount of the start settlement statement and the end settlement statement is calculated based on the contract data. Further, the settlement account data can be selected by searching the settlement account master using the business partner name as a key.
[0041]
FIG. 5 is a diagram illustrating an example of a data structure of the netting DB 213. The netting DB 213 stores a netting statement created by netting a start settlement statement and an end settlement statement of the same brand on the same settlement date among settlement statements (original settlement statement) held by the settlement DB 212. Note that the netting data refers to a set of data items shown in FIG. 5, and the netting statement is a statement created based on the netting data. (A plurality of items) and a statement linking the settlement statement (one) after the netting. When the netting statement is confirmed by both customers, the settlement statement after the netting is stored in the settlement DB 212, and the original settlement statement is deleted from the settlement DB 212. As described above, since the original settlement statement and the settlement statement after netting are stored in the netting DB in association with each other as a netting statement, when the statement after netting is settled, it is assumed that the original settlement statement is settled. The settlement information can be returned to the contract DB 211 and the terminal devices 31 and 41 of the customer.
[0042]
FIG. 6 is a diagram illustrating an example of a data structure of the security management DB 214. The collateral management DB 214 obtains the market value of the bond from the external system, calculates the bond value of the repo transaction managed by the repo system, and calculates the collateral received (or passed) as the consideration of the bond and the bond amount first. The purpose of this is to compare the bond prices obtained and manage the difference as a margin. Specifically, the collateral management DB 214 is composed of a bond table and a collateral table, compares the bond value of the bond table with the collateral of the collateral table, and, when the difference exceeds a certain standard. As a margin call, the customer who has the right to exercise is notified. Note that the bond market value is a bond value per 100 yen face value of the bond, and the bond value is a value of a fixed face value bond calculated by the face value × bond market value.
[0043]
[Payment process at start]
Next, the flow of the payment process (at the start) of the GC repo transaction by the payment system 10 will be described in detail with reference to FIG. First, the client A, who is the fund taker, enters contract information from the repo registration screen. FIG. 8A is a diagram illustrating an example of the configuration of a repo registration screen. The repo registration screen includes an area for entering contract information, an area for displaying settlement account information, and an area for selecting a brand selection logic. The dealer of the customer A can input the contract information, specify the presence or absence of the netting, and specify the selection condition of the brand. When the dealer of the customer A selects “collateral search”, the terminal device 31 of the customer A transmits the input contract information and selection conditions to the settlement system 10. Note that the settlement account information is automatically displayed by searching for the settlement account master using the name of the business partner as a key.
[0044]
Returning to FIG. 7, the description will be continued. The settlement system 10 receives the contract information and the selection condition from the terminal device 31 of the customer A (S701). If the brand selection logic has been selected (S702; Yes), bond selection processing is executed (S703). Note that the bond selection processing will be described later with reference to FIG. When a bond is selected, a contract statement is created and registered in the contract DB 211 (S704).
[0045]
The settlement system 10 creates a settlement statement based on the settlement data obtained by adding settlement information to the contract data, and temporarily registers it in the settlement DB 212 (S705). Thereafter, the settlement system 10 transmits the contract statement and the settlement statement to the terminal device 31 of the customer A (S706). The terminal device 31 of the customer A displays the received contract statement and settlement statement on the repo statement screen. FIG. 8B is a diagram illustrating an example of the configuration of a repo detail screen. The repo statement screen includes an area for displaying the contents of the target contract, an area for displaying the selected bond brand, and an area for displaying settlement account information. When the dealer of the customer A selects “confirmation / transmission”, the confirmation data is transmitted. When “detailed change input” or “update” is selected, the change data is transmitted to the settlement system 10.
[0046]
When the settlement data is received from the terminal device 31 of the customer A (S707; Yes), the settlement system 10 transmits the contract and settlement statement to the terminal device 41 of the customer B (S708). When the change data is received (S707; No), the contract statement and the settlement statement are corrected (S709).
[0047]
The terminal device 41 of the customer B displays the received contract and settlement statement on the repo statement screen. FIG. 8C is a diagram illustrating an example of the configuration of the repo detail screen. The repo statement screen includes an area for displaying the contents of the target contract, an area for displaying the selected bond brand, and an area for displaying settlement account information. When the dealer of the customer B selects “approval / send”, the approval data is transmitted, and when the “rejection” or “self-payment account change input” is selected, the rejection data and the change data are transmitted to the settlement system 10. .
[0048]
When receiving the approval data from the terminal device 41 of the customer B (S710; Yes), the settlement system 10 confirms that the contract has been established and confirms the completion of the settlement of the settlement statement (S711), and temporarily registered in S705. The payment statement is registered as a formal payment statement (S713). Then, the settlement system 10 executes the DVP process based on the start settlement details on the contract start date (S714). When the DVP process is executed, the completion of the settlement is notified to the terminal device 31 of the customer A and the terminal device 41 of the customer B (S715).
[0049]
In the above-described processing, the case where the payment details are temporarily registered has been described. However, the payment details are transmitted to the customer without being stored in the payment DB, and the payment May be registered.
[0050]
[Brand selection process]
Next, the flow of brand selection by the settlement system 10 will be described in detail with reference to FIG. As shown in FIG. 8A, the brand selection logic according to the present embodiment includes basic logic and option logic. The selection of the basic logic is indispensable, and the selection of the option logic is optional. The user can arbitrarily combine these logics. As a prerequisite, for stocks scheduled to be paid out on the day of the sale or SC repo, the next day, etc., the corresponding balance is deducted in advance and calculated. If the option logic is selected, it is applied prior to the basic logic.
[0051]
Here, each basic logic will be described (see FIG. 8A). The issue number minimum priority logic, which is the first logic, is a logic configured to preferentially select issues with a large balance so as to minimize the issue number. The low balance priority brand logic, which is the second logic, is a logic configured to preferentially select brands with a small balance. The held brand apportioning logic, which is the third logic, is a logic configured to select a brand according to the owned balance apportionment. In the above logic, when there are a plurality of selectable brands, it is possible to set so as to give priority to a bond having a shorter remaining period (a period until maturity redemption).
[0052]
Next, the option logic will be described. First, the netting priority logic is configured to select a brand such that it can be paired off-netted with the end payment details automatically created at the start payment date. Second, the logic that considers certain reserves is configured to select a brand while leaving a certain percentage of the balance. For example, when "minimum each brand 20 has a balance" is set, brands having a balance larger than 20 are to be selected. Third, the cheapest brand priority logic is configured to preferentially select the cheapest brand.
[0053]
The logic for selecting a brand is not limited to the above-described logic, but may be set as appropriate.
[0054]
Returning to FIG. 9, the description will be continued. The settlement system 10 determines whether or not the option logic has been designated (S901). If the option logic has been designated, the settlement system 10 refers to the bond account of the fund taker and executes processing according to the designated logic. (S902, S903, S904).
[0055]
Subsequently, the settlement system 10 determines whether or not the basic logic is specified (S905). If the basic logic is specified, the settlement system 10 refers to the bond account of the fund holder to determine the specified basic logic. The processing is executed according to the logic (S906, S907, S908). If the basic logic is not specified, error processing is performed. When the processing of the option logic is executed, the basic logic is executed based on the processing result of the option logic.
[0056]
FIG. 10 is a diagram illustrating an example of an execution result of the brand selection process. According to the figure, it is understood that the selected brand differs depending on the selected logic. Here, a case where the bond 200 is selected from the brands A to R held in the bond account of the company A which is the fund taker will be exemplified. Therefore, for example, in the case of the basic logic 1, among the issues A, B, C, and D satisfying the condition of the basic logic 1, the issue C having the shortest remaining term of the bond is selected (see FIG. 1)). In the case of other logics, if there are a plurality of selectable issues, the issue with the shortest remaining term of the bond is selected (see (* 2) and (* 4) in the figure). Also, in the case of the combination of the option logic 1 and the basic logic 1, among the selectable issues A to I, the issue E with the shortest remaining term of the bond is selected (see FIG. 4 (* 4)). If the option logic 2 (see FIG. (* 5)) is set to "minimum, each brand 20 has a balance", the brands O to R are excluded. Here, since the brand F is the cheapest brand, the brand F is selected for the option logic 3 (see FIG. (* 6)).
[0057]
[Netting process]
Next, the flow of the netting process by the settlement system 10 will be described in detail with reference to FIG. When the settlement system 10 receives the contract input from the terminal device 31 of the customer A (S1101), the settlement system 10 determines whether or not the netting is designated (S1102). If it is determined that netting has been designated, netting processing is executed (S1103). Here, an outline of the netting process will be described with reference to FIGS.
[0058]
12 and 13 are diagrams for explaining the outline of the netting process. First, FIG. 12 shows (1) Company A raises 10 billion yen from Company B by GC repo. In this case, the start settlement statement (Ref. 0001) includes four brands (A, B, C, and D) totaling 10 billion yen from company A, which is the fund source, and 10 billion yen from company B, which is the source of the fund. The circle is the content to be delivered. The end settlement statement (Ref. 0001) is as follows: 10.4 billion yen of funds from Company A, the fund provider, and 4 brands (A, B, C, D) from Company B, the provider of funds, totaling 10 billion yen Are the contents to be passed respectively.
[0059]
Next, it is assumed that (2) Company A repurchased 10 billion yen from Company B by GC repo on the end settlement date of the above contract. In this case, the start settlement statement (Ref. 0099) includes four brands (A, C, D, and E) totaling 10 billion yen from company A, which is the fund source, and 10 billion yen from company B, the source of the fund. The circle is the content to be delivered. The end settlement statement (Ref. 0099) is as follows: 10.5 billion yen in funds from company A, the fund provider, and 10 billion yen in 4 brands (A, C, D, E) from company B, the provider of funds. Are the contents to be passed respectively.
[0060]
When company A inputs netting to the start settlement statement (Ref. 0099), the end settlement statement (Ref. 0001) and the start settlement statement (Ref. 0099) are subjected to the netting process.
[0061]
FIG. 13 shows the result of the netting process. An end settlement statement (Ref. 0001) and a start settlement statement (Ref. 0099) are netted, and a netting statement is created based on the result. In the netting statement, 400 million yen in funds from Company A, which is the source of funds, and 4 billion yen in total for 2 issues (C, E), and 4 billion yen in total, 2 issues (A, B) from Company B, the issuer of funds It can be seen that the circles are the contents to be delivered.
[0062]
Returning to FIG. 11, the description will be continued. After executing the netting process, the settlement system 10 notifies the terminal device 31 of the customer A of the netting details (S1104). The terminal device 31 of the customer A displays the received netting details on the netting confirmation screen. FIG. 14 is a diagram illustrating an example of a configuration of a netting confirmation screen. The netting confirmation screen includes an area for displaying the settlement details after netting and an area for displaying the original settlement details. When the person in charge of the customer A selects “confirmation”, confirmation data is transmitted to the settlement system 10.
[0063]
When receiving the confirmation data from the terminal device 31 of the customer A (S1105; Yes), the settlement system 10 transmits the netting details to the terminal device 41 of the customer B (S1107). The terminal device 41 of the customer B displays the received netting details on the netting confirmation screen as shown in FIG. When the person in charge of the customer B selects “confirmation”, the approval data is transmitted to the settlement system 10. When receiving the confirmation data from the terminal device 41 of the customer B company (S1108; Yes), the settlement system 10 confirms the establishment of the netting (S1109), and registers the netting details in the netting DB (S1111). The settlement statement after netting is registered in the settlement DB, and the original settlement statement is deleted from the settlement DB (S1112). Then, the settlement system 10 executes a DVP (Free Of Payment) (DOP) process on the settlement date (S1113). Note that the FOP process refers to a process of transferring a bond only when the transfer of funds becomes zero as a result of netting, and without transferring the bond.
[0064]
[Margin call processing]
Next, the flow of the margin call process by the settlement system 10 will be described in detail with reference to FIG.
[0065]
The settlement system 10 acquires the market value information of the bond from a bond market value database (not shown) that manages the market value of the bond, and updates the bond value in the bond table of the collateral management DB 214 based on the obtained market value information (S1501). ). Then, the bond value in the bond table is compared with the security value in the security table (S1502). Based on the comparison result, it is determined whether or not a margin call has occurred (S1503). If it is determined that a margin call has occurred, the fact that a margin call has occurred is notified to the customer who exercises the margin call. (S1504).
[0066]
The terminal device that has received the notification of the occurrence of the margin call can notify the occurrence of the margin call in real time by a message. FIG. 16A is a diagram illustrating an example of a screen of the terminal device that has been notified of the occurrence of the margin call. When the confirmation of the message is selected, the terminal device acquires the details of the margin call from the settlement system 10 and displays it on the margin call target list screen. The margin call target list screen has an area for displaying the details of the margin call. When the customer who exercises the margin call selects “execute margin call”, execution instruction data is transmitted to settlement system 10.
[0067]
Upon receiving the execution instruction data (S1505), the payment system 10 notifies the exercised right customer of the execution of the margin call (S1506). The terminal device that has received the notification of the execution of the margin call can notify the execution of the margin call by a message in real time.
[0068]
FIG. 16B is a diagram illustrating an example of the screen of the terminal device that has been notified of the execution of the margin call. When the confirmation of the message is selected, the terminal device obtains the details of the margin call from the settlement system 10 and displays it on the margin call execution notification screen. The margin call execution notification screen has an area for displaying the contents of execution of the margin call. When the margin call exercised right side customer selects “margin call confirmation”, confirmation data is transmitted to the settlement system 10.
[0069]
When receiving the confirmation data (S1507), the payment system 10 creates a margin call payment statement and registers it in the payment statement DB (S1508). Then, the settlement system 10 executes a margin call settlement process (S1510). That is, the difference between the value of the bond and the security money is transferred from the fund account of the exerciser customer to the fund account of the exerciser customer so that the bond value and the security money match.
Upon completion of the margin call settlement processing, the completion of the margin call settlement is notified to the exerciser customer and the exerciser customer (S1511). Then, the security money in the security money management DB 214 is updated (S1512). Further, the end payment details in the payment details DB 212 are updated (S1513). That is, the end amount of the end settlement statement is updated.
[0070]
FIG. 17 is a diagram illustrating an example of a result of the margin call settlement process. First, (1) As a state before the transaction, the bond balance of Company A is 500 yen in par value (500 yen in market value), and the fund account of Company B is 1000 yen. Here, it is assumed that the contract is executed with "GC repo 500 yen" and the transaction is started.
[0071]
(2) At the start of the transaction, 500 yen is transferred from the fund account of Company B to the fund account of Company A, and the face value of the bond is transferred from the bond account of Company A to the bond account of Company B.
[0072]
Thereafter, (3) the market value of the bond drops from 500 yen to 450 yen in face value, causing a margin call, and Company B exercises the margin call. As a result, 50 yen has been transferred from the fund account of Company A to the fund account of Company B. Since the occurrence of the margin call is automatically notified to the company B, the company B only needs to determine whether or not to exercise the margin call.
[0073]
Thereafter, (3) the market value of the bond increased from 450 yen to 550 yen, causing a margin call to occur again, and Company A exercised the margin call. As a result, 100 yen has been transferred from the fund account of Company B to the fund account of Company A. At this time, since the occurrence of the margin call is automatically notified to the company A, the company A only needs to determine whether to exercise the margin call.
[0074]
(5) At the end of the transaction, 550 yen has been transferred from the fund account of Company A to the fund account of Company B, and the face value of the loan has been transferred from the bond account of Company B to the bond account of Company A. Since the end settlement details are automatically updated each time a margin call is exercised, companies A and B can complete the transaction without managing the end settlement details.
[0075]
[End payment process]
Next, the flow of the settlement process at the end by the settlement system 10 will be described in detail with reference to FIG. When the processing date corresponds to the end date of the end settlement statement (S1801: Yes), the settlement system 10 determines whether the end settlement statement is netted (S1802). If the net has been set (S1802; Yes), the above-described netting processing is executed (S1803). If the net has not been set (S1801; No), the gross processing according to the end settlement specification is executed. (S1804). When the settlement is completed, the completion of the settlement is notified to the fund taker and the fund issuer.
[Other embodiments]
Each of the above embodiments is an example for explaining the present invention, and is not intended to limit the present invention to only these embodiments. The present invention can be implemented in various forms without departing from the gist thereof. In the above flowchart, the request message receiving process has been described in a sequential manner. However, as long as there is no inconsistency in the operation, the order of the processes may be changed or the processes may be performed in parallel.
[0076]
For example, in the above embodiment, the case where the present invention is applied to the GC repo has been described, but the present invention may be applied to the SC repo. In this case, the automatic brand selection function may be a function used only in the case of GC, and in the case of SC, the brand may be manually selected by setting it to SC (brand input) or the like. Further, in the above embodiment applied to the GC repo, it is assumed that the fund holder inputs the contract, but in the case of the SC repo, the bond holder (fund source) inputs the contract. Is also good.
[0077]
【The invention's effect】
According to the present invention, a series of operations from execution to settlement in a repo transaction is converted to STP, and only confirmation input such as execution of a contract input, confirmation of a contract statement and a settlement statement, exercise of a margin call, execution / confirmation of netting, etc. are performed. In addition to improving the efficiency of office work and reducing operation risk, it is also possible to cope with the T + 1 shift in securities settlement that has been pursued through the settlement system reform.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating functions and an overall scheme of a payment system according to an embodiment.
FIG. 2 is a flowchart showing an overall flow of a settlement process by a settlement system 10.
FIG. 3 is a diagram illustrating an example of a data structure of a repo DB 211.
FIG. 4 is a diagram illustrating an example of a data structure of a settlement DB 212.
FIG. 5 is a diagram illustrating an example of a data structure of a netting DB 213.
FIG. 6 is a diagram illustrating an example of a data structure of a security management DB 214.
FIG. 7 is a flowchart showing a flow of a settlement process (at the time of start) by the settlement system 10.
FIG. 8 is a diagram showing an example of a configuration of a GC repo registration screen and the like.
FIG. 9 is a flowchart showing a flow of brand selection by the settlement system 10.
FIG. 10 is a diagram illustrating an example of an execution result of a brand selection process.
FIG. 11 is a flowchart showing a flow of a netting process by the settlement system 10.
FIG. 12 is a diagram for explaining an outline of a netting process.
FIG. 13 is a diagram illustrating an outline of a netting process.
FIG. 14 is a diagram illustrating an example of a configuration of a netting confirmation screen.
FIG. 15 is a flowchart showing a flow of a margin call process by the settlement system 10.
FIG. 16 is a diagram illustrating an example of a screen of a terminal device that has been notified of the occurrence of a margin call.
FIG. 17 is a diagram illustrating an example of a result of a margin call settlement process.
FIG. 18 is a flowchart showing the flow of an end payment process by the payment system 10.
FIG. 19 is a diagram showing a flow of a conventional GC repo transaction using the BOJ-NET.
[Explanation of symbols]
10. Payment system
20 ... IF system
21 ... Repo system
22 ... Funding system
23 ... Bond system
30… Customer A company
40… Customer B company

Claims

Storage means for storing a fund account for managing customer funds and a bond account for managing customer bonds;
Receiving contract information based on the repo transaction from the terminal device of the fund taker, creating means for creating a contract statement and a settlement statement based on the received contract information,
The created contract statement and settlement statement are transmitted to the terminal device of the fund taker and the sender side, and when the confirmation data for the transmitted contract statement and settlement statement is received from both terminal devices, the contract statement and settlement statement is determined. Means for determining
Based on the determined settlement statement, transfer a predetermined bond balance from the bond account of the fund taker to the bond account of the fund taker, and transfer the fund of the fund taker from the fund account of the fund taker. Settlement means for executing settlement by transferring a predetermined amount to an account;
A payment system comprising:

2. The system according to claim 1, further comprising: a bond issue selecting means for selecting a bond issue from the bond issues stored in the bond account of the fund taker based on the contract information in accordance with predetermined conditions. The payment system described.

When a netting instruction for the first contract is received from the terminal device on the fund taker side, the start settlement statement of the first contract and the second settlement whose start settlement date and end settlement date of the first contract match. Further comprising netting means for performing netting based on the end settlement statement of the contract of
The settlement system according to claim 1, wherein the settlement unit executes settlement based on a result of the executed netting.

Storage means for storing the bond subject to the contract and the collateral received as consideration for the bond in association with each other,
Obtain the market value of the bond, compare the bond value calculated based on the market value of the obtained bond with the collateral stored in the storage unit, and determine whether a margin call has occurred based on the comparison result. Margin call determination means to
If it is determined that a margin call has occurred, the terminal device on the margin call exercising side is notified of the occurrence of the margin call, and if it is received from the terminal device on the margin call exercising side that the margin call is to be exercised, Notification means for notifying the terminal device on the exercise side of the margin call that the margin call is exercised;
A margin call settlement means for generating a margin call settlement statement and executing the margin call settlement when a confirmation of the exercise of the margin call is received from the terminal device on the margin call exercised side;
Updating means for updating the security deposit of the storage means based on the execution result of the margin call settlement, and updating the end settlement details of the contract,
The settlement system according to any one of claims 1 to 3, further comprising:

A payment method for performing payment between customers in a payment system configured to allow communication between a terminal device and a server of the customer,
When receiving the contract information based on the repo transaction from the terminal device of the fund taker, creates a contract statement and a settlement statement based on the received contract information,
The created contract statement and settlement statement are transmitted to the terminal device of the fund taker and the sender side, and when the confirmation data for the transmitted contract statement and settlement statement is received from both terminal devices, the contract statement and settlement statement is determined. And
Based on the determined settlement statement, while transferring a predetermined bond balance from the bond account of the fund taker to the bond account of the fund taker, and the fund of the fund taker from the fund account of the fund taker A settlement method characterized by executing settlement by transferring a predetermined amount to an account.

6. The settlement method according to claim 5, wherein a bond brand is selected from the bond brands stored in the bond account of the fund taker based on the contract information in accordance with a predetermined condition.

When a netting instruction for the first contract is received from the terminal device on the fund taker side, the start settlement statement of the first contract and the second settlement whose start settlement date and end settlement date of the first contract match. Perform netting based on the contract's end settlement statement and
The settlement method according to claim 5, wherein the settlement is executed based on a result of the executed netting.

The bond subject to the contract and the collateral received as consideration for the bond are stored in association with each other,
Obtain the market value of the bond, compare the bond value calculated based on the market value of the obtained bond with the stored collateral, and determine whether a margin call has occurred based on the comparison result,
When it is determined that a margin call has occurred, the terminal device on the margin call exercising side is notified of the occurrence of the margin call, and when it is received from the terminal device on the margin call exercising side that the margin call is to be exercised, the margin call is made. Notify the terminal device on the exercised side of the margin call that the call is exercised,
If a confirmation of the exercise of the margin call is received from the terminal device on the exercise side of the margin call, a margin call settlement statement is created and the margin call is executed,
The settlement method according to any one of claims 5 to 7, wherein the security deposit in the storage unit is updated based on the execution result of the margin call settlement, and the end settlement statement of the contract is updated.

An information processing program for causing a computer to execute the settlement method according to claim 5.