複合取引情報管理システム及び方法
【課題】既存の金融商品に対応した情報システムの個別の機能を有効活用して、一つの複雑な金融商品の取り扱いを実現することにより、ユーザの入力負担を軽減すること。
【解決手段】第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品に対して予め定められた分解ロジックに基づいて、第１の取引情報と、第２の取引情報に分解して出力する取引受付システムと、第１の取引情報を入力し、これを管理する第１の取引管理システムと、第２の取引情報を入力し、これを管理する第２の取引管理システムと、を備える。取引受付システムは、第１の金融商品の項目のうち受け付けた複合金融商品に含まれない項目におけるデータを補完して第１の取引情報を生成し、第２の金融商品の項目のうち受け付けた複合金融商品に含まれない項目におけるデータを補完し、第１の取引情報に対応するデータを含めて第２の取引情報を生成する取引情報生成手段を備える。
【解決手段】第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品に対して予め定められた分解ロジックに基づいて、第１の取引情報と、第２の取引情報に分解して出力する取引受付システムと、第１の取引情報を入力し、これを管理する第１の取引管理システムと、第２の取引情報を入力し、これを管理する第２の取引管理システムと、を備える。取引受付システムは、第１の金融商品の項目のうち受け付けた複合金融商品に含まれない項目におけるデータを補完して第１の取引情報を生成し、第２の金融商品の項目のうち受け付けた複合金融商品に含まれない項目におけるデータを補完し、第１の取引情報に対応するデータを含めて第２の取引情報を生成する取引情報生成手段を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複合取引情報管理システム及び方法に関し、特に、複雑なデリバティブの性質を内在する債券である仕組債等の複合取引情報を管理する複合取引情報管理システム及び方法に関する。
【背景技術】
【０００２】
近年、複雑なデリバティブの性質を内在する債券であるデリバティブ内在型の仕組債や非標準型のデリバティブ商品等に代表される複雑な金融商品が開発されている。そして、このような複雑な金融商品の種類や取引件数は、年々、増加する傾向がある。また、金融機関は、従来から単一のデリバティブ商品等の金融商品それぞれに特化した専用の情報システムを有している。例えば、特許文献１には、デリバティブ商品を扱う情報システムに関する技術が開示されている。
【０００３】
一方、複雑な金融商品は、複数の単一のデリバティブ商品等の金融商品を複数組み合わせて表現することが可能である。例えば、「金利交換」に関する金融商品である場合には、金利を支払う商品と、金利を受け取る商品という２つの単一の金融商品の組合せで表現することができる。そこで、オペレータは、まず、複雑な金融商品における一つの契約を既存のデリバティブ商品等に分割して複数の取引の組合せで管理する。そして、分割した複数の取引のそれぞれについて、対応する専用の情報システムに対して個別に入力作業を行う。これにより、複数の取引により、複雑な金融商品における一つの契約と同一の経済効果を奏するものとみなすことができる。そのため、複雑な金融商品の専用の新規システム開発をせずとも新規の複雑な金融商品の取り扱いを始めることが可能である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−５６１８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した手法では、各情報システムへの入力を行うオペレータの作業負担が大きいという問題がある。その理由は、本来、一つの契約であるにもかかわらず、実質的に複数の取引に相当する入力作業が発生するためである。また、複雑な金融商品から単一のデリバティブ商品に分割するには、各商品が単独の取引として成立し得るように、各取引に対するデータの修正や補完等を適宜行う必要がある。これらのデータの修正や補完等は、分割された各商品に対応する情報システムごとに、また、分割元の金融商品に応じて複雑なパターンがあり、作業が煩雑である。
【０００６】
一方、新規の複雑な金融商品の取り扱いを始めるに当たり、当該新規な金融商品に対応したシステムを個別に開発するか、既存の情報システムへ当該金融商品に対応した機能を追加するなども考えられる。しかしながら、その場合は、相応の開発コストとスケジュールを要することから、取引の機会喪失リスクが顕在化する可能性が高く、取り扱い件数が少ないケースでは当該リスクは顕著である。その理由は、複雑な金融商品は、取引元と取引先の双方の要望に応えるべく、詳細な取引条件が取引ごとに様々に変動するという特徴があるからである。また、近年の複雑な金融商品の一種類当たりの取り扱い件数は、単一のデリバティブ商品に比べて少ないという特徴がある。そのため、新規の複雑な金融商品のために新規に情報システムを開発した場合の費用対効果が低く、有効な対策とはいえない。
【０００７】
本発明は、このような問題を解決するためになされたものであり、既存の金融商品に対応した情報システムの個別の機能を有効活用して、一つの複雑な金融商品の取り扱いを実現することにより、ユーザの入力負担を軽減した複合取引情報管理システム及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の第１の態様にかかる複合取引情報管理システムは、第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を管理する複合取引情報管理システムであって、前記複合取引情報を外部から受け付けて、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、前記第１の金融商品の取引情報である第１の取引情報と、前記第２の金融商品の取引情報である第２の取引情報に分解して出力する取引受付システムと、前記取引受付システムより出力された第１の取引情報を入力し、これを管理する第１の取引管理システムと、前記取引受付システムより出力された第２の取引情報を入力し、これを管理する第２の取引管理システムと、を備え、前記取引受付システムは、前記第１の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完して前記第１の取引情報を生成し、前記第２の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完し、前記第１の取引情報に対応するデータを含めて前記第２の取引情報を生成する取引情報生成手段を備える。
【０００９】
また、前記第１の取引管理システムは、第１のデータ形式に基づく第１の処理要求を外部から受信し、当該第１の処理要求に基づいて、前記第１の取引情報を管理するための第１のデータベースに対して処理を行う第１のＩＦ手段を備え、前記第２の取引管理システムは、第２のデータ形式に基づく第２の処理要求を外部から受信し、当該第２の処理要求に基づいて、前記第２の取引情報を管理するための第２のデータベースに対して処理を行う第２のＩＦ手段を備え、前記取引受付システムは、前記第１のＩＦ手段に対して、前記第１の処理要求に前記生成された第１の取引情報を含めて送信する第１の処理要求手段と、前記第２のＩＦ手段に対して、前記第２の処理要求に前記生成された第２の取引情報を含めて送信する第２の処理要求手段と、を備えることが望ましい。
【００１０】
さらに、前記第１の処理要求手段は、前記第１のＩＦ手段に対して、前記生成した第１の取引情報を含めて前記第１のデータ形式に基づく第１の登録要求を送信し、前記第１のＩＦ手段は、前記第１の登録要求を受信した場合に、当該第１の登録要求に含まれる第１の取引情報を前記第１のデータベースへ登録し、登録された第１の取引情報に対して発行された取引識別情報を前記第１の処理要求手段へ返信し、前記第２の処理要求手段は、前記第１の処理要求手段が前記第１のＩＦ手段から前記取引識別情報を受信した場合に、前記第２のＩＦ手段に対して、当該取引識別情報と前記生成した第２の取引情報とを含めて前記第２のデータ形式に基づく第２の登録要求を送信し、前記第２のＩＦ手段は、前記第２の登録要求を受信した場合に、当該第２の登録要求に含まれる第２の取引情報を当該第２の登録要求に含まれる取引識別情報に関連付けて前記第２のデータベースへ登録することが望ましい。
【００１１】
また、前記取引受付システムは、ユーザの識別情報を含む前記複合取引情報を外部から受け付けた場合に、当該ユーザの識別情報に基づき、当該取引受付システムにおける認証を行う認証手段をさらに備え、前記第１の処理要求手段は、前記認証手段により認証された場合に、前記第１のＩＦ手段に対して、前記第１の処理要求に前記取引受付システムの識別情報をさらに含めて送信し、前記複合取引情報管理システムは、前記第１のＩＦ手段を介した処理を許可する外部システムの識別情報を格納する記憶部をさらに備え、前記第１のＩＦ手段は、前記第１の処理要求手段から受信した第１の処理要求に含まれる前記取引受付システムの識別情報に基づき、前記記憶部を参照し、当該取引受付システムが当該第１のＩＦ手段を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、前記第１の処理要求に含まれる前記第１の取引情報を用いて前記第１のデータベースに対して処理を行うことが望ましい。
【００１２】
さらに、前記記憶部は、前記外部システムの識別情報を前記第１のＩＦ手段が受信する処理要求の種別ごとに関連付けて記憶し、前記第１のＩＦ手段は、前記第１の処理要求手段から受信した第１の処理要求の種別に基づき、前記記憶部を参照し、当該取引受付システムが前記第１のＩＦ手段を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、前記第１の処理要求に含まれる前記第１の取引情報を用いて前記第１のデータベースに対して処理を行うとよい。
【００１３】
また、前記取引情報生成手段は、前記第１の金融商品の項目のうち前記複合金融商品に含まれる項目におけるデータを、前記第１の金融商品の項目に対応するように補正して前記第１の取引情報を生成し、前記第１の取引情報の逆取引となるデータを含めて前記第２の取引情報を生成するとよい。
【００１４】
また、前記複合金融商品は、所定の金利条件と、取引期間の決定条件とを含む金融商品であり、前記第１の金融商品は、前記所定の金利条件についての取引期間が固定された金融商品であり、前記第２の金融商品は、前記取引期間の決定条件に関する金融商品であり、前記取引情報生成手段は、前記複合取引情報に含まれる日付のデータを固定期間となるように補正して前記第１の取引情報を生成し、前記複合取引情報に含まれる取引期間の決定条件を用いて前記第２の取引情報を生成するとよい。
【００１５】
また、前記取引情報生成手段は、前記複合取引情報を登録する場合には、当該複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定された場合の取引期間となるように前記第１の取引情報を生成し、前記複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定されなかった場合には、当該取引期間を延長するように前記第１の取引情報を生成するとよい。
【００１６】
また、前記取引情報生成手段は、前記複合取引情報における一部の契約が確定した場合に、未確定の契約に基づき、前記第１の取引情報及び前記第２の取引情報の更新情報を生成し、前記第１の処理要求手段は、前記第１のＩＦ手段に対して、前記生成した第１の取引情報の更新情報を含めて前記第１のデータ形式に基づく第１の更新要求を送信し、前記第１のＩＦ手段は、前記第１の更新要求を受信した場合に、当該第１の更新要求に含まれる第１の取引情報の更新情報に基づき前記第１のデータベースに登録された第１の取引情報を更新し、前記第２の処理要求手段は、前記取引識別情報と前記生成した第２の取引情報の更新情報とを含めて前記第２のデータ形式に基づく第２の更新要求を送信し、前記第２のＩＦ手段は、前記第２の更新要求を受信した場合に、当該第２の更新要求に含まれる第２の取引情報の更新情報及び当該第２の更新要求に含まれる取引識別情報に基づき、前記第２のデータベースに登録された第２の取引情報を更新するとよい。
【００１７】
本発明の第２の態様にかかる複合取引情報管理方法は、第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を外部から受け付ける取引受付システムと、前記第１の金融商品の取引情報である第１の取引情報を管理する第１の取引管理システムと、前記第２の金融商品の取引情報である第２の取引情報を管理する第２の取引管理システムと、を用いて、前記複合取引情報を管理する複合取引情報管理方法であって、前記取引受付システムにおいて、前記外部から受け付けた前記複合取引情報から、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、前記第１の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完して前記第１の取引情報を生成し、前記取引受付システムにおいて、前記複合取引情報から、前記分解ロジックに基づいて、前記第２の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完し、前記第１の取引情報に対応するデータを含めて前記第２の取引情報を生成し、前記取引受付システムにおいて、前記生成した第１の取引情報を前記第１の取引管理システムに対して出力し、前記第１の取引管理システムにおいて、前記取引受付システムより出力された第１の取引情報を入力し、当該入力された第１の取引情報について、当該第１の取引情報を管理するための第１のデータベースに対して処理を行い、前記取引受付システムにおいて、前記生成した第２の取引情報を前記第２の取引管理システムに対して出力し、前記第２の取引管理システムにおいて、前記取引受付システムより出力された第２の取引情報を入力し、当該入力された第２の取引情報について、当該第２の取引情報を管理するための第２のデータベースに対して処理を行う。
【発明の効果】
【００１８】
本発明によれば、既存の金融商品に対応した情報システムの個別の機能を有効活用して、一つの複雑な金融商品の取り扱いを実現することにより、ユーザの入力負担を軽減した複合取引情報管理システム及び方法を提供することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態１にかかる複合取引情報管理システムの全体構成を示すブロック図である。
【図２】本発明の実施の形態１にかかる仕組債の項目及び入力データの例を示す図である。
【図３】本発明の実施の形態１にかかるＷｅｂサービスのアクセス制限情報の例を示す図である。
【図４】本発明の実施の形態１にかかる親取引（スワップ）の項目の例を示す図である。
【図５】本発明の実施の形態１にかかる取引情報の項目毎の生成方法の例を示す図である。
【図６】本発明の実施の形態１にかかる子取引（スワップション）の項目の例を示す図である。
【図７】本発明の実施の形態１にかかる生成される親取引情報の一部（クーポン及びコスト）の例を示す図である。
【図８】本発明の実施の形態１にかかる生成される子取引情報の一部（クーポン及びコスト）の例を示す図である。
【図９】本発明の実施の形態１にかかる取引受付システムのハードウェア構成を示すブロック図である。
【図１０】本発明の実施の形態１にかかる取引管理システムのハードウェア構成を示すブロック図である。
【図１１】本発明の実施の形態１にかかる仕組債登録処理の流れを示すシーケンス図である。
【図１２】本発明の実施の形態１にかかる取引受付システムの処理要求の受付処理の流れを示すフローチャートである。
【図１３】本発明の実施の形態１にかかる取引管理システムの処理要求に応じた処理の流れを示すフローチャートである。
【図１４】本発明の実施の形態１にかかる複合取引情報管理システムの応用例の全体構成を示すブロック図である。
【発明を実施するための形態】
【００２０】
以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
【００２１】
＜発明の実施の形態１＞
図１は、本発明の実施の形態１にかかる複合取引情報管理システム１００の全体構成を示すブロック図である。複合取引情報管理システム１００は、第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を管理する情報システムである。複合金融商品とは、例えば、上述したデリバティブ内在型の仕組債や非標準型のデリバティブ商品等の複雑な金融商品を指す。そして、複合取引情報管理システム１００は、当該複合金融商品のみを管理するための専用のデータベースシステムを用いずに、既存の複数の金融商品のそれぞれを管理するためのデータベースシステムを当該複合金融商品と同等の経済効果を奏するように組み合わせることで、当該複合金融商品の管理を実現するものである。
【００２２】
ここで、複合金融商品としては、例えば、マルチコーラブル型の仕組債が挙げられる。図２は、本発明の実施の形態１にかかる複合金融商品の一例である仕組債の項目及び入力データの例を示す図である。すなわち、マルチコーラブル型の仕組債における項目の一部と、これらの項目に対応するデータ、つまり、複合取引情報の一例である。尚、当該仕組債における項目及びデータは、これに限定されない。
【００２３】
また、複合金融商品が第１の金融商品と第２の金融商品の特性に分解可能であるとは、例えば、複合金融商品がマルチコーラブル型の仕組債である場合に、デリバティブ部分については、第１の金融商品としてスワップ取引の商品及び第２の金融商品としてスワップション取引の商品として分解できることが挙げられる。尚、複合金融商品の分解の仕方はこれに限定されない。
【００２４】
この場合、複合金融商品は、所定の金利条件と、取引期間の決定条件とを含む金融商品であるといえる。そして、第１の金融商品は、所定の金利条件についての取引期間が固定された金融商品であるといえる。また、第２の金融商品は、取引期間の決定条件に関する金融商品であるといえる。尚、複合金融商品が当該仕組債以外の金融商品である場合には、これらとは異なる特性を含むものとなる。
【００２５】
但し、複合金融商品は、第１の金融商品及び第２の金融商品それぞれの項目自体を単純に足し合わせたものではなく、第１の金融商品及び第２の金融商品それぞれの特性の一部分を含むものである。そのため、第１の金融商品及び第２の金融商品に共通する項目もあれば、いずれかにしか存在しない項目もある。さらに、複合金融商品における一の項目が第１の金融商品又は第２の金融商品における複数の項目に対応する場合もある。そのため、複合金融商品の項目数は、第１の金融商品及び第２の金融商品それぞれの項目数に比べて十分に少ないものとなる。また、第１の金融商品及び第２の金融商品の項目が共通する場合であっても、異なるデータとする必要もある。すなわち、これらを合わせて複合金融商品と同一の経済効果を奏するためには、第１の金融商品と第２の金融商品との間で、整合性を保つためのデータの加工が必要な場合もある。
【００２６】
図１に戻り、説明する。複合取引情報管理システム１００は、端末１と、取引受付システム２と、取引管理システム群３とを備える。端末１は、取引受付システム２に対して複合取引情報の入力を行う。端末１は、キーボードやマウス等の入力装置（不図示）と、画面等の表示装置（不図示）とを備える端末装置である。端末１は、例えば、通信機能を備え、ＷＥＢブラウザ等の表示アプリケーションを備えたパーソナルコンピュータであるとよい。
【００２７】
取引受付システム２は、端末１等の外部から複合取引情報を受け付けて、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、第１の金融商品の取引情報である第１の取引情報と、第２の金融商品の取引情報である第２の取引情報に分解して出力する情報システムである。取引受付システム２は、例えば、ＷＥＢアプリケーションにより実現される。ここで、分解ロジックとしては、複合金融商品と第１の金融商品及び第２の金融商品との項目の対応付けの定義や、データの補完処理、補正処理、第１の金融商品と第２の金融商品との間で入れ替えるデータの定義等を含む。尚、取引受付システム２の具体的なハードウェア構成については、図９にて後述する。尚、取引受付システム２は、１台又は複数台のコンピュータ装置により実現されるものである。また、取引受付システム２は、受付手段２１と、取引情報生成手段２２と、ＷＳＣ（Web Service Client）２３１と、ＷＳＣ２３２とを備える。
【００２８】
受付手段２１は、端末１から入力される複合取引情報を含む処理要求を受け付ける。そして、受付手段２１は、受け付けた複合取引情報を取引情報生成手段２２へ出力する。その際、受付手段２１は、端末１に対してアクセス認証を行うことが望ましい。例えば、受付手段２１は、端末１からユーザの識別情報を含む複合取引情報を受け付けた場合に、当該ユーザの識別情報に基づき、取引受付システム２における認証を行う。そして、受付手段２１は、認証できた場合に、受け付けた複合取引情報を取引情報生成手段２２へ出力する。尚、端末１からの処理要求として、例えば、複合取引情報の登録要求、更新要求、削除要求、契約中の途中解約要求及び承認要求等が含まれる。
【００２９】
また、受付手段２１は、端末１からのアクセス要求に対する応答として、複合取引情報の入力画面を返信するとよい。その場合、端末１の表示装置上に、当該入力画面が表示される。例えば、入力画面の項目としては、図２の各項目についてのデータ入力欄が含まれる。これにより、端末１を操作するユーザにおける複合取引情報の入力作業を支援することができる。但し、受付手段２１は、少なくとも端末１から送信される複合取引情報を受け付けることができれば、実現手段は問わないものとする。つまり、受付手段２１は、端末１から図２のデータを受け付けることができればよい。
【００３０】
取引情報生成手段２２は、受付手段２１から出力された複合取引情報から第１の取引情報及び第２取引情報に分解する処理を行う。すなわち、取引情報生成手段２２は、複合取引情報から、第１の金融商品の項目のうち受け付けた複合金融商品に含まれない項目におけるデータを補完して第１の取引情報を生成する。また、取引情報生成手段２２は、複合取引情報から、第２の金融商品の項目のうち受け付けた複合金融商品に含まれない項目におけるデータを補完し、第１の取引情報に対応するデータを含めて第２の取引情報を生成する。また、取引情報生成手段２２は、１の複合取引情報から２以上の取引情報に分解するものである。そのため、ここでは、第１の取引情報を親取引とし、第２の取引情報を親取引との整合性を保つためのデータを含む子取引とする。尚、子取引は、複数存在しても構わない。
【００３１】
ＷＳＣ２３１は、後述するＷｅｂサービスサーバであるＷＳＳ（Web Service Server）３１１との通信が可能なＷｅｂサービスクライアントである。すなわち、ＷＳＣ２３１は、ＷＳＳ３１１に対して、ＷＳＳ３１１が処理可能な第１のデータ形式に基づく第１の処理要求に、取引情報生成手段２２により生成された第１の取引情報を含めて送信する第１の処理要求手段といえる。さらに、ＷＳＣ２３１は、受付手段２１において複合取引情報に含まれるユーザの識別情報が認証された場合に、ＷＳＳ３１１に対して、第１の処理要求に取引受付システム２の識別情報をさらに含めて送信する。
【００３２】
また、ＷＳＣ２３２は、後述するＷｅｂサービスサーバであるＷＳＳ３２１との通信が可能なＷｅｂサービスクライアントである。すなわち、ＷＳＣ２３２は、ＷＳＳ３２１に対して、ＷＳＳ３２１が処理可能な第２のデータ形式に基づく第２の処理要求に、取引情報生成手段２２により生成された第２の取引情報を含めて送信する第２の処理要求手段といえる。さらに、ＷＳＣ２３２は、受付手段２１において複合取引情報に含まれるユーザの識別情報が認証された場合に、ＷＳＳ３２１に対して、第２の処理要求に取引受付システム２の識別情報をさらに含めて送信する。
【００３３】
取引管理システム群３は、取引管理システム３１及び３２と、ＷＥＢサービスアクセス制限ＤＢ３０とを備える。尚、取引管理システム群３は、一つの情報システム又は複数の情報システムの集合のいずれであっても構わない。但し、以降の説明では、便宜上、取引管理システム３１と、取引管理システム３２とは異なる情報システムであるものとして説明する。
【００３４】
取引管理システム３１及び３２は、それぞれ単一の金融商品における取引情報を管理するための情報システムである。尚、取引管理システム３１及び３２の具体的なハードウェア構成については、図１０にて後述する。取引管理システム３１は、取引受付システム２より出力された第１の取引情報を入力し、これを管理する情報システムである。取引管理システム３１は、ＷＳＳ３１１と、取引処理手段３１２と、金融商品ＤＢ３１３とを備える。
【００３５】
金融商品ＤＢ３１３は、第１の取引情報を管理するためのＤＢＭＳ（DataBase Management System）及びデータを格納する記憶領域である。取引処理手段３１２は、外部からの処理要求に応じて、金融商品ＤＢ３１３に対するアクセスを行う。そして、ＷＳＳ３１１は、取引処理手段３１２に対して外部からの処理要求と同等の処理要求を出力する。つまり、ＷＳＳ３１１は、第１のデータ形式に基づく第１の処理要求を外部から受信し、当該第１の処理要求に基づいて、取引処理手段３１２を介して金融商品ＤＢ３１３に対して処理を行うＷｅｂサービスサーバである。ここで、第１のデータ形式とは、例えば、ＷＳＤＬ（Web Services Description Language）ファイルに定義された情報である。すなわち、上述したＷＳＣ２３１は、当該ＷＳＤＬに基づく通信を行うものである。そのため、ＷＳＳ３１１は、当該ＷＳＤＬに基づく通信であれば、取引受付システム２に限らず、任意の外部のシステムから第１の処理要求を受信し、所定の処理を行うことができる。
【００３６】
ここで、取引処理手段３１２及び金融商品ＤＢ３１３には、既存の単一の金融商品を管理するためのデータベースシステムを用いることが可能である。その場合、例えば、取引処理手段３１２へのアクセス要求を行うための専用のクライアントアプリケーションが存在するものとする。このとき、ユーザは、端末１内に搭載された当該クライアントアプリケーションを用いて、取引処理手段３１２を介して金融商品ＤＢ３１３にアクセスし、所定の処理を行うことができる。つまり、取引処理手段３１２及び金融商品ＤＢ３１３は、取引受付システム２以外の外部のシステム等からも利用されている可能性が高い。そのため、新規な金融商品を採用するに当たり、既存のデータベースシステムを用いるとしても、そのために、取引処理手段３１２及び金融商品ＤＢ３１３に改修を加えることは、困難である。その理由は、既存の外部のシステム等への影響が大きいためである。
【００３７】
そこで、本発明の実施の形態１では、取引処理手段３１２及び金融商品ＤＢ３１３が既存の機能だとしても、これらに手を加えず、任意の外部のシステムからの処理要求を受け付け可能なＷＳＳ３１１を追加することで、既存のサービスを維持しつつ、新規な金融商品のためにも当該取引処理手段３１２及び金融商品ＤＢ３１３の機能を利用することを可能とした。そのため、取引受付システム２は、ＷＳＳ３１１との通信が可能なＷＳＣ２３１を介して処理要求を行うようにするだけで、他の実装については、採用する金融商品に特化した処理を含めることが可能となり、実現可能な機能の自由度が高まる。加えて、既存の機能の再利用性が高まるため、新規な金融商品の採用に応じた開発コストを抑えることができる。特に、仕組債のような複雑な金融商品は、総取引数が既存の金融商品に比べて少なく、商品サイクルが短く、新たな金融商品が次々と開発される。そのため、既存の機能の再利用性を高めることの効果が大きい。
【００３８】
また、取引管理システム３２は、取引受付システム２より出力された第２の取引情報を入力し、これを管理する情報システムである。取引管理システム３２は、ＷＳＳ３２１と、取引処理手段３２２と、金融商品ＤＢ３２３とを備える。
【００３９】
金融商品ＤＢ３２３は、第２の取引情報を管理するためのＤＢＭＳ及びデータを格納する記憶領域である。取引処理手段３２２は、外部からの処理要求に応じて、金融商品ＤＢ３２３に対するアクセスを行う。そして、ＷＳＳ３２１は、取引処理手段３２２に対して外部からの処理要求と同等の処理要求を出力する。つまり、ＷＳＳ３２１は、第２のデータ形式に基づく第２の処理要求を外部から受信し、当該第２の処理要求に基づいて、取引処理手段３２２を介して金融商品ＤＢ３２３に対して処理を行うＷｅｂサービスサーバである。ここで、第２のデータ形式とは、例えば、ＷＳＤＬファイルに定義された情報である。すなわち、上述したＷＳＣ２３２は、当該ＷＳＤＬに基づく通信を行うものである。そのため、ＷＳＳ３２１は、当該ＷＳＤＬに基づく通信であれば、取引受付システム２に限らず、任意の外部のシステムから第２の処理要求を受信し、所定の処理を行うことができる。
【００４０】
尚、取引処理手段３２２及び金融商品ＤＢ３２３に、既存の単一の金融商品を管理するためのデータベースシステムを用いることが可能である。すなわち、取引管理システム３２における本発明の実施の形態１に関係する構成の詳細や特徴は、取引管理システム３１と同等であるため、詳細な説明を省略する。
【００４１】
このように、ＷＳＳ３１１及び３２１を一度、開発するだけで、以降の複合金融商品においては、ＷＳＳ３１１及び３２１を改修することなく、これらの処理要求元であるＷＳＣ２３１及び２３２を流用することにより、既存システムの再利用性を高め、新たな複合金融商品に対応したシステムの開発を容易にすることができる。
【００４２】
ＷＥＢサービスアクセス制限ＤＢ３０は、ＷＳＳ３１１又はＷＳＳ３２１を介した処理を許可する外部システムの識別情報を格納する記憶装置である。そして、ＷＳＳ３１１は、ＷＳＣ２３１から受信した第１の処理要求に含まれる取引受付システム２の識別情報に基づき、ＷＥＢサービスアクセス制限ＤＢ３０を参照し、取引受付システム２がＷＳＳ３１１を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、第１の処理要求に含まれる第１の取引情報を用いて金融商品ＤＢ３１３に対して処理を行う。これにより、ユーザ単位の既存システムへのアクセス権限の管理が不要となり、管理負担を軽減することができる。
【００４３】
例えば、取引処理手段３１２及び金融商品ＤＢ３１３は、既存システムであるため、取引受付システム２とは異なるアクセス権限の管理が必要である場合が多い。しかし、複合取引情報管理システム１００を含む金融機関における情報システムのユーザは、人数が多いため、店舗や部署異動に伴う各情報システムのアクセス権限の更新頻度も多い。また、各ユーザについての複数のシステムにおけるアクセス権限の管理は、通常、シングルサインオン等の技術を用いることが多い。しかし、シングルサインオンでは、取引管理システム３１に対する処理要求の度に、アクセス権限を管理するサーバへのアクセスが発生し、本来の処理に対する応答時間に影響が出る場合もある。そのため、アクセス権限管理のための通信負荷を抑える必要性が高い。
【００４４】
ここで、取引受付システム２は、端末１を操作するユーザからのアクセス認証を行った上で、取引管理システム群３への処理要求を行う。そのため、取引受付システム２からのアクセスについては、信頼性が高いと言える。そこで、本発明の実施の形態１にかかるＷＥＢサービスアクセス制限ＤＢ３０は、ユーザごとの権限管理ではなく、処理要求元のシステムを識別することにより、アクセス権限を管理するためのものである。これにより、ユーザの異動に伴うアクセス権限の更新は、取引受付システム２に対して行うことで、取引管理システム群３に対する権限管理を併せて行うことができる。そして、取引受付システム２においては、シングルサインオンなどの仕組を適用することでより効率的に、かつ、実質的に権限を一元管理することができる。尚、システムの識別情報としては、例えば、ＩＰアドレスやホスト名（コンピュータ名）、システム名等が挙げられる。
【００４５】
さらに、ＷＥＢサービスアクセス制限ＤＢ３０は、外部システムの識別情報をＷＳＳ３１１が受信する処理要求の種別ごとに関連付けて記憶することが望ましい。処理要求の種別ごととは、例えば、ＷＥＢサービスにおける各イベントが挙げられる。そして、ＷＳＳ３１１は、ＷＳＣ２３１から受信した第１の処理要求の種別に基づき、ＷＥＢサービスアクセス制限ＤＢ３０を参照し、取引受付システム２がＷＳＳ３１１を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、第１の処理要求に含まれる第１の取引情報を用いて金融商品ＤＢ３１３に対して処理を行う。また、上述したことは、ＷＳＳ３２１についても同様である。但し、ＷＥＢサービスアクセス制限ＤＢ３０は、少なくともＷＳＳ３１１を介した処理を許可する外部システムの識別情報を格納していればよい。
【００４６】
図３は、本発明の実施の形態１にかかるＷｅｂサービスのアクセス制限情報の例を示す図である。図３では、サービス名が２種類、個々のサービスに対応したイベント名が５種類存在する場合に、これらのサービス名とイベント名の組合せについて処理の許可有無が定義されていることを示す。例えば、ＳＹＳＴＥＭ＿Ｘには、フロント業務を行うユーザのみがアクセス可能で、ＳＹＳＴＥＭ＿Ｙには、バック業務を行うユーザのみがアクセス可能であるものとする。そして、削除要求（delete_A）や途中解約要求（terminate_A）といったイベントは、バック業務のみで行われるため、ＳＹＳＴＥＭ＿Ｙからの処理要求である場合のみ、許可することを示す。このように、業務に応じてアクセス可能な取引受付システム２を分けることで、容易に、処理可能なイベントの制御をすることができる。
【００４７】
ここで、図４は、本発明の実施の形態１にかかる親取引（スワップ）の項目の例を示す図である。つまり、複合金融商品が図２に示した仕組債である場合に、親取引をスワップ取引とし、図示した大項目により表現することを示す。尚、上述したように親取引の項目数は、分割前の複合金融商品の項目数より多くなるため、親取引における小項目の詳細は、省略し、各大項目内の小項目数のみを示す。つまり、取引情報生成手段２２は、第１の取引情報を生成する場合に、図４の親取引の項目のうち図２の複合取引情報の各項目と特性が一致する項目に対してそのデータを含める。また、取引情報生成手段２２は、親取引の項目のうち複合金融商品に含まれない項目におけるデータを補完する。
【００４８】
図５は、本発明の実施の形態１にかかる取引情報の項目毎の生成方法の例を示す図である。ここでは、図４の大項目である基本情報における小項目の一部を示し、かつ、小項目ごとのデータの生成方法を例示する。例えば、「担当者」については、取引情報生成手段２２は、図２の「担当者」に入力されたデータをそのまま第１の取引情報に含めて設定する。また、「所属部署」及び「営業所」については、取引情報生成手段２２は、担当者における所属部署及び営業所等の情報を格納するデータベース（不図示）から所属部署及び営業所等を取得し、第１の取引情報に含めることにより補完を行う。また、「グループ名」については、取引情報生成手段２２は、前記データベースに予めデフォルト値として登録されたグループ名を取得し、第１の取引情報に含めることにより補完を行う。このように、取引情報生成手段２２は、図２の「担当者」に入力されたデータに基づき、その他の項目におけるデータを補完して第１の取引情報を生成する。これにより、端末１を操作するユーザが入力するデータ量が減少するため、入力負担を軽減することができる。なお、基本情報以外の大項目についても、複合金融商品に含まれない項目におけるデータについては、適宜、補完されるものとする。
【００４９】
また、図６は、本発明の実施の形態１にかかる子取引（スワップション）の項目の例を示す図である。つまり、図４と同様に、複合金融商品が図２に示した仕組債である場合に、子取引をスワップション取引とし、図示した大項目により表現することを示す。尚、図６の基本情報、休日参照都市情報及び手数料情報については、取引情報生成手段２２は、概ね親取引と同等の補完処理等を行うため、説明を省略する。
【００５０】
また、図６のオプション情報、プレミアム情報及びオプション休日参照都市情報については、子取引であるスワップション取引のみの項目である。これらの項目については、取引情報生成手段２２は、主に、図２の「コール条件」に入力されたデータに基づき、その他の項目におけるデータを補完して第２の取引情報を生成する。逆に、親取引であるスワップ取引には、「コール条件」に対応する項目が存在しない。ここで、「コール条件」とは、取引期間の決定条件と呼ぶことができる。そのため、第１の取引情報は、複合取引情報から取引期間の決定条件の特性を除き、取引期間を固定して生成された情報といえる。言い換えると、取引情報生成手段２２は、複合取引情報に含まれる日付のデータを固定期間となるように補正して第１の取引情報を生成する。一方、取引情報生成手段２２は、複合取引情報に含まれる取引期間の決定条件を用いて第２の取引情報を生成する。
【００５１】
ここで、図４の親取引と図６の子取引では大項目であるクーポン及びコストが共通する。また、図２の複合金融商品にもクーポン及びコストが存在する。しかし、親取引と子取引について、取引情報生成手段２２は、クーポン及びコストのデータを異なるものとする。その点を図７及び図８を用いて説明する。
【００５２】
図７は、本発明の実施の形態１にかかる生成される親取引情報の一部（クーポン及びコスト）の例を示す図である。図８は、本発明の実施の形態１にかかる生成される子取引情報の一部（クーポン及びコスト）の例を示す図である。例えば、図２のクーポンのレートについて、取引情報生成手段２２は、図７の親取引においてはクーポンの金利として設定し、また、図８の子取引においてはコストの金利として設定することを示す。逆に、図２のコストのレートについて、取引情報生成手段２２は、図７の親取引においてはコストの金利として設定し、また、図８の子取引においてはクーポンの金利として設定することを示す。つまり、取引情報生成手段２２は、親取引と子取引との間の整合性を保つように、両取引に分解する。さらに、取引情報生成手段２２は、図２の開始日、終了日、クーポンのロール月及びロール日を用いて、図７及び図８のクーポン及びコストの金利期間情報を算出する。このとき、取引情報生成手段２２は、図２の初回利払日と同日又は直近の日付を親取引の金利期間情報の値とする。また、取引情報生成手段２２は、利払サイクル月数の日付を考慮して子取引の金利期間情報の値とする。
【００５３】
まとめると、次のようになる。まず、取引情報生成手段２２は、第１の金融商品の項目のうち複合金融商品に含まれる項目におけるデータを、第１の金融商品の項目に対応するように補正して第１の取引情報を生成する。一方、取引情報生成手段２２は、第１の取引情報の逆取引となるデータを含めて第２の取引情報を生成する。これにより、このような第１の取引情報と第２の取引情報の関係となるような入力をユーザが逐次判断して入力することなく、本発明の実施の形態１により、複数の取引情報について整合性を保つように生成することができる。
【００５４】
図９は、本発明の実施の形態１にかかる取引受付システム２のハードウェア構成を示すブロック図である。取引受付システム２は、ＣＰＵ（Central Processing Unit）２０１と、ＲＡＭ（Random Access Memory）２０２と、ＲＯＭ（Read Only Memory）２０３と、通信部２０４と、ハードディスク２０５とを備える。また、ハードディスク２０５は、不揮発性記憶装置であり、ＯＳ（Operating System）２５１、ＷＥＢサーバプログラム２５２、ＷＥＢアプリケーションプログラム２５３、ＷＥＢサービスクライアントプログラム２５４及び２５５が格納されている。
【００５５】
ＯＳ２５１及びＷＥＢサーバプログラム２５２は、周知のコンピュータプログラムであるため、説明を省略する。ＷＥＢアプリケーションプログラム２５３は、図１の受付手段２１及び取引情報生成手段２２を実現するためのコンピュータプログラムである。特に、ＷＥＢアプリケーションプログラム２５３には、上述した分解ロジックが実装されている。但し、当該分解ロジックは、別のプログラムモジュール（不図示）であってもよい。また、ＷＥＢサービスクライアントプログラム２５４及び２５５は、それぞれＷＳＣ２３１及び２３２を実現するためのコンピュータプログラムである。
【００５６】
ＣＰＵ２０１は、取引受付システム２における各種処理、ＲＡＭ２０２、ＲＯＭ２０３、通信部２０４及びハードディスク２０５へのアクセス等を制御する。通信部２０４は、端末１及び取引管理システム群３との通信を行う。取引受付システム２は、ＣＰＵ２０１が、ＲＡＭ２０２、ＲＯＭ２０３又はハードディスク２０５に格納されたＯＳ２５１、ＷＥＢサーバプログラム２５２、ＷＥＢアプリケーションプログラム２５３、ＷＥＢサービスクライアントプログラム２５４及び２５５を読み込み、実行する。これにより、取引受付システム２は、取引管理システム群３に複合取引情報の処理を行わせることができる。尚、取引受付システム２は、複数台に分散して実現されても構わない。
【００５７】
図１０は、本発明の実施の形態１にかかる取引管理システム３１のハードウェア構成を示すブロック図である。尚、取引管理システム３２についても同等であるため、図示及び説明を省略する。取引管理システム３１は、ＣＰＵ（Central Processing Unit）３０１と、ＲＡＭ（Random Access Memory）３０２と、ＲＯＭ（Read Only Memory）３０３と、通信部３０４と、ハードディスク３０５とを備える。また、ハードディスク３０５は、不揮発性記憶装置であり、ＯＳ（Operating System）３５１、金融商品ＤＢ３５２、取引処理プログラム３５３及びＷＥＢサービスサーバプログラム３５４が格納されている。
【００５８】
ＯＳ３５１は、周知のコンピュータプログラムであるため、説明を省略する。金融商品ＤＢ３５２は、図１の金融商品ＤＢ３１３に対応するデータ及びＤＢＭＳである。また、取引処理プログラム３５３は、取引処理手段３１２を実現するためのコンピュータプログラムである。また、ＷＥＢサービスサーバプログラム３５４は、ＷＳＳ３１１を実現するためのコンピュータプログラムである。
【００５９】
ＣＰＵ３０１は、取引管理システム３１における各種処理、ＲＡＭ３０２、ＲＯＭ３０３、通信部３０４及びハードディスク３０５へのアクセス等を制御する。通信部３０４は、端末１、取引受付システム２、取引管理システム３２及びＷＥＢサービスアクセス制限ＤＢ３０との通信を行う。取引管理システム３１は、ＣＰＵ３０１が、ＲＡＭ３０２、ＲＯＭ３０３又はハードディスク３０５に格納されたＯＳ３５１、取引処理プログラム３５３及びＷＥＢサービスサーバプログラム３５４を読み込み、実行する。これにより、取引管理システム３１は、金融商品ＤＢ３１３に対する処理要求を行うことができる。尚、取引管理システム３１は、複数台に分散して実現されても構わない。
【００６０】
図１１は、本発明の実施の形態１にかかる仕組債登録処理の流れを示すシーケンス図である。まず、受付手段２１は、端末１から複合取引情報の入力を受け付ける（Ｓ１０１）。次に、取引情報生成手段２２は、複合取引情報から複数の取引情報に分解する（Ｓ１０２）。そして、ＷＳＣ２３１は、親取引における取引情報の登録要求を送信する（Ｓ１０３）。すなわち、ＷＳＣ２３１は、ＷＳＳ３１１に対して、生成した第１の取引情報を含めて第１のデータ形式に基づく第１の登録要求を送信する。
【００６１】
続いて、取引管理システム３１は、親取引の登録処理を行う（Ｓ１０４）。すなわち、まず、ＷＳＳ３１１は、ＷＳＣ２３１から第１の登録要求を受信する。次に、ＷＳＳ３１１は、当該第１の登録要求に含まれる第１の取引情報を、取引処理手段３１２を用いて金融商品ＤＢ３１３へ登録する。このとき、取引処理手段３１２は、登録された第１の取引情報に対して取引識別情報を発行する。そして、ＷＳＳ３１１は、発行された取引識別情報をＷＳＣ２３１へ返信する（Ｓ１０５）。
【００６２】
そして、ＷＳＣ２３１は、ＷＳＳ３１１から取引識別情報を受信する。ここで、ＷＳＣ２３２は、取引識別情報を含む子取引における取引情報の登録要求を送信する（Ｓ１０６）。すなわち、ＷＳＣ２３２は、ＷＳＣ２３１がＷＳＳ３１１から取引識別情報を受信した場合に、ＷＳＳ３２１に対して、当該取引識別情報と生成した第２の取引情報とを含めて第２のデータ形式に基づく第２の登録要求を送信する。
【００６３】
その後、取引管理システム３２は、子取引の登録処理を行う（Ｓ１０７）。すなわち、まず、ＷＳＳ３２１は、ＷＳＣ２３２から第２の登録要求を受信する。次に、ＷＳＳ３２１は、当該第２の登録要求に含まれる第２の取引情報を当該第２の登録要求に含まれる取引識別情報に関連付けて、取引処理手段３２２を用いて金融商品ＤＢ３２３へ登録する。
【００６４】
そして、ＷＳＳ３２１は、ＷＳＣ２３２へ処理結果を返信する（Ｓ１０８）。その後、ＷＳＣ２３２は、ＷＳＳ３２１から処理結果を受信する。そして、受付手段２１は、端末１に対して処理結果を出力する（Ｓ１０９）。
【００６５】
このように、金融商品ＤＢ３１３及び金融商品ＤＢ３２３を用いて、分解した第１及び第２の取引情報を登録することにより、実質的に複合取引情報の登録が可能となる。
【００６６】
図１２は、本発明の実施の形態１にかかる取引受付システムの処理要求の受付処理の流れを示すフローチャートである。まず、受付手段２１は、端末１から複合取引情報を含む処理要求を受け付ける。このとき、処理要求は、複合取引情報の登録要求又は更新要求等である。
【００６７】
次に、受付手段２１は、複合取引情報からユーザの識別情報を抽出する。そして、受付手段２１は、ユーザ認証処理を行う（Ｓ２０１）。すなわち、受付手段２１は、取引受付システム２において当該ユーザ識別情報がアクセスを許可されているか否かを判定する。例えば、シングルサインオン機能を利用しても構わない。
【００６８】
次に、受付手段２１は、認証が成功したか否かを判定する（Ｓ２０２）。認証が失敗したと判定した場合、受付手段２１は、端末１に対して認証失敗の旨を返信する（Ｓ２０８）。そして、当該受付処理を終了する。
【００６９】
ステップＳ２０２において、認証が成功したと判定した場合、取引情報生成手段２２は、複合取引情報から複数の取引情報に分解する。すなわち、取引情報生成手段２２は、受付手段２１から出力された複合取引情報から第１の取引情報である親取引情報を生成する（Ｓ２０３）。このとき、取引情報生成手段２２は、生成した親取引情報を含めて、第１のデータ形式に基づく処理要求を生成する。そして、ＷＳＣ２３１は、生成した親取引情報の処理要求をＷＳＳ３１１へ送信する（Ｓ２０４）。また、取引情報生成手段２２は、受付手段２１から出力された複合取引情報から第２の取引情報である子取引情報を生成する（Ｓ２０５）。このとき、取引情報生成手段２２は、生成した子取引情報を含めて、第２のデータ形式に基づく処理要求を生成する。尚、処理要求が更新要求である場合、ステップＳ２０３及びＳ２０５では、それぞれ親取引情報及び子取引情報の更新情報を生成する。
【００７０】
そして、ＷＳＣ２３２は、ステップＳ２０４及びＳ２０５の後、子取引情報の処理要求をＷＳＳ３２１に対して送信する（Ｓ２０６）。ここで、処理要求が登録要求である場合、ＷＳＣ２３２は、子取引情報が生成され、かつ、ＷＳＣ２３１がＷＳＳ３１１から取引識別情報を受信後に、送信する。その後、ＷＳＣ２３２がＷＳＳ３２１から処理結果を受信した後に、受付手段２１は、処理結果を端末１に対して返信する（Ｓ２０７）。そして、当該受付処理を終了する。
【００７１】
図１３は、本発明の実施の形態１にかかる取引管理システム３１の処理要求に応じた処理の流れを示すフローチャートである。尚、取引管理システム３２についても同等の処理であるため、図示及び説明を省略する。
【００７２】
まず、ＷＳＳ３１１は、ＷＳＣ２３１から処理要求を受信する（Ｓ３０１）。つまり、ＷＳＳ３１１は、第１のデータ形式に基づく処理要求を受信する。次に、ＷＳＳ３１１は、処理要求元の取引受付システム２にＷＥＢサービスの利用が許可されているか否かを判定する（Ｓ３０２）。具体的には、ＷＳＳ３１１は、受信した処理要求を解析し、サービス名及びイベント名並びに取引受付システム２のＩＰアドレス又はシステム名を抽出する。そして、ＷＳＳ３１１は、ＷＥＢサービスアクセス制限ＤＢ３０を参照し、抽出したサービス名及びイベント名並びにＩＰアドレス又はシステム名の組合せが登録されているか否かを判定する。
【００７３】
ステップＳ３０２において、取引受付システム２にＷＥＢサービスの利用が許可されていると判定した場合、ＷＳＳ３１１は、受信した取引情報を処理する（Ｓ３０３）。すなわち、ＷＳＳ３１１は、取引処理手段３１２を用いて金融商品ＤＢ３１３へ受信した取引情報に関する処理を行う。
【００７４】
その後、ＷＳＳ３１１は、処理結果をＷＳＣ２３１へ返信する（Ｓ３０４）。このとき、処理要求が登録要求である場合、取引処理手段３１２は、登録した取引情報における取引識別情報を発行する。そして、ＷＳＳ３１１は、処理結果に取引識別情報を含めて返信する。
【００７５】
ステップＳ３０２において、取引受付システム２にＷＥＢサービスの利用が許可されていないと判定した場合、ＷＳＳ３１１は、処理不可の旨をＷＳＣ２３１へ返信する（Ｓ３０５）。その後、当該処理要求に応じた処理を終了する。
【００７６】
図１４は、本発明の実施の形態１にかかる複合取引情報管理システムの応用例の全体構成を示すブロック図である。複合取引情報管理システム１０１は、複合取引情報管理システム１００に構成要素を追加したものである。すなわち、図１に比べて、取引受付システム２ａが追加され、取引管理システム群３が取引管理システム群３ａに変更したものである。以下、図１との違いを中心に説明し、同一の構成要素については同一の符号を付し、詳細な説明を省略する。
【００７７】
取引管理システム群３ａは、取引管理システム群３に取引管理システム３３が追加されたものである。取引管理システム３３は、第３の金融商品における第３の取引情報を管理するための情報システムである。尚、取引管理システム３３は、ＷＳＳ３３１、取引処理手段３３２及び金融商品ＤＢ３３３を備えるが、それぞれ、取引管理システム３１又は３２が備える構成要素に対応する。但し、ＷＳＳ３３１は、第３のデータ形式に基づく処理要求についてのみ処理を行う。
【００７８】
取引受付システム２ａは、取引受付システム２とは異なり、第２の金融商品及び第３の金融商品に分解可能な複合金融商品の取引情報を受け付けるための情報システムである。尚、取引受付システム２ａは、受付手段２１ａ、取引情報生成手段２２ａ、ＷＳＣ２３１ａ及び２３２ａを備えるが、それぞれ、取引受付システム２が備える構成要素に対応する。但し、取引情報生成手段２２ａは、受け付けた複合取引情報から第２の取引情報及び第３の取引情報に分解する。そして、ＷＳＣ２３１ａは、ＷＳＣ２３２と同じくＷＳＳ３２１に対する処理要求を行うＷｅｂサービスクライアントである。つまり、ＷＳＣ２３１ａには、ＷＳＣ２３２が流用可能である。また、ＷＳＣ２３２ａは、第３のデータ形式に基づく処理要求をＷＳＳ３３１に対して送信するＷｅｂサービスクライアントである。
【００７９】
このように、本発明の実施の形態１を応用すると、複合取引情報管理システム１０１のように、既存の複合金融商品と一部の条件が異なるような新規の複合金融商品を採用する場合であっても、情報システムの開発コストを抑えることができる。例えば、取引処理手段３３２及び金融商品ＤＢ３３３に、既存の単一の金融商品を管理するためのデータベースシステムを用いることができる。その場合、新規開発する構成要素は、ＷＳＳ３３１、ＷＳＣ２３２ａ、取引情報生成手段２２ａ及び受付手段２１ａとなる。そのため、複合取引情報管理システム１００を開発した時に比べて、さらに開発コストを抑えることができる。
【００８０】
＜その他の発明の実施の形態＞
尚、本発明の実施の形態は、さらに以下の構成を備えても構わない。まず、取引情報生成手段２２は、複合取引情報を登録する場合には、当該複合取引情報が取引期間の決定条件に基づき最も短い期間に決定された場合の取引期間となるように第１の取引情報を生成する。また、取引情報生成手段２２は、複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定されなかった場合には、当該取引期間を延長するように第１の取引情報を生成するとよい。これにより、第２の取引情報における権利行使等により第１の取引情報の内容を自動的に対応させることができる。つまり、ユーザの入力負担をさらに軽減することができる。
【００８１】
さらには、次のようにしてもよい。まず、取引情報生成手段２２は、複合取引情報における一部の契約が確定した場合に、未確定の契約に基づき、第１の取引情報及び第２の取引情報の更新情報を生成する。次に、ＷＳＣ２３１は、ＷＳＳ３１１に対して、生成した第１の取引情報の更新情報を含めて第１のデータ形式に基づく第１の更新要求を送信する。このとき、ＷＳＳ３１１は、第１の更新要求を受信した場合に、当該第１の更新要求に含まれる第１の取引情報の更新情報に基づき金融商品ＤＢ３１３に登録された第１の取引情報を更新する。そして、ＷＳＣ２３２は、取引識別情報と生成した第２の取引情報の更新情報とを含めて第２のデータ形式に基づく第２の更新要求を送信する。このとき、ＷＳＳ３２１は、第２の更新要求を受信した場合に、当該第２の更新要求に含まれる第２の取引情報の更新情報及び当該第２の更新要求に含まれる取引識別情報に基づき、金融商品ＤＢ３２３に登録された第２の取引情報を更新するとよい。これにより、分解された複数の取引情報間のスケジュールの整合性を保つことができ、実質的に複合取引情報の管理を容易にすることができる。
【００８２】
さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。
【符号の説明】
【００８３】
１００ 複合取引情報管理システム
１０１ 複合取引情報管理システム
１ 端末
２ 取引受付システム
２ａ 取引受付システム
２１ 受付手段
２１ａ 受付手段
２２ 取引情報生成手段
２２ａ 取引情報生成手段
２３１ ＷＳＣ（Web Service Client）
２３１ａ ＷＳＣ
２３２ ＷＳＣ
２３２ａ ＷＳＣ
３ 取引管理システム群
３ａ 取引管理システム群
３０ ＷＥＢサービスアクセス制限ＤＢ
３１ 取引管理システム
３１１ ＷＳＳ（Web Service Server）
３１２ 取引処理手段
３１３ 金融商品ＤＢ
３２ 取引管理システム
３２１ ＷＳＳ
３２２ 取引処理手段
３２３ 金融商品ＤＢ
３３ 取引管理システム
３３１ ＷＳＳ
３３２ 取引処理手段
３３３ 金融商品ＤＢ
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ 通信部
２０５ ハードディスク
２５１ ＯＳ
２５２ ＷＥＢサーバプログラム
２５３ ＷＥＢアプリケーションプログラム
２５４ ＷＥＢサービスクライアントプログラム
２５５ ＷＥＢサービスクライアントプログラム
３０１ ＣＰＵ
３０２ ＲＡＭ
３０３ ＲＯＭ
３０４ 通信部
３０５ ハードディスク
３５１ ＯＳ
３５２ 金融商品ＤＢ
３５３ 取引処理プログラム
３５４ ＷＥＢサービスサーバプログラム
【技術分野】
【０００１】
本発明は、複合取引情報管理システム及び方法に関し、特に、複雑なデリバティブの性質を内在する債券である仕組債等の複合取引情報を管理する複合取引情報管理システム及び方法に関する。
【背景技術】
【０００２】
近年、複雑なデリバティブの性質を内在する債券であるデリバティブ内在型の仕組債や非標準型のデリバティブ商品等に代表される複雑な金融商品が開発されている。そして、このような複雑な金融商品の種類や取引件数は、年々、増加する傾向がある。また、金融機関は、従来から単一のデリバティブ商品等の金融商品それぞれに特化した専用の情報システムを有している。例えば、特許文献１には、デリバティブ商品を扱う情報システムに関する技術が開示されている。
【０００３】
一方、複雑な金融商品は、複数の単一のデリバティブ商品等の金融商品を複数組み合わせて表現することが可能である。例えば、「金利交換」に関する金融商品である場合には、金利を支払う商品と、金利を受け取る商品という２つの単一の金融商品の組合せで表現することができる。そこで、オペレータは、まず、複雑な金融商品における一つの契約を既存のデリバティブ商品等に分割して複数の取引の組合せで管理する。そして、分割した複数の取引のそれぞれについて、対応する専用の情報システムに対して個別に入力作業を行う。これにより、複数の取引により、複雑な金融商品における一つの契約と同一の経済効果を奏するものとみなすことができる。そのため、複雑な金融商品の専用の新規システム開発をせずとも新規の複雑な金融商品の取り扱いを始めることが可能である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−５６１８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した手法では、各情報システムへの入力を行うオペレータの作業負担が大きいという問題がある。その理由は、本来、一つの契約であるにもかかわらず、実質的に複数の取引に相当する入力作業が発生するためである。また、複雑な金融商品から単一のデリバティブ商品に分割するには、各商品が単独の取引として成立し得るように、各取引に対するデータの修正や補完等を適宜行う必要がある。これらのデータの修正や補完等は、分割された各商品に対応する情報システムごとに、また、分割元の金融商品に応じて複雑なパターンがあり、作業が煩雑である。
【０００６】
一方、新規の複雑な金融商品の取り扱いを始めるに当たり、当該新規な金融商品に対応したシステムを個別に開発するか、既存の情報システムへ当該金融商品に対応した機能を追加するなども考えられる。しかしながら、その場合は、相応の開発コストとスケジュールを要することから、取引の機会喪失リスクが顕在化する可能性が高く、取り扱い件数が少ないケースでは当該リスクは顕著である。その理由は、複雑な金融商品は、取引元と取引先の双方の要望に応えるべく、詳細な取引条件が取引ごとに様々に変動するという特徴があるからである。また、近年の複雑な金融商品の一種類当たりの取り扱い件数は、単一のデリバティブ商品に比べて少ないという特徴がある。そのため、新規の複雑な金融商品のために新規に情報システムを開発した場合の費用対効果が低く、有効な対策とはいえない。
【０００７】
本発明は、このような問題を解決するためになされたものであり、既存の金融商品に対応した情報システムの個別の機能を有効活用して、一つの複雑な金融商品の取り扱いを実現することにより、ユーザの入力負担を軽減した複合取引情報管理システム及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の第１の態様にかかる複合取引情報管理システムは、第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を管理する複合取引情報管理システムであって、前記複合取引情報を外部から受け付けて、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、前記第１の金融商品の取引情報である第１の取引情報と、前記第２の金融商品の取引情報である第２の取引情報に分解して出力する取引受付システムと、前記取引受付システムより出力された第１の取引情報を入力し、これを管理する第１の取引管理システムと、前記取引受付システムより出力された第２の取引情報を入力し、これを管理する第２の取引管理システムと、を備え、前記取引受付システムは、前記第１の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完して前記第１の取引情報を生成し、前記第２の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完し、前記第１の取引情報に対応するデータを含めて前記第２の取引情報を生成する取引情報生成手段を備える。
【０００９】
また、前記第１の取引管理システムは、第１のデータ形式に基づく第１の処理要求を外部から受信し、当該第１の処理要求に基づいて、前記第１の取引情報を管理するための第１のデータベースに対して処理を行う第１のＩＦ手段を備え、前記第２の取引管理システムは、第２のデータ形式に基づく第２の処理要求を外部から受信し、当該第２の処理要求に基づいて、前記第２の取引情報を管理するための第２のデータベースに対して処理を行う第２のＩＦ手段を備え、前記取引受付システムは、前記第１のＩＦ手段に対して、前記第１の処理要求に前記生成された第１の取引情報を含めて送信する第１の処理要求手段と、前記第２のＩＦ手段に対して、前記第２の処理要求に前記生成された第２の取引情報を含めて送信する第２の処理要求手段と、を備えることが望ましい。
【００１０】
さらに、前記第１の処理要求手段は、前記第１のＩＦ手段に対して、前記生成した第１の取引情報を含めて前記第１のデータ形式に基づく第１の登録要求を送信し、前記第１のＩＦ手段は、前記第１の登録要求を受信した場合に、当該第１の登録要求に含まれる第１の取引情報を前記第１のデータベースへ登録し、登録された第１の取引情報に対して発行された取引識別情報を前記第１の処理要求手段へ返信し、前記第２の処理要求手段は、前記第１の処理要求手段が前記第１のＩＦ手段から前記取引識別情報を受信した場合に、前記第２のＩＦ手段に対して、当該取引識別情報と前記生成した第２の取引情報とを含めて前記第２のデータ形式に基づく第２の登録要求を送信し、前記第２のＩＦ手段は、前記第２の登録要求を受信した場合に、当該第２の登録要求に含まれる第２の取引情報を当該第２の登録要求に含まれる取引識別情報に関連付けて前記第２のデータベースへ登録することが望ましい。
【００１１】
また、前記取引受付システムは、ユーザの識別情報を含む前記複合取引情報を外部から受け付けた場合に、当該ユーザの識別情報に基づき、当該取引受付システムにおける認証を行う認証手段をさらに備え、前記第１の処理要求手段は、前記認証手段により認証された場合に、前記第１のＩＦ手段に対して、前記第１の処理要求に前記取引受付システムの識別情報をさらに含めて送信し、前記複合取引情報管理システムは、前記第１のＩＦ手段を介した処理を許可する外部システムの識別情報を格納する記憶部をさらに備え、前記第１のＩＦ手段は、前記第１の処理要求手段から受信した第１の処理要求に含まれる前記取引受付システムの識別情報に基づき、前記記憶部を参照し、当該取引受付システムが当該第１のＩＦ手段を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、前記第１の処理要求に含まれる前記第１の取引情報を用いて前記第１のデータベースに対して処理を行うことが望ましい。
【００１２】
さらに、前記記憶部は、前記外部システムの識別情報を前記第１のＩＦ手段が受信する処理要求の種別ごとに関連付けて記憶し、前記第１のＩＦ手段は、前記第１の処理要求手段から受信した第１の処理要求の種別に基づき、前記記憶部を参照し、当該取引受付システムが前記第１のＩＦ手段を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、前記第１の処理要求に含まれる前記第１の取引情報を用いて前記第１のデータベースに対して処理を行うとよい。
【００１３】
また、前記取引情報生成手段は、前記第１の金融商品の項目のうち前記複合金融商品に含まれる項目におけるデータを、前記第１の金融商品の項目に対応するように補正して前記第１の取引情報を生成し、前記第１の取引情報の逆取引となるデータを含めて前記第２の取引情報を生成するとよい。
【００１４】
また、前記複合金融商品は、所定の金利条件と、取引期間の決定条件とを含む金融商品であり、前記第１の金融商品は、前記所定の金利条件についての取引期間が固定された金融商品であり、前記第２の金融商品は、前記取引期間の決定条件に関する金融商品であり、前記取引情報生成手段は、前記複合取引情報に含まれる日付のデータを固定期間となるように補正して前記第１の取引情報を生成し、前記複合取引情報に含まれる取引期間の決定条件を用いて前記第２の取引情報を生成するとよい。
【００１５】
また、前記取引情報生成手段は、前記複合取引情報を登録する場合には、当該複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定された場合の取引期間となるように前記第１の取引情報を生成し、前記複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定されなかった場合には、当該取引期間を延長するように前記第１の取引情報を生成するとよい。
【００１６】
また、前記取引情報生成手段は、前記複合取引情報における一部の契約が確定した場合に、未確定の契約に基づき、前記第１の取引情報及び前記第２の取引情報の更新情報を生成し、前記第１の処理要求手段は、前記第１のＩＦ手段に対して、前記生成した第１の取引情報の更新情報を含めて前記第１のデータ形式に基づく第１の更新要求を送信し、前記第１のＩＦ手段は、前記第１の更新要求を受信した場合に、当該第１の更新要求に含まれる第１の取引情報の更新情報に基づき前記第１のデータベースに登録された第１の取引情報を更新し、前記第２の処理要求手段は、前記取引識別情報と前記生成した第２の取引情報の更新情報とを含めて前記第２のデータ形式に基づく第２の更新要求を送信し、前記第２のＩＦ手段は、前記第２の更新要求を受信した場合に、当該第２の更新要求に含まれる第２の取引情報の更新情報及び当該第２の更新要求に含まれる取引識別情報に基づき、前記第２のデータベースに登録された第２の取引情報を更新するとよい。
【００１７】
本発明の第２の態様にかかる複合取引情報管理方法は、第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を外部から受け付ける取引受付システムと、前記第１の金融商品の取引情報である第１の取引情報を管理する第１の取引管理システムと、前記第２の金融商品の取引情報である第２の取引情報を管理する第２の取引管理システムと、を用いて、前記複合取引情報を管理する複合取引情報管理方法であって、前記取引受付システムにおいて、前記外部から受け付けた前記複合取引情報から、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、前記第１の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完して前記第１の取引情報を生成し、前記取引受付システムにおいて、前記複合取引情報から、前記分解ロジックに基づいて、前記第２の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完し、前記第１の取引情報に対応するデータを含めて前記第２の取引情報を生成し、前記取引受付システムにおいて、前記生成した第１の取引情報を前記第１の取引管理システムに対して出力し、前記第１の取引管理システムにおいて、前記取引受付システムより出力された第１の取引情報を入力し、当該入力された第１の取引情報について、当該第１の取引情報を管理するための第１のデータベースに対して処理を行い、前記取引受付システムにおいて、前記生成した第２の取引情報を前記第２の取引管理システムに対して出力し、前記第２の取引管理システムにおいて、前記取引受付システムより出力された第２の取引情報を入力し、当該入力された第２の取引情報について、当該第２の取引情報を管理するための第２のデータベースに対して処理を行う。
【発明の効果】
【００１８】
本発明によれば、既存の金融商品に対応した情報システムの個別の機能を有効活用して、一つの複雑な金融商品の取り扱いを実現することにより、ユーザの入力負担を軽減した複合取引情報管理システム及び方法を提供することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態１にかかる複合取引情報管理システムの全体構成を示すブロック図である。
【図２】本発明の実施の形態１にかかる仕組債の項目及び入力データの例を示す図である。
【図３】本発明の実施の形態１にかかるＷｅｂサービスのアクセス制限情報の例を示す図である。
【図４】本発明の実施の形態１にかかる親取引（スワップ）の項目の例を示す図である。
【図５】本発明の実施の形態１にかかる取引情報の項目毎の生成方法の例を示す図である。
【図６】本発明の実施の形態１にかかる子取引（スワップション）の項目の例を示す図である。
【図７】本発明の実施の形態１にかかる生成される親取引情報の一部（クーポン及びコスト）の例を示す図である。
【図８】本発明の実施の形態１にかかる生成される子取引情報の一部（クーポン及びコスト）の例を示す図である。
【図９】本発明の実施の形態１にかかる取引受付システムのハードウェア構成を示すブロック図である。
【図１０】本発明の実施の形態１にかかる取引管理システムのハードウェア構成を示すブロック図である。
【図１１】本発明の実施の形態１にかかる仕組債登録処理の流れを示すシーケンス図である。
【図１２】本発明の実施の形態１にかかる取引受付システムの処理要求の受付処理の流れを示すフローチャートである。
【図１３】本発明の実施の形態１にかかる取引管理システムの処理要求に応じた処理の流れを示すフローチャートである。
【図１４】本発明の実施の形態１にかかる複合取引情報管理システムの応用例の全体構成を示すブロック図である。
【発明を実施するための形態】
【００２０】
以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
【００２１】
＜発明の実施の形態１＞
図１は、本発明の実施の形態１にかかる複合取引情報管理システム１００の全体構成を示すブロック図である。複合取引情報管理システム１００は、第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を管理する情報システムである。複合金融商品とは、例えば、上述したデリバティブ内在型の仕組債や非標準型のデリバティブ商品等の複雑な金融商品を指す。そして、複合取引情報管理システム１００は、当該複合金融商品のみを管理するための専用のデータベースシステムを用いずに、既存の複数の金融商品のそれぞれを管理するためのデータベースシステムを当該複合金融商品と同等の経済効果を奏するように組み合わせることで、当該複合金融商品の管理を実現するものである。
【００２２】
ここで、複合金融商品としては、例えば、マルチコーラブル型の仕組債が挙げられる。図２は、本発明の実施の形態１にかかる複合金融商品の一例である仕組債の項目及び入力データの例を示す図である。すなわち、マルチコーラブル型の仕組債における項目の一部と、これらの項目に対応するデータ、つまり、複合取引情報の一例である。尚、当該仕組債における項目及びデータは、これに限定されない。
【００２３】
また、複合金融商品が第１の金融商品と第２の金融商品の特性に分解可能であるとは、例えば、複合金融商品がマルチコーラブル型の仕組債である場合に、デリバティブ部分については、第１の金融商品としてスワップ取引の商品及び第２の金融商品としてスワップション取引の商品として分解できることが挙げられる。尚、複合金融商品の分解の仕方はこれに限定されない。
【００２４】
この場合、複合金融商品は、所定の金利条件と、取引期間の決定条件とを含む金融商品であるといえる。そして、第１の金融商品は、所定の金利条件についての取引期間が固定された金融商品であるといえる。また、第２の金融商品は、取引期間の決定条件に関する金融商品であるといえる。尚、複合金融商品が当該仕組債以外の金融商品である場合には、これらとは異なる特性を含むものとなる。
【００２５】
但し、複合金融商品は、第１の金融商品及び第２の金融商品それぞれの項目自体を単純に足し合わせたものではなく、第１の金融商品及び第２の金融商品それぞれの特性の一部分を含むものである。そのため、第１の金融商品及び第２の金融商品に共通する項目もあれば、いずれかにしか存在しない項目もある。さらに、複合金融商品における一の項目が第１の金融商品又は第２の金融商品における複数の項目に対応する場合もある。そのため、複合金融商品の項目数は、第１の金融商品及び第２の金融商品それぞれの項目数に比べて十分に少ないものとなる。また、第１の金融商品及び第２の金融商品の項目が共通する場合であっても、異なるデータとする必要もある。すなわち、これらを合わせて複合金融商品と同一の経済効果を奏するためには、第１の金融商品と第２の金融商品との間で、整合性を保つためのデータの加工が必要な場合もある。
【００２６】
図１に戻り、説明する。複合取引情報管理システム１００は、端末１と、取引受付システム２と、取引管理システム群３とを備える。端末１は、取引受付システム２に対して複合取引情報の入力を行う。端末１は、キーボードやマウス等の入力装置（不図示）と、画面等の表示装置（不図示）とを備える端末装置である。端末１は、例えば、通信機能を備え、ＷＥＢブラウザ等の表示アプリケーションを備えたパーソナルコンピュータであるとよい。
【００２７】
取引受付システム２は、端末１等の外部から複合取引情報を受け付けて、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、第１の金融商品の取引情報である第１の取引情報と、第２の金融商品の取引情報である第２の取引情報に分解して出力する情報システムである。取引受付システム２は、例えば、ＷＥＢアプリケーションにより実現される。ここで、分解ロジックとしては、複合金融商品と第１の金融商品及び第２の金融商品との項目の対応付けの定義や、データの補完処理、補正処理、第１の金融商品と第２の金融商品との間で入れ替えるデータの定義等を含む。尚、取引受付システム２の具体的なハードウェア構成については、図９にて後述する。尚、取引受付システム２は、１台又は複数台のコンピュータ装置により実現されるものである。また、取引受付システム２は、受付手段２１と、取引情報生成手段２２と、ＷＳＣ（Web Service Client）２３１と、ＷＳＣ２３２とを備える。
【００２８】
受付手段２１は、端末１から入力される複合取引情報を含む処理要求を受け付ける。そして、受付手段２１は、受け付けた複合取引情報を取引情報生成手段２２へ出力する。その際、受付手段２１は、端末１に対してアクセス認証を行うことが望ましい。例えば、受付手段２１は、端末１からユーザの識別情報を含む複合取引情報を受け付けた場合に、当該ユーザの識別情報に基づき、取引受付システム２における認証を行う。そして、受付手段２１は、認証できた場合に、受け付けた複合取引情報を取引情報生成手段２２へ出力する。尚、端末１からの処理要求として、例えば、複合取引情報の登録要求、更新要求、削除要求、契約中の途中解約要求及び承認要求等が含まれる。
【００２９】
また、受付手段２１は、端末１からのアクセス要求に対する応答として、複合取引情報の入力画面を返信するとよい。その場合、端末１の表示装置上に、当該入力画面が表示される。例えば、入力画面の項目としては、図２の各項目についてのデータ入力欄が含まれる。これにより、端末１を操作するユーザにおける複合取引情報の入力作業を支援することができる。但し、受付手段２１は、少なくとも端末１から送信される複合取引情報を受け付けることができれば、実現手段は問わないものとする。つまり、受付手段２１は、端末１から図２のデータを受け付けることができればよい。
【００３０】
取引情報生成手段２２は、受付手段２１から出力された複合取引情報から第１の取引情報及び第２取引情報に分解する処理を行う。すなわち、取引情報生成手段２２は、複合取引情報から、第１の金融商品の項目のうち受け付けた複合金融商品に含まれない項目におけるデータを補完して第１の取引情報を生成する。また、取引情報生成手段２２は、複合取引情報から、第２の金融商品の項目のうち受け付けた複合金融商品に含まれない項目におけるデータを補完し、第１の取引情報に対応するデータを含めて第２の取引情報を生成する。また、取引情報生成手段２２は、１の複合取引情報から２以上の取引情報に分解するものである。そのため、ここでは、第１の取引情報を親取引とし、第２の取引情報を親取引との整合性を保つためのデータを含む子取引とする。尚、子取引は、複数存在しても構わない。
【００３１】
ＷＳＣ２３１は、後述するＷｅｂサービスサーバであるＷＳＳ（Web Service Server）３１１との通信が可能なＷｅｂサービスクライアントである。すなわち、ＷＳＣ２３１は、ＷＳＳ３１１に対して、ＷＳＳ３１１が処理可能な第１のデータ形式に基づく第１の処理要求に、取引情報生成手段２２により生成された第１の取引情報を含めて送信する第１の処理要求手段といえる。さらに、ＷＳＣ２３１は、受付手段２１において複合取引情報に含まれるユーザの識別情報が認証された場合に、ＷＳＳ３１１に対して、第１の処理要求に取引受付システム２の識別情報をさらに含めて送信する。
【００３２】
また、ＷＳＣ２３２は、後述するＷｅｂサービスサーバであるＷＳＳ３２１との通信が可能なＷｅｂサービスクライアントである。すなわち、ＷＳＣ２３２は、ＷＳＳ３２１に対して、ＷＳＳ３２１が処理可能な第２のデータ形式に基づく第２の処理要求に、取引情報生成手段２２により生成された第２の取引情報を含めて送信する第２の処理要求手段といえる。さらに、ＷＳＣ２３２は、受付手段２１において複合取引情報に含まれるユーザの識別情報が認証された場合に、ＷＳＳ３２１に対して、第２の処理要求に取引受付システム２の識別情報をさらに含めて送信する。
【００３３】
取引管理システム群３は、取引管理システム３１及び３２と、ＷＥＢサービスアクセス制限ＤＢ３０とを備える。尚、取引管理システム群３は、一つの情報システム又は複数の情報システムの集合のいずれであっても構わない。但し、以降の説明では、便宜上、取引管理システム３１と、取引管理システム３２とは異なる情報システムであるものとして説明する。
【００３４】
取引管理システム３１及び３２は、それぞれ単一の金融商品における取引情報を管理するための情報システムである。尚、取引管理システム３１及び３２の具体的なハードウェア構成については、図１０にて後述する。取引管理システム３１は、取引受付システム２より出力された第１の取引情報を入力し、これを管理する情報システムである。取引管理システム３１は、ＷＳＳ３１１と、取引処理手段３１２と、金融商品ＤＢ３１３とを備える。
【００３５】
金融商品ＤＢ３１３は、第１の取引情報を管理するためのＤＢＭＳ（DataBase Management System）及びデータを格納する記憶領域である。取引処理手段３１２は、外部からの処理要求に応じて、金融商品ＤＢ３１３に対するアクセスを行う。そして、ＷＳＳ３１１は、取引処理手段３１２に対して外部からの処理要求と同等の処理要求を出力する。つまり、ＷＳＳ３１１は、第１のデータ形式に基づく第１の処理要求を外部から受信し、当該第１の処理要求に基づいて、取引処理手段３１２を介して金融商品ＤＢ３１３に対して処理を行うＷｅｂサービスサーバである。ここで、第１のデータ形式とは、例えば、ＷＳＤＬ（Web Services Description Language）ファイルに定義された情報である。すなわち、上述したＷＳＣ２３１は、当該ＷＳＤＬに基づく通信を行うものである。そのため、ＷＳＳ３１１は、当該ＷＳＤＬに基づく通信であれば、取引受付システム２に限らず、任意の外部のシステムから第１の処理要求を受信し、所定の処理を行うことができる。
【００３６】
ここで、取引処理手段３１２及び金融商品ＤＢ３１３には、既存の単一の金融商品を管理するためのデータベースシステムを用いることが可能である。その場合、例えば、取引処理手段３１２へのアクセス要求を行うための専用のクライアントアプリケーションが存在するものとする。このとき、ユーザは、端末１内に搭載された当該クライアントアプリケーションを用いて、取引処理手段３１２を介して金融商品ＤＢ３１３にアクセスし、所定の処理を行うことができる。つまり、取引処理手段３１２及び金融商品ＤＢ３１３は、取引受付システム２以外の外部のシステム等からも利用されている可能性が高い。そのため、新規な金融商品を採用するに当たり、既存のデータベースシステムを用いるとしても、そのために、取引処理手段３１２及び金融商品ＤＢ３１３に改修を加えることは、困難である。その理由は、既存の外部のシステム等への影響が大きいためである。
【００３７】
そこで、本発明の実施の形態１では、取引処理手段３１２及び金融商品ＤＢ３１３が既存の機能だとしても、これらに手を加えず、任意の外部のシステムからの処理要求を受け付け可能なＷＳＳ３１１を追加することで、既存のサービスを維持しつつ、新規な金融商品のためにも当該取引処理手段３１２及び金融商品ＤＢ３１３の機能を利用することを可能とした。そのため、取引受付システム２は、ＷＳＳ３１１との通信が可能なＷＳＣ２３１を介して処理要求を行うようにするだけで、他の実装については、採用する金融商品に特化した処理を含めることが可能となり、実現可能な機能の自由度が高まる。加えて、既存の機能の再利用性が高まるため、新規な金融商品の採用に応じた開発コストを抑えることができる。特に、仕組債のような複雑な金融商品は、総取引数が既存の金融商品に比べて少なく、商品サイクルが短く、新たな金融商品が次々と開発される。そのため、既存の機能の再利用性を高めることの効果が大きい。
【００３８】
また、取引管理システム３２は、取引受付システム２より出力された第２の取引情報を入力し、これを管理する情報システムである。取引管理システム３２は、ＷＳＳ３２１と、取引処理手段３２２と、金融商品ＤＢ３２３とを備える。
【００３９】
金融商品ＤＢ３２３は、第２の取引情報を管理するためのＤＢＭＳ及びデータを格納する記憶領域である。取引処理手段３２２は、外部からの処理要求に応じて、金融商品ＤＢ３２３に対するアクセスを行う。そして、ＷＳＳ３２１は、取引処理手段３２２に対して外部からの処理要求と同等の処理要求を出力する。つまり、ＷＳＳ３２１は、第２のデータ形式に基づく第２の処理要求を外部から受信し、当該第２の処理要求に基づいて、取引処理手段３２２を介して金融商品ＤＢ３２３に対して処理を行うＷｅｂサービスサーバである。ここで、第２のデータ形式とは、例えば、ＷＳＤＬファイルに定義された情報である。すなわち、上述したＷＳＣ２３２は、当該ＷＳＤＬに基づく通信を行うものである。そのため、ＷＳＳ３２１は、当該ＷＳＤＬに基づく通信であれば、取引受付システム２に限らず、任意の外部のシステムから第２の処理要求を受信し、所定の処理を行うことができる。
【００４０】
尚、取引処理手段３２２及び金融商品ＤＢ３２３に、既存の単一の金融商品を管理するためのデータベースシステムを用いることが可能である。すなわち、取引管理システム３２における本発明の実施の形態１に関係する構成の詳細や特徴は、取引管理システム３１と同等であるため、詳細な説明を省略する。
【００４１】
このように、ＷＳＳ３１１及び３２１を一度、開発するだけで、以降の複合金融商品においては、ＷＳＳ３１１及び３２１を改修することなく、これらの処理要求元であるＷＳＣ２３１及び２３２を流用することにより、既存システムの再利用性を高め、新たな複合金融商品に対応したシステムの開発を容易にすることができる。
【００４２】
ＷＥＢサービスアクセス制限ＤＢ３０は、ＷＳＳ３１１又はＷＳＳ３２１を介した処理を許可する外部システムの識別情報を格納する記憶装置である。そして、ＷＳＳ３１１は、ＷＳＣ２３１から受信した第１の処理要求に含まれる取引受付システム２の識別情報に基づき、ＷＥＢサービスアクセス制限ＤＢ３０を参照し、取引受付システム２がＷＳＳ３１１を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、第１の処理要求に含まれる第１の取引情報を用いて金融商品ＤＢ３１３に対して処理を行う。これにより、ユーザ単位の既存システムへのアクセス権限の管理が不要となり、管理負担を軽減することができる。
【００４３】
例えば、取引処理手段３１２及び金融商品ＤＢ３１３は、既存システムであるため、取引受付システム２とは異なるアクセス権限の管理が必要である場合が多い。しかし、複合取引情報管理システム１００を含む金融機関における情報システムのユーザは、人数が多いため、店舗や部署異動に伴う各情報システムのアクセス権限の更新頻度も多い。また、各ユーザについての複数のシステムにおけるアクセス権限の管理は、通常、シングルサインオン等の技術を用いることが多い。しかし、シングルサインオンでは、取引管理システム３１に対する処理要求の度に、アクセス権限を管理するサーバへのアクセスが発生し、本来の処理に対する応答時間に影響が出る場合もある。そのため、アクセス権限管理のための通信負荷を抑える必要性が高い。
【００４４】
ここで、取引受付システム２は、端末１を操作するユーザからのアクセス認証を行った上で、取引管理システム群３への処理要求を行う。そのため、取引受付システム２からのアクセスについては、信頼性が高いと言える。そこで、本発明の実施の形態１にかかるＷＥＢサービスアクセス制限ＤＢ３０は、ユーザごとの権限管理ではなく、処理要求元のシステムを識別することにより、アクセス権限を管理するためのものである。これにより、ユーザの異動に伴うアクセス権限の更新は、取引受付システム２に対して行うことで、取引管理システム群３に対する権限管理を併せて行うことができる。そして、取引受付システム２においては、シングルサインオンなどの仕組を適用することでより効率的に、かつ、実質的に権限を一元管理することができる。尚、システムの識別情報としては、例えば、ＩＰアドレスやホスト名（コンピュータ名）、システム名等が挙げられる。
【００４５】
さらに、ＷＥＢサービスアクセス制限ＤＢ３０は、外部システムの識別情報をＷＳＳ３１１が受信する処理要求の種別ごとに関連付けて記憶することが望ましい。処理要求の種別ごととは、例えば、ＷＥＢサービスにおける各イベントが挙げられる。そして、ＷＳＳ３１１は、ＷＳＣ２３１から受信した第１の処理要求の種別に基づき、ＷＥＢサービスアクセス制限ＤＢ３０を参照し、取引受付システム２がＷＳＳ３１１を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、第１の処理要求に含まれる第１の取引情報を用いて金融商品ＤＢ３１３に対して処理を行う。また、上述したことは、ＷＳＳ３２１についても同様である。但し、ＷＥＢサービスアクセス制限ＤＢ３０は、少なくともＷＳＳ３１１を介した処理を許可する外部システムの識別情報を格納していればよい。
【００４６】
図３は、本発明の実施の形態１にかかるＷｅｂサービスのアクセス制限情報の例を示す図である。図３では、サービス名が２種類、個々のサービスに対応したイベント名が５種類存在する場合に、これらのサービス名とイベント名の組合せについて処理の許可有無が定義されていることを示す。例えば、ＳＹＳＴＥＭ＿Ｘには、フロント業務を行うユーザのみがアクセス可能で、ＳＹＳＴＥＭ＿Ｙには、バック業務を行うユーザのみがアクセス可能であるものとする。そして、削除要求（delete_A）や途中解約要求（terminate_A）といったイベントは、バック業務のみで行われるため、ＳＹＳＴＥＭ＿Ｙからの処理要求である場合のみ、許可することを示す。このように、業務に応じてアクセス可能な取引受付システム２を分けることで、容易に、処理可能なイベントの制御をすることができる。
【００４７】
ここで、図４は、本発明の実施の形態１にかかる親取引（スワップ）の項目の例を示す図である。つまり、複合金融商品が図２に示した仕組債である場合に、親取引をスワップ取引とし、図示した大項目により表現することを示す。尚、上述したように親取引の項目数は、分割前の複合金融商品の項目数より多くなるため、親取引における小項目の詳細は、省略し、各大項目内の小項目数のみを示す。つまり、取引情報生成手段２２は、第１の取引情報を生成する場合に、図４の親取引の項目のうち図２の複合取引情報の各項目と特性が一致する項目に対してそのデータを含める。また、取引情報生成手段２２は、親取引の項目のうち複合金融商品に含まれない項目におけるデータを補完する。
【００４８】
図５は、本発明の実施の形態１にかかる取引情報の項目毎の生成方法の例を示す図である。ここでは、図４の大項目である基本情報における小項目の一部を示し、かつ、小項目ごとのデータの生成方法を例示する。例えば、「担当者」については、取引情報生成手段２２は、図２の「担当者」に入力されたデータをそのまま第１の取引情報に含めて設定する。また、「所属部署」及び「営業所」については、取引情報生成手段２２は、担当者における所属部署及び営業所等の情報を格納するデータベース（不図示）から所属部署及び営業所等を取得し、第１の取引情報に含めることにより補完を行う。また、「グループ名」については、取引情報生成手段２２は、前記データベースに予めデフォルト値として登録されたグループ名を取得し、第１の取引情報に含めることにより補完を行う。このように、取引情報生成手段２２は、図２の「担当者」に入力されたデータに基づき、その他の項目におけるデータを補完して第１の取引情報を生成する。これにより、端末１を操作するユーザが入力するデータ量が減少するため、入力負担を軽減することができる。なお、基本情報以外の大項目についても、複合金融商品に含まれない項目におけるデータについては、適宜、補完されるものとする。
【００４９】
また、図６は、本発明の実施の形態１にかかる子取引（スワップション）の項目の例を示す図である。つまり、図４と同様に、複合金融商品が図２に示した仕組債である場合に、子取引をスワップション取引とし、図示した大項目により表現することを示す。尚、図６の基本情報、休日参照都市情報及び手数料情報については、取引情報生成手段２２は、概ね親取引と同等の補完処理等を行うため、説明を省略する。
【００５０】
また、図６のオプション情報、プレミアム情報及びオプション休日参照都市情報については、子取引であるスワップション取引のみの項目である。これらの項目については、取引情報生成手段２２は、主に、図２の「コール条件」に入力されたデータに基づき、その他の項目におけるデータを補完して第２の取引情報を生成する。逆に、親取引であるスワップ取引には、「コール条件」に対応する項目が存在しない。ここで、「コール条件」とは、取引期間の決定条件と呼ぶことができる。そのため、第１の取引情報は、複合取引情報から取引期間の決定条件の特性を除き、取引期間を固定して生成された情報といえる。言い換えると、取引情報生成手段２２は、複合取引情報に含まれる日付のデータを固定期間となるように補正して第１の取引情報を生成する。一方、取引情報生成手段２２は、複合取引情報に含まれる取引期間の決定条件を用いて第２の取引情報を生成する。
【００５１】
ここで、図４の親取引と図６の子取引では大項目であるクーポン及びコストが共通する。また、図２の複合金融商品にもクーポン及びコストが存在する。しかし、親取引と子取引について、取引情報生成手段２２は、クーポン及びコストのデータを異なるものとする。その点を図７及び図８を用いて説明する。
【００５２】
図７は、本発明の実施の形態１にかかる生成される親取引情報の一部（クーポン及びコスト）の例を示す図である。図８は、本発明の実施の形態１にかかる生成される子取引情報の一部（クーポン及びコスト）の例を示す図である。例えば、図２のクーポンのレートについて、取引情報生成手段２２は、図７の親取引においてはクーポンの金利として設定し、また、図８の子取引においてはコストの金利として設定することを示す。逆に、図２のコストのレートについて、取引情報生成手段２２は、図７の親取引においてはコストの金利として設定し、また、図８の子取引においてはクーポンの金利として設定することを示す。つまり、取引情報生成手段２２は、親取引と子取引との間の整合性を保つように、両取引に分解する。さらに、取引情報生成手段２２は、図２の開始日、終了日、クーポンのロール月及びロール日を用いて、図７及び図８のクーポン及びコストの金利期間情報を算出する。このとき、取引情報生成手段２２は、図２の初回利払日と同日又は直近の日付を親取引の金利期間情報の値とする。また、取引情報生成手段２２は、利払サイクル月数の日付を考慮して子取引の金利期間情報の値とする。
【００５３】
まとめると、次のようになる。まず、取引情報生成手段２２は、第１の金融商品の項目のうち複合金融商品に含まれる項目におけるデータを、第１の金融商品の項目に対応するように補正して第１の取引情報を生成する。一方、取引情報生成手段２２は、第１の取引情報の逆取引となるデータを含めて第２の取引情報を生成する。これにより、このような第１の取引情報と第２の取引情報の関係となるような入力をユーザが逐次判断して入力することなく、本発明の実施の形態１により、複数の取引情報について整合性を保つように生成することができる。
【００５４】
図９は、本発明の実施の形態１にかかる取引受付システム２のハードウェア構成を示すブロック図である。取引受付システム２は、ＣＰＵ（Central Processing Unit）２０１と、ＲＡＭ（Random Access Memory）２０２と、ＲＯＭ（Read Only Memory）２０３と、通信部２０４と、ハードディスク２０５とを備える。また、ハードディスク２０５は、不揮発性記憶装置であり、ＯＳ（Operating System）２５１、ＷＥＢサーバプログラム２５２、ＷＥＢアプリケーションプログラム２５３、ＷＥＢサービスクライアントプログラム２５４及び２５５が格納されている。
【００５５】
ＯＳ２５１及びＷＥＢサーバプログラム２５２は、周知のコンピュータプログラムであるため、説明を省略する。ＷＥＢアプリケーションプログラム２５３は、図１の受付手段２１及び取引情報生成手段２２を実現するためのコンピュータプログラムである。特に、ＷＥＢアプリケーションプログラム２５３には、上述した分解ロジックが実装されている。但し、当該分解ロジックは、別のプログラムモジュール（不図示）であってもよい。また、ＷＥＢサービスクライアントプログラム２５４及び２５５は、それぞれＷＳＣ２３１及び２３２を実現するためのコンピュータプログラムである。
【００５６】
ＣＰＵ２０１は、取引受付システム２における各種処理、ＲＡＭ２０２、ＲＯＭ２０３、通信部２０４及びハードディスク２０５へのアクセス等を制御する。通信部２０４は、端末１及び取引管理システム群３との通信を行う。取引受付システム２は、ＣＰＵ２０１が、ＲＡＭ２０２、ＲＯＭ２０３又はハードディスク２０５に格納されたＯＳ２５１、ＷＥＢサーバプログラム２５２、ＷＥＢアプリケーションプログラム２５３、ＷＥＢサービスクライアントプログラム２５４及び２５５を読み込み、実行する。これにより、取引受付システム２は、取引管理システム群３に複合取引情報の処理を行わせることができる。尚、取引受付システム２は、複数台に分散して実現されても構わない。
【００５７】
図１０は、本発明の実施の形態１にかかる取引管理システム３１のハードウェア構成を示すブロック図である。尚、取引管理システム３２についても同等であるため、図示及び説明を省略する。取引管理システム３１は、ＣＰＵ（Central Processing Unit）３０１と、ＲＡＭ（Random Access Memory）３０２と、ＲＯＭ（Read Only Memory）３０３と、通信部３０４と、ハードディスク３０５とを備える。また、ハードディスク３０５は、不揮発性記憶装置であり、ＯＳ（Operating System）３５１、金融商品ＤＢ３５２、取引処理プログラム３５３及びＷＥＢサービスサーバプログラム３５４が格納されている。
【００５８】
ＯＳ３５１は、周知のコンピュータプログラムであるため、説明を省略する。金融商品ＤＢ３５２は、図１の金融商品ＤＢ３１３に対応するデータ及びＤＢＭＳである。また、取引処理プログラム３５３は、取引処理手段３１２を実現するためのコンピュータプログラムである。また、ＷＥＢサービスサーバプログラム３５４は、ＷＳＳ３１１を実現するためのコンピュータプログラムである。
【００５９】
ＣＰＵ３０１は、取引管理システム３１における各種処理、ＲＡＭ３０２、ＲＯＭ３０３、通信部３０４及びハードディスク３０５へのアクセス等を制御する。通信部３０４は、端末１、取引受付システム２、取引管理システム３２及びＷＥＢサービスアクセス制限ＤＢ３０との通信を行う。取引管理システム３１は、ＣＰＵ３０１が、ＲＡＭ３０２、ＲＯＭ３０３又はハードディスク３０５に格納されたＯＳ３５１、取引処理プログラム３５３及びＷＥＢサービスサーバプログラム３５４を読み込み、実行する。これにより、取引管理システム３１は、金融商品ＤＢ３１３に対する処理要求を行うことができる。尚、取引管理システム３１は、複数台に分散して実現されても構わない。
【００６０】
図１１は、本発明の実施の形態１にかかる仕組債登録処理の流れを示すシーケンス図である。まず、受付手段２１は、端末１から複合取引情報の入力を受け付ける（Ｓ１０１）。次に、取引情報生成手段２２は、複合取引情報から複数の取引情報に分解する（Ｓ１０２）。そして、ＷＳＣ２３１は、親取引における取引情報の登録要求を送信する（Ｓ１０３）。すなわち、ＷＳＣ２３１は、ＷＳＳ３１１に対して、生成した第１の取引情報を含めて第１のデータ形式に基づく第１の登録要求を送信する。
【００６１】
続いて、取引管理システム３１は、親取引の登録処理を行う（Ｓ１０４）。すなわち、まず、ＷＳＳ３１１は、ＷＳＣ２３１から第１の登録要求を受信する。次に、ＷＳＳ３１１は、当該第１の登録要求に含まれる第１の取引情報を、取引処理手段３１２を用いて金融商品ＤＢ３１３へ登録する。このとき、取引処理手段３１２は、登録された第１の取引情報に対して取引識別情報を発行する。そして、ＷＳＳ３１１は、発行された取引識別情報をＷＳＣ２３１へ返信する（Ｓ１０５）。
【００６２】
そして、ＷＳＣ２３１は、ＷＳＳ３１１から取引識別情報を受信する。ここで、ＷＳＣ２３２は、取引識別情報を含む子取引における取引情報の登録要求を送信する（Ｓ１０６）。すなわち、ＷＳＣ２３２は、ＷＳＣ２３１がＷＳＳ３１１から取引識別情報を受信した場合に、ＷＳＳ３２１に対して、当該取引識別情報と生成した第２の取引情報とを含めて第２のデータ形式に基づく第２の登録要求を送信する。
【００６３】
その後、取引管理システム３２は、子取引の登録処理を行う（Ｓ１０７）。すなわち、まず、ＷＳＳ３２１は、ＷＳＣ２３２から第２の登録要求を受信する。次に、ＷＳＳ３２１は、当該第２の登録要求に含まれる第２の取引情報を当該第２の登録要求に含まれる取引識別情報に関連付けて、取引処理手段３２２を用いて金融商品ＤＢ３２３へ登録する。
【００６４】
そして、ＷＳＳ３２１は、ＷＳＣ２３２へ処理結果を返信する（Ｓ１０８）。その後、ＷＳＣ２３２は、ＷＳＳ３２１から処理結果を受信する。そして、受付手段２１は、端末１に対して処理結果を出力する（Ｓ１０９）。
【００６５】
このように、金融商品ＤＢ３１３及び金融商品ＤＢ３２３を用いて、分解した第１及び第２の取引情報を登録することにより、実質的に複合取引情報の登録が可能となる。
【００６６】
図１２は、本発明の実施の形態１にかかる取引受付システムの処理要求の受付処理の流れを示すフローチャートである。まず、受付手段２１は、端末１から複合取引情報を含む処理要求を受け付ける。このとき、処理要求は、複合取引情報の登録要求又は更新要求等である。
【００６７】
次に、受付手段２１は、複合取引情報からユーザの識別情報を抽出する。そして、受付手段２１は、ユーザ認証処理を行う（Ｓ２０１）。すなわち、受付手段２１は、取引受付システム２において当該ユーザ識別情報がアクセスを許可されているか否かを判定する。例えば、シングルサインオン機能を利用しても構わない。
【００６８】
次に、受付手段２１は、認証が成功したか否かを判定する（Ｓ２０２）。認証が失敗したと判定した場合、受付手段２１は、端末１に対して認証失敗の旨を返信する（Ｓ２０８）。そして、当該受付処理を終了する。
【００６９】
ステップＳ２０２において、認証が成功したと判定した場合、取引情報生成手段２２は、複合取引情報から複数の取引情報に分解する。すなわち、取引情報生成手段２２は、受付手段２１から出力された複合取引情報から第１の取引情報である親取引情報を生成する（Ｓ２０３）。このとき、取引情報生成手段２２は、生成した親取引情報を含めて、第１のデータ形式に基づく処理要求を生成する。そして、ＷＳＣ２３１は、生成した親取引情報の処理要求をＷＳＳ３１１へ送信する（Ｓ２０４）。また、取引情報生成手段２２は、受付手段２１から出力された複合取引情報から第２の取引情報である子取引情報を生成する（Ｓ２０５）。このとき、取引情報生成手段２２は、生成した子取引情報を含めて、第２のデータ形式に基づく処理要求を生成する。尚、処理要求が更新要求である場合、ステップＳ２０３及びＳ２０５では、それぞれ親取引情報及び子取引情報の更新情報を生成する。
【００７０】
そして、ＷＳＣ２３２は、ステップＳ２０４及びＳ２０５の後、子取引情報の処理要求をＷＳＳ３２１に対して送信する（Ｓ２０６）。ここで、処理要求が登録要求である場合、ＷＳＣ２３２は、子取引情報が生成され、かつ、ＷＳＣ２３１がＷＳＳ３１１から取引識別情報を受信後に、送信する。その後、ＷＳＣ２３２がＷＳＳ３２１から処理結果を受信した後に、受付手段２１は、処理結果を端末１に対して返信する（Ｓ２０７）。そして、当該受付処理を終了する。
【００７１】
図１３は、本発明の実施の形態１にかかる取引管理システム３１の処理要求に応じた処理の流れを示すフローチャートである。尚、取引管理システム３２についても同等の処理であるため、図示及び説明を省略する。
【００７２】
まず、ＷＳＳ３１１は、ＷＳＣ２３１から処理要求を受信する（Ｓ３０１）。つまり、ＷＳＳ３１１は、第１のデータ形式に基づく処理要求を受信する。次に、ＷＳＳ３１１は、処理要求元の取引受付システム２にＷＥＢサービスの利用が許可されているか否かを判定する（Ｓ３０２）。具体的には、ＷＳＳ３１１は、受信した処理要求を解析し、サービス名及びイベント名並びに取引受付システム２のＩＰアドレス又はシステム名を抽出する。そして、ＷＳＳ３１１は、ＷＥＢサービスアクセス制限ＤＢ３０を参照し、抽出したサービス名及びイベント名並びにＩＰアドレス又はシステム名の組合せが登録されているか否かを判定する。
【００７３】
ステップＳ３０２において、取引受付システム２にＷＥＢサービスの利用が許可されていると判定した場合、ＷＳＳ３１１は、受信した取引情報を処理する（Ｓ３０３）。すなわち、ＷＳＳ３１１は、取引処理手段３１２を用いて金融商品ＤＢ３１３へ受信した取引情報に関する処理を行う。
【００７４】
その後、ＷＳＳ３１１は、処理結果をＷＳＣ２３１へ返信する（Ｓ３０４）。このとき、処理要求が登録要求である場合、取引処理手段３１２は、登録した取引情報における取引識別情報を発行する。そして、ＷＳＳ３１１は、処理結果に取引識別情報を含めて返信する。
【００７５】
ステップＳ３０２において、取引受付システム２にＷＥＢサービスの利用が許可されていないと判定した場合、ＷＳＳ３１１は、処理不可の旨をＷＳＣ２３１へ返信する（Ｓ３０５）。その後、当該処理要求に応じた処理を終了する。
【００７６】
図１４は、本発明の実施の形態１にかかる複合取引情報管理システムの応用例の全体構成を示すブロック図である。複合取引情報管理システム１０１は、複合取引情報管理システム１００に構成要素を追加したものである。すなわち、図１に比べて、取引受付システム２ａが追加され、取引管理システム群３が取引管理システム群３ａに変更したものである。以下、図１との違いを中心に説明し、同一の構成要素については同一の符号を付し、詳細な説明を省略する。
【００７７】
取引管理システム群３ａは、取引管理システム群３に取引管理システム３３が追加されたものである。取引管理システム３３は、第３の金融商品における第３の取引情報を管理するための情報システムである。尚、取引管理システム３３は、ＷＳＳ３３１、取引処理手段３３２及び金融商品ＤＢ３３３を備えるが、それぞれ、取引管理システム３１又は３２が備える構成要素に対応する。但し、ＷＳＳ３３１は、第３のデータ形式に基づく処理要求についてのみ処理を行う。
【００７８】
取引受付システム２ａは、取引受付システム２とは異なり、第２の金融商品及び第３の金融商品に分解可能な複合金融商品の取引情報を受け付けるための情報システムである。尚、取引受付システム２ａは、受付手段２１ａ、取引情報生成手段２２ａ、ＷＳＣ２３１ａ及び２３２ａを備えるが、それぞれ、取引受付システム２が備える構成要素に対応する。但し、取引情報生成手段２２ａは、受け付けた複合取引情報から第２の取引情報及び第３の取引情報に分解する。そして、ＷＳＣ２３１ａは、ＷＳＣ２３２と同じくＷＳＳ３２１に対する処理要求を行うＷｅｂサービスクライアントである。つまり、ＷＳＣ２３１ａには、ＷＳＣ２３２が流用可能である。また、ＷＳＣ２３２ａは、第３のデータ形式に基づく処理要求をＷＳＳ３３１に対して送信するＷｅｂサービスクライアントである。
【００７９】
このように、本発明の実施の形態１を応用すると、複合取引情報管理システム１０１のように、既存の複合金融商品と一部の条件が異なるような新規の複合金融商品を採用する場合であっても、情報システムの開発コストを抑えることができる。例えば、取引処理手段３３２及び金融商品ＤＢ３３３に、既存の単一の金融商品を管理するためのデータベースシステムを用いることができる。その場合、新規開発する構成要素は、ＷＳＳ３３１、ＷＳＣ２３２ａ、取引情報生成手段２２ａ及び受付手段２１ａとなる。そのため、複合取引情報管理システム１００を開発した時に比べて、さらに開発コストを抑えることができる。
【００８０】
＜その他の発明の実施の形態＞
尚、本発明の実施の形態は、さらに以下の構成を備えても構わない。まず、取引情報生成手段２２は、複合取引情報を登録する場合には、当該複合取引情報が取引期間の決定条件に基づき最も短い期間に決定された場合の取引期間となるように第１の取引情報を生成する。また、取引情報生成手段２２は、複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定されなかった場合には、当該取引期間を延長するように第１の取引情報を生成するとよい。これにより、第２の取引情報における権利行使等により第１の取引情報の内容を自動的に対応させることができる。つまり、ユーザの入力負担をさらに軽減することができる。
【００８１】
さらには、次のようにしてもよい。まず、取引情報生成手段２２は、複合取引情報における一部の契約が確定した場合に、未確定の契約に基づき、第１の取引情報及び第２の取引情報の更新情報を生成する。次に、ＷＳＣ２３１は、ＷＳＳ３１１に対して、生成した第１の取引情報の更新情報を含めて第１のデータ形式に基づく第１の更新要求を送信する。このとき、ＷＳＳ３１１は、第１の更新要求を受信した場合に、当該第１の更新要求に含まれる第１の取引情報の更新情報に基づき金融商品ＤＢ３１３に登録された第１の取引情報を更新する。そして、ＷＳＣ２３２は、取引識別情報と生成した第２の取引情報の更新情報とを含めて第２のデータ形式に基づく第２の更新要求を送信する。このとき、ＷＳＳ３２１は、第２の更新要求を受信した場合に、当該第２の更新要求に含まれる第２の取引情報の更新情報及び当該第２の更新要求に含まれる取引識別情報に基づき、金融商品ＤＢ３２３に登録された第２の取引情報を更新するとよい。これにより、分解された複数の取引情報間のスケジュールの整合性を保つことができ、実質的に複合取引情報の管理を容易にすることができる。
【００８２】
さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。
【符号の説明】
【００８３】
１００ 複合取引情報管理システム
１０１ 複合取引情報管理システム
１ 端末
２ 取引受付システム
２ａ 取引受付システム
２１ 受付手段
２１ａ 受付手段
２２ 取引情報生成手段
２２ａ 取引情報生成手段
２３１ ＷＳＣ（Web Service Client）
２３１ａ ＷＳＣ
２３２ ＷＳＣ
２３２ａ ＷＳＣ
３ 取引管理システム群
３ａ 取引管理システム群
３０ ＷＥＢサービスアクセス制限ＤＢ
３１ 取引管理システム
３１１ ＷＳＳ（Web Service Server）
３１２ 取引処理手段
３１３ 金融商品ＤＢ
３２ 取引管理システム
３２１ ＷＳＳ
３２２ 取引処理手段
３２３ 金融商品ＤＢ
３３ 取引管理システム
３３１ ＷＳＳ
３３２ 取引処理手段
３３３ 金融商品ＤＢ
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ 通信部
２０５ ハードディスク
２５１ ＯＳ
２５２ ＷＥＢサーバプログラム
２５３ ＷＥＢアプリケーションプログラム
２５４ ＷＥＢサービスクライアントプログラム
２５５ ＷＥＢサービスクライアントプログラム
３０１ ＣＰＵ
３０２ ＲＡＭ
３０３ ＲＯＭ
３０４ 通信部
３０５ ハードディスク
３５１ ＯＳ
３５２ 金融商品ＤＢ
３５３ 取引処理プログラム
３５４ ＷＥＢサービスサーバプログラム
【特許請求の範囲】
【請求項１】
第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を管理する複合取引情報管理システムであって、
前記複合取引情報を外部から受け付けて、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、前記第１の金融商品の取引情報である第１の取引情報と、前記第２の金融商品の取引情報である第２の取引情報に分解して出力する取引受付システムと、
前記取引受付システムより出力された第１の取引情報を入力し、これを管理する第１の取引管理システムと、
前記取引受付システムより出力された第２の取引情報を入力し、これを管理する第２の取引管理システムと、を備え、
前記取引受付システムは、前記第１の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完して前記第１の取引情報を生成し、前記第２の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完し、前記第１の取引情報に対応するデータを含めて前記第２の取引情報を生成する取引情報生成手段を備えることを特徴とする複合取引情報管理システム。
【請求項２】
前記第１の取引管理システムは、
第１のデータ形式に基づく第１の処理要求を外部から受信し、当該第１の処理要求に基づいて、前記第１の取引情報を管理するための第１のデータベースに対して処理を行う第１のＩＦ手段を備え、
前記第２の取引管理システムは、
第２のデータ形式に基づく第２の処理要求を外部から受信し、当該第２の処理要求に基づいて、前記第２の取引情報を管理するための第２のデータベースに対して処理を行う第２のＩＦ手段を備え、
前記取引受付システムは、
前記第１のＩＦ手段に対して、前記第１の処理要求に前記生成された第１の取引情報を含めて送信する第１の処理要求手段と、
前記第２のＩＦ手段に対して、前記第２の処理要求に前記生成された第２の取引情報を含めて送信する第２の処理要求手段と、を備えることを特徴とする請求項１に記載の複合取引情報管理システム。
【請求項３】
前記第１の処理要求手段は、前記第１のＩＦ手段に対して、前記生成した第１の取引情報を含めて前記第１のデータ形式に基づく第１の登録要求を送信し、
前記第１のＩＦ手段は、前記第１の登録要求を受信した場合に、当該第１の登録要求に含まれる第１の取引情報を前記第１のデータベースへ登録し、登録された第１の取引情報に対して発行された取引識別情報を前記第１の処理要求手段へ返信し、
前記第２の処理要求手段は、前記第１の処理要求手段が前記第１のＩＦ手段から前記取引識別情報を受信した場合に、前記第２のＩＦ手段に対して、当該取引識別情報と前記生成した第２の取引情報とを含めて前記第２のデータ形式に基づく第２の登録要求を送信し、
前記第２のＩＦ手段は、前記第２の登録要求を受信した場合に、当該第２の登録要求に含まれる第２の取引情報を当該第２の登録要求に含まれる取引識別情報に関連付けて前記第２のデータベースへ登録することを特徴とする請求項２に記載の複合取引情報管理システム。
【請求項４】
前記取引受付システムは、ユーザの識別情報を含む前記複合取引情報を外部から受け付けた場合に、当該ユーザの識別情報に基づき、当該取引受付システムにおける認証を行う認証手段をさらに備え、
前記第１の処理要求手段は、前記認証手段により認証された場合に、前記第１のＩＦ手段に対して、前記第１の処理要求に前記取引受付システムの識別情報をさらに含めて送信し、
前記複合取引情報管理システムは、前記第１のＩＦ手段を介した処理を許可する外部システムの識別情報を格納する記憶部をさらに備え、
前記第１のＩＦ手段は、前記第１の処理要求手段から受信した第１の処理要求に含まれる前記取引受付システムの識別情報に基づき、前記記憶部を参照し、当該取引受付システムが当該第１のＩＦ手段を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、前記第１の処理要求に含まれる前記第１の取引情報を用いて前記第１のデータベースに対して処理を行うことを特徴とする請求項２又は３に記載の複合取引情報管理システム。
【請求項５】
前記記憶部は、前記外部システムの識別情報を前記第１のＩＦ手段が受信する処理要求の種別ごとに関連付けて記憶し、
前記第１のＩＦ手段は、前記第１の処理要求手段から受信した第１の処理要求の種別に基づき、前記記憶部を参照し、当該取引受付システムが前記第１のＩＦ手段を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、前記第１の処理要求に含まれる前記第１の取引情報を用いて前記第１のデータベースに対して処理を行うことを特徴とする請求項４に記載の複合取引情報管理システム。
【請求項６】
前記取引情報生成手段は、前記第１の金融商品の項目のうち前記複合金融商品に含まれる項目におけるデータを、前記第１の金融商品の項目に対応するように補正して前記第１の取引情報を生成し、前記第１の取引情報の逆取引となるデータを含めて前記第２の取引情報を生成することを特徴とする請求項１乃至５のいずれか１項に記載の複合取引情報管理システム。
【請求項７】
前記複合金融商品は、所定の金利条件と、取引期間の決定条件とを含む金融商品であり、
前記第１の金融商品は、前記所定の金利条件についての取引期間が固定された金融商品であり、
前記第２の金融商品は、前記取引期間の決定条件に関する金融商品であり、
前記取引情報生成手段は、前記複合取引情報に含まれる日付のデータを固定期間となるように補正して前記第１の取引情報を生成し、前記複合取引情報に含まれる取引期間の決定条件を用いて前記第２の取引情報を生成することを特徴とする請求項１乃至６のいずれか１項に記載の複合取引情報管理システム。
【請求項８】
前記取引情報生成手段は、
前記複合取引情報を登録する場合には、当該複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定された場合の取引期間となるように前記第１の取引情報を生成し、
前記複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定されなかった場合には、当該取引期間を延長するように前記第１の取引情報を生成する
ことを特徴とする請求項７に記載の複合取引情報管理システム。
【請求項９】
前記取引情報生成手段は、前記複合取引情報における一部の契約が確定した場合に、未確定の契約に基づき、前記第１の取引情報及び前記第２の取引情報の更新情報を生成し、
前記第１の処理要求手段は、前記第１のＩＦ手段に対して、前記生成した第１の取引情報の更新情報を含めて前記第１のデータ形式に基づく第１の更新要求を送信し、
前記第１のＩＦ手段は、前記第１の更新要求を受信した場合に、当該第１の更新要求に含まれる第１の取引情報の更新情報に基づき前記第１のデータベースに登録された第１の取引情報を更新し、
前記第２の処理要求手段は、前記取引識別情報と前記生成した第２の取引情報の更新情報とを含めて前記第２のデータ形式に基づく第２の更新要求を送信し、
前記第２のＩＦ手段は、前記第２の更新要求を受信した場合に、当該第２の更新要求に含まれる第２の取引情報の更新情報及び当該第２の更新要求に含まれる取引識別情報に基づき、前記第２のデータベースに登録された第２の取引情報を更新することを特徴とする請求項８に記載の複合取引情報管理システム。
【請求項１０】
第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を外部から受け付ける取引受付システムと、
前記第１の金融商品の取引情報である第１の取引情報を管理する第１の取引管理システムと、
前記第２の金融商品の取引情報である第２の取引情報を管理する第２の取引管理システムと、を用いて、
前記複合取引情報を管理する複合取引情報管理方法であって、
前記取引受付システムにおいて、前記外部から受け付けた前記複合取引情報から、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、前記第１の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完して前記第１の取引情報を生成し、
前記取引受付システムにおいて、前記複合取引情報から、前記分解ロジックに基づいて、前記第２の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完し、前記第１の取引情報に対応するデータを含めて前記第２の取引情報を生成し、
前記取引受付システムにおいて、前記生成した第１の取引情報を前記第１の取引管理システムに対して出力し、
前記第１の取引管理システムにおいて、前記取引受付システムより出力された第１の取引情報を入力し、当該入力された第１の取引情報について、当該第１の取引情報を管理するための第１のデータベースに対して処理を行い、
前記取引受付システムにおいて、前記生成した第２の取引情報を前記第２の取引管理システムに対して出力し、
前記第２の取引管理システムにおいて、前記取引受付システムより出力された第２の取引情報を入力し、当該入力された第２の取引情報について、当該第２の取引情報を管理するための第２のデータベースに対して処理を行う複合取引情報管理方法。
【請求項１】
第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を管理する複合取引情報管理システムであって、
前記複合取引情報を外部から受け付けて、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、前記第１の金融商品の取引情報である第１の取引情報と、前記第２の金融商品の取引情報である第２の取引情報に分解して出力する取引受付システムと、
前記取引受付システムより出力された第１の取引情報を入力し、これを管理する第１の取引管理システムと、
前記取引受付システムより出力された第２の取引情報を入力し、これを管理する第２の取引管理システムと、を備え、
前記取引受付システムは、前記第１の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完して前記第１の取引情報を生成し、前記第２の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完し、前記第１の取引情報に対応するデータを含めて前記第２の取引情報を生成する取引情報生成手段を備えることを特徴とする複合取引情報管理システム。
【請求項２】
前記第１の取引管理システムは、
第１のデータ形式に基づく第１の処理要求を外部から受信し、当該第１の処理要求に基づいて、前記第１の取引情報を管理するための第１のデータベースに対して処理を行う第１のＩＦ手段を備え、
前記第２の取引管理システムは、
第２のデータ形式に基づく第２の処理要求を外部から受信し、当該第２の処理要求に基づいて、前記第２の取引情報を管理するための第２のデータベースに対して処理を行う第２のＩＦ手段を備え、
前記取引受付システムは、
前記第１のＩＦ手段に対して、前記第１の処理要求に前記生成された第１の取引情報を含めて送信する第１の処理要求手段と、
前記第２のＩＦ手段に対して、前記第２の処理要求に前記生成された第２の取引情報を含めて送信する第２の処理要求手段と、を備えることを特徴とする請求項１に記載の複合取引情報管理システム。
【請求項３】
前記第１の処理要求手段は、前記第１のＩＦ手段に対して、前記生成した第１の取引情報を含めて前記第１のデータ形式に基づく第１の登録要求を送信し、
前記第１のＩＦ手段は、前記第１の登録要求を受信した場合に、当該第１の登録要求に含まれる第１の取引情報を前記第１のデータベースへ登録し、登録された第１の取引情報に対して発行された取引識別情報を前記第１の処理要求手段へ返信し、
前記第２の処理要求手段は、前記第１の処理要求手段が前記第１のＩＦ手段から前記取引識別情報を受信した場合に、前記第２のＩＦ手段に対して、当該取引識別情報と前記生成した第２の取引情報とを含めて前記第２のデータ形式に基づく第２の登録要求を送信し、
前記第２のＩＦ手段は、前記第２の登録要求を受信した場合に、当該第２の登録要求に含まれる第２の取引情報を当該第２の登録要求に含まれる取引識別情報に関連付けて前記第２のデータベースへ登録することを特徴とする請求項２に記載の複合取引情報管理システム。
【請求項４】
前記取引受付システムは、ユーザの識別情報を含む前記複合取引情報を外部から受け付けた場合に、当該ユーザの識別情報に基づき、当該取引受付システムにおける認証を行う認証手段をさらに備え、
前記第１の処理要求手段は、前記認証手段により認証された場合に、前記第１のＩＦ手段に対して、前記第１の処理要求に前記取引受付システムの識別情報をさらに含めて送信し、
前記複合取引情報管理システムは、前記第１のＩＦ手段を介した処理を許可する外部システムの識別情報を格納する記憶部をさらに備え、
前記第１のＩＦ手段は、前記第１の処理要求手段から受信した第１の処理要求に含まれる前記取引受付システムの識別情報に基づき、前記記憶部を参照し、当該取引受付システムが当該第１のＩＦ手段を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、前記第１の処理要求に含まれる前記第１の取引情報を用いて前記第１のデータベースに対して処理を行うことを特徴とする請求項２又は３に記載の複合取引情報管理システム。
【請求項５】
前記記憶部は、前記外部システムの識別情報を前記第１のＩＦ手段が受信する処理要求の種別ごとに関連付けて記憶し、
前記第１のＩＦ手段は、前記第１の処理要求手段から受信した第１の処理要求の種別に基づき、前記記憶部を参照し、当該取引受付システムが前記第１のＩＦ手段を介した処理を許可されているか否かを判定し、許可されていると判定した場合に、前記第１の処理要求に含まれる前記第１の取引情報を用いて前記第１のデータベースに対して処理を行うことを特徴とする請求項４に記載の複合取引情報管理システム。
【請求項６】
前記取引情報生成手段は、前記第１の金融商品の項目のうち前記複合金融商品に含まれる項目におけるデータを、前記第１の金融商品の項目に対応するように補正して前記第１の取引情報を生成し、前記第１の取引情報の逆取引となるデータを含めて前記第２の取引情報を生成することを特徴とする請求項１乃至５のいずれか１項に記載の複合取引情報管理システム。
【請求項７】
前記複合金融商品は、所定の金利条件と、取引期間の決定条件とを含む金融商品であり、
前記第１の金融商品は、前記所定の金利条件についての取引期間が固定された金融商品であり、
前記第２の金融商品は、前記取引期間の決定条件に関する金融商品であり、
前記取引情報生成手段は、前記複合取引情報に含まれる日付のデータを固定期間となるように補正して前記第１の取引情報を生成し、前記複合取引情報に含まれる取引期間の決定条件を用いて前記第２の取引情報を生成することを特徴とする請求項１乃至６のいずれか１項に記載の複合取引情報管理システム。
【請求項８】
前記取引情報生成手段は、
前記複合取引情報を登録する場合には、当該複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定された場合の取引期間となるように前記第１の取引情報を生成し、
前記複合取引情報が前記取引期間の決定条件に基づき最も短い期間に決定されなかった場合には、当該取引期間を延長するように前記第１の取引情報を生成する
ことを特徴とする請求項７に記載の複合取引情報管理システム。
【請求項９】
前記取引情報生成手段は、前記複合取引情報における一部の契約が確定した場合に、未確定の契約に基づき、前記第１の取引情報及び前記第２の取引情報の更新情報を生成し、
前記第１の処理要求手段は、前記第１のＩＦ手段に対して、前記生成した第１の取引情報の更新情報を含めて前記第１のデータ形式に基づく第１の更新要求を送信し、
前記第１のＩＦ手段は、前記第１の更新要求を受信した場合に、当該第１の更新要求に含まれる第１の取引情報の更新情報に基づき前記第１のデータベースに登録された第１の取引情報を更新し、
前記第２の処理要求手段は、前記取引識別情報と前記生成した第２の取引情報の更新情報とを含めて前記第２のデータ形式に基づく第２の更新要求を送信し、
前記第２のＩＦ手段は、前記第２の更新要求を受信した場合に、当該第２の更新要求に含まれる第２の取引情報の更新情報及び当該第２の更新要求に含まれる取引識別情報に基づき、前記第２のデータベースに登録された第２の取引情報を更新することを特徴とする請求項８に記載の複合取引情報管理システム。
【請求項１０】
第１の金融商品と第２の金融商品の特性に分解可能な複合金融商品の取引情報である複合取引情報を外部から受け付ける取引受付システムと、
前記第１の金融商品の取引情報である第１の取引情報を管理する第１の取引管理システムと、
前記第２の金融商品の取引情報である第２の取引情報を管理する第２の取引管理システムと、を用いて、
前記複合取引情報を管理する複合取引情報管理方法であって、
前記取引受付システムにおいて、前記外部から受け付けた前記複合取引情報から、当該複合取引情報の複合金融商品に対して予め定められた分解ロジックに基づいて、前記第１の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完して前記第１の取引情報を生成し、
前記取引受付システムにおいて、前記複合取引情報から、前記分解ロジックに基づいて、前記第２の金融商品の項目のうち受け付けた前記複合金融商品に含まれない項目におけるデータを補完し、前記第１の取引情報に対応するデータを含めて前記第２の取引情報を生成し、
前記取引受付システムにおいて、前記生成した第１の取引情報を前記第１の取引管理システムに対して出力し、
前記第１の取引管理システムにおいて、前記取引受付システムより出力された第１の取引情報を入力し、当該入力された第１の取引情報について、当該第１の取引情報を管理するための第１のデータベースに対して処理を行い、
前記取引受付システムにおいて、前記生成した第２の取引情報を前記第２の取引管理システムに対して出力し、
前記第２の取引管理システムにおいて、前記取引受付システムより出力された第２の取引情報を入力し、当該入力された第２の取引情報について、当該第２の取引情報を管理するための第２のデータベースに対して処理を行う複合取引情報管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−３８１２３（Ｐ２０１２−３８１２３Ａ）
【公開日】平成２４年２月２３日（２０１２．２．２３）
【国際特許分類】
【出願番号】特願２０１０−１７８３３３（Ｐ２０１０−１７８３３３）
【出願日】平成２２年８月９日（２０１０．８．９）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
【公開日】平成２４年２月２３日（２０１２．２．２３）
【国際特許分類】
【出願日】平成２２年８月９日（２０１０．８．９）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
[ Back to top ]