JP2008262269A - 証券担保ローン管理システムおよびその方法、並びにプログラム - Google Patents

Abstract

【課題】 証券会社およびローン会社の双方の事務負担の軽減、並びに顧客にとっての利便性向上を図ることができる証券担保ローン管理システムおよびその方法を提供する。
【解決手段】 証券会社サーバ２０の適格審査処理手段２３により、証券会社が保有する顧客情報を利用して、顧客がローン契約が可能な顧客であるか否かを判断し、この証券会社での適格審査処理を通過した場合に、証券会社サーバ２０のローン会社向け連携情報送信処理手段２６により、住所、氏名、振込先金融機関データ、および担保残高データを含むローン会社向け連携情報を、証券会社サーバ２０からローン会社サーバ５０へ送信し、ローン会社サーバ５０の契約借入審査処理５２により、極度額データを算出するとともに借入の可否を判断する契約借入審査処理を行う。
【選択図】 図１

Description

本発明は、証券会社に預けられた有価証券を担保として顧客が借入を行う証券担保ローンに関する処理を実行するコンピュータからなる証券担保ローン管理システムおよびその方法、並びにプログラムに係り、例えば、オンライントレードを行う顧客によるローン契約、借入、返済の申込をオンラインで受け付ける場合等に利用できる。

従来より、証券会社に預けられた有価証券を担保として顧客が借入を行う証券担保ローンは、証券会社の店頭で対面業務として行われてきた。すなわち、ローンの契約、融資、返済に関する手続を証券会社の店頭で行い、ローン会社へ取り次いでいた。

また、ネットワークを利用したコンピュータ処理で証券担保ローンに関する処理を実現する有価証券担保ローン処理システムも開発されている（特許文献１参照）。この有価証券担保ローン処理システムでは、ローンの契約、融資、返済、追証の手続の大半を証券金融会社側で自動的に処理することにより、証券会社および証券金融会社（ローン会社）の手続負担の軽減とコストダウンが図られている。

特開２００４−１５１９００号公報（要約）

しかしながら、証券会社の店頭で対面業務として行われる証券担保ローンは、顧客にとっては、来店を求められるとともに、証券会社との間で済んでいるような手続についても、再度、ローン会社に対して手続しなければならないこともあり、非効率的かつ不便であり、証券会社にとっても、ローン会社への取次ぎにあたり、店頭で新たな事務処理が発生するので、やはり非効率的である。

また、前述した特許文献１に記載された有価証券担保ローン処理システムでは、ネットワークを利用したコンピュータ処理により証券会社および証券金融会社（ローン会社）の手続負担が全体として軽減されているものの、大半の手続が証券金融会社側で行われているため、証券金融会社側の負担が大きい。そして、顧客から見ると、証券会社は単なる取次にすぎず、証券金融会社（ローン会社）との間で手続を行っているというイメージになるので、対面業務の場合と同様に、面倒が増えた印象を受ける。

本発明の目的は、証券会社およびローン会社の双方の事務負担の軽減、並びに顧客にとっての利便性向上を図ることができる証券担保ローン管理システムおよびその方法、並びにプログラムを提供するところにある。

本発明は、証券会社に預けられた有価証券を担保として顧客が借入を行う証券担保ローンに関する処理を実行するコンピュータからなる証券担保ローン管理システムであって、顧客が操作する顧客端末装置とネットワークを介して接続されて証券会社が管理する証券会社サーバと、この証券会社サーバと通信回線を介して接続され、かつ、顧客端末装置とネットワークを介して接続されてローン会社が管理するローン会社サーバとを備え、証券会社サーバは、顧客の住所、氏名、振込先金融機関データ、およびローン契約の可否の判定要素となる少なくとも１つの契約可否判定要素フラグを含む顧客情報を、顧客を識別するための顧客識別情報と関連付けて記憶する顧客登録データベースと、顧客が証券会社に預けている有価証券の担保残高データを、顧客識別情報と関連付けて記憶する担保残高データベースと、顧客端末装置からネットワークを介して送信されてくる顧客のローン契約の申込のための入力データとして、ローン契約の申込を行った顧客の顧客識別情報を受け付ける処理を実行する契約申込受付処理手段と、この契約申込受付処理手段により受け付けた顧客識別情報をキーとして顧客登録データベースに記憶された契約可否判定要素フラグを参照し、ローン契約の申込を行った顧客がローン契約が可能な顧客であるか否かを判断する処理を実行する適格審査処理手段と、この適格審査処理手段によりローン契約が可能であると判断された顧客について、顧客識別情報をキーとして顧客登録データベースから住所、氏名、および振込先金融機関データを抽出するとともに、顧客識別情報をキーとして担保残高データベースから担保残高データを抽出することにより、顧客識別情報、住所、氏名、振込先金融機関データ、および担保残高データを含むローン会社向け連携情報を作成し、このローン会社向け連携情報を通信回線を介してローン会社サーバへ送信する処理を実行するローン会社向け連携情報送信処理手段とを含んで構成され、ローン会社サーバは、証券会社サーバから通信回線を介して送信されてくるローン会社向け連携情報を受信する処理を実行するローン会社向け連携情報受信処理手段と、このローン会社向け連携情報受信処理手段により受信したローン会社向け連携情報のうちの住所、氏名、および振込先金融機関データを、顧客識別情報と関連付けて記憶する顧客属性データベースと、ローン会社向け連携情報受信処理手段により受信したローン会社向け連携情報のうちの担保残高データを、顧客識別情報と関連付けて記憶する担保情報データベースと、有価証券の担保残高データから貸付可能な極度額データを算出するための掛け目データを有価証券の種別毎に記憶する掛け目データベースと、顧客への貸付残高データを、顧客識別情報と関連付けて記憶する貸付残高データベースと、顧客端末装置からネットワークを介して送信されてくる顧客の借入の申込のための入力データとして、借入の申込を行った顧客の顧客識別情報および借入希望金額データを受け付ける処理を実行する借入申込受付処理手段と、ローン会社向け連携情報受信処理手段により受信した担保残高データおよび掛け目データベースに記憶された掛け目データを用いて貸付可能な極度額データを算出するとともに、顧客識別情報をキーとして貸付残高データベースから、借入の申込を行った顧客についての貸付残高データを抽出し、極度額データ、借入申込受付処理手段により受け付けた借入希望金額データ、および貸付残高データを用いて、顧客の借入の可否を判断する処理を実行する契約借入審査処理手段とを含んで構成されていることを特徴とするものである。

ここで、「ローン会社」には、証券取引法の規定により内閣総理大臣の免許を受けた証券金融会社が含まれる。

このような本発明の証券担保ローン管理システムにおいては、証券会社サーバで、証券会社が保有する顧客情報を利用して、顧客がローン契約が可能な顧客であるか否かを判断する適格審査処理を行い、この証券会社での適格審査処理を通過した場合に、ローン会社での契約借入審査処理に回ることになる。このため、適切なリスク管理を証券会社側で行うことができるうえ、ローン会社側の審査処理が簡略化され、審査負担の軽減、融資の迅速化が図られる。

また、顧客にとっては、証券会社が保有する顧客情報を利用して適格審査処理が行われ、かつ、証券会社での適格審査処理を通過した場合に、住所、氏名、振込先金融機関データ、および担保残高データを含むローン会社向け連携情報が、証券会社サーバからローン会社サーバへ送信されるので、証券会社との間での手続の際に入力した住所等の情報を、ローン契約にあたり、再度、ローン会社との間の手続として入力する等の手間がかかることはないので、利便性が向上し、これらにより前記目的が達成される。

また、前述した証券担保ローン管理システムにおいて、証券会社サーバの契約申込受付処理手段は、顧客端末装置からネットワークを介して送信されてくる顧客のローン契約の申込およびこれと同時に行う借入の申込のための入力データとして、ローン契約の申込および同時借入の申込を行った顧客の顧客識別情報および借入希望金額データを受け付ける処理を行う構成とされ、証券会社サーバのローン会社向け連携情報送信処理手段は、顧客識別情報、住所、氏名、振込先金融機関データ、および担保残高データに加え、契約申込受付処理手段により受け付けた借入希望金額データを含むローン会社向け連携情報を、通信回線を介してローン会社サーバへ送信する処理を行う構成とされ、ローン会社サーバのローン会社向け連携情報受信処理手段は、証券会社サーバからのローン会社向け連携情報として、同時借入の借入希望金額データも受信する処理を行う構成とされ、ローン会社サーバの契約借入審査処理手段は、極度額データ、およびローン会社向け連携情報受信処理手段により受信した同時借入の借入希望金額データを用いて、顧客の借入の可否を判断する処理も行う構成とされていることが望ましい。

このようにローン契約の申込と同時に借入の申込も行うことができる構成とした場合には、より早期の借入が実現され、顧客の利便性がより一層高まる。

さらに、前述した証券担保ローン管理システムにおいて、ローン会社サーバは、担保情報データベースに記憶された担保残高データに掛け目データベースに記憶された掛け目データを乗じて得られる担保評価額データに対する貸付残高データベースに記憶された貸付残高データの割合が一定の基準値を超えているか否かをチェックし、超えている場合にアラーム情報を作成する処理を実行する残高チェック処理手段と、この残高チェック処理手段によるアラーム情報の作成対象となった顧客についての顧客識別情報およびアラーム情報を含む証券会社向け連携情報を作成し、この証券会社向け連携情報を通信回線を介して証券会社サーバへ送信する処理を実行する証券会社向け連携情報送信処理手段とを備え、証券会社サーバは、ローン会社サーバから通信回線を介して送信されてくる証券会社向け連携情報を受信する処理を実行する証券会社向け連携情報受信処理手段と、この証券会社向け連携情報受信処理手段により受信した証券会社向け連携情報にアラーム情報が含まれる場合に、アラーム情報とともに受信した顧客識別情報の顧客について証券会社に開設されている口座からの出金を止めるロック処理を実行するロック処理手段とを備えていることが望ましい。

このようにローン会社側で貸付の限度額オーバーや担保不足等のチェックを行い、そのチェック結果を証券会社側に送信して証券会社側でロック処理を行う構成とした場合には、ローン会社と証券会社との相互の連携により、より高いリスク管理を実現することが可能となる。

そして、前述した証券担保ローン管理システムにおいて、証券会社サーバの顧客登録データベースには、顧客の生年月日も顧客識別情報と関連付けて記憶され、証券会社サーバの適格審査処理手段は、顧客識別情報をキーとして顧客登録データベースに記憶された生年月日を抽出し、抽出した前記生年月日を用いて、予め定められたローン契約が可能な年齢条件を満たすか否かを判断する処理も行う構成とされていることが望ましい。

このように証券会社側の適格審査処理で年齢条件を満たしているか否かを判断する構成とした場合には、より一層適切なリスク管理を証券会社側で行うことができ、ローン会社側の審査負担がより一層軽減される。

また、前述した証券担保ローン管理システムにおいて、ローン会社サーバは、顧客端末装置からネットワークを介して送信されてくる顧客の返済の申込のための入力データとして、返済の申込を行った顧客の顧客識別情報および返済金額データを受け付ける処理を実行する返済申込受付処理手段と、この返済申込受付処理手段により受け付けた顧客識別情報および返済金額データを含む帳票データを作成し、この帳票データをローン会社の帳票サーバへローン会社の内部ネットワークを介して送信する処理を実行する出力データ作成処理手段と、帳票サーバにより帳票データを用いて出力された帳票に記載された返済金額データと顧客による金融機関への返済入金データとの一致を確認したローン会社の担当者により入力されて、このローン会社の担当者が操作するローン会社端末装置からローン会社の内部ネットワークを介して送信されてくる、返済の申込を行った顧客についての顧客識別情報および返済入金データを受け付ける処理を実行する返済金額入力受付処理手段と、この返済金額入力受付処理手段により受け付けた返済入金データを、顧客識別情報と関連付けて記憶する入金実績データベースと、この入金実績データベースに返済入金データが記憶されている顧客について顧客識別情報をキーとして貸付残高データベースから貸付残高データを抽出し、抽出した貸付残高データから返済入金データを減じることにより貸付残高データの更新処理を実行する貸付残高更新処理手段とを備えていることが望ましい。

ここで、「返済金額入力受付処理手段」が受け付ける「返済入金データ」には、ローン会社の担当者による手入力データ（キーボードでキー入力したデータ等）の他、金融機関システムが提供するファームバンキング機能を利用してローン会社の担当者が金融機関システムから取得し（ダウンロードし）、ローン会社サーバの入金実績データベースにアップロードするデータも含まれる。

このように顧客の返済の申込を受け付けてから返済入金に関する処理を行う構成とした場合には、顧客が返済の申込を行うことなく、いきなり返済入金を行う場合に比べ、返済に関する処理の円滑化が図られ、より一層確実な処理を実現することが可能となる。

さらに、前述した証券担保ローン管理システムにおいて、証券会社サーバは、顧客端末装置からネットワークを介して送信されてくる顧客のＭＲＦ残高からの返済の申込のための入力データとして、ＭＲＦ返済の申込を行った顧客の顧客識別情報およびＭＲＦ返済金額データを受け付ける処理を実行するＭＲＦ返済申込受付処理手段を備え、証券会社サーバのローン会社向け連携情報送信処理手段は、ローン会社向け連携情報として、ＭＲＦ返済申込受付処理手段により受け付けたＭＲＦ返済金額データもローン会社サーバへ送信する処理を行う構成とされ、ローン会社サーバのローン会社向け連携情報受信処理手段は、証券会社サーバからのローン会社向け連携情報として、ＭＲＦ返済金額データも受信する処理を行う構成とされ、ローン会社サーバは、ＭＲＦ返済の申込を行った顧客について顧客識別情報をキーとして貸付残高データベースから貸付残高データを抽出し、抽出した貸付残高データからローン会社向け連携情報受信処理手段により受信したＭＲＦ返済金額データを減じることにより貸付残高データの更新処理を実行する貸付残高更新処理手段を備えていることが望ましい。

このようにＭＲＦ返済を行うことができる構成とした場合には、顧客の返済時の選択自由度が増し、顧客の利便性が、より一層高まる。

また、以上に述べた本発明の証券担保ローン管理システムにより実現される方法として、以下のような本発明の証券担保ローン管理方法が挙げられる。

すなわち、本発明は、証券会社に預けられた有価証券を担保として顧客が借入を行う証券担保ローンに関する処理を実行するコンピュータからなる証券担保ローン管理システムで実行される証券担保ローン管理方法であって、証券会社サーバの顧客登録データベースに、顧客の住所、氏名、振込先金融機関データ、およびローン契約の可否の判定要素となる少なくとも１つの契約可否判定要素フラグを含む顧客情報を、顧客を識別するための顧客識別情報と関連付けて記憶させ、証券会社サーバの担保残高データベースに、顧客が証券会社に預けている有価証券の担保残高データを、顧客識別情報と関連付けて記憶させ、証券会社サーバの契約申込受付処理手段が、顧客が操作する顧客端末装置からネットワークを介して送信されてくる顧客のローン契約の申込のための入力データとして、ローン契約の申込を行った顧客の顧客識別情報を受け付ける処理を実行し、証券会社サーバの適格審査処理手段が、契約申込受付処理手段により受け付けた顧客識別情報をキーとして顧客登録データベースに記憶された契約可否判定要素フラグを参照し、ローン契約の申込を行った顧客がローン契約が可能な顧客であるか否かを判断する処理を実行し、証券会社サーバのローン会社向け連携情報送信処理手段が、適格審査処理手段によりローン契約が可能であると判断された顧客について、顧客識別情報をキーとして顧客登録データベースから住所、氏名、および振込先金融機関データを抽出するとともに、顧客識別情報をキーとして担保残高データベースから担保残高データを抽出することにより、顧客識別情報、住所、氏名、振込先金融機関データ、および担保残高データを含むローン会社向け連携情報を作成し、このローン会社向け連携情報を通信回線を介してローン会社サーバへ送信する処理を実行し、ローン会社サーバのローン会社向け連携情報受信処理手段が、証券会社サーバから通信回線を介して送信されてくるローン会社向け連携情報を受信する処理を実行し、ローン会社サーバの顧客属性データベースに、ローン会社向け連携情報受信処理手段により受信したローン会社向け連携情報のうちの住所、氏名、および振込先金融機関データを、顧客識別情報と関連付けて記憶させ、ローン会社サーバの担保情報データベースに、ローン会社向け連携情報受信処理手段により受信したローン会社向け連携情報のうちの担保残高データを、顧客識別情報と関連付けて記憶させ、ローン会社サーバの掛け目データベースに、有価証券の担保残高データから貸付可能な極度額データを算出するための掛け目データを有価証券の種別毎に記憶させ、ローン会社サーバの貸付残高データベースに、顧客への貸付残高データを、顧客識別情報と関連付けて記憶させ、ローン会社サーバの借入申込受付処理手段が、顧客端末装置からネットワークを介して送信されてくる顧客の借入の申込のための入力データとして、借入の申込を行った顧客の顧客識別情報および借入希望金額データを受け付ける処理を実行し、ローン会社サーバの契約借入審査処理手段が、ローン会社向け連携情報受信処理手段により受信した担保残高データおよび掛け目データベースに記憶された掛け目データを用いて貸付可能な極度額データを算出するとともに、顧客識別情報をキーとして貸付残高データベースから、借入の申込を行った顧客についての貸付残高データを抽出し、極度額データ、借入申込受付処理手段により受け付けた借入希望金額データ、および貸付残高データを用いて、顧客の借入の可否を判断する処理を実行することを特徴とするものである。

このような本発明の証券担保ローン管理方法においては、前述した本発明の証券担保ローン管理システムで得られる作用・効果がそのまま得られ、これにより前記目的が達成される。

さらに、本発明は、前述した証券担保ローン管理システムとして、コンピュータを機能させるためのプログラムである。

なお、上記のプログラムまたはその一部は、例えば、光磁気ディスク（ＭＯ）、コンパクトディスク（ＣＤ）を利用した読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）、デジタル・バーサタイル・ディスク（ＤＶＤ）を利用した読出し専用メモリ（ＤＶＤ−ＲＯＭ）、ＤＶＤを利用したランダム・アクセス・メモリ（ＤＶＤ−ＲＡＭ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去および書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）等の記録媒体に記録して保存や流通等させることが可能であるとともに、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等の有線ネットワーク、あるいは無線通信ネットワーク、さらにはこれらの組合せ等の伝送媒体を用いて伝送することが可能であり、また、搬送波に載せて搬送することも可能である。さらに、上記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。

以上に述べたように本発明によれば、証券会社サーバで、証券会社が保有する顧客情報を利用して、顧客がローン契約が可能な顧客であるか否かを判断する適格審査処理を行い、この証券会社での適格審査処理を通過した場合に、ローン会社での契約借入審査処理に回ることになるので、適切なリスク管理を証券会社側で行うことができ、かつ、対面業務の場合に比べ、証券会社およびローン会社の双方の事務負担の軽減を図ることができるうえ、証券会社での適格審査処理を通過した場合に、住所、氏名、振込先金融機関データ、および担保残高データを含むローン会社向け連携情報が、証券会社サーバからローン会社サーバへ送信されるので、顧客の入力の手間を省くことができ、顧客にとっての利便性向上を図ることができるという効果がある。

以下に本発明の一実施形態について図面を参照して説明する。図１には、本実施形態の証券担保ローン管理システム１０の全体構成が示されている。図２には、証券担保ローン管理システム１０による証券担保ローンの契約、借入、返済に関する日中等に行われるオンライン処理の流れがフローチャートで示され、図３および図４には、夜間等に行われるバッチ処理の流れがフローチャートで示されている。

＜システムの全体構成＞

図１において、証券担保ローン管理システム１０は、証券会社が管理する証券会社サーバ２０と、ローン会社が管理するローン会社サーバ５０とを備え、これらのサーバ２０，５０は、ネットワーク１介して顧客が操作する顧客端末装置８０に接続されている。これらの証券会社サーバ２０とローン会社サーバ５０とは、通信回線である専用線２で接続されている。なお、証券会社サーバ２０とローン会社サーバ５０とは、遠隔地に設置されていてもよく、あるいは、例えば、証券会社およびローン会社の双方から各サーバ２０，５０の管理の代行を依頼された会社の同じ建屋内等に設置されていてもよく、後者の場合には、各サーバ２０，５０を接続する通信回線は、同じ建屋内等に配設された通信回線でよい。

また、証券会社サーバ２０には、証券会社の内部ネットワーク３を介して証券会社の本店や支店に設置された証券会社端末装置９０が接続されている。さらに、ローン会社サーバ５０には、ローン会社の内部ネットワーク４を介して、ローン会社に設置されてローン会社の担当者が操作するローン会社端末装置１００と、ローン会社に設置された帳票サーバ１１０とが接続されている。そして、ローン会社には、ファームバンキング用端末装置１２０が設置され、ネットワーク１を介して金融機関システム１３０に接続されている。

ネットワーク１は、本実施形態では、主としてインターネットであり、インターネットとイントラネットやＬＡＮ等との組合せでもよい。証券会社の内部ネットワーク３やローン会社の内部ネットワーク４は、社内用のイントラネットやＬＡＮ等である。

＜証券会社サーバの構成＞

証券会社サーバ２０は、１台または複数台のコンピュータにより構成され、証券担保ローンに関する証券会社側の担当する各種処理を実行する処理手段２０Ａと、この処理手段２０Ａに接続された顧客登録データベース３０、担保残高データベース３１、契約申込データベース３２、ＭＲＦ返済データベース３３、およびローン契約データベース３４とを含んで構成されている。

処理手段２０Ａは、オンライントレード処理手段２１と、契約申込受付処理手段２２と、適格審査処理手段２３と、ＭＲＦ返済申込受付処理手段２４と、ＭＲＦ処理手段２５と、ローン会社向け連携情報送信処理手段２６と、証券会社向け連携情報受信処理手段２７と、ロック処理手段２８と、ローン契約情報閲覧処理手段２９とを含んで構成されている。

オンライントレード処理手段２１は、証券会社とオンライントレードの契約を行っている顧客がオンライントレードを行うための処理を実行するものであり、顧客端末装置８０からの顧客の要求に応じて、オンライントレードのための各種画面（Ｗｅｂ画面）の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信するとともに、各種画面で顧客により入力されたデータや操作情報を、ネットワーク１を介して受信する処理を行うものであり、少なくともＷｅｂサーバの機能を備えている。

具体的には、オンライントレード処理手段２１は、オンライントレードのログイン画面（Ｗｅｂ画面）をネットワーク１を介して顧客端末装置８０へ送信し、顧客による顧客識別情報（例えば、顧客が証券会社に開設している口座の口座番号等）およびパスワードの入力を受け付ける。

また、オンライントレード処理手段２１は、ローン契約（極度貸付契約）の申込（契約と同時に借入の申込を行う場合も含む。）、借入の申込、返済（ＭＲＦ返済以外）の申込、ＭＲＦ返済の申込、自己のローン契約に関する情報の閲覧を行うための画面（Ｗｅｂ画面）に遷移するためのボタンを含むオンライントレードのための画面（Ｗｅｂ画面）を送信する。そして、顧客によるボタンの押下操作（クリック操作）に伴って顧客端末装置８０からネットワーク１を介して送信されてくる顧客の表示要求に従って、顧客がローン契約（同時借入を行う場合も含む。）の申込を行うための画面の表示要求を行っている場合には、その表示要求を、契約申込受付処理手段２２に引き渡し、ＭＲＦ返済の申込を行うための画面の表示要求を行っている場合には、その表示要求を、ＭＲＦ返済申込受付処理手段２４に引き渡し、顧客が自己のローン契約に関する情報の閲覧を行うための画面の表示要求を行っている場合には、その表示要求を、ローン契約情報閲覧処理手段２９に引き渡す。なお、顧客が、借入の申込および返済（ＭＲＦ返済以外）の申込を行うための画面の表示要求を行った場合には、その表示要求は、ネットワーク１を介してローン会社サーバ５０へ送信される。

契約申込受付処理手段２２は、顧客端末装置８０からネットワーク１を介して送信されてくる顧客のローン契約の申込のための入力データとして、ローン契約の申込を行った顧客の顧客識別情報（口座番号等）を受け付ける処理を実行するものであり、少なくともＷｅｂサーバの機能を備えている。すなわち、契約申込受付処理手段２２は、オンライントレード処理手段２１から、顧客によるローン契約（同時借入を行う場合も含む。）の申込を行うための画面の表示要求を受け取ると、ローン契約（同時借入を行う場合も含む。）の申込を行うための画面（Ｗｅｂ画面）の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信するとともに、顧客端末装置８０からネットワーク１を介して送信されてくるローン契約の申込の意思を示す信号を受信する。この際、ローン契約の申込を行った顧客の顧客識別情報（口座番号等）は、オンライントレード処理手段２１から受け取ってもよく、顧客端末装置８０からローン契約の申込の意思を示す信号とともに再度受信するようにしてもよい。但し、後者の場合は、顧客による顧客識別情報の再入力を要求するのではなく、ローン契約（同時借入を行う場合も含む。）の申込を行うための画面の裏情報として保持されている顧客識別情報が、顧客端末装置８０から送信されるようにすればよい。

また、契約申込受付処理手段２２は、ローン契約の申込と同時に借入の申込を受け付ける場合には、顧客端末装置８０からネットワーク１を介して、ローン契約の申込の意思を示す信号とともに借入希望金額データが送信されてくるので、この借入希望金額データを受信する。

適格審査処理手段２３は、ローン契約の申込を行った顧客が、契約（極度貸付契約）が可能な顧客であるか否かをリアルタイムで判断し、その判断結果を示す画面（Ｗｅｂ画面）の表示用データを、インターネット１を介して顧客端末装置８０へリアルタイムで送信する処理を実行するものである。

具体的には、適格審査処理手段２３は、契約申込受付処理手段２２により受け付けた顧客識別情報をキーとして、顧客登録データベース３０に記憶された契約可否判定要素フラグを参照し、ローン契約の申込を行った顧客が、ローン契約が可能な顧客であるか否かをリアルタイムで判断する。すなわち、適格審査処理手段２３は、顧客が信用取引を行っている（信用取引用の口座を開設している）か否かを示す信用取引フラグ（複数種類の信用取引に関するサービスが存在する場合には、各サービス毎の信用取引フラグ）を参照し、信用取引を行っていることを示すフラグが立っている場合には、ローン契約ができない顧客であると判断する。また、適格審査処理手段２３は、顧客が為替トレードを行っているか否かを示す為替トレードフラグを参照し、為替トレードを行っていることを示すフラグが立っている場合には、ローン契約ができない顧客であると判断する。さらに、適格審査処理手段２３は、別ローン（例えば、本システムで提供されるサービスとしてのインターネットローンではなく、別のサービスとして提供されている営業員との対面で行われる証券担保ローン等）を行っているか否かを示す別ローンフラグ（複数種類の別ローンに関するサービスが存在する場合には、各サービス毎の別ローンフラグ）を参照し、別ローンを行っていることを示すフラグが立っている場合には、ローン契約ができない顧客であると判断する。

また、適格審査処理手段２３は、契約申込受付処理手段２２により受け付けた顧客識別情報をキーとして、顧客登録データベース３０に記憶された生年月日を抽出し、抽出した生年月日を用いて、予め定められたローン契約が可能な年齢条件（例えば、２０歳以上、８０歳未満）を満たすか否かを判断する。

そして、適格審査処理手段２３は、ローン契約の申込を行った顧客が、ローン契約が可能な顧客であると判断した場合には、その旨を示す画面（Ｗｅｂ画面）の表示用データを、インターネット１を介して顧客端末装置８０へリアルタイムで送信するとともに、その顧客の個人情報（住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データ、担保残高データ等）をローン会社へ転送することに同意するか否かを示す信号を、インターネット１を介して顧客端末装置８０から受信し、同意することを示す信号を受信した場合には、契約申込日（同時借入の申込の場合には、契約申込日および借入希望金額データ）を、顧客識別情報と関連付けて契約申込データベース３２に記憶させ、さらに、明日以降、借入を行うことができる旨や、明日、ローン会社での審査の結果（極度額の算出結果）が出る旨を示す画面（Ｗｅｂ画面）の表示用データを、インターネット１を介して顧客端末装置８０へリアルタイムで送信する。一方、適格審査処理手段２３は、ローン契約の申込を行った顧客が、ローン契約ができない顧客であると判断した場合には、その旨および理由を示す画面（例えば、為替トレードを行っているので、ローン契約を締結することができない旨等が示されたＷｅｂ画面）の表示用データを、インターネット１を介して顧客端末装置８０へリアルタイムで送信する。

ＭＲＦ返済申込受付処理手段２４は、顧客端末装置８０からネットワーク１を介して送信されてくる顧客のＭＲＦ（Money Reserve Fund：マネー・リザーブ・ファンド）の残高からの返済の申込のための入力データとして、ＭＲＦ返済の申込を行った顧客の顧客識別情報およびＭＲＦ返済金額データを受け付ける処理を実行するものであり、少なくともＷｅｂサーバの機能を備えている。すなわち、ＭＲＦ返済申込受付処理手段２４は、オンライントレード処理手段２１から、顧客によるＭＲＦ残高からの返済の申込を行うための画面の表示要求を受け取ると、ＭＲＦ残高からの返済の申込を行うための画面（Ｗｅｂ画面）の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信するとともに、顧客端末装置８０からネットワーク１を介して送信されてくるＭＲＦ返済金額データを受信する。この際、ＭＲＦ返済の申込を行った顧客の顧客識別情報（口座番号等）は、オンライントレード処理手段２１から受け取ってもよく、顧客端末装置８０からＭＲＦ返済金額データとともに再度受信するようにしてもよい。但し、後者の場合は、顧客による顧客識別情報の再入力を要求するのではなく、ＭＲＦ残高からの返済の申込を行うための画面の裏情報として保持されている顧客識別情報が、顧客端末装置８０から送信されるようにすればよい。

ＭＲＦ処理手段２５は、ＭＲＦ返済の申込を行った顧客の顧客識別情報をキーとして、証券会社に設置されている図示されないＭＲＦ残高データベース（各顧客のＭＲＦ残高データが顧客識別情報と関連付けて記憶されているデータベース）にアクセスし、ＭＲＦの売却処理、すなわちＭＲＦ残高データからＭＲＦ返済金額データを減じる処理を実行するものである。また、ＭＲＦ処理手段２５は、ＭＲＦ返済金額データおよびＭＲＦ返済申込日を、顧客識別情報と関連付けてＭＲＦ返済データベース３３に記憶させる。

ローン会社向け連携情報送信処理手段２６は、契約申込データベース３２に顧客識別情報が記憶されている顧客、すなわち適格審査処理手段２３によりローン契約が可能であると判断され、かつ、ローン会社への自己の個人情報の転送に同意した顧客のうち、契約申込データベース３２に記憶された契約申込日が当日となっている顧客（その日の日中に契約申込を行った顧客）について、契約申込データベース３２から契約申込日（同時借入の申込の場合には、契約申込日および借入希望金額データ）を抽出するとともに、当該顧客の顧客識別情報をキーとして、顧客登録データベース３０から住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データを抽出する。なお、住所、氏名、電話番号、生年月日、振込先金融機関データが変更されることを考慮し、契約申込データベース３２に記憶された契約申込日が当日となっている顧客（その日の日中に契約申込を行った顧客）に限らず、契約申込データベース３２に顧客識別情報が記憶されている顧客の全て（その日までに契約申込を行った顧客の全て）について、顧客登録データベース３０から住所、氏名、電話番号、生年月日、振込先金融機関データを抽出してもよい。

また、ローン会社向け連携情報送信処理手段２６は、契約申込データベース３２に顧客識別情報が記憶されている顧客の全て（その日までに契約申込を行った顧客の全て）について、当該顧客の顧客識別情報をキーとして、担保残高データベース３１から担保残高データを抽出する。

さらに、ローン会社向け連携情報送信処理手段２６は、契約申込データベース３２に顧客識別情報が記憶されている顧客のうち、ＭＲＦ返済データベース３３に記憶されたＭＲＦ返済申込日が当日となっている顧客（その日の日中にＭＲＦ返済の申込を行った顧客）について、当該顧客の顧客識別情報をキーとして、ＭＲＦ返済データベース３３から、ＭＲＦ返済金額データおよびＭＲＦ返済申込日を抽出する。

そして、ローン会社向け連携情報送信処理手段２６は、以上の抽出処理により、顧客識別情報、住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データ、担保残高データ、契約申込日、同時借入の申込の場合における借入希望金額データ、ＭＲＦ返済金額データ、およびＭＲＦ返済申込日を含むローン会社向け連携情報を作成し、このローン会社向け連携情報を、通信回線である専用線２を介してローン会社サーバ５０へ夜間等に送信するバッチ処理を実行するものである。

証券会社向け連携情報受信処理手段２７は、ローン会社サーバ５０から通信回線である専用線２を介して送信されてくる証券会社向け連携情報を受信する処理を実行するものである。また、証券会社向け連携情報受信処理手段２７は、証券会社向け連携情報のうちのＴ日およびＴ＋α日の貸付残高データ（Ｔ日等の意味は後述する。）、並びに極度額データを、顧客識別情報と関連付けてローン契約データベース３４に記憶させる。

ロック処理手段２８は、証券会社向け連携情報受信処理手段２７により受信した証券会社向け連携情報にアラーム情報が含まれる場合に、アラーム情報とともに受信した顧客識別情報の顧客について証券会社に開設されている口座からの出金を止めるロック処理を実行するものである。ここで、ロック処理とは、有価証券の売却代金をＡＴＭから引き出したり、銀行振込で自分の指定する口座に振り込んだりする手続を行うことができないようにする処理（但し、有価証券の売却処理自体は行うことができる。）であり、具体的には、そのような操作が行われたときに参照される証券会社のシステム内に設けられた操作の許否を示す操作許否フラグ（顧客識別情報と関連付けられたフラグ）について、操作できないことを示すフラグを立てておく処理等である。

ローン契約情報閲覧処理手段２９は、顧客端末装置８０からネットワーク１を介して送信されてくる顧客のローン契約情報の閲覧のための入力データとして、ローン契約情報の閲覧要求を行った顧客の顧客識別情報を受け付ける処理を実行するものであり、少なくともＷｅｂサーバの機能を備えている。すなわち、ローン契約情報閲覧処理手段２９は、オンライントレード処理手段２１から、顧客による自己のローン契約情報の閲覧を行うための画面の表示要求およびその顧客の顧客識別情報（口座番号等）を受け取ると、その顧客の顧客識別情報をキーとして、ローン契約データベース３４から、Ｔ日およびＴ＋α日の貸付残高データ（Ｔ日等の意味は後述する。）や、極度額データを抽出し、抽出した貸付残高データや極度額データを示す画面（Ｗｅｂ画面）の表示用データを作成し、この画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信する。なお、ローン契約データベース３４に記憶されたデータを用いて、貸付残高データや極度額データを顧客端末装置８０の画面上に表示する同様な機能は、ＭＲＦ返済申込受付処理手段２４も備えており、ＭＲＦ残高からの返済の申込を行うための画面（Ｗｅｂ画面）にも、同様にして、貸付残高データ（返済申込の画面の場合は、例えば、Ｔ＋２日の貸付残高データとする。）や極度額データが表示される。

また、ローン契約情報閲覧処理手段２９は、証券会社端末装置９０から証券会社の内部ネットワーク３を介して送信されてくる証券会社の本店や支店にいる営業員やオペレータによる顧客のローン契約情報の閲覧のための入力データとして、ローン契約情報の閲覧対象とする顧客についての顧客識別情報を受け付ける処理も行う。この場合も、同様にして、顧客識別情報をキーとして、ローン契約データベース３４から貸付残高データや極度額データを抽出し、抽出した貸付残高データや極度額データを示す画面の表示用データを作成し、この画面の表示用データを、証券会社の内部ネットワーク３を介して証券会社端末装置９０へ送信することにより、貸付残高データや極度額データを証券会社端末装置９０の画面上に表示する。

顧客登録データベース３０は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、顧客の住所と、氏名と、電話番号と、電子メールアドレスと、生年月日と、振込先金融機関データ（有価証券の売却代金の振込先として顧客により指定された金融機関の口座を特定するためのデータであるが、本システムでは、ローン会社による貸付金の振込先となる。）と、ローン契約の可否の判定要素となる各種の契約可否判定要素フラグとを記憶するものである。ここで、契約可否判定要素フラグとしては、本実施形態では、一例として、顧客が信用取引を行っている（信用取引用の口座を開設している）か否かを示す信用取引フラグ（複数種類の信用取引に関するサービスが存在する場合には、各サービス毎の信用取引フラグ）と、顧客が為替トレードを行っているか否かを示す為替トレードフラグと、別ローン（例えば、本システムで提供されるサービスとしてのインターネットローンではなく、別のサービスとして提供されている営業員との対面で行われる証券担保ローン等）を行っているか否かを示す別ローンフラグ（複数種類の別ローンに関するサービスが存在する場合には、各サービス毎の別ローンフラグ）とがあるが、これに限定されるものではない。

担保残高データベース３１は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、顧客が証券会社に預けている担保となる有価証券（株式、債券、投資信託等）の残高を示す担保残高データを、有価証券の各種別毎で、かつ、各銘柄毎に記憶するものである。有価証券の各種別（株式、債券、投資信託等の別）は、担保残高データを、証券種別識別情報と関連付けて記憶することにより識別することができ、有価証券の各銘柄は、担保残高データを、銘柄名や銘柄コード等の銘柄識別情報と関連付けて記憶することにより識別することができるようになっている。また、担保残高データには、各種別毎で、かつ、各銘柄毎の数量（例えば、株式の場合には、株数）、時価単価、時価評価額（数量×時価単価）が含まれるとともに、時価評価額の総額も含まれる。なお、時価単価、時価評価額、および時価評価額の総額は、処理手段２０Ａにより、図示されない市場システムまたは時価情報提供システムから取得した最新の時価情報で定期的に更新される。

契約申込データベース３２は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、顧客が契約（極度貸付契約）の申込を行った契約申込日と、顧客が契約申込と同時に借入申込を行った場合において顧客が入力した借入希望金額データとを記憶するものである。

ＭＲＦ返済データベース３３は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、顧客が保有しているその証券会社のＭＲＦ（Money Reserve Fund：マネー・リザーブ・ファンド）の残高からの返済金額を示すＭＲＦ返済金額データと、顧客がＭＲＦ返済の申込を行ったＭＲＦ返済申込日とを記憶するものである。

ローン契約データベース３４は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、Ｔ日およびＴ＋α日の貸付残高データ（本システムによるインターネットローンで顧客が借り入れている借入残高データである。Ｔ日等の意味は後述する。）と、極度額データ（本システムによるインターネットローンで顧客が借り入れることができる限度額を示す金額データ）とを記憶するものである。

＜ローン会社サーバの構成＞

ローン会社サーバ５０は、１台または複数台のコンピュータにより構成され、証券担保ローンに関するローン会社側の担当する各種処理を実行する処理手段５０Ａと、この処理手段５０Ａに接続された顧客属性データベース７０、借入返済申込データベース７１、担保情報データベース７２、ローン契約データベース７３、掛け目データベース７４、貸付残高データベース７５、および入金実績データベース７６とを含んで構成されている。

処理手段５０Ａは、借入申込受付処理手段５１と、契約借入審査処理手段５２と、返済申込受付処理手段５３と、返済金額入力受付処理手段５４と、ローン会社向け連携情報受信処理手段５５と、証券会社向け連携情報送信処理手段５６と、貸付残高更新処理手段５７と、残高チェック処理手段５８と、出力データ作成処理手段５９とを含んで構成されている。

借入申込受付処理手段５１は、顧客端末装置８０からネットワーク１を介して送信されてくる顧客の借入の申込のための入力データとして、借入の申込を行った顧客の顧客識別情報および借入希望金額データを受け付ける処理を実行するものであり、少なくともＷｅｂサーバの機能を備えている。すなわち、借入申込受付処理手段５１は、オンライントレード処理手段２１により表示されたログイン画面での顧客による顧客識別情報およびパスワードの入力後に、オンライントレード処理手段２１により顧客端末装置８０の画面上に表示されたオンライントレードのための画面上で、顧客がボタンの押下操作（クリック操作）をしたときに、この操作に伴って顧客端末装置８０からネットワーク１を介して送信されてくる顧客による借入の申込を行うための画面の表示要求およびその顧客の顧客識別情報を受信し、借入の申込を行うための画面（Ｗｅｂ画面）の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信するとともに、顧客端末装置８０からネットワーク１を介して送信されてくる顧客の借入希望金額データ（顧客識別情報は既に受信している。）を受信する。そして、借入申込受付処理手段５１は、借入希望金額データおよび借入申込日を、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させる。

なお、借入申込受付処理手段５１は、顧客の顧客識別情報をキーとして、貸付残高データベース７５から、貸付残高データや極度額データを抽出し、抽出した貸付残高データや極度額データを示す画面（Ｗｅｂ画面）の表示用データを作成し、この画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信することにより、顧客端末装置８０の画面上に貸付残高データ（借入申込の画面の場合は、例えば、Ｔ＋１日の貸付残高データとする。）や極度額データを表示する機能も備えている。

契約借入審査処理手段５２は、ローン会社向け連携情報受信処理手段５５により受信したローン会社向け連携情報に契約申込日が含まれている顧客、すなわちローン契約データベース７３に記憶されている契約申込日が当日となっている顧客（その日の日中にローン契約の申込を行った顧客）について、担保情報データベース７２に記憶されている担保残高データ（ローン会社向け連携情報受信処理手段５５により受信した担保残高データ）および掛け目データベース７４に記憶された掛け目データを用いて、貸付可能な極度額データを夜間等に算出するバッチ処理を実行するものである。具体的には、契約借入審査処理手段５２は、例えば、担保残高データ（担保となる有価証券の時価評価額）に、有価証券の種別毎に予め定められている担保掛目（例えば、６０％）と、極度掛目（例えば、７０％）とを乗じることにより、融資限度額を示す極度額データを算出する。有価証券が複数銘柄ある場合には、各有価証券についての担保残高データ（時価評価額）×担保掛目×極度掛目の合計値が極度額データとなる。

また、契約借入審査処理手段５２は、ローン契約データベース７３に顧客識別情報が記憶されている顧客のうち、借入返済申込データベース７１に記憶されている借入申込日（ローン契約の申込と同時に借入の申込を行った場合における契約申込日が借入申込日として記憶されている場合も含む。）が当日となっている顧客（その日の日中に借入の申込を行った顧客）について、当該顧客の顧客識別情報をキーとして、貸付残高データベース７５から、借入の申込を行った顧客についての貸付残高データを抽出し、極度額データと、借入返済申込データベース７１に記憶されている借入希望金額データ（借入申込受付処理手段５１により受け付けた借入希望金額データ、およびローン会社向け連携情報受信処理手段５５により受信したローン会社向け連携情報に含まれている同時借入の場合における借入希望金額データ）と、貸付残高データとを用いて、顧客の借入の可否を夜間等に判断するバッチ処理を実行するものである。具体的には、貸付残高データ（同時借入の場合は、ゼロである。）に、借入希望金額データを加算した金額データが、極度額データ以下であるか否かを判断し、極度額データ以下の場合には、借入が可能であり、極度額データを超えている場合には、借入することができないと判断する。

そして、契約借入審査処理手段５２は、算出した極度額データを、顧客識別情報と関連付けて貸付残高データベース７５に記憶させる。この貸付残高データベース７５に記憶された極度額データは、出力データ作成処理手段５９により参照され、顧客によるローン契約の申込に対する極度額データの算出結果を通知するための帳票データの作成処理に用いられる。また、契約借入審査処理手段５２は、借入の可否の判断結果を示す情報を、判断対象の借入希望金額データおよび借入申込日と対応させて、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させる。この借入返済申込データベース７１に記憶された借入の可否の判断結果を示す情報は、顧客による借入の申込に対する貸付不能等の判断結果を通知するための電子メールの作成処理と、顧客による借入の申込に対して借入が可能と判断された顧客に対する振込データの作成処理に用いられる。なお、借入返済申込データベース７１に借入の可否の判断結果を示す情報を記憶するのではなく、例えば、借入可能と判断された顧客のデータ（レコード）は借入返済申込データベース７１に残し、借入できないと判断された顧客のデータ（レコード）は借入返済申込データベース７１から削除し、借入できないと判断された顧客の顧客識別情報、借入希望金額データ、借入申込日等のデータについては、別途に貸付不能データベースに記憶させてもよく、このようにした場合には、契約借入審査処理手段５２による処理後に借入返済申込データベース７１に残っている借入の申込に係るデータ（レコード）は、すべて借入可能と判断された顧客のデータとなるので、貸付残高データの更新処理の際には、借入返済申込データベース７１に記憶されている借入希望金額データが借入可能と判断されたものであるか否かの判断処理を省略することができる。

返済申込受付処理手段５３は、顧客端末装置８０からネットワーク１を介して送信されてくる顧客の返済（ＭＲＦ返済以外）の申込のための入力データとして、返済の申込を行った顧客の顧客識別情報および返済金額データを受け付ける処理を実行するものであり、少なくともＷｅｂサーバの機能を備えている。すなわち、返済申込受付処理手段５３は、オンライントレード処理手段２１により表示されたログイン画面での顧客による顧客識別情報およびパスワードの入力後に、オンライントレード処理手段２１により顧客端末装置８０の画面上に表示されたオンライントレードのための画面上で、顧客がボタンの押下操作（クリック操作）をしたときに、この操作に伴って顧客端末装置８０からネットワーク１を介して送信されてくる顧客による返済（ＭＲＦ返済以外）の申込を行うための画面の表示要求およびその顧客の顧客識別情報を受信し、返済の申込を行うための画面（Ｗｅｂ画面）の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信するとともに、顧客端末装置８０からネットワーク１を介して送信されてくる顧客の返済金額データ（顧客識別情報は既に受信している。）を受信する。そして、返済申込受付処理手段５３は、返済金額データおよび返済申込日を、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させる。

なお、返済申込受付処理手段５３は、顧客の顧客識別情報をキーとして、貸付残高データベース７５から、貸付残高データや極度額データを抽出し、抽出した貸付残高データや極度額データを示す画面（Ｗｅｂ画面）の表示用データを作成し、この画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信することにより、顧客端末装置８０の画面上に貸付残高データ（返済申込の画面の場合は、例えば、Ｔ＋２日の貸付残高データとする。）や極度額データを表示する機能も備えている。

返済金額入力受付処理手段５４は、ローン会社の担当者によりローン会社端末装置１００からローン会社の内部ネットワーク４を介して送信されてくる顧客識別情報および返済入金データを受信し、受信した返済入金データを、顧客識別情報と関連付けて入金実績データベース７６に記憶させる処理を実行するものである。すなわち、ローン会社の担当者は、帳票サーバ１１０の帳票作成処理手段１１１により帳票データを用いて出力された帳票（返済申込を行った翌日の朝には、出力されている。）に記載された返済金額データと、ファームバンキング用端末装置１２０を操作して参照した顧客による金融機関への実際の返済入金データとを突き合わせ、これらの金額が一致していることを確認した後に、ローン会社端末装置１００を操作して顧客識別情報および返済入金データを入力し、ローン会社サーバ５０へ送信する作業を行うが、返済金額入力受付処理手段５４は、この作業で入力された顧客識別情報および返済入金データを、ローン会社の内部ネットワーク４を介して受信する。

ローン会社向け連携情報受信処理手段５５は、証券会社サーバ２０から通信回線である専用線２を介して送信されてくるローン会社向け連携情報を夜間等に受信する処理を実行するものである。また、ローン会社向け連携情報受信処理手段５５は、受信したローン会社向け連携情報のうちの住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データを、顧客識別情報と関連付けて顧客属性データベース７０に記憶させ、担保残高データを、顧客識別情報と関連付けて担保情報データベース７２に記憶させ、契約申込日を、顧客識別情報と関連付けてローン契約データベース７３に記憶させ、同時借入の申込の場合における借入希望金額データおよび借入申込日（契約申込日を借入申込日として記憶させる。）を、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させ、ＭＲＦ返済金額データおよびＭＲＦ返済申込日を、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させる。

証券会社向け連携情報送信処理手段５６は、ローン契約データベース７３に顧客識別情報が記憶されている顧客の全てについて、貸付残高データベース７５から、Ｔ日およびＴ＋α日（例えば、Ｔ＋１日、Ｔ＋２日、Ｔ＋３日）の貸付残高データ（Ｔ日等の意味は後述する。）、並びに極度額データを抽出する。また、証券会社向け連携情報送信処理手段５６は、残高チェック処理手段５８によるアラーム情報の作成対象となった顧客（ローン契約データベース７３にアラーム情報が記憶されている顧客）について、ローン契約データベース７３から、顧客識別情報およびアラーム情報を抽出する。そして、証券会社向け連携情報送信処理手段５６は、顧客識別情報と、Ｔ日およびＴ＋α日（例えば、Ｔ＋１日、Ｔ＋２日、Ｔ＋３日）の貸付残高データと、極度額データと、アラーム情報とを含む証券会社向け連携情報を作成し、この証券会社向け連携情報を、通信回線である専用線２を介して証券会社サーバ２０へ夜間等に送信するバッチ処理を実行するものである。

貸付残高更新処理手段５７は、Ｔ日およびＴ＋α日（例えば、Ｔ＋１日、Ｔ＋２日、Ｔ＋３日）の貸付残高データを算出し、それらの貸付残高データを更新するバッチ処理を夜間等に実行するものである。すなわち、貸付残高更新処理手段５７は、入金実績データベース７６に記憶されている返済入金日が当日（本日）となっている顧客の顧客識別情報および返済入金データを抽出し、抽出した顧客識別情報をキーとして、貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データから、返済入金データを減じることにより、Ｔ日の貸付残高データの更新処理（図３のステップＳ２２の処理）を実行する。ここで、Ｔ日とは、バッチ処理日、すなわち前回のバッチ処理の時点から今回実行されるバッチ処理の時点までの間においてオンライン処理を受け付けていたオンライン受付時間帯が属する日をいい、Ｔ日の貸付残高データとは、バッチ処理日における確定した貸付残高データをいう。また、貸付残高更新処理手段５７は、Ｔ＋α日（例えば、Ｔ＋１日、Ｔ＋２日、Ｔ＋３日）の貸付残高データについても、元本については、Ｔ日の貸付残高データと同じ金額とし、更新処理を行う（図４のステップＳ２６参照）。ここで、Ｔ＋α日とは、バッチ処理日の翌営業日以降の営業日をいい、例えば、Ｔ＋１日とは、バッチ処理日翌営業日をいい、Ｔ＋２日とは、バッチ処理日翌々営業日をいい、Ｔ＋α日の貸付残高データとは、バッチ処理日（Ｔ日）の翌営業日以降の営業日における予定される貸付残高データをいう。従って、上記の場合におけるＴ日〜Ｔ＋３日の貸付残高データは、経過利息の相違のみとなる。なお、返済（ＭＲＦ返済以外）の場合に返済した分だけＴ日およびＴ＋α日の貸付残高データを減らす更新処理については、金融機関に実際に返済入金が行われ、その返済入金データが入金実績データベース７６に書き込まれた時点で、初めてその返済入金データを反映させるＴ日およびＴ＋α日の貸付残高データの更新処理が行われる。従って、借入返済申込データベース７１に返済（ＭＲＦ返済以外）に係る返済金額データが記憶されているだけでは、その返済金額データは、Ｔ日およびＴ＋α日の貸付残高データに反映されない。そして、このようなバッチ処理は、例えば、午前０時過ぎに開始され、土曜日・日曜日・祝日にも実行されるが、実際の日付が変わっても（午前０時を過ぎても）、バッチ処理日（Ｔ日）はその前日となる。例えば、４月３日（火曜日）分のバッチ処理は、４月４日（水曜日）の午前０時過ぎから開始されるが、バッチ処理日（Ｔ日）は４月３日（火曜日）となる。

また、貸付残高更新処理手段５７は、ＭＲＦ返済の申込を行った顧客について、顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データから、ローン会社向け連携情報受信処理手段５５により受信したＭＲＦ返済金額データ（借入返済申込データベース７１に記憶されているＭＲＦ返済申込日が当日となっているＭＲＦ返済金額データ）を減じることにより、Ｔ＋α日の貸付残高データを算出し、その更新処理（図４のステップＳ２６の処理）を実行する。なお、Ｔ日の貸付残高データの算出処理（図３のステップＳ２２の処理）は、ローン会社向け連携情報受信処理手段５５により証券会社サーバからのＭＲＦ返済金額データを受信し、これを借入返済申込データベース７１に記憶させる処理（図３のステップＳ２４の処理）の前に行われるので、ＭＲＦ返済申込日には、ＭＲＦ返済金額データを反映させるＴ日の貸付残高データの更新処理は行われず、ＭＲＦ返済申込日の翌日におけるＴ日の貸付残高データの算出処理（図３のステップＳ２２の処理）で、初めてＭＲＦ返済金額データを反映させるＴ日の貸付残高データの更新処理が行われる。

さらに、貸付残高更新処理手段５７は、借入の申込（ローン契約の申込と同時の借入の申込を除く。）を行った顧客について、顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データに、借入希望金額データ（借入返済申込データベース７１に記憶されている借入申込日が当日となっている借入希望金額データ：但し、借入の可否の判断結果を示す情報が、借入可能となっている場合に限る。）を加算することにより、Ｔ＋α日の貸付残高データを算出し、その更新処理（図４のステップＳ２６の処理）を実行する（図４のステップ２５の借入の審査は済んでいるので。）。なお、Ｔ日の貸付残高データの算出処理（図３のステップＳ２２の処理）では、借入返済申込データベース７１に記憶されている借入申込日が当日となっている借入希望金額データを反映させるＴ日の貸付残高データの更新処理は行われず（未だ図４のステップ２５の借入の審査が行われていないので。）、借入返済申込データベース７１に記憶されている借入申込日の翌日になって、初めて借入希望金額データを反映させるＴ日の貸付残高データの更新処理が行われる。従って、借入申込日の夜間等のバッチ処理の時点では、Ｔ日の貸付残高データは更新されないが、Ｔ＋α日の貸付残高データは更新されるので、借入申込日には貸付残高データが仮更新された状態となり、借入申込日の翌日になってＴ日の貸付残高データが更新されるので、借入申込日の翌日に貸付残高データが本更新された状態となる。なお、処理を実行している当日が借入申込日の翌日に該当するという判断は、借入返済申込データベース７１に記憶されている借入申込日を参照して行ってもよく、あるいは借入返済申込データベース７１に振込日（借入申込日の翌日となる。）が記憶されている場合には、その振込日を参照して行ってもよい。

また、貸付残高更新処理手段５７は、ローン契約の申込と同時に借入の申込を行った顧客について、顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データに、借入希望金額データ（借入返済申込データベース７１に記憶されている借入申込日が当日となっている借入希望金額データ：但し、借入の可否の判断結果を示す情報が、借入可能となっている場合に限る。）を加算することにより、Ｔ＋α日の貸付残高データを算出し、その更新処理（図４のステップＳ２６の処理）を実行する（図４のステップ２５の借入の審査は済んでいるので。）。なお、Ｔ日の貸付残高データの算出処理（図３のステップＳ２２の処理）は、ローン会社向け連携情報受信処理手段５５により証券会社サーバからの同時借入の場合における借入希望金額データを受信し、これを借入返済申込データベース７１に記憶させる処理（図３のステップＳ２４の処理）の前に行われるので、借入申込日（＝契約申込日）には、借入希望金額データを反映させるＴ日の貸付残高データの更新処理は行われず、借入申込日（＝契約申込日）の翌日におけるＴ日の貸付残高データの算出処理（図３のステップＳ２２の処理）で、初めて借入希望金額データを反映させるＴ日の貸付残高データの更新処理が行われる。従って、結局、ローン契約の申込と同時に借入の申込を行った場合についても、それ以外の借入の申込の場合と同様になる。

残高チェック処理手段５８は、ローン契約データベース７３に顧客識別情報が記憶されている顧客の全てについて、担保情報データベース７２に記憶された担保残高データに掛け目データベース７４に記憶された掛け目データを乗じて得られる担保評価額データに対する貸付残高データベース７５に記憶された貸付残高データの割合が一定の基準値を超えているか否かをチェックし、超えている場合にアラーム情報を作成し、作成したアラーム情報を、顧客識別情報と関連付けてローン契約データベース７３に記憶させる処理を実行するものである。具体的には、残高チェック処理手段５８は、担保残高データ（担保となる有価証券の時価評価額）に、有価証券の種別毎に予め定められている担保掛目（例えば、６０％）を乗じることにより、各有価証券の担保評価額データを算出し、これらの担保評価額データを合計した金額データに対する貸付残高データの割合が、予め定められた一定の基準値を超えているか否かをチェックする。なお、一定の基準値は、例えば、７０％を超えるとアラームレベル１、８０％を超えるとアラームレベル２のように、段階的に設定してもよく、この場合には、アラーム情報として、例えば、アラームレベル１、アラームレベル２等がローン契約データベース７３に記憶される。

出力データ作成処理手段５９は、ローン会社で出力される各種帳票を作成するための帳票データと、ローン会社で出力される振込データと、顧客宛の電子メールとを作成し、ローン会社の帳票サーバ１１０や顧客端末装置８０へ夜間等に送信するバッチ処理を実行するものである。なお、顧客端末装置８０への電子メールの送信の場合には、顧客端末装置８０で顧客が電子メールを受信することができるように、顧客が契約しているプロバイダの管理するＰＯＰサーバへ電子メールを送信する処理となる。すなわち、出力データ作成処理手段５９は、ローン会社向け連携情報受信処理手段５５により受信したローン会社向け連携情報に契約申込日が含まれている顧客、すなわちローン契約データベース７３に記憶されている契約申込日が当日となっている顧客（その日の日中にローン契約の申込を行った顧客）について、当該顧客の顧客識別情報をキーとして、貸付残高データベース７５に記憶された極度額データを抽出し、顧客によるローン契約の申込に対する極度額データの算出結果を通知するための帳票データを作成し、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信する。

また、出力データ作成処理手段５９は、ローン契約データベース７３に顧客識別情報が記憶されている顧客のうち、借入返済申込データベース７１に記憶されている借入申込日（ローン契約の申込と同時に借入の申込を行った場合における契約申込日が借入申込日として記憶されている場合も含む。）が当日となっている顧客（その日の日中に借入の申込を行った顧客）について、当該顧客の顧客識別情報をキーとして、借入返済申込データベース７１に記憶された借入の可否の判断結果を示す情報を参照し、借入不可となっている場合に、当該顧客の顧客識別情報をキーとして、顧客属性データベース７０から電子メールアドレスを抽出し、顧客による借入の申込に対する貸付不能等の判断結果を通知するための電子メールを作成し、顧客端末装置８０で顧客が受信・閲覧することができるように顧客のＰＯＰサーバへ送信する。

さらに、出力データ作成処理手段５９は、ローン契約データベース７３に顧客識別情報が記憶されている顧客のうち、借入返済申込データベース７１に記憶されている借入申込日（ローン契約の申込と同時に借入の申込を行った場合における契約申込日が借入申込日として記憶されている場合も含む。）が当日となっている顧客（その日の日中に借入の申込を行った顧客）について、当該顧客の顧客識別情報をキーとして、借入返済申込データベース７１に記憶された借入の可否の判断結果を示す情報を参照し、借入可能となっている場合に、借入返済申込データベース７１に記憶された借入希望金額データを抽出するとともに、当該顧客の顧客識別情報をキーとして、顧客属性データベース７０から振込先金融機関データを抽出し、これらの借入希望金額データ、振込先金融機関データ、および顧客識別情報を用いて、顧客への貸付金の振込データ（例えばＣＳＶデータ）を作成し、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信する。

そして、出力データ作成処理手段５９は、ローン契約データベース７３に顧客識別情報が記憶されている顧客のうち、借入返済申込データベース７１に記憶されている返済申込日またはＭＲＦ返済申込日が当日となっている顧客（その日の日中に返済の申込またはＭＲＦ返済の申込を行った顧客）について、当該顧客の顧客識別情報をキーとして、借入返済申込データベース７１に記憶された返済金額データまたはＭＲＦ返済金額データを抽出し、顧客による返済の申込に係る返済金額データまたはＭＲＦ返済の申込に係るＭＲＦ返済金額データを含む帳票データを作成し、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信する。なお、ＭＲＦ返済金額データについては、ローン会社の担当者による返済入金データ（実際に返済入金があったデータ）との突合処理に用いられないため、帳票出力を省略してもよい。

また、出力データ作成処理手段５９は、ローン契約データベース７３を参照し、残高チェック処理手段５８により作成されたアラーム情報が出ている顧客の顧客識別情報を抽出し、抽出された顧客について貸付額が限度額をオーバーしている旨、あるいは担保が不足している旨を示す帳票データを作成し、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信する。

なお、処理手段５０Ａは、以上の各処理手段５１〜５９による処理の他に、例えば、日々の経過利息の算出処理や、毎月一定日（例えば２５日）の元加の処理等を実行する。

顧客属性データベース７０は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、ローン会社向け連携情報受信処理手段５５により受信した住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データを記憶するものである。

借入返済申込データベース７１は、借入に関するデータとして、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、借入希望金額データ（ローン契約の申込と同時に借入の申込を行った場合における借入希望金額データも含む。）と、借入申込日（ローン契約の申込と同時に借入の申込を行った場合における契約申込日が借入申込日として記憶されている場合も含む。）と、借入の可否の判断結果を示す情報とを記憶するものである。また、借入返済申込データベース７１は、返済に関するデータとして、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、返済またはＭＲＦ返済の別を示す情報と、返済金額データまたはＭＲＦ返済金額データと、返済申込日またはＭＲＦ返済申込日とを記憶するものである。

担保情報データベース７２は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、ローン会社向け連携情報受信処理手段５５により受信した担保残高データを記憶するものである。

ローン契約データベース７３は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、ローン会社向け連携情報受信処理手段５５により受信した契約申込日と、残高チェック処理手段５８により作成されたアラーム情報とを記憶するものである。

掛け目データベース７４は、有価証券の各種別（株式、債券、投資信託等の別）を識別するための証券種別識別情報と関連付けて、有価証券の種別毎に予め定められた担保掛目データを記憶するとともに、予め定められた極度掛目データも記憶するものである。

貸付残高データベース７５は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、Ｔ日およびＴ＋α日（例えば、Ｔ＋１日、Ｔ＋２日、Ｔ＋３日）の貸付残高データと、極度額データとを記憶するものである。

入金実績データベース７６は、顧客識別情報（例えば、証券会社に開設された顧客の口座番号等）と関連付けて、返済金額入力受付処理手段５４により受け付けた返済入金データ（金融機関に実際に返済入金されたデータ）を記憶するものである。

＜各端末装置およびその他の構成＞

顧客端末装置８０、証券会社端末装置９０、およびローン会社端末装置１００は、コンピュータにより構成され、ＷＷＷブラウザまたは専用の閲覧用ソフトウェアが搭載されている。これらの端末装置８０，９０，１００は、マウスやキーボード等の入力手段と、ＣＲＴディスプレイや液晶ディスプレイ等の表示手段と、プリンタ等の出力手段とを備えている。なお、これらの端末装置８０，９０，１００は、携帯電話機や携帯情報端末（ＰＤＡ）等の携帯機器であってもよい。

帳票サーバ１１０は、コンピュータにより構成され、出力データ作成処理手段５９により作成されてローン会社サーバ５０からローン会社の内部ネットワーク４を介して送信されてくる帳票データ（図示されない帳票データ記憶手段に記憶されている。）を用いて帳票出力処理を実行する帳票作成処理手段１１１と、出力データ作成処理手段５９により作成されてローン会社サーバ５０からローン会社の内部ネットワーク４を介して送信されてくる振込データを記憶する振込データ記憶手段１１２とを含んで構成されている。

ファームバンキング用端末装置１２０は、コンピュータにより構成され、ＷＷＷブラウザまたはファームバンキング専用のソフトウェアが搭載されている。このファームバンキング用端末装置１２０は、インターネット１を介して金融機関システム１３０（銀行や郵便貯金のシステム等）に開設されているローン会社の口座の入出金処理の実行、残高表示（残高および入出金の確認）、顧客の指定口座への振込処理等の一般的なファームバンキングを行うための端末装置であり、マウスやキーボード等の入力手段と、ＣＲＴディスプレイや液晶ディスプレイ等の表示手段と、プリンタ等の出力手段とを備えている。なお、このファームバンキング用端末装置１２０は、携帯電話機や携帯情報端末（ＰＤＡ）等の携帯機器であってもよい。また、ファームバンキング用端末装置１２０は、ローン会社端末装置１００と物理的に同じコンピュータで構成されていてもよい。

そして、以上において、証券会社サーバ２０、ローン会社サーバ５０、および帳票サーバ１１０は、１台のコンピュータあるいは１つのＣＰＵにより実現されるものに限定されず、複数のコンピュータ等で分散処理を行うことにより実現されるものであってもよい。

また、証券会社サーバ２０の処理手段２０Ａに含まれる各処理手段２１〜２９、ローン会社サーバ５０の処理手段５０Ａに含まれる各処理手段５１〜５９、および帳票サーバ１１０の帳票作成処理手段１１１は、証券会社サーバ２０、ローン会社サーバ５０、および帳票サーバ１１０を構成する各コンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラムにより実現される。

さらに、証券会社サーバ２０の各データベース３０〜３４、ローン会社サーバ５０の各データベース７０〜７６、および帳票サーバ１１０の振込データ記憶手段１１２は、例えばハードディスク等により好適に実現されるが、記憶容量やアクセス速度等に問題が生じない範囲であれば、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、ＲＡＭ、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＦＤ、磁気テープ、あるいはこれらの組合せ等を採用してもよい。

このような本実施形態においては、以下のようにして、証券担保ローン管理システム１０により、証券担保ローンの契約、借入、返済に関する処理が行われる。

＜システムの全体的な処理の流れ＞

図２において、先ず、顧客がローン契約の申込を行う際には、次のような処理が行われる。すなわち、顧客が顧客端末装置８０を操作し、オンライントレードのための画面の表示要求を行うと、この要求信号がネットワーク１を介して証券会社サーバ２０に送信され、証券会社サーバ２０のオンライントレード処理手段２１により、オンライントレードのためのログイン画面の表示用データがネットワーク１を介して顧客端末装置８０へ送信され、顧客端末装置８０の画面上に、ログイン画面が表示される。

顧客がログイン画面で顧客識別情報（口座番号等）およびパスワードを入力すると、入力した顧客識別情報およびパスワードがネットワーク１を介して証券会社サーバ２０に送信され、証券会社サーバ２０のオンライントレード処理手段２１により受信される。なお、顧客識別情報およびパスワードは、オンライントレードの契約を行っている顧客のものであり、本実施形態では、オンライントレードの契約を行っている顧客が、本システムによるインターネットローンの契約をする場合を取り扱うものとする。オンライントレード処理手段２１は、受信した顧客識別情報およびパスワードを用いて認証処理を行った後、オンライントレードのための画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信し、これにより顧客端末装置８０の画面上には、オンライントレードのための画面が表示される。

オンライントレードのための画面には、ローン契約（極度貸付契約）の申込（契約と同時に借入の申込を行う場合も含む。）を行うための画面に遷移するためのボタンが設けられているので、顧客がこのボタンの押下操作（クリック操作）を行うと、ローン契約（同時借入を行う場合も含む。）の申込を行うための画面の表示要求信号が、顧客端末装置８０からネットワーク１を介して証券会社サーバ２０へ送信される。証券会社サーバ２０では、オンライントレード処理手段２１により表示要求信号を受信すると、オンライントレード処理手段２１は、表示要求信号を契約申込受付処理手段２２に引き渡す。

契約申込受付処理手段２２は、オンライントレード処理手段２１から、顧客によるローン契約（同時借入を行う場合も含む。）の申込を行うための画面の表示要求信号を受け取ると、ローン契約（同時借入を行う場合も含む。）の申込を行うための画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信する。すると、顧客端末装置８０の画面上には、ローン契約（同時借入を行う場合も含む。）の申込を行うための画面が表示されるので、顧客は、この画面でローン契約の申込のための入力操作（ボタンの押下操作等）を行う。また、ローン契約の申込と同時に借入の申込を行う場合には、顧客は、借入希望金額データを入力する。そして、ローン契約の申込の意思を示す信号、またはローン契約の申込の意思を示す信号および借入希望金額データが、顧客端末装置８０からネットワーク１を介して証券会社サーバ２０へ送信され、証券会社サーバ２０の契約申込受付処理手段２２により受信される（ステップＳ１）。この際、ローン契約の申込を行った顧客の顧客識別情報（口座番号等）は、オンライントレード処理手段２１から契約申込受付処理手段２２に引き渡してもよく、あるいはローン契約の申込の意思を示す信号および借入希望金額データとともに顧客端末装置８０から送信されてくるようにしてもよい。

続いて、適格審査処理手段２３により、契約申込受付処理手段２２により受け付けた顧客識別情報をキーとして、顧客登録データベース３０に記憶された契約可否判定要素フラグを参照し、ローン契約の申込を行った顧客が、ローン契約が可能な顧客であるか否かをリアルタイムで判断する（ステップＳ２）。すなわち、適格審査処理手段２３は、顧客が信用取引を行っている（信用取引用の口座を開設している）か否かを示す信用取引フラグ（複数種類の信用取引に関するサービスが存在する場合には、各サービス毎の信用取引フラグ）を参照し、信用取引を行っていることを示すフラグが立っている場合には、ローン契約ができない顧客であると判断する。また、適格審査処理手段２３は、顧客が為替トレードを行っているか否かを示す為替トレードフラグを参照し、為替トレードを行っていることを示すフラグが立っている場合には、ローン契約ができない顧客であると判断する。さらに、適格審査処理手段２３は、別ローン（例えば、本システムで提供されるサービスとしてのインターネットローンではなく、別のサービスとして提供されている営業員との対面で行われる証券担保ローン等）を行っているか否かを示す別ローンフラグ（複数種類の別ローンに関するサービスが存在する場合には、各サービス毎の別ローンフラグ）を参照し、別ローンを行っていることを示すフラグが立っている場合には、ローン契約ができない顧客であると判断する。

また、適格審査処理手段２３は、契約申込受付処理手段２２により受け付けた顧客識別情報をキーとして、顧客登録データベース３０に記憶された生年月日を抽出し、抽出した生年月日を用いて、審査対象の顧客の年齢を算出し、当該顧客の年齢が、予め定められたローン契約が可能な年齢条件（例えば、２０歳以上、８０歳未満）を満たすか否かを判断する（ステップＳ２）。

そして、適格審査処理手段２３は、ローン契約の申込を行った顧客が、ローン契約が可能な顧客であると判断した場合には、ローン契約が可能である旨が記載されるとともに当該顧客の個人情報（住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データ、担保残高データ等）をローン会社へ転送することについて当該顧客の同意を得るためのボタンが設けられた画面の表示用データを、インターネット１を介して顧客端末装置８０へリアルタイムで送信する。すると、顧客端末装置８０の画面上には、ローン契約が可能である旨を示す画面が表示されるので、顧客が、この画面で個人情報の転送の同意のためのボタンの押下操作を行うと、個人情報の転送の同意の信号が、顧客端末装置８０から証券会社サーバ２０へインターネット１を介して送信される。証券会社サーバ２０では、適格審査処理手段２３により個人情報の転送の同意の信号を受信すると、適格審査処理手段２３は、契約申込日（同時借入の申込の場合には、契約申込日および借入希望金額データ）を、顧客識別情報と関連付けて契約申込データベース３２に記憶させる。また、適格審査処理手段２３は、個人情報の転送の同意の信号を受信すると、明日以降、借入を行うことができる旨や、明日、ローン会社での審査の結果（極度額の算出結果）が出る旨を示す画面の表示用データを、インターネット１を介して顧客端末装置８０へリアルタイムで送信する。すると、顧客端末装置８０の画面上には、明日以降、借入を行うことができる旨や、明日、ローン会社での審査の結果（極度額の算出結果）が出る旨を示す画面が表示されるので、顧客は、この内容を確認することができる。

一方、適格審査処理手段２３は、ローン契約の申込を行った顧客が、ローン契約ができない顧客であると判断した場合には、その旨および理由を示す画面の表示用データを、インターネット１を介して顧客端末装置８０へリアルタイムで送信する。すると、顧客端末装置８０の画面上には、例えば、為替トレードを行っているのでローン契約を締結することができない旨等が示された画面が表示されるので、顧客は、この内容を確認することができる。

次に、顧客が借入の申込を行う際には、次のような処理が行われる。すなわち、顧客が顧客端末装置８０を操作し、オンライントレードのための画面の表示要求を行うと、この要求信号がネットワーク１を介して証券会社サーバ２０に送信され、証券会社サーバ２０のオンライントレード処理手段２１により、オンライントレードのためのログイン画面の表示用データがネットワーク１を介して顧客端末装置８０へ送信され、顧客端末装置８０の画面上に、ログイン画面が表示される。

顧客がログイン画面で顧客識別情報（口座番号等）およびパスワードを入力すると、入力した顧客識別情報およびパスワードがネットワーク１を介して証券会社サーバ２０に送信され、証券会社サーバ２０のオンライントレード処理手段２１により受信される。オンライントレード処理手段２１は、受信した顧客識別情報およびパスワードを用いて認証処理を行った後、オンライントレードのための画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信し、これにより顧客端末装置８０の画面上には、オンライントレードのための画面が表示される。

オンライントレードのための画面（顧客識別情報を保持している。）には、借入の申込を行うための画面に遷移するためのボタンが設けられているので、顧客がこのボタンの押下操作（クリック操作）を行うと、顧客による借入の申込を行うための画面の表示要求信号および当該顧客の顧客識別情報が、顧客端末装置８０からネットワーク１を介してローン会社サーバ５０へ送信される。ローン会社サーバ５０では、借入申込受付処理手段５１により表示要求信号および顧客識別情報を受信すると、借入の申込を行うための画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信する。すると、顧客端末装置８０の画面上には、借入の申込を行うための画面が表示されるので、顧客は、この画面で借入希望金額データを入力し、入力した借入希望金額データを、顧客端末装置８０からネットワーク１を介してローン会社サーバ５０へ送信する。ローン会社サーバ５０では、借入申込受付処理手段５１により借入希望金額データを受信し、借入希望金額データおよび借入申込日を、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させる（ステップＳ３）。

また、顧客が返済（ＭＲＦによる返済を除く。）の申込を行う際には、次のような処理が行われる。すなわち、顧客が顧客端末装置８０を操作し、オンライントレードのための画面の表示要求を行うと、この要求信号がネットワーク１を介して証券会社サーバ２０に送信され、証券会社サーバ２０のオンライントレード処理手段２１により、オンライントレードのためのログイン画面の表示用データがネットワーク１を介して顧客端末装置８０へ送信され、顧客端末装置８０の画面上に、ログイン画面が表示される。

顧客がログイン画面で顧客識別情報（口座番号等）およびパスワードを入力すると、入力した顧客識別情報およびパスワードがネットワーク１を介して証券会社サーバ２０に送信され、証券会社サーバ２０のオンライントレード処理手段２１により受信される。オンライントレード処理手段２１は、受信した顧客識別情報およびパスワードを用いて認証処理を行った後、オンライントレードのための画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信し、これにより顧客端末装置８０の画面上には、オンライントレードのための画面が表示される。

オンライントレードのための画面（顧客識別情報を保持している。）には、返済の申込を行うための画面に遷移するためのボタンが設けられているので、顧客がこのボタンの押下操作（クリック操作）を行うと、顧客による返済の申込を行うための画面の表示要求信号および当該顧客の顧客識別情報が、顧客端末装置８０からネットワーク１を介してローン会社サーバ５０へ送信される。ローン会社サーバ５０では、返済申込受付処理手段５３により表示要求信号および顧客識別情報を受信すると、返済の申込を行うための画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信する。すると、顧客端末装置８０の画面上には、返済の申込を行うための画面が表示されるので、顧客は、この画面で返済金額データを入力し、入力した返済金額データを、顧客端末装置８０からネットワーク１を介してローン会社サーバ５０へ送信する。ローン会社サーバ５０では、返済申込受付処理手段５３により返済金額データを受信し、返済金額データおよび返済申込日を、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させる（ステップＳ４）。

上記のステップＳ４の処理（日中等の処理）で、返済申込受付処理手段５３により、借入返済申込データベース７１に返済金額データおよび返済申込日が書き込まれると、後述する図４のステップＳ３１の処理（返済金額データが書き込まれた日、すなわち返済申込日の当日の夜間等のバッチ処理）で、返済金額データを含む帳票データが作成されてローン会社の帳票サーバ１１０に送信され、翌日（返済申込日の翌日）の朝には、ローン会社において、返済金額が記載された帳票が出力された状態となっている。従って、ローン会社の担当者は、出力された帳票を見ることで、顧客の返済の申込に係る返済金額データを把握することができる。

一方、顧客は、返済申込日の翌日までに、返済の申込に係る資金を、金融機関の指定口座に実際に入金しなければならないので、ローン会社の担当者は、ファームバンキング用端末装置１２０を用いて金融機関システム１３０にアクセスし、金融機関に開設されたローン会社の指定口座の入出金情報を参照することにより、顧客からの返済入金があったか否かを確認する。

そして、ローン会社の担当者は、帳票に記載された顧客の返済の申込に係る返済金額データと、ファームバンキング用端末装置１２０で確認した実際の返済入金データとを突き合わせ、これらの金額が一致していることを確認した後、ローン会社端末装置１００を操作し、返済入金を行った顧客の顧客識別情報および確認した実際の返済入金データを入力し、ローン会社端末装置１００からローン会社サーバ５０へローン会社の内部ネットワーク４を介して送信する。ローン会社サーバ５０では、返済金額入力受付処理手段５４により、ローン会社端末装置１００からローン会社の担当者により入力されて送信されてくる顧客識別情報および返済入金データを受信し、受信した返済入金データおよび返済入金日を、顧客識別情報と関連付けて入金実績データベース７６に記憶させる（ステップＳ５）。

また、顧客がＭＲＦによる返済の申込を行う際には、次のような処理が行われる。すなわち、顧客が顧客端末装置８０を操作し、オンライントレードのための画面の表示要求を行うと、この要求信号がネットワーク１を介して証券会社サーバ２０に送信され、証券会社サーバ２０のオンライントレード処理手段２１により、オンライントレードのためのログイン画面の表示用データがネットワーク１を介して顧客端末装置８０へ送信され、顧客端末装置８０の画面上に、ログイン画面が表示される。

顧客がログイン画面で顧客識別情報（口座番号等）およびパスワードを入力すると、入力した顧客識別情報およびパスワードがネットワーク１を介して証券会社サーバ２０に送信され、証券会社サーバ２０のオンライントレード処理手段２１により受信される。オンライントレード処理手段２１は、受信した顧客識別情報およびパスワードを用いて認証処理を行った後、オンライントレードのための画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信し、これにより顧客端末装置８０の画面上には、オンライントレードのための画面が表示される。

オンライントレードのための画面には、ＭＲＦ残高からの返済の申込を行うための画面に遷移するためのボタンが設けられているので、顧客がこのボタンの押下操作（クリック操作）を行うと、ＭＲＦ残高からの返済の申込を行うための画面の表示要求信号が、顧客端末装置８０からネットワーク１を介して証券会社サーバ２０へ送信される。証券会社サーバ２０では、オンライントレード処理手段２１により表示要求信号を受信すると、オンライントレード処理手段２１は、表示要求信号をＭＲＦ返済申込受付処理手段２４に引き渡す。

ＭＲＦ返済申込受付処理手段２４は、オンライントレード処理手段２１から、ＭＲＦ残高からの返済の申込を行うための画面の表示要求信号を受け取ると、ＭＲＦ残高からの返済の申込を行うための画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信する。すると、顧客端末装置８０の画面上には、ＭＲＦ残高からの返済の申込を行うための画面が表示されるので、顧客がこの画面でＭＲＦ返済金額データを入力し、送信操作を行うと、入力されたＭＲＦ返済金額データは、顧客端末装置８０からネットワーク１を介して証券会社サーバ２０へ送信され、証券会社サーバ２０のＭＲＦ返済申込受付処理手段２４により受信される（ステップＳ６）。この際、ＭＲＦ返済の申込を行った顧客の顧客識別情報（口座番号等）は、オンライントレード処理手段２１からＭＲＦ返済申込受付処理手段２４に引き渡してもよく、あるいはＭＲＦ返済金額データとともに顧客端末装置８０から送信されてくるようにしてもよい。

続いて、ＭＲＦ処理手段２５により、ＭＲＦ返済の申込を行った顧客の顧客識別情報をキーとして、証券会社に設置されている図示されないＭＲＦ残高データベース（各顧客のＭＲＦ残高データが顧客識別情報と関連付けて記憶されているデータベース）にアクセスし、ＭＲＦ残高データがＭＲＦ返済金額データ以上であるか否かを判断し、ＭＲＦ返済金額データ以上であった場合には、ＭＲＦの売却処理、すなわちＭＲＦ残高データからＭＲＦ返済金額データを減じる処理を実行した後、ＭＲＦ返済金額データおよびＭＲＦ返済申込日を、顧客識別情報と関連付けてＭＲＦ返済データベース３３に記憶させる（ステップＳ７）。一方、ＭＲＦ処理手段２５は、ＭＲＦ残高データがＭＲＦ返済金額データに満たないと判断した場合には、ＭＲＦ残高データが足りないので、ＭＲＦ残高からの返済を行うことができない旨を示す画面の表示用データを、ネットワーク１を介して顧客端末装置８０へ送信する。すると、顧客端末装置８０の画面上には、その旨の表示がなされ、顧客はＭＲＦ残高データが足りないことを把握することができる。もっとも、ＭＲＦ残高からの返済の申込を行うための画面には、ＭＲＦ返済申込受付処理手段２４がＭＲＦ残高データベースにアクセスして取得したＭＲＦ残高データが表示されるので、顧客は、ＭＲＦ返済金額データを入力する際に、ＭＲＦ残高データを把握することができるようになっている。

以上に述べた図２の処理は、例えば日中等に行われるオンライン処理であるが、ステップＳ１，Ｓ２の契約の申込（同時借入の申込も含む。）の受付および適格審査の処理と、ステップＳ３の借入の申込の受付処理と、ステップＳ４の返済（ＭＲＦ返済を除く。）の申込の受付処理と、ステップＳ５の返済金額の入力の受付処理と、ステップＳ６，Ｓ７のＭＲＦ返済の申込の受付およびＭＲＦ売却の処理とは、図２に記載された順序で行われるわけではなく、これらのオンライン処理は、独立して日中等に（すなわち、オンラインの受付時間中に）、随時行われる。なお、ステップＳ４の返済（ＭＲＦ返済を除く。）の申込の受付処理と、ステップＳ５の返済金額の入力の受付処理との時間的関係は、同一の顧客の同一の返済について見れば、ステップＳ４の処理の翌日にステップＳ５の処理が行われるという関係になる。

図３において、例えば夜間等になると（すなわち、オンラインの受付時間の終了後に）、以下のようなバッチ処理が行われる。先ず、ローン会社サーバ５０では、貸付残高更新処理手段５７により、入金実績データベース７６に記憶されている返済入金日が当日（本日）となっている顧客の顧客識別情報および返済入金データを抽出し（ステップＳ２１）、抽出した顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データから、返済入金データを減じることにより、更新後のＴ日の貸付残高データを算出し、その更新後のＴ日の貸付残高データを、顧客識別情報と関連付けて貸付残高データベース７５に記憶させる（ステップＳ２２）。

例えば、４月２日に返済（ＭＲＦ返済以外）の申込が行われ、翌日の４月３日に実際に金融機関の指定口座への返済入金が行われ、その返済入金データが４月３日に入金実績データベース７６に書き込まれた場合には、４月３日の夜間の時点で、入金実績データベース７６には、返済入金データおよび４月３日という返済入金日が記憶されているので、貸付残高更新処理手段５７による４月３日の夜間のバッチ処理において、この４月３日という返済入金日となっている返済入金データ（すなわち、４月２日の返済（ＭＲＦ返済以外）の申込に係る返済入金データ）が、Ｔ日の貸付残高データに反映される。従って、返済（ＭＲＦ返済以外）の申込を行った４月２日の夜間の時点では、未だ入金実績データベース７６には４月２日の返済（ＭＲＦ返済以外）の申込に係る返済入金データは記憶されていないので（未だ実際に返済入金が行われていない状態であるので）、貸付残高更新処理手段５７による４月２日の夜間のバッチ処理では、４月２日の返済（ＭＲＦ返済以外）の申込に係る返済入金データは、Ｔ日の貸付残高データに反映されない。

また、貸付残高更新処理手段５７により、借入返済申込データベース７１に記憶されているＭＲＦ返済申込日が前日（処理を行っている日の前日）となっている顧客の顧客識別情報およびＭＲＦ返済金額データを抽出し、あるいは借入返済申込データベース７１にＭＲＦ返済反映日（ＭＲＦ返済申込日の翌日）が記憶されている場合には、ＭＲＦ返済反映日が当日（本日）となっている顧客の顧客識別情報およびＭＲＦ返済金額データを抽出し、抽出した顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データから、ＭＲＦ返済金額データを減じることにより、更新後のＴ日の貸付残高データを算出し、その更新後のＴ日の貸付残高データを顧客識別情報と関連付けて貸付残高データベース７５に記憶させる（ステップＳ２２）。

例えば、４月２日にＭＲＦ返済の申込が行われ、ローン会社向け連携情報受信処理手段５５により４月２日の夜間にＭＲＦ返済金額データおよびＭＲＦ返済申込日が受信され（ステップＳ２４）、受信したＭＲＦ返済金額データおよびＭＲＦ返済申込日が借入返済申込データベース７１に書き込まれ場合には、貸付残高更新処理手段５７による４月２日の夜間におけるＴ日の貸付残高算出のバッチ処理の時点（ステップＳ２２）では、借入返済申込データベース７１には、未だ４月２日のＭＲＦ返済の申込に係るＭＲＦ返済金額データおよびＭＲＦ返済申込日は記憶されていない状態にあるので、４月２日の夜間のバッチ処理では、４月２日のＭＲＦ返済の申込に係るＭＲＦ返済金額データは、Ｔ日の貸付残高データに反映されず、翌日の４月３日の夜間におけるＴ日の貸付残高算出のバッチ処理の時点（ステップＳ２２）で、初めて４月２日のＭＲＦ返済の申込に係るＭＲＦ返済金額データが、Ｔ日の貸付残高データに反映される。なお、後述するように、４月２日の夜間におけるＴ＋α日の貸付残高算出のバッチ処理の時点（図４のステップＳ２６）では、借入返済申込データベース７１には、既に４月２日のＭＲＦ返済の申込に係るＭＲＦ返済金額データおよびＭＲＦ返済申込日が記憶されている状態となっているので、４月２日の夜間のバッチ処理で、４月２日のＭＲＦ返済の申込に係るＭＲＦ返済金額データが、Ｔ＋α日の貸付残高データに反映される。

さらに、貸付残高更新処理手段５７により、借入返済申込データベース７１に記憶されている借入申込日が前日（処理を行っている日の前日）となっている顧客の顧客識別情報および借入希望金額データ（同時借入の場合も含む。）を抽出し（借入の可否の判断結果を示す情報が、借入可能となっている場合に限る。）、あるいは借入返済申込データベース７１に振込日（借入申込日の翌日）が記憶されている場合には、振込日が当日（本日）となっている顧客の顧客識別情報および借入希望金額データ（同時借入の場合も含む。）を抽出し、抽出した顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データに、借入希望金額データを加算することにより、更新後のＴ日の貸付残高データを算出し、その更新後のＴ日の貸付残高データを顧客識別情報と関連付けて貸付残高データベース７５に記憶させる（ステップＳ２２）。

例えば、４月２日に借入の申込（契約の申込と同時の借入の申込を除く。）が行われ、借入希望金額データが借入返済申込データベース７１に書き込まれた場合には、貸付残高更新処理手段５７による４月２日の夜間におけるＴ日の貸付残高算出のバッチ処理の時点（ステップＳ２２）では、借入返済申込データベース７１には、既に４月２日の借入の申込（同時借入の申込を除く。）に係る借入希望金額データおよび借入申込日は記憶されている状態となっているものの、借入審査（図４のステップＳ２５）が未だ済んでいない状態であるので、４月２日の夜間のバッチ処理では、４月２日の借入の申込（同時借入の申込を除く。）に係る借入希望金額データは、Ｔ日の貸付残高データに反映されず、翌日の４月３日の夜間におけるＴ日の貸付残高算出のバッチ処理の時点（ステップＳ２２）で、初めて４月２日の借入の申込（同時借入の申込を除く。）に係る借入希望金額データが、Ｔ日の貸付残高データに反映される。なお、後述するように、４月２日の夜間におけるＴ＋α日の貸付残高算出のバッチ処理の時点（図４のステップＳ２６）では、借入返済申込データベース７１には、既に４月２日の借入の申込（同時借入の申込を除く。）に係る借入希望金額データおよび借入申込日が記憶され、かつ、借入審査（図４のステップＳ２５）も済んでいる状態となっているので、４月２日の夜間のバッチ処理で、４月２日の借入の申込（同時借入の申込を除く。）に係る借入希望金額データが、Ｔ＋α日の貸付残高データに反映される。つまり、振込は４月３日に行われるため、４月２日の夜間のバッチ処理の時点では、未だ顧客への振込は行われていない状態にあるが、借入審査を通過しているので、振込が行われた状態の予定の貸付残高データとして、Ｔ＋α日の貸付残高データを算出する。

また、例えば、４月２日に契約の申込と同時の借入の申込が行われ、ローン会社向け連携情報受信処理手段５５により４月２日の夜間に同時借入の場合における借入希望金額データおよび借入申込日（＝契約申込日）が受信され（ステップＳ２４）、受信した借入希望金額データおよび借入申込日が借入返済申込データベース７１に書き込まれた場合には、貸付残高更新処理手段５７による４月２日の夜間におけるＴ日の貸付残高算出のバッチ処理の時点（ステップＳ２２）では、借入返済申込データベース７１には、未だ４月２日の同時借入の申込に係る借入希望金額データおよび借入申込日は記憶されていない状態（勿論、図４のステップＳ２５の借入審査も済んでいない状態である。）であるので、４月２日の夜間のバッチ処理では、４月２日の同時借入の申込に係る借入希望金額データは、Ｔ日の貸付残高データに反映されず、翌日の４月３日の夜間におけるＴ日の貸付残高算出のバッチ処理の時点（ステップＳ２２）で、初めて４月２日の同時借入の申込に係る借入希望金額データが、Ｔ日の貸付残高データに反映される。なお、後述するように、４月２日の夜間におけるＴ＋α日の貸付残高算出のバッチ処理の時点（図４のステップＳ２６）では、借入返済申込データベース７１には、既に４月２日の同時借入の申込に係る借入希望金額データおよび借入申込日（＝契約申込日）が記憶され、かつ、借入審査（図４のステップＳ２５）も済んでいる状態となっているので、４月２日の夜間のバッチ処理で、４月２日の同時借入の申込に係る借入希望金額データが、Ｔ＋α日の貸付残高データに反映される。つまり、振込は４月３日に行われるため、４月２日の夜間のバッチ処理の時点では、未だ顧客への振込は行われていない状態にあるが、借入審査を通過しているので、振込が行われた状態の予定の貸付残高データとして、Ｔ＋α日の貸付残高データを算出する。

その後、証券会社サーバ２０では、ローン会社向け連携情報送信処理手段２６により、契約申込データベース３２に顧客識別情報が記憶されている顧客、すなわち適格審査処理手段２３によりローン契約が可能であると判断され、かつ、ローン会社への自己の個人情報の転送に同意した顧客のうち、契約申込データベース３２に記憶された契約申込日が当日となっている顧客（その日の日中に契約申込を行った顧客）について、契約申込データベース３２から契約申込日（同時借入の申込の場合には、契約申込日および借入希望金額データ）を抽出するとともに、当該顧客の顧客識別情報をキーとして、顧客登録データベース３０から住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データを抽出する。なお、住所、氏名、電話番号、生年月日、振込先金融機関データが変更されることを考慮し、契約申込データベース３２に記憶された契約申込日が当日となっている顧客（その日の日中に契約申込を行った顧客）に限らず、契約申込データベース３２に顧客識別情報が記憶されている顧客の全て（その日までに契約申込を行った顧客の全て）について、顧客登録データベース３０から住所、氏名、電話番号、生年月日、振込先金融機関データを抽出してもよい。

また、ローン会社向け連携情報送信処理手段２６により、契約申込データベース３２に顧客識別情報が記憶されている顧客の全て（その日までに契約申込を行った顧客の全て）について、当該顧客の顧客識別情報をキーとして、担保残高データベース３１から担保残高データを抽出する。

さらに、ローン会社向け連携情報送信処理手段２６により、契約申込データベース３２に顧客識別情報が記憶されている顧客のうち、ＭＲＦ返済データベース３３に記憶されたＭＲＦ返済申込日が当日となっている顧客（その日の日中にＭＲＦ返済の申込を行った顧客）について、当該顧客の顧客識別情報をキーとして、ＭＲＦ返済データベース３３から、ＭＲＦ返済金額データおよびＭＲＦ返済申込日を抽出する。

そして、ローン会社向け連携情報送信処理手段２６は、以上の抽出処理を行って、顧客識別情報、住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データ、担保残高データ、契約申込日、同時借入の申込の場合における借入希望金額データ、ＭＲＦ返済金額データ、およびＭＲＦ返済申込日を含むローン会社向け連携情報を作成し、このローン会社向け連携情報を、通信回線である専用線２を介してローン会社サーバ５０へ送信する（ステップＳ２３）。なお、ローン会社向け連携情報を構成する各データは、同時に送信するのではなく、分けて送信してもよい。

続いて、ローン会社サーバ５０では、ローン会社向け連携情報受信処理手段５５により、証券会社サーバ２０から通信回線である専用線２を介して送信されてくるローン会社向け連携情報を受信した後、受信したローン会社向け連携情報のうちの住所、氏名、電話番号、電子メールアドレス、生年月日、振込先金融機関データを、顧客識別情報と関連付けて顧客属性データベース７０に記憶させ、担保残高データを、顧客識別情報と関連付けて担保情報データベース７２に記憶させ、契約申込日を、顧客識別情報と関連付けてローン契約データベース７３に記憶させ、同時借入の申込の場合における借入希望金額データおよび借入申込日（契約申込日を借入申込日として記憶させる。）を、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させ、ＭＲＦ返済金額データおよびＭＲＦ返済申込日を、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させる（ステップＳ２４）。

図４において、ローン会社向け連携情報受信処理手段５５によりローン会社向け連携情報を受信した後に、契約借入審査処理手段５２により、受信したローン会社向け連携情報に契約申込日が含まれている顧客（その日の日中にローン契約の申込を行った顧客）の顧客識別情報（ローン契約データベース７３に記憶されている契約申込日が当日となっている顧客の顧客識別情報を抽出してもよい。）をキーとして、担保情報データベース７２に記憶されている担保残高データ（ローン会社向け連携情報受信処理手段５５により受信した担保残高データ）を抽出し、担保残高データに含まれるかまたは担保残高データのデータ形式から把握される証券種別識別情報をキーとして、掛け目データベース７４に記憶された掛け目データを抽出し、担保残高データおよび掛け目データを用いて、貸付可能な極度額データを算出し、算出した極度額データを、顧客識別情報と関連付けて貸付残高データベース７５に記憶させる（ステップＳ２５）。具体的には、契約借入審査処理手段５２により、例えば、担保残高データ（担保となる有価証券の時価評価額）に、有価証券の種別毎に予め定められている担保掛目データ（例えば、６０％）と、極度掛目データ（例えば、７０％）とを乗じて得られる金額データを、全ての担保証券について合計することにより、極度額データを算出する。

また、契約借入審査処理手段５２により、借入返済申込データベース７１に記憶されている借入申込日（ローン契約の申込と同時に借入の申込を行った場合における契約申込日が借入申込日として記憶されている場合も含む。）が当日（本日）となっている顧客（その日の日中に借入の申込を行った顧客）の顧客識別情報および借入希望金額データを抽出し、抽出した顧客識別情報をキーとして、貸付残高データベース７５から、借入の申込を行った顧客についての貸付残高データを抽出し、上記で算出した極度額データと、借入希望金額データ（同時借入の場合における借入希望金額データを含む。）と、貸付残高データとを用いて、顧客の借入の可否を判断し、借入の可否の判断結果を示す情報を、判断対象の借入希望金額データおよび借入申込日と対応させて、顧客識別情報と関連付けて借入返済申込データベース７１に記憶させる（ステップＳ２５）。具体的には、契約借入審査処理手段５２により、貸付残高データ（同時借入の場合は、ゼロである。）に、借入希望金額データを加算した金額データが、極度額データ以下であるか否かを判断し、極度額データ以下の場合には、借入が可能であり、極度額データを超えている場合には、借入することができないと判断する。

それから、貸付残高更新処理手段５７により、Ｔ＋α日（例えば、Ｔ＋１日、Ｔ＋２日、Ｔ＋３日）の貸付残高データを算出する（ステップ２６）。すなわち、先ず、貸付残高更新処理手段５７により、貸付残高データベース７５に顧客識別情報が記憶されている全ての顧客について、貸付残高データベース７５に記憶されたＴ日の貸付残高データを、貸付残高データベース７５に記憶されたＴ＋α日の貸付残高データに上書きし、Ｔ＋α日の貸付残高データを更新する。

これにより、入金実績データベース７６に記憶されている返済入金日が当日（本日）となっている顧客の返済入金データは、前述した図３のステップＳ２２の処理でＴ日の貸付残高データに既に反映されているので、Ｔ＋α日の貸付残高データにも反映されることになる。例えば、４月２日に返済（ＭＲＦ返済以外）の申込が行われ、翌日の４月３日に実際に金融機関の指定口座への返済入金が行われ、その返済入金データが４月３日に入金実績データベース７６に書き込まれた場合には、貸付残高更新処理手段５７による４月３日の夜間における図３のステップＳ２２のバッチ処理で、４月３日という返済入金日となっている返済入金データ（すなわち、４月２日の返済（ＭＲＦ返済以外）の申込に係る返済入金データ）が、Ｔ日の貸付残高データ（４月３日時点の確定した貸付残高データ）に反映されるので、その返済入金データは、貸付残高更新処理手段５７による４月３日の夜間における図４のステップＳ２６のバッチ処理で、Ｔ＋α日の貸付残高データ（４月４日、５日、６日時点の予定の貸付残高データ）にも反映されることになる。

また、借入返済申込データベース７１に記憶されているＭＲＦ返済申込日が前日（処理を行っている日の前日）となっている顧客のＭＲＦ返済金額データは、前述した図３のステップＳ２２の処理でＴ日の貸付残高データに既に反映されているので、Ｔ＋α日の貸付残高データにも反映されることになる。例えば、４月２日にＭＲＦ返済の申込が行われ、ローン会社向け連携情報受信処理手段５５により４月２日の夜間にＭＲＦ返済金額データおよびＭＲＦ返済申込日が受信され（図３のステップＳ２４）、受信したＭＲＦ返済金額データおよびＭＲＦ返済申込日が借入返済申込データベース７１に書き込まれた場合には、貸付残高更新処理手段５７による４月３日の夜間における図３のステップＳ２２のバッチ処理で、４月２日のＭＲＦ返済の申込に係るＭＲＦ返済金額データが、Ｔ日の貸付残高データ（４月３日時点の確定した貸付残高データ）に反映されるので、そのＭＲＦ返済金額データは、貸付残高更新処理手段５７による４月３日の夜間における図４のステップＳ２６のバッチ処理で、Ｔ＋α日の貸付残高データ（４月４日、５日、６日時点の予定の貸付残高データ）にも反映されることになる。

さらに、借入返済申込データベース７１に記憶されている借入申込日が前日（処理を行っている日の前日）となっている顧客の借入希望金額データ（同時借入の場合も含む。）は、前述した図３のステップＳ２２の処理でＴ日の貸付残高データに既に反映されているので、Ｔ＋α日の貸付残高データにも反映されることになる。例えば、４月２日に借入の申込（同時借入の申込を除く。）が行われ、借入希望金額データおよび借入申込日が借入返済申込データベース７１に書き込まれた場合、あるいは４月２日に同時借入の申込が行われ、ローン会社向け連携情報受信処理手段５５により４月２日の夜間に借入希望金額データおよび借入申込日（＝契約申込日）が受信され（図３のステップＳ２４）、受信した借入希望金額データおよび借入申込日が借入返済申込データベース７１に書き込まれた場合には、貸付残高更新処理手段５７による４月３日の夜間における図３のステップＳ２２のバッチ処理で、４月２日の借入の申込（同時借入の申込を含む。）に係る借入希望金額データが、Ｔ日の貸付残高データ（４月３日時点の確定した貸付残高データ）に反映されるので、その借入希望金額データは、貸付残高更新処理手段５７による４月３日の夜間における図４のステップＳ２６のバッチ処理で、Ｔ＋α日の貸付残高データ（４月４日、５日、６日時点の予定の貸付残高データ）にも反映されることになる。

次に、貸付残高更新処理手段５７により、借入返済申込データベース７１に記憶されているＭＲＦ返済申込日が当日（本日）となっている顧客の顧客識別情報およびＭＲＦ返済金額データ（その日にローン会社向け連携情報受信処理手段５５により受信したＭＲＦ返済金額データ）を抽出し、抽出した顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データからＭＲＦ返済金額データを減じることにより、更新後のＴ＋α日の貸付残高データを算出し、その更新後のＴ＋α日の貸付残高データを貸付残高データベース７５に記憶させる。例えば、４月３日にＭＲＦ返済の申込が行われ、ローン会社向け連携情報受信処理手段５５により４月３日の夜間にＭＲＦ返済金額データおよびＭＲＦ返済申込日が受信され（図３のステップＳ２４）、受信したＭＲＦ返済金額データおよびＭＲＦ返済申込日が借入返済申込データベース７１に書き込まれた場合には、貸付残高更新処理手段５７による４月３日の夜間における図３のステップＳ２２のバッチ処理の時点では、証券会社サーバ２０から未だ４月３日のＭＲＦ返済の申込に係るＭＲＦ返済金額データおよびＭＲＦ返済申込日を受信していないので、借入返済申込データベース７１には、４月３日というＭＲＦ返済申込日は、未だ記憶されていない状態であるから、４月３日のＭＲＦ返済の申込に係るＭＲＦ返済金額データは、Ｔ日の貸付残高データには反映されないが、貸付残高更新処理手段５７による４月３日の夜間における図４のステップＳ２６のバッチ処理の時点では、証券会社サーバ２０から既に４月３日のＭＲＦ返済の申込に係るＭＲＦ返済金額データおよびＭＲＦ返済申込日を受信しているので、借入返済申込データベース７１には、４月３日というＭＲＦ返済申込日が記憶されていることから、４月３日のＭＲＦ返済の申込に係るＭＲＦ返済金額データは、Ｔ＋α日の貸付残高データには反映される。この際、前述したように、４月２日にＭＲＦ返済の申込が行われ、ローン会社向け連携情報受信処理手段５５により４月２日の夜間にＭＲＦ返済金額データおよびＭＲＦ返済申込日が受信され（図３のステップＳ２４）、受信したＭＲＦ返済金額データおよびＭＲＦ返済申込日が借入返済申込データベース７１に書き込まれていた場合には、貸付残高更新処理手段５７による４月３日の夜間における図３のステップＳ２２のバッチ処理で、４月２日のＭＲＦ返済の申込に係るＭＲＦ返済金額データが、Ｔ日の貸付残高データに反映されているので、貸付残高更新処理手段５７による４月３日の夜間における図４のステップＳ２６のバッチ処理において、貸付残高データベース７５から抽出したＴ日の貸付残高データ（４月２日のＭＲＦ返済の申込に係るＭＲＦ返済金額データが既に反映されている。）から、４月３日のＭＲＦ返済の申込に係るＭＲＦ返済金額データを減じることにより得られるＴ＋α日の貸付残高データには、４月２日および４月３日の双方のＭＲＦ返済の申込に係るＭＲＦ返済金額データが反映されることになる。経過利息を考慮せずに元本だけで考えると、４月１日の貸付残高データがＸ万円であったときに、４月２日に２００万円のＭＲＦ返済の申込、４月３日に３００万円のＭＲＦ返済の申込が行われたとすると、４月２日の夜間のバッチ処理では、ステップＳ２２で、Ｔ日の貸付残高データ＝Ｘ万円となり（未だ２００万円というデータを受信していないので）、ステップＳ２６で、このＸ万円がＴ＋α日の貸付残高データに上書きされ、一旦、Ｔ＋α日の貸付残高データ＝Ｘ万円となるが、Ｔ日の貸付残高データ＝Ｘ万円からの２００万円の減算処理が行われ（既に２００万円というデータを受信しているので）、Ｔ＋α日の貸付残高データ＝（Ｘ−２００）万円となり、４月３日の夜間のバッチ処理では、ステップＳ２２で、Ｔ日の貸付残高データ＝（Ｘ−２００）万円となり（既に２００万円というデータを受信しているので）、ステップＳ２６で、この（Ｘ−２００）万円がＴ＋α日の貸付残高データに上書きされ、一旦、Ｔ＋α日の貸付残高データ＝（Ｘ−２００）万円となるが、Ｔ日の貸付残高データ＝（Ｘ−２００）万円からの３００万円の減算処理が行われ（既に３００万円というデータを受信しているので）、Ｔ＋α日の貸付残高データ＝（Ｘ−２００−３００）万円となる。

なお、貸付残高更新処理手段５７は、借入返済申込データベース７１に返済申込日（ＭＲＦ返済申込日以外）が当日（本日）となっている顧客の顧客識別情報および返済金額データ（その日に返済の申込が行われた返済金額データ）があったとしても、ステップＳ２６の処理において、それらを抽出し、抽出した顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データから返済金額データを減じることにより、更新後のＴ＋α日の貸付残高データを算出し、その更新後のＴ＋α日の貸付残高データを貸付残高データベース７５に記憶させる処理は行わない。従って、返済の申込（ＭＲＦ返済の申込を除く。）については、実際に返済入金が行われるまで、Ｔ日およびＴ＋α日の貸付残高データの更新処理は行わない。

また、貸付残高更新処理手段５７により、借入返済申込データベース７１に記憶されている借入申込日（ローン契約の申込と同時に借入の申込を行った場合において契約申込日が借入申込日として記憶されている場合を含む。）が当日（本日）となっている顧客の顧客識別情報および借入希望金額データ（その日に借入の申込や同時借入の申込が行われた借入希望金額データ）を抽出し（借入の可否の判断結果を示す情報が、借入可能となっている場合に限る。）、抽出した顧客識別情報をキーとして貸付残高データベース７５からＴ日の貸付残高データを抽出し、抽出したＴ日の貸付残高データに、借入希望金額データを加算することにより、更新後のＴ＋α日の貸付残高データを算出し、その更新後のＴ＋α日の貸付残高データを貸付残高データベース７５に記憶させる。例えば、４月３日に借入の申込（同時借入の申込を含む。）が行われ、借入希望金額データが借入返済申込データベース７１に書き込まれた場合には、貸付残高更新処理手段５７による４月３日の夜間における図３のステップＳ２２のバッチ処理の時点では、借入審査（図４のステップＳ２５）が未だ済んでいない状態であるので、４月３日の借入の申込（同時借入の申込を含む。）に係る借入希望金額データは、Ｔ日の貸付残高データには反映されないが、貸付残高更新処理手段５７による４月３日の夜間における図４のステップＳ２６のバッチ処理の時点では、借入審査（図４のステップＳ２５）が既に済んでおり、かつ、借入返済申込データベース７１に４月３日という借入申込日（ローン契約の申込と同時に借入の申込を行った場合において契約申込日が借入申込日として記憶されている場合を含む。）が記憶されていることから、４月３日の借入の申込（同時借入の申込を含む。）に係る借入希望金額データは、Ｔ＋α日の貸付残高データには反映される。この際、前述したように、４月２日に借入の申込（同時借入の申込を含む。）が行われ、借入希望金額データが借入返済申込データベース７１に書き込まれていた場合には、貸付残高更新処理手段５７による４月３日の夜間における図３のステップＳ２２のバッチ処理で、４月２日の借入の申込（同時借入の申込を含む。）に係る借入希望金額データが、Ｔ日の貸付残高データに反映されているので、貸付残高更新処理手段５７による４月３日の夜間における図４のステップＳ２６のバッチ処理において、貸付残高データベース７５から抽出したＴ日の貸付残高データ（４月２日の借入の申込や同時借入の申込に係る借入希望金額データが既に反映されている。）に、４月３日の借入の申込に係る借入希望金額データを加算することにより得られるＴ＋α日の貸付残高データには、４月２日および４月３日の双方の借入の申込や同時借入の申込に係る借入希望金額データが反映されることになる。経過利息を考慮せずに元本だけで考えると、４月１日の貸付残高データがＸ万円であったときに、４月２日に２００万円の借入の申込、４月３日に３００万円の借入の申込が行われたとすると、４月２日の夜間のバッチ処理では、ステップＳ２２で、Ｔ日の貸付残高データ＝Ｘ万円となり（未だ２００万円の借入審査は済んでいないので）、ステップＳ２６で、このＸ万円がＴ＋α日の貸付残高データに上書きされ、一旦、Ｔ＋α日の貸付残高データ＝Ｘ万円となるが、Ｔ日の貸付残高データ＝Ｘ万円への２００万円の加算処理が行われ（既に２００万円の借入審査は済んでいるので）、Ｔ＋α日の貸付残高データ＝（Ｘ＋２００）万円となり、４月３日の夜間のバッチ処理では、ステップＳ２２で、Ｔ日の貸付残高データ＝（Ｘ＋２００）万円となり（既に２００万円の借入審査は済んでいるので）、ステップＳ２６で、この（Ｘ＋２００）万円がＴ＋α日の貸付残高データに上書きされ、一旦、Ｔ＋α日の貸付残高データ＝（Ｘ＋２００）万円となるが、Ｔ日の貸付残高データ＝（Ｘ＋２００）万円への３００万円の加算処理が行われ（既に３００万円の借入審査は済んでいるので）、Ｔ＋α日の貸付残高データ＝（Ｘ＋２００＋３００）万円となる。

その後、残高チェック処理手段５８により、ローン契約データベース７３に顧客識別情報が記憶されている顧客の全てについて、担保情報データベース７２に記憶された担保残高データに掛け目データベース７４に記憶された掛け目データを乗じて得られる担保評価額データに対する貸付残高データベース７５に記憶された貸付残高データの割合が一定の基準値を超えているか否かをチェックし、超えている場合にアラーム情報を作成し、作成したアラーム情報を、顧客識別情報と関連付けてローン契約データベース７３に記憶させる（ステップＳ２７）。具体的には、残高チェック処理手段５８により、各有価証券の担保残高データに含まれるかまたは担保残高データのデータ形式から把握される証券種別識別情報をキーとして、掛け目データベース７４から担保掛目データを抽出し、各有価証券の担保残高データ（担保となる有価証券の時価評価額）に、抽出した担保掛目データ（例えば、６０％）を乗じることにより、各有価証券の担保評価額データを算出し、これらの担保評価額データを合計した金額データに対する貸付残高データの割合が、予め定められた一定の基準値を超えているか否かをチェックする。

続いて、証券会社向け連携情報送信処理手段５６により、ローン契約データベース７３に顧客識別情報が記憶されている顧客の全てについて、貸付残高データベース７５から、Ｔ日およびＴ＋α日（例えば、Ｔ＋１日、Ｔ＋２日、Ｔ＋３日）の貸付残高データ、並びに極度額データを抽出する。また、証券会社向け連携情報送信処理手段５６により、残高チェック処理手段５８によるアラーム情報の作成対象となった顧客（ローン契約データベース７３にアラーム情報が記憶されている顧客）について、ローン契約データベース７３から、顧客識別情報およびアラーム情報を抽出する。そして、証券会社向け連携情報送信処理手段５６により、顧客識別情報と、Ｔ日およびＴ＋α日（例えば、Ｔ＋１日、Ｔ＋２日、Ｔ＋３日）の貸付残高データと、極度額データと、アラーム情報とを含む証券会社向け連携情報を作成し、この証券会社向け連携情報を、通信回線である専用線２を介して証券会社サーバ２０へ送信する（ステップＳ２８）。なお、証券会社向け連携情報を構成する各データは、同時に送信してもよく、分けて送信してもよい。

それから、証券会社サーバ２０では、証券会社向け連携情報受信処理手段２７により、ローン会社サーバ５０から通信回線である専用線２を介して送信されてくる証券会社向け連携情報を受信し、受信した証券会社向け連携情報のうちのＴ日およびＴ＋α日の貸付残高データ、並びに極度額データを、顧客識別情報と関連付けてローン契約データベース３４に記憶させる（ステップＳ２９）。

続いて、ロック処理手段２８により、証券会社向け連携情報受信処理手段２７により受信した証券会社向け連携情報にアラーム情報が含まれていた場合に、アラーム情報とともに受信した顧客識別情報の顧客について証券会社に開設されている口座からの出金を止めるロック処理を実行する（ステップＳ３０）。

また、ローン会社サーバ５０では、出力データ作成処理手段５９により、ローン契約データベース７３に記憶されている契約申込日が当日（本日）となっている顧客（その日の日中にローン契約の申込を行った顧客）の顧客識別情報をローン契約データベース７３から抽出し、抽出した顧客識別情報をキーとして、貸付残高データベース７５に記憶された極度額データを抽出し、顧客によるローン契約の申込に対する極度額データの算出結果を通知するための帳票データを作成し、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信する（ステップＳ３１）。帳票サーバ１１０では、送信されてきた帳票データを用いて、帳票作成処理手段１１１により帳票が出力され、出力された帳票は、ローン契約（極度貸付契約）の審査結果の通知として、顧客に郵送される。なお、郵送先である顧客の住所は、顧客属性データベース７０に顧客識別情報と関連付けて記憶されているので、出力データ作成処理手段５９は、帳票データの作成処理の際に、顧客識別情報をキーとして顧客属性データベース７０から住所を抽出し、抽出した住所を帳票データに含ませる処理を行う。

さらに、出力データ作成処理手段５９により、借入返済申込データベース７１に記憶されている借入申込日（ローン契約の申込と同時に借入の申込を行った場合における契約申込日が借入申込日として記憶されている場合も含む。）が当日（本日）となっている顧客（その日の日中に借入の申込を行った顧客）の顧客識別情報を借入返済申込データベース７１から抽出し、借入返済申込データベース７１に記憶された当該顧客についての借入の可否の判断結果を示す情報を参照し、借入可能となっている場合に、借入返済申込データベース７１に記憶された当該顧客についての借入希望金額データを抽出するとともに、当該顧客の顧客識別情報をキーとして、顧客属性データベース７０から振込先金融機関データを抽出し、これらの借入希望金額データ、振込先金融機関データ、および顧客識別情報を用いて、顧客への貸付金の振込データ（例えばＣＳＶデータ）を作成し、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信する（ステップＳ３１）。帳票サーバ１１０では、送信されてきた振込データを振込データ記憶手段１１２に記憶させる。そして、ローン会社の担当者は、振込データ記憶手段１１２から振込データを取り出し、ファームバンキング用端末装置１２０を操作して金融機関システム１３０にアクセスし、振込データを金融機関システム１３０に送信するか、または振込データを用いて顧客の指定口座への振込作業を行う。なお、出力データ作成処理手段５９により作成した振込データを、顧客属性データベース７０から抽出した振込先金融機関データにより特定される金融機関システム１３０へネットワーク１を介して直接に送信することにより、借入希望金額データに相当する貸付金の振込処理を自動的に行ってもよく、あるいは出力データ作成処理手段５９により作成した振込データを、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信して振込データ記憶手段１１２に記憶させた後、帳票サーバ１１０により、振込データ記憶手段１１２に記憶された振込データから振込先金融機関データを抽出し、抽出した振込先金融機関データにより特定される金融機関システム１３０へネットワーク１を介して振込データを送信することにより、借入希望金額データに相当する貸付金の振込処理を自動的に行ってもよい。

また、出力データ作成処理手段５９により、借入返済申込データベース７１に記憶されている返済申込日またはＭＲＦ返済申込日が当日（本日）となっている顧客（その日の日中に返済の申込またはＭＲＦ返済の申込を行った顧客）の顧客識別情報、返済金額データまたはＭＲＦ返済金額データを借入返済申込データベース７１から抽出し、顧客による返済の申込に係る返済金額データまたはＭＲＦ返済の申込に係るＭＲＦ返済金額データを含む帳票データを作成し、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信する（ステップＳ３１）。帳票サーバ１１０では、送信されてきた帳票データを用いて、帳票作成処理手段１１１により帳票が出力される。なお、ＭＲＦ返済金額データについては、次のようなローン会社の担当者による返済入金データ（実際に返済入金があったデータ）との突合処理に用いられないため、帳票データの作成および帳票出力を省略してもよい。それから、出力データ作成処理手段５９による帳票データの作成処理が行われた日の翌日、すなわち返済申込日の翌日に、ローン会社の担当者は、出力した帳票に記載された返済の申込に係る返済金額データを確認する。一方、ローン会社の担当者は、ファームバンキング用端末装置１２０を操作して金融機関システム１３０にアクセスし、顧客による実際の返済入金データを確認する。そして、ローン会社の担当者は、返済の申込に係る返済金額データと、実際の返済入金データとが一致していることを確認した後、ローン会社端末装置１００を操作し、前述した図２のステップＳ５の返済入金データの入力作業を行う。

さらに、出力データ作成処理手段５９により、ローン契約データベース７３を参照し、残高チェック処理手段５８により作成されたアラーム情報が出ている顧客の顧客識別情報を抽出し、抽出された顧客について貸付額が限度額をオーバーしている旨、あるいは担保が不足している旨を示す帳票データを作成し、ローン会社の内部ネットワーク４を介して帳票サーバ１１０へ送信する（ステップＳ３１）。帳票サーバ１１０では、送信されてきた帳票データを用いて、帳票作成処理手段１１１により帳票が出力される。ローン会社の担当者は、帳票を見てアラームが出ている顧客を把握することができる。

また、出力データ作成処理手段５９により、借入返済申込データベース７１に記憶されている借入申込日（ローン契約の申込と同時に借入の申込を行った場合における契約申込日が借入申込日として記憶されている場合も含む。）が当日（本日）となっている顧客（その日の日中に借入の申込を行った顧客）の顧客識別情報を借入返済申込データベース７１から抽出し、借入返済申込データベース７１に記憶された当該顧客についての借入の可否の判断結果を示す情報を参照し、借入不可となっている場合に、当該顧客の顧客識別情報をキーとして、顧客属性データベース７０から電子メールアドレスを抽出し、顧客による借入の申込に対する貸付不能等の判断結果を通知するための電子メールを作成し、顧客端末装置８０で受信することができるように顧客のＰＯＰサーバへ送信する（ステップＳ３２）。顧客は、顧客端末装置８０を操作し、この電子メールの内容を確認し、借入の申込を行った借入希望金額データの借入ができないことを把握することができる。

以上が証券担保ローン管理システム１０による全体的な処理の流れであるが、以下には、１つのローン契約の申込、１つの借入（契約と同時借入を除く。）の申込、１つの同時借入の申込、１つの返済（ＭＲＦ返済を除く。）の申込、１つのＭＲＦ返済の申込のそれぞれについて、各処理の流れを時系列で追っていった場合の説明を行う。

＜ローン契約の申込後の処理の流れ＞

ローン契約の申込については、図２のステップＳ１において、証券会社サーバ２０で日中等にローン契約の申込を受け付け、図２のステップＳ２において、証券会社サーバ２０でリアルタイムで適格審査を行い、図３のステップＳ２３において、証券会社サーバ２０からローン会社サーバ５０へローン会社向け連携情報を夜間等のバッチ処理で送信し、図３のステップＳ２４において、ローン会社サーバ５０でローン会社向け連携情報を夜間等に受信し、図４のステップＳ２５において、ローン会社サーバ５０で夜間等に契約審査を行って極度額データを算出し、図４のステップＳ２８において、ローン会社サーバ５０から証券会社サーバ２０へ極度額データを夜間等に送信し、図４のステップＳ３１において、ローン会社サーバ５０で極度額データを含む帳票データを夜間等に作成してローン会社の帳票サーバ１１０へ送信し、帳票サーバ１１０で帳票出力し、翌日に顧客へ郵送する。

＜借入（契約と同時借入を除く。）の申込後の処理の流れ＞

借入（契約と同時借入を除く。）の申込については、図２のステップＳ３において、ローン会社サーバ５０で日中に借入の申込を受け付け、図４のステップＳ２５において、ローン会社サーバ５０で夜間等に借入審査を行って借入の可否を判断し、借入可能という審査結果の場合には、図４のステップＳ２６において、ローン会社サーバ５０で夜間等にＴ＋α日の貸付残高データを更新し（仮更新）、図４のステップＳ３１において、ローン会社サーバ５０で振込データを夜間等に作成してローン会社の帳票サーバ１１０へ送信し、ローン会社の担当者が翌日に帳票サーバ１１０から振込データを取り出し、ファームバンキング用端末装置１２０に振込データを入力する。そして、その振込日（借入申込日の翌日）の夜間等に、図３のステップＳ２２において、ローン会社サーバ５０でＴ日の貸付残高データを更新する（本更新）。なお、振込に関し、顧客の指定口座への振込を行うことができなかった等のトラブルが生じた場合には、借入返済申込データベース７１における借入の申込に係るデータ（レコード）に、振込エラーを示すフラグを立てたり、あるいは振込日を書き込まない等の処理が行われ、Ｔ日の貸付残高データの更新（本更新）は行われない。一方、図４のステップＳ２５において、借入できないという審査結果の場合には、図４のステップＳ３２において、貸付不能等を通知する電子メールを作成し、顧客は、顧客端末装置８０でこの電子メールの内容を確認する。

＜契約と同時借入の申込後の処理の流れ＞

ローン契約の申込と同時の借入の申込については、図２のステップＳ１において、証券会社サーバ２０で日中にローン契約の申込および同時借入の申込を受け付け、図２のステップＳ２において、証券会社サーバ２０でローン契約についてリアルタイムで適格審査を行い、図３のステップＳ２３において、証券会社サーバ２０からローン会社サーバ５０へローン会社向け連携情報を夜間等のバッチ処理で送信し、図３のステップＳ２４において、ローン会社サーバ５０でローン会社向け連携情報を夜間等に受信し、図４のステップＳ２５において、ローン会社サーバ５０で夜間等に契約審査を行って極度額データを算出するとともに、借入審査を行って借入の可否を判断し、借入可能という審査結果の場合には、図４のステップＳ２６において、ローン会社サーバ５０で夜間等にＴ＋α日の貸付残高データを更新し（仮更新）、図４のステップＳ３１において、ローン会社サーバ５０で振込データを夜間等に作成してローン会社の帳票サーバ１１０へ送信し、ローン会社の担当者が翌日に帳票サーバ１１０から振込データを取り出し、ファームバンキング用端末装置１２０に振込データを入力する。そして、その振込日（借入申込日の翌日）の夜間等に、図３のステップＳ２２において、ローン会社サーバ５０でＴ日の貸付残高データを更新する（本更新）。一方、図４のステップＳ２５において、借入できないという審査結果の場合には、図４のステップＳ３２において、貸付不能等を通知する電子メールを作成し、顧客は、顧客端末装置８０でこの電子メールの内容を確認する。また、図４のステップＳ２５における審査結果の如何を問わず、図４のステップＳ２８において、ローン会社サーバ５０から証券会社サーバ２０へ極度額データを夜間等に送信し、図４のステップＳ３１において、ローン会社サーバ５０で極度額データを含む帳票データを夜間等に作成してローン会社の帳票サーバ１１０へ送信し、帳票サーバ１１０で帳票出力し、翌日に顧客へ郵送する。従って、図４のステップＳ２５において、借入できないという審査結果の場合であっても、ローン契約が締結されて極度額データが算出されることがあり、この場合には、同時借入の申込に係る借入希望金額データの借入はできなかったが、同時借入の申込を行った翌日に、借入希望金額データの額を減らした借入の申込を行えば、借入審査で借入可能と判断されることがあり得る。

＜返済（ＭＲＦ返済を除く。）の申込後の処理の流れ＞

１つの返済（ＭＲＦ返済を除く。）の申込については、図２のステップＳ４において、ローン会社サーバ５０で日中に返済の申込を受け付け、図４のステップＳ３１において、ローン会社サーバ５０で返済金額データを含む帳票データを夜間等に作成してローン会社の帳票サーバ１１０へ送信し、帳票サーバ１１０で帳票出力し、返済申込日の翌日の朝には、ローン会社の担当者が、出力された帳票に記載された返済金額データを確認できるようにする。一方、顧客は、返済申込日の翌日までに、金融機関に開設されているローン会社の口座に自分で返済入金を行う。そして、ローン会社の担当者は、返済申込日の翌日に、ファームバンキング用端末装置１２０を操作して金融機関システム１３０にアクセスし、顧客による実際の返済入金データを確認し、帳票に記載された返済の申込に係る返済金額データと実際の返済入金データとの一致を確認した後、返済申込日の翌日の日中における図２のステップＳ５において、ローン会社端末装置１００から返済入金データを入力し、ローン会社サーバ５０でこれを受け付ける。その後、返済申込日の翌日の夜間等に、図３のステップＳ２２において、Ｔ日の貸付残高データを更新し、図４のステップＳ２６において、Ｔ＋α日の貸付残高データを更新する。

＜ＭＲＦ返済の申込後の処理の流れ＞

ＭＲＦ返済の申込については、図２のステップＳ６において、証券会社サーバ２０で日中にＭＲＦ返済の申込を受け付け、図２のステップＳ７において、証券会社サーバ２０でＭＲＦの売却を行い、図３のステップＳ２３において、証券会社サーバ２０からローン会社サーバ５０へローン会社向け連携情報を夜間等のバッチ処理で送信し、図３のステップＳ２４において、ローン会社サーバ５０でローン会社向け連携情報を夜間等に受信し、図４のステップＳ２６において、ローン会社サーバ５０で夜間等にＴ＋α日の貸付残高データを更新し、ＭＲＦ返済申込日の翌日の夜間等に、図３のステップＳ２２において、ローン会社サーバ５０でＴ日の貸付残高データを更新する。

＜残高管理の処理の流れ＞

残高管理については、担保残高データベース３１に記憶された各担保証券の時価単価および時価評価額、並びに時価評価額の総額を、処理手段２０Ａにより、図示されない市場システムまたは時価情報提供システムから取得した最新の時価情報を用いて、日々、バッチ処理で更新する。そして、担保残高データベース３１に記憶された最新の状態の担保残高データを、図３のステップＳ２３において、証券会社サーバ２０からローン会社サーバ５０へローン会社向け連携情報として夜間等のバッチ処理で送信し、図３のステップＳ２４において、ローン会社サーバ５０でローン会社向け連携情報を夜間等に受信し、図４のステップＳ２７において、極度額、貸付残高、担保評価額を算出して残高チェックを行い、図４のステップＳ２８において、ローン会社サーバ５０から証券会社サーバ２０へ貸付残高データ、極度額データ、アラーム情報を含む証券会社向け連携情報を夜間等のバッチ処理で送信し、図４のステップＳ２９において、証券会社サーバ２０で証券会社向け連携情報を夜間等に受信し、アラーム情報が含まれる場合には、図４のステップＳ３０において、証券会社サーバ２０でロック処理を行う。また、図４のステップＳ３１において、限度額オーバー、担保不足等を示すアラーム情報を含む帳票データを作成してローン会社の帳票サーバ１１０へ送信し、帳票サーバ１１０で帳票出力する。さらに、処理手段２０Ａにより、経過利息の算出処理や、毎月一定日（例えば２５日）の元加の処理を行う。

このような本実施形態によれば、次のような効果がある。すなわち、証券担保ローン管理システム１０は、先ず、証券会社側で、証券会社サーバ２０の適格審査処理手段２３により、オンライントレードの契約をしている顧客について証券会社が保有する顧客情報を利用して、顧客がローン契約が可能な顧客であるか否かを判断する適格審査処理を行い、この証券会社での適格審査処理を通過した場合のみ、ローン会社側で、ローン会社サーバ５０の契約借入審査処理５２により、契約借入審査処理を行う構成とされているので、適切なリスク管理を証券会社側で行うことができるうえ、ローン会社側の審査処理を簡略化することができ、審査負担の軽減、融資の迅速化を図ることができる。

また、顧客にとっては、証券会社サーバ２０の適格審査処理手段２３により、証券会社が保有する顧客情報を利用して適格審査処理が行われ、かつ、証券会社での適格審査処理を通過した場合に、証券会社サーバ２０のローン会社向け連携情報送信処理手段２６により、住所、氏名、振込先金融機関データ、および担保残高データを含むローン会社向け連携情報が、証券会社サーバ２０からローン会社サーバ５０へ送信されるので、証券会社との間での手続の際に入力した住所等の情報を、ローン契約にあたり、再度、ローン会社との間の手続として入力する等の手間をかける必要はないことから、顧客の利便性を向上させることができる。換言すれば、証券会社を介してローン契約の申込を行うことで、ローン会社に対する信用保証を、証券会社が個人に代わって行うので、顧客の手間を省くことができる。

さらに、上記のように、ローン契約にあたり、顧客による住所等の情報の再入力の手間を省略することができることに加え、ローン契約の申込、借入の申込、同時借入の申込、返済の申込、ＭＲＦ返済の申込のいずれの申込を行う場合にも、顧客は、オンライントレードのための画面からログインし、オンライントレード処理手段２１による認証処理を経て、各申込を行うための画面での入力作業を行うので、顧客は、あたかも証券会社から借入を行うような感覚でローン契約、借入、返済等の手続を行うことができ、顧客の手続の煩わしさを軽減することができる。

そして、証券会社サーバ２０の契約申込受付処理手段２２は、ローン契約の申込と同時に借入の申込も受け付けることができるので、顧客の多様なニーズに応え、より早期の借入を実現することができ、顧客の利便性をより一層高めることができる。

また、借入の申込（同時借入の申込を除く。）や返済の申込（ＭＲＦ返済の申込を除く。）を行う際には、オンライントレードのための画面からログインして証券会社側の認証処理を経るものの、その後の処理は、ローン会社サーバ５０の借入申込受付処理手段５１や返済申込受付処理手段５３により行われ、借入希望金額データや返済金額データは、ローン会社サーバ５０の借入返済申込データベース７１に記憶されるので、証券会社側は、自己にとって不要なデータ処理やデータ保存を行う必要はなくなることから、証券会社側とローン会社側との間での適切な役割分担を実現することができる。

さらに、証券担保ローン管理システム１０は、ＭＲＦ返済申込受付処理手段２４を備えているので、顧客は、ＭＲＦ残高からの返済を行うことができる。このため、返済を行う際の顧客の選択自由度を高め、顧客の利便性をより一層高めることができる。また、ＭＲＦ返済申込受付処理手段２４は、返済申込受付処理手段５３とは異なり、ＭＲＦ残高を管理する証券会社サーバ２０に設けられているので、この点でも、証券会社側とローン会社側との間での適切な役割分担を実現することができる。

そして、証券担保ローン管理システム１０は、ローン会社サーバ５０に、残高チェック処理手段５８と、証券会社向け連携情報送信処理手段５８とを備え、証券会社サーバ２０に、証券会社向け連携情報受信処理手段２７と、ロック処理手段２８とを備えているので、ローン会社側で貸付の限度額オーバーや担保不足等のチェックを行い、そのチェック結果を証券会社側に送信して証券会社側でロック処理を行うことができる。このため、ローン会社と証券会社との相互の連携により、より高いリスク管理を実現することができる。

また、証券担保ローン管理システム１０は、返済申込受付処理手段５３と、出力データ作成処理手段５９と、返済金額入力受付処理手段５４と、入金実績データベース７６と、貸付残高更新処理手段５７とを備え、顧客の返済の申込を受け付けてから返済入金に関する処理を行う構成、すなわち返済申込受付処理手段５３により受け付けた顧客の返済の申込に係る返済金額データを、出力データ作成処理手段５９により帳票データとし、ローン会社の担当者が帳票に記載された返済金額データと金融機関への実際の返済入金データとを突き合わせて一致を確認してから入力した返済入金データを、返済金額入力受付処理手段５４で受け付けて入金実績データベース７６に記憶させ、入金実績データベース７６に記憶された返済入金データを用いて、貸付残高更新処理手段５７により貸付残高データの更新処理を行う構成とされているので、顧客が返済の申込を行うことなく、いきなり返済入金を行う場合に比べ、返済に関する処理の円滑化を図ることができ、より一層確実な処理を実現することができる。

さらに、貸付残高更新処理手段５７は、Ｔ日の貸付残高データのみならず、Ｔ＋α日の貸付残高データも算出する構成とされ、さらに、Ｔ日およびＴ＋α日の貸付残高データは、証券会社向け連携情報送信処理手段５６により証券会社サーバ２０へ送信されるので、証券会社サーバ２０およびローン会社サーバ５０の双方から、目的に応じた適切な貸付残高データを、顧客あるいは証券会社やローン会社の担当者に提供することができる。例えば、借入の申込を行うための画面では、Ｔ＋１日の貸付残高データを表示し、返済の申込を行うための画面では、Ｔ＋２日の貸付残高データを表示すること等ができる。

なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。

すなわち、前記実施形態では、返済金額入力受付処理手段５４は、ローン会社の担当者がローン会社端末装置１００を操作して手入力したデータ（キーボードでキー入力したデータ等）を、返済入金データとして受け付ける構成とされていたが、本発明の返済金額入力受付処理手段は、これに限定されず、ローン会社の担当者がファームバンキング用端末装置１２０を操作して金融機関システム１３０から取得（ダウンロード）した返済入金データを、ローン会社端末装置１００からローン会社サーバ５０の入金実績データベース７６にアップロードする処理を受け付ける構成としてもよい。

また、前記実施形態では、ローン会社向け連携情報送信処理手段２６により、電子メールアドレスをローン会社向け連携情報として証券会社サーバ２０からローン会社サーバ５０へ送信する構成となっていたが、このような構成に限定されるものではなく、例えば、ローン会社サーバ５０の処理手段５０Ａにより、電子メールでの送信を希望する顧客からの電子メールアドレスの入力を受け付け、受け付けた電子メールアドレスを顧客識別情報（口座番号等）と関連付けて顧客属性データベース７０に記憶させる構成としてもよい。

さらに、前記実施形態では、主として、日中にオンライン処理を行い、夜間にバッチ処理を行うという説明がなされていたが、これに限定されるものではなく、例えば、オンラインの受付時間を３時までとし、バッチ処理を夕方３時以降に行ってもよく、あるいはオンラインの受付時間を日中とし、バッチ処理を翌日の早朝（但し、この場合でも、バッチ処理日であるＴ日は、前日である。）としてもよく、要するに、オンラインの受付時間帯と、バッチ処理を行う時間帯とが、データ処理上、混乱が生じないように切り分けられていればよい。

以上のように、本発明の証券担保ローン管理システムおよびその方法、並びにプログラムは、例えば、オンライントレードを行う顧客によるローン契約、借入、返済の申込をオンラインで受け付ける場合等に用いるのに適している。

本発明の一実施形態の証券担保ローン管理システムの全体構成図。 前記実施形態の証券担保ローン管理システムによる証券担保ローンの契約、借入、返済に関する日中等に行われるオンライン処理の流れを示すフローチャートの図。 前記実施形態の証券担保ローン管理システムによる証券担保ローンの契約、借入、返済に関する夜間等に行われるバッチ処理の流れ（その１）を示すフローチャートの図。 前記実施形態の証券担保ローン管理システムによる証券担保ローンの契約、借入、返済に関する夜間等に行われるバッチ処理の流れ（その２）を示すフローチャートの図。

符号の説明

１ ネットワーク
２ 通信回線である専用線
４ ローン会社の内部ネットワーク
１０ 証券担保ローン管理システム
２０ 証券会社サーバ
２２ 契約申込受付処理手段
２３ 適格審査処理手段
２４ ＭＲＦ返済申込受付処理手段
２６ ローン会社向け連携情報送信処理手段
２７ 証券会社向け連携情報受信処理手段
２８ ロック処理手段
３０ 顧客登録データベース
３１ 担保残高データベース
５０ ローン会社サーバ
５１ 借入申込受付処理手段
５２ 契約借入審査処理手段
５３ 返済申込受付処理手段
５４ 返済金額入力受付処理手段
５５ ローン会社向け連携情報受信処理手段
５６ 証券会社向け連携情報送信処理手段
５７ 貸付残高更新処理手段
５８ 残高チェック処理手段
５９ 出力データ作成処理手段
７０ 顧客属性データベース
７２ 担保情報データベース
７４ 掛け目データベース
７５ 貸付残高データベース
７６ 入金実績データベース
８０ 顧客端末装置
１００ ローン会社端末装置
１１０ 帳票サーバ

Claims (7)

1. 証券会社に預けられた有価証券を担保として顧客が借入を行う証券担保ローンに関する処理を実行するコンピュータからなる証券担保ローン管理システムであって、
   前記顧客が操作する顧客端末装置とネットワークを介して接続されて証券会社が管理する証券会社サーバと、
   この証券会社サーバと通信回線を介して接続され、かつ、前記顧客端末装置と前記ネットワークを介して接続されてローン会社が管理するローン会社サーバとを備え、
   前記証券会社サーバは、
   顧客の住所、氏名、振込先金融機関データ、およびローン契約の可否の判定要素となる少なくとも１つの契約可否判定要素フラグを含む顧客情報を、顧客を識別するための顧客識別情報と関連付けて記憶する顧客登録データベースと、
   顧客が証券会社に預けている有価証券の担保残高データを、前記顧客識別情報と関連付けて記憶する担保残高データベースと、
   前記顧客端末装置から前記ネットワークを介して送信されてくる顧客のローン契約の申込のための入力データとして、ローン契約の申込を行った前記顧客の顧客識別情報を受け付ける処理を実行する契約申込受付処理手段と、
   この契約申込受付処理手段により受け付けた前記顧客識別情報をキーとして前記顧客登録データベースに記憶された前記契約可否判定要素フラグを参照し、ローン契約の申込を行った前記顧客がローン契約が可能な顧客であるか否かを判断する処理を実行する適格審査処理手段と、
   この適格審査処理手段によりローン契約が可能であると判断された前記顧客について、前記顧客識別情報をキーとして前記顧客登録データベースから前記住所、前記氏名、および前記振込先金融機関データを抽出するとともに、前記顧客識別情報をキーとして前記担保残高データベースから前記担保残高データを抽出することにより、前記顧客識別情報、前記住所、前記氏名、前記振込先金融機関データ、および前記担保残高データを含むローン会社向け連携情報を作成し、このローン会社向け連携情報を前記通信回線を介して前記ローン会社サーバへ送信する処理を実行するローン会社向け連携情報送信処理手段とを含んで構成され、
   前記ローン会社サーバは、
   前記証券会社サーバから前記通信回線を介して送信されてくる前記ローン会社向け連携情報を受信する処理を実行するローン会社向け連携情報受信処理手段と、
   このローン会社向け連携情報受信処理手段により受信した前記ローン会社向け連携情報のうちの前記住所、前記氏名、および前記振込先金融機関データを、前記顧客識別情報と関連付けて記憶する顧客属性データベースと、
   前記ローン会社向け連携情報受信処理手段により受信した前記ローン会社向け連携情報のうちの前記担保残高データを、前記顧客識別情報と関連付けて記憶する担保情報データベースと、
   有価証券の担保残高データから貸付可能な極度額データを算出するための掛け目データを有価証券の種別毎に記憶する掛け目データベースと、
   顧客への貸付残高データを、前記顧客識別情報と関連付けて記憶する貸付残高データベースと、
   前記顧客端末装置から前記ネットワークを介して送信されてくる顧客の借入の申込のための入力データとして、借入の申込を行った前記顧客の顧客識別情報および借入希望金額データを受け付ける処理を実行する借入申込受付処理手段と、
   前記ローン会社向け連携情報受信処理手段により受信した前記担保残高データおよび前記掛け目データベースに記憶された前記掛け目データを用いて貸付可能な極度額データを算出するとともに、前記顧客識別情報をキーとして前記貸付残高データベースから、借入の申込を行った前記顧客についての前記貸付残高データを抽出し、前記極度額データ、前記借入申込受付処理手段により受け付けた前記借入希望金額データ、および前記貸付残高データを用いて、前記顧客の借入の可否を判断する処理を実行する契約借入審査処理手段とを含んで構成されている
   ことを特徴とする証券担保ローン管理システム。
2. 前記証券会社サーバの前記契約申込受付処理手段は、前記顧客端末装置から前記ネットワークを介して送信されてくる顧客のローン契約の申込およびこれと同時に行う借入の申込のための入力データとして、ローン契約の申込および同時借入の申込を行った前記顧客の顧客識別情報および借入希望金額データを受け付ける処理を行う構成とされ、
   前記証券会社サーバの前記ローン会社向け連携情報送信処理手段は、前記顧客識別情報、前記住所、前記氏名、前記振込先金融機関データ、および前記担保残高データに加え、前記契約申込受付処理手段により受け付けた前記借入希望金額データを含む前記ローン会社向け連携情報を、前記通信回線を介して前記ローン会社サーバへ送信する処理を行う構成とされ、
   前記ローン会社サーバの前記ローン会社向け連携情報受信処理手段は、前記証券会社サーバからの前記ローン会社向け連携情報として、同時借入の前記借入希望金額データも受信する処理を行う構成とされ、
   前記ローン会社サーバの前記契約借入審査処理手段は、前記極度額データ、および前記ローン会社向け連携情報受信処理手段により受信した同時借入の前記借入希望金額データを用いて、前記顧客の借入の可否を判断する処理も行う構成とされている
   ことを特徴とする請求項１に記載の証券担保ローン管理システム。
3. 前記ローン会社サーバは、
   前記担保情報データベースに記憶された前記担保残高データに前記掛け目データベースに記憶された前記掛け目データを乗じて得られる担保評価額データに対する前記貸付残高データベースに記憶された前記貸付残高データの割合が一定の基準値を超えているか否かをチェックし、超えている場合にアラーム情報を作成する処理を実行する残高チェック処理手段と、
   この残高チェック処理手段による前記アラーム情報の作成対象となった顧客についての顧客識別情報および前記アラーム情報を含む証券会社向け連携情報を作成し、この証券会社向け連携情報を前記通信回線を介して前記証券会社サーバへ送信する処理を実行する証券会社向け連携情報送信処理手段とを備え、
   前記証券会社サーバは、
   前記ローン会社サーバから前記通信回線を介して送信されてくる前記証券会社向け連携情報を受信する処理を実行する証券会社向け連携情報受信処理手段と、
   この証券会社向け連携情報受信処理手段により受信した前記証券会社向け連携情報に前記アラーム情報が含まれる場合に、前記アラーム情報とともに受信した前記顧客識別情報の顧客について証券会社に開設されている口座からの出金を止めるロック処理を実行するロック処理手段とを備えている
   ことを特徴とする請求項１または２に記載の証券担保ローン管理システム。
4. 前記ローン会社サーバは、
   前記顧客端末装置から前記ネットワークを介して送信されてくる顧客の返済の申込のための入力データとして、返済の申込を行った前記顧客の顧客識別情報および返済金額データを受け付ける処理を実行する返済申込受付処理手段と、
   この返済申込受付処理手段により受け付けた前記顧客識別情報および前記返済金額データを含む帳票データを作成し、この帳票データをローン会社の帳票サーバへローン会社の内部ネットワークを介して送信する処理を実行する出力データ作成処理手段と、
   前記帳票サーバにより前記帳票データを用いて出力された帳票に記載された前記返済金額データと前記顧客による金融機関への返済入金データとの一致を確認したローン会社の担当者により入力されて、このローン会社の担当者が操作するローン会社端末装置から前記ローン会社の内部ネットワークを介して送信されてくる、返済の申込を行った前記顧客についての前記顧客識別情報および前記返済入金データを受け付ける処理を実行する返済金額入力受付処理手段と、
   この返済金額入力受付処理手段により受け付けた前記返済入金データを、前記顧客識別情報と関連付けて記憶する入金実績データベースと、
   この入金実績データベースに前記返済入金データが記憶されている前記顧客について前記顧客識別情報をキーとして前記貸付残高データベースから前記貸付残高データを抽出し、抽出した前記貸付残高データから前記返済入金データを減じることにより前記貸付残高データの更新処理を実行する貸付残高更新処理手段とを備えている
   ことを特徴とする請求項１〜３のいずれかに記載の証券担保ローン管理システム。
5. 前記証券会社サーバは、
   前記顧客端末装置から前記ネットワークを介して送信されてくる顧客のＭＲＦ残高からの返済の申込のための入力データとして、ＭＲＦ返済の申込を行った前記顧客の顧客識別情報およびＭＲＦ返済金額データを受け付ける処理を実行するＭＲＦ返済申込受付処理手段を備え、
   前記証券会社サーバの前記ローン会社向け連携情報送信処理手段は、前記ローン会社向け連携情報として、前記ＭＲＦ返済申込受付処理手段により受け付けた前記ＭＲＦ返済金額データも前記ローン会社サーバへ送信する処理を行う構成とされ、
   前記ローン会社サーバの前記ローン会社向け連携情報受信処理手段は、前記証券会社サーバからの前記ローン会社向け連携情報として、前記ＭＲＦ返済金額データも受信する処理を行う構成とされ、
   前記ローン会社サーバは、
   ＭＲＦ返済の申込を行った前記顧客について前記顧客識別情報をキーとして前記貸付残高データベースから前記貸付残高データを抽出し、抽出した前記貸付残高データから前記ローン会社向け連携情報受信処理手段により受信した前記ＭＲＦ返済金額データを減じることにより前記貸付残高データの更新処理を実行する貸付残高更新処理手段を備えている
   ことを特徴とする請求項１〜４のいずれかに記載の証券担保ローン管理システム。
6. 証券会社に預けられた有価証券を担保として顧客が借入を行う証券担保ローンに関する処理を実行するコンピュータからなる証券担保ローン管理システムで実行される証券担保ローン管理方法であって、
   証券会社サーバの顧客登録データベースに、顧客の住所、氏名、振込先金融機関データ、およびローン契約の可否の判定要素となる少なくとも１つの契約可否判定要素フラグを含む顧客情報を、顧客を識別するための顧客識別情報と関連付けて記憶させ、
   前記証券会社サーバの担保残高データベースに、顧客が証券会社に預けている有価証券の担保残高データを、前記顧客識別情報と関連付けて記憶させ、
   前記証券会社サーバの契約申込受付処理手段が、顧客が操作する顧客端末装置からネットワークを介して送信されてくる顧客のローン契約の申込のための入力データとして、ローン契約の申込を行った前記顧客の顧客識別情報を受け付ける処理を実行し、
   前記証券会社サーバの適格審査処理手段が、前記契約申込受付処理手段により受け付けた前記顧客識別情報をキーとして前記顧客登録データベースに記憶された前記契約可否判定要素フラグを参照し、ローン契約の申込を行った前記顧客がローン契約が可能な顧客であるか否かを判断する処理を実行し、
   前記証券会社サーバのローン会社向け連携情報送信処理手段が、前記適格審査処理手段によりローン契約が可能であると判断された前記顧客について、前記顧客識別情報をキーとして前記顧客登録データベースから前記住所、前記氏名、および前記振込先金融機関データを抽出するとともに、前記顧客識別情報をキーとして前記担保残高データベースから前記担保残高データを抽出することにより、前記顧客識別情報、前記住所、前記氏名、前記振込先金融機関データ、および前記担保残高データを含むローン会社向け連携情報を作成し、このローン会社向け連携情報を通信回線を介してローン会社サーバへ送信する処理を実行し、
   ローン会社サーバのローン会社向け連携情報受信処理手段が、前記証券会社サーバから前記通信回線を介して送信されてくる前記ローン会社向け連携情報を受信する処理を実行し、
   前記ローン会社サーバの顧客属性データベースに、前記ローン会社向け連携情報受信処理手段により受信した前記ローン会社向け連携情報のうちの前記住所、前記氏名、および前記振込先金融機関データを、前記顧客識別情報と関連付けて記憶させ、
   前記ローン会社サーバの担保情報データベースに、前記ローン会社向け連携情報受信処理手段により受信した前記ローン会社向け連携情報のうちの前記担保残高データを、前記顧客識別情報と関連付けて記憶させ、
   前記ローン会社サーバの掛け目データベースに、有価証券の担保残高データから貸付可能な極度額データを算出するための掛け目データを有価証券の種別毎に記憶させ、
   前記ローン会社サーバの貸付残高データベースに、顧客への貸付残高データを、前記顧客識別情報と関連付けて記憶させ、
   前記ローン会社サーバの借入申込受付処理手段が、前記顧客端末装置から前記ネットワークを介して送信されてくる顧客の借入の申込のための入力データとして、借入の申込を行った前記顧客の顧客識別情報および借入希望金額データを受け付ける処理を実行し、
   前記ローン会社サーバの契約借入審査処理手段が、前記ローン会社向け連携情報受信処理手段により受信した前記担保残高データおよび前記掛け目データベースに記憶された前記掛け目データを用いて貸付可能な極度額データを算出するとともに、前記顧客識別情報をキーとして前記貸付残高データベースから、借入の申込を行った前記顧客についての前記貸付残高データを抽出し、前記極度額データ、前記借入申込受付処理手段により受け付けた前記借入希望金額データ、および前記貸付残高データを用いて、前記顧客の借入の可否を判断する処理を実行する
   ことを特徴とする証券担保ローン管理方法。
7. 請求項１〜５のいずれかに記載の証券担保ローン管理システムとして、コンピュータを機能させるためのプログラム。

Images