(57)【要約】【課題】貸金業者が不適当な貸金契約を締結するリスクを軽減する。【解決手段】クエリ取得部４２は、貸金業者によって操作される操作端末１２を通じて入力される顧客の信用情報に係るデータを照会するクエリを受け取る。照会ファイル作成部は、クエリに基づき、契約者の信用情報を管理する信用情報機関によって運営されるサーバ１４が要求するフォーマットでデータ照会用のファイルを作成する。照会結果受領部５４は、照会ファイルにしたがってサーバから回答された照会結果ファイルを受け取る。名寄せ候補特定部は、照会結果ファイルに含まれる貸金契約の中から、同一人物が異なる貸金業者との間で締結した貸金契約、または婚姻関係にある人物同士がそれぞれ貸金業者との間で締結した貸金契約を選び出して名寄せ候補として特定する。総量規制判定部は、名寄せ候補とされた貸金契約に係る借入残高を積算し、契約者毎に予め定められている借入上限値と比較する。【選択図】図２
2009301236.tif 000002
【特許請求の範囲】
【請求項１】
貸金業者によって操作される複数のコンピュータ端末と、契約者の信用情報を管理する信用情報機関によって運営されるサーバとに接続される装置であって、
前記コンピュータ端末を通じて入力される、顧客の貸金契約に係るデータを照会するクエリを受け取るクエリ取得部と、
前記クエリに基づき、前記信用情報機関のサーバが要求するフォーマットでデータ照会用のファイルを作成する照会ファイル作成部と、
作成された照会ファイルを前記サーバに送信する送信部と、
前記照会ファイルにしたがって前記サーバから回答された貸金契約の照会結果ファイルを受け取る照会結果受領部と、
前記照会結果ファイルに含まれる貸金契約の中から、同一人物が異なる貸金業者との間で締結した貸金契約、または婚姻関係にある人物同士がそれぞれ貸金業者との間で締結した貸金契約を選び出して名寄せ候補として特定する名寄せ候補特定部と、
を備えることを特徴とする信用情報機関仲介装置。
【請求項２】
名寄せ候補として特定された貸金契約に係る借入残高を積算し、契約者毎に予め定められている借入上限値と比較する総量規制判定部をさらに備えることを特徴とする請求項１に記載の信用情報機関仲介装置。
【請求項３】
前記名寄せ候補特定部は、前記照会結果ファイルに含まれる貸金契約の中から、同一人物の同一の貸金契約が重複して登録されているものを特定し、前記総量規制判定部は、特定された貸金契約を一件の貸金契約とみなした上で、契約者毎に予め定められている借入上限値と比較することを特徴とする請求項１に記載の信用情報機関仲介装置。
【請求項４】
貸金業者によって操作される複数のコンピュータ端末と、契約者の信用情報を管理する信用情報機関によって運営されるサーバとに接続され、信用情報の照会を代行するコンピュータで実行されるプログラムであって、
前記コンピュータ端末を通じて入力される、顧客の信用情報に係るデータを照会するクエリを受け取る機能と、
前記クエリに基づき、前記信用情報機関のサーバが要求するフォーマットでデータ照会用のファイルを作成する機能と、
作成された照会ファイルを前記サーバに送信する機能と、
前記照会ファイルにしたがって前記サーバから回答された貸金契約の照会結果ファイルを受け取る機能と、
前記照会結果ファイルに含まれる貸金契約の中から、同一人物が異なる貸金業者との間で締結した貸金契約、または婚姻関係にある人物同士がそれぞれ貸金業者との間で締結した貸金契約を選び出して名寄せ候補として特定する機能と、
を実現させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、貸金業において個人信用情報を管理する技術に関する。
【背景技術】
【０００２】
２００７年１２月に貸金業の適正化やグレーゾーン金利廃止等を盛り込んだ改正貸金業法の本体部分が施行された。この改正は過剰貸付けの抑制を目的としており、以下の内容が含まれる。１．指定信用情報機関制度の創設。信用情報の適切な管理や全件登録などの条件を満たす信用情報機関を指定する制度を導入し、貸金業者が借り手の総借入残高を把握できる仕組を整備する。指定信用情報機関が複数ある場合、相互に残高情報等の交流を義務づける。２．総量規制の導入。信用情報機関の信用情報を使用した借り手の返済能力の調査を貸金業者に対して義務づける。調査の結果、総借入残高が年収の３分の１を超える貸付けなどの返済能力を超えた貸付けを禁止する。これらの制度は、本体施行後２年半以内に施行されることになっている。
【０００３】
貸金業法の改正に伴い、貸金業者には以下の負担が生じる。１．指定信用情報機関の信用情報の利用が義務づけられる。したがって、各貸金業者は、指定信用情報機関への接続機能を持つシステムの構築が必須となる。２．契約の登録時および個人信用情報の変更時には、「遅滞なく」指定信用情報機関に報告をするよう求められる。具体的には、前日分の登録情報および更新情報を翌朝までに信用情報機関に報告しなければならない。したがって、各貸金業者は、信用情報機関の授受スケジュールに合わせて情報の登録、更新を行う必要がある。
【０００４】
総量規制の導入後、信用情報機関と契約しない貸金業者は事業を継続することができなくなる。また、総量規制への対応が不完全な貸金業者が存在すると、貸金業全体の信用不安を招くおそれがあるため、貸金業法の対象となる全ての業者が信用情報機関と適切な情報交換を行えるようにすることが望ましい。
【０００５】
貸金業者等が信用情報の調査のために使用する従来の技術として、例えば特許文献１には、クレジットカードの発行等の個人に対する信用供与の可否を決定するための個人識別システムが開示されている。これによると、本人識別のための照会キーを用いて、本人情報、類似情報、参考情報の照会回答をそれぞれ作成し、３つの照会回答を一画面内に階層表示するようにしている。
【特許文献１】特開２００２−２４５３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来、クレジット業者、信販業者、消費者金融業者等の貸金業者は、各業者個別に信用情報機関に加入し、個人信用情報の照会や貸金契約の登録、更新手続を行っていた。また、従来は信用情報機関の利用は任意であったため、情報機関に加盟しない業者も存在した。総量規制の施行後、各貸金業者は、一つまたは複数の信用情報機関のサーバと接続する自社システムを構築する必要がある。これは、貸金業者にとって多大なコストと手間の負担となる。特に、契約情報の報告や個人信用情報の更新を翌日までに信用情報機関に報告することは、貸金業者にとってかなり重い負担となると予想される。
【０００７】
本発明はこうした状況に鑑みてなされたものであり、その目的は、貸金業者の操作端末および指定信用情報機関のサーバの間に配置され、貸金業者からの契約情報の報告や信用情報の更新を代理して実行する信用情報機関への仲介技術を提供することにある。
【課題を解決するための手段】
【０００８】
本発明のある態様は、信用情報機関仲介装置である。この装置は、貸金業者によって操作される複数のコンピュータ端末と、契約者の信用情報を管理する信用情報機関によって運営されるサーバとに接続される装置であって、コンピュータ端末を通じて入力される、顧客の貸金契約に係るデータを照会するクエリを受け取るクエリ取得部と、クエリに基づき、信用情報機関のサーバが要求するフォーマットでデータ照会用のファイルを作成する照会ファイル作成部と、作成された照会ファイルをサーバに送信する送信部と、照会ファイルにしたがってサーバから回答された貸金契約の照会結果ファイルを受け取る照会結果受領部と、前記結果ファイルに含まれる貸金契約の中から、同一人物が異なる貸金業者との間で締結した貸金契約、または婚姻関係にある人物同士がそれぞれ貸金業者との間で締結した貸金契約を選び出して名寄せ候補として特定する名寄せ候補特定部と、を備える。
【０００９】
この態様によると、複数の信用情報機関からの照会結果ファイルに含まれる契約情報を情報機関仲介装置において名寄せすることで、名目上は異なる貸金契約であるが、貸金業者の立場からは実質的に一つの貸金契約とみなして対応すべきである契約を発見することができる。
【００１０】
名寄せ候補として特定された貸金契約に係る借入残高を積算し、契約者毎に予め定められている借入上限値と比較する総量規制判定部をさらに備えてもよい。これによって、貸金業者が総量規制の上限額を超える不適当な貸金契約を締結するリスクを軽減することができる。
【００１１】
名寄せ候補特定部は、照会結果ファイルに含まれる貸金契約の中から、同一人物の同一の貸金契約が重複して登録されているものを特定し、総量規制判定部は、特定された貸金契約を一件の貸金契約とみなした上で、契約者毎に予め定められている借入上限値と比較してもよい。これによると、複数の信用情報機関にまたがって登録されている同一の貸金契約をダブルカウントして借入残高が実際より多く算出される事態を回避できるので、貸金業者の貸し付け機会の損失を予防できる。
【００１２】
なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１３】
本発明によれば、複数の信用情報機関からの照会結果を情報機関仲介装置において名寄せすることで、名目上は異なる貸金契約であるが、貸金業者の立場からは実質的に一つの貸金契約とみなして対応すべきである契約を発見することができる。
【発明を実施するための最良の形態】
【００１４】
図１は、本発明の一実施形態に係る信用情報管理システム１００の全体概要図である。この信用情報管理システム１００は、複数の貸金業者および信用情報機関の間で、貸金契約の契約者の身元、過去の取引履歴、返済能力等に関する情報、いわゆる信用情報を共有するためのシステムである。
【００１５】
信用情報機関は、会員である貸金業者から貸金契約の契約者の信用情報を受け取り整備し、会員間で信用情報を共有せしめることによって正確な融資審査に役立てることを目的として設立された機関である。本実施形態では、指定信用情報機関としてＤおよびＥの二機関が存在するものとして説明する。現実にも、機関設立の経緯や会員企業の業種、取り扱う契約の種類等が異なる複数の信用情報機関が併存している。各信用情報機関はそれぞれサーバ１４ｄ、１４ｅを運営し、会員である貸金業者からの貸金契約情報の登録や顧客の信用情報の照会を処理する。
【００１６】
貸金業者Ａ〜Ｃは、貸金業法の規制対象となる貸金業者である。各業者は一つまたは複数の店舗を有し、各店舗が典型的にはパーソナルコンピュータである操作端末１２ａ〜１２ｃを備えている。各操作端末は、キーボードやマウス等の入力装置、ディスプレイ等の出力装置、ネットワークへの接続機能を有している。操作端末１２ａ〜１２ｃは業者毎の基幹システム１２１ａ〜１２１ｃの管理下にあり、操作端末１２ａ〜１２ｃからの貸金契約情報の登録や顧客の信用情報の照会は、各基幹システム１２１ａ〜１２１ｃに一旦蓄積される。
【００１７】
一般に、貸金業者は、幅広く信用情報を収集するため複数の信用情報機関と契約を結んでいることが多く、各信用情報機関の運営するサーバとの間で別個に貸金契約情報の登録、信用情報の更新、照会を行っている。また、報告または照会の際に要求するフォーマットは、信用情報機関毎に異なっているのが通例である。そのため、貸金業者は、日々発生する新たな契約の設定や契約の更新のたびに、複数の信用情報機関向けに報告用または照会用のファイルを作成しなければならず、時間と費用の負荷が大きい。
【００１８】
そこで、本実施形態では、信用情報機関サーバと各貸金業者の基幹システムとの間に、契約情報の報告や信用情報の照会を代理する情報機関仲介装置１０を配置するようにした。
【００１９】
情報機関仲介装置１０は、インターネット、ＬＡＮ（Local Area Network）等のネットワークを介してまたは専用回線で各業者の基幹システム１２１ａ〜１２１ｃと接続される。また、情報機関仲介装置１０は、各信用情報機関のサーバ１４ｄ、１４ｅともネットワークを介するか専用回線で接続される。情報機関仲介装置１０は、それぞれ異なる機能を有する二つのユニットからなる。報告ユニット２０は、貸金業者において貸金契約の設定や信用情報の更新等が行われたとき、信用情報機関のサーバ１４にその旨を報告するための報告ファイルを作成し、サーバ１４に送信する。照会ユニット４０は、貸金業者において契約の設定や更新を行う際に顧客の信用情報を信用情報機関のサーバ１４に問い合わせるための照会ファイルを作成し、サーバ１４に送信する。この際、情報機関仲介装置１０は、各貸金業者固有のフォーマットで送信される報告または照会用のファイルを、信用情報機関のサーバ１４が要求する所定のフォーマットのファイルに変換した上で送信する。つまり、情報機関仲介装置１０は、各貸金業者が採用しているシステムの仕様の違いを吸収する役割を有している。
【００２０】
また、情報機関仲介装置１０は、フォーマットのチェックや貸金契約情報の一時蓄積といった機能も有しており、信用情報機関のサーバとの接続に伴う貸金業者側の基幹システムの改変を軽減する役割も有している。情報機関仲介装置１０の機能については、図２を参照してさらに後述する。
【００２１】
なお、各業者の基幹システム１２１ａ〜１２１ｃを経由せずに、操作端末１２ａ〜１２ｃから直接、情報機関仲介装置１０に対して貸金契約情報の登録や顧客の信用情報の照会が行われてもよい。
【００２２】
図２は、情報機関仲介装置１０の詳細な構成を示す機能ブロック図である。これらの構成は、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子で実現でき、ソフトウェア的には以下で述べる機能を有しメモリにロードされるコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックとして描いている。したがって、これらの機能ブロックはハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００２３】
最初に、報告ユニット２０内の各ブロックについて説明する。
ファイル取込部２２は、各貸金業者の基幹システム１２１に蓄積されている、信用情報機関に貸金契約内容を報告するための契約情報ファイルを取り込む。この取り込みは、各基幹システムに蓄積された契約情報ファイルを定期的に一括して取り込むバッチ処理で実行されることが好ましいが、操作端末で契約情報ファイルが作成され基幹システムに蓄積される都度取り込みを行ってもよい。後述するように、各操作端末から基幹システムを介して送信される契約情報ファイルは、貸金業者の採用するシステム固有の仕様に基づく業者仕様フォーマットと、情報機関仲介装置１０の標準仕様である共通フォーマットのいずれかであってよい。ファイル取込部２２は、業者仕様フォーマットの契約情報ファイルを受け取ると、共通フォーマットに変換する機能も有している。この機能については、図４を参照して後述する。
【００２４】
契約情報ファイルは、顧客との新規の貸金契約時、契約更新時、信用情報の変更時等に作成されるファイルであり、顧客の身元情報や借入残高等のデータ項目が含まれる。契約情報ファイルはさらに、報告区分を表すデータを含んでもよい。報告区分とは、その契約情報ファイルが新規データの追加、既存データの訂正または削除のいずれに当たるのかを記述するものである。
【００２５】
登録済データ保持部３４は、信用情報機関のサーバ１４に登録された顧客の契約情報のコピーを保持している。この保持されている契約情報を、以下では「契約情報マスタ」と呼ぶ。
【００２６】
登録・更新判定部２４は、貸金業者の基幹システム１２１から送信された契約情報ファイルを元に契約情報マスタを登録または更新する。登録・更新判定部２４は、契約者の氏名を元に、契約情報ファイルに対応する記録をマスタから検索する。契約情報ファイルに対応する記録がマスタに存在すればその記録を更新し、対応する記録がなければ契約情報マスタに新規登録する。なお、この判断を上述の報告区分にしたがって実施してもよい。契約情報マスタは、貸金業者別に準備されている。
【００２７】
延滞判定部２６は、契約情報ファイルに基づき貸金契約に延滞があったか否かを判定する。延滞判定部２６における処理は、図８および図９のフローチャートを参照して詳細に説明する。
【００２８】
続いて、報告ファイル作成部３０は、受け取った契約情報ファイルがいずれの信用情報機関に向けての報告であるかを判定し、各信用情報機関の要求するデータ項目からなる報告ファイルを共通フォーマットから作成する。この処理については、図５を参照して後述する。報告ファイル作成部３０は、各信用情報機関の規定に合わせて、商品コードや契約区分等の違いの変換や、文字コードの変換等も実行する。作成された報告用ファイルは、送信タイミング判定部３２に送られる。
【００２９】
送信タイミング判定部３２は、作成された送信用ファイルをあて先の信用情報機関毎に一時的に保持し、各信用情報機関のサーバ１４に送信するタイミングを判定する。これは、バッチ処理による契約情報ファイルの受信時刻と、各サーバでの受領可能時間との差を吸収するために実施される。送信タイミング判定部３２は、所望のタイミングになると、それまでに蓄積していた報告ファイルを送信部３３を介して各信用情報機関のサーバ１４に一斉送信する。転送タイミングは、以下のいずれかの条件で判定することができる。すなわち、１．一時保持している報告ファイルの件数が所定件数に到達したとき、２．同一の契約者に関する報告ファイルが所定件数に到達したとき、３．所定の時刻になったとき。
【００３０】
登録結果受領部３６は、各信用情報機関のサーバ１４から、報告ファイルの登録が完了したことを通知する登録結果ファイルを受信し、登録結果が正常であるかエラーであるかを確認する。登録結果が正常であった場合、登録結果ファイルには正常に登録された旨を示すメッセージが記載されている。登録結果受領部３６は、登録済データ保持部３４内の契約情報マスタの契約ステータスを「仕掛中」から「報告済」に変更するとともに、信用情報機関に対して報告した事項を登録結果ファイルに付加した上で、貸金業者の基幹システム１２１を介して報告ファイルの送信元である操作端末１２に送信する。登録結果がエラーであった場合、登録結果ファイルには登録に失敗した旨を示すメッセージとともに、信用情報機関に報告した事項が記載される。登録結果受領部３６は、この登録結果ファイルを貸金業者の基幹システム１２１を介して報告ファイルの送信元である操作端末１２に送信する。
【００３１】
強制修正判定部３８は、契約情報ファイルの送信によらず、信用情報機関に記録されている契約情報の内容を強制的に修正する指示を貸金業者の基幹システム１２１を介して操作端末１２から受け取る。報告ファイル作成部３０は、これに対応した報告ファイルを作成する。
【００３２】
続いて、照会ユニット４０内の各ブロックについて説明する。
クエリ取得部４２は、各貸金業者の基幹システム１２１に蓄積されている、信用情報機関に対して顧客の信用情報を照会するクエリを取得する。このとき、複数の信用情報機関に対するクエリを同時に取得しても別個に取得してもよい。クエリには、照会対象の人物の氏名、生年月日、電話番号、住所等が含まれる。
【００３３】
照会検索部４４は、クエリを信用情報機関のサーバ１４に渡すか、または情報機関仲介装置１０内部で処理するか否かを判定する。例えば、異なる貸金業者の複数の操作端末から同一の顧客に対するクエリが短期間に連続して発せられる場合がある。このようなときに、仲介装置に保持されているデータに基づき回答できるのであれば、信用情報機関に問い合わせず内部で処理して基幹システムを介して操作端末に返す。これによって、回答時間の短縮、および信用情報機関への接続料の低減につながる。
【００３４】
照会検索部４４は、照会結果保持部５２を参照し、クエリで照会された人物に対する照会結果ファイルが存在するかを確認する。照会結果ファイルが存在する場合、その記録日時を参照する。記録日時が所定の有効期間内の場合、例えばクエリを受け取った時から２４時間前以内の場合、信用情報機関のサーバ１４にクエリを渡すことなく、照会折返し部４６が照会結果保持部５２内の照会結果ファイルを基幹システム１２１を介して操作端末１２に送る。記録日時がクエリの受領時から２４時間前以上であった場合、または照会結果保持部５２内に照会結果ファイルが存在しない場合には、照会検索部４４はクエリを信用情報機関のサーバ１４に送ると判定し、そのクエリを照会ファイル作成部４８に渡す。なお、上述の有効期間は、例えば貸金業者毎に異なる値に設定可能である。
【００３５】
照会検索部４４は、クエリのデータ項目と照会結果ファイルのデータ項目（例えば、氏名、生年月日、電話番号）のうち一つまたは複数が一致する場合、同一の人物と判定する。
【００３６】
照会結果保持部５２は、過去に信用情報機関のサーバ１４から情報機関仲介装置１０に送られた照会に対する回答を保持する。この回答は所定の期間、照会結果保持部５２に保持される。この期間は、上述の有効期間と一致させてもよい。
【００３７】
照会ファイル作成部４８は、操作端末１２から送られたクエリを、各信用情報機関のサーバが要求する所定のフォーマットを有する照会ファイルに変換する。この変換の仕組は、報告ファイル作成部３０と同様である。
【００３８】
順序判定部５０は、複数の照会ファイルを一時的に保持する。そして、照会ファイルの優先順序を判定し、その順序にしたがって、送信部５３を介して信用情報機関のサーバ１４に照会ファイルを発信する。一例として、順序判定部５０は、リアルタイム照会をバッチ照会よりも優先させる。リアルタイム照会とは、貸金業者の操作端末１２から随時行われる照会であり、バッチ照会とは、操作端末１２から所定の間隔で定期的に行われる大量の照会である。こうすることで、操作端末からのリアルタイム照会に対する回答の遅延を防止することができる。順序判定部５０は、他の基準にしたがって照会ファイルの優先順序を判定してもよい。例えば、特定の貸金業者に係る照会ファイルを他の業者に優先させてもよいし、特定の信用情報機関に対する照会ファイルを優先させてもよい。
【００３９】
照会結果受領部５４は、照会ファイルに対する信用情報機関のサーバ１４からの照会結果ファイルを受信する。この回答には、信用情報の調査対象である人物の貸金契約に関する情報が含まれる。具体的には、後述する図３の共通フォーマットのデータ８２に示す各データ項目が含まれている。
【００４０】
名寄せ部５５は、複数の信用情報機関から得られた照会結果ファイルに含まれる貸金契約を、名寄せすべき契約と名寄せすべきでない契約とに分類し、照会結果ファイルに分類結果を追加する。照会結果ファイルは、照会結果保持部５２に記録されるとともに、貸金業者の基幹システム１２１を介して操作端末１２に送られる。名寄せ部５５の動作については、図６を参照して後述する。
【００４１】
図３は、契約情報ファイルの業者仕様フォーマットに含まれるデータ８０と、共通フォーマットに含まれるデータ８２とを示す。「本人情報」には、契約者の氏名、住所、電話番号等の人物を特定する情報が含まれる。「契約情報」には、契約の種類、契約日、返済期日等の貸金契約に関する情報、および報告先の信用情報機関名が含まれる。「残高情報」には、借入残高、借入上限額の情報等が含まれる。「配偶者情報」には、契約者の配偶者の氏名等が含まれる。「連帯保証人情報」には、連帯保証人の氏名、住所、電話番号等が含まれる。「入金履歴情報」には、入金予定日、入金日等の入金履歴と、入金ステータスが含まれる。なお、入金ステータスは、「正常」「延滞中」「延滞解消」の３つの状態を表すフラグである。「異動情報」は、民事再生法や破産法による免責決定の有無等の情報である。「業者固有領域」は、各業者で固有の判定に使用するデータのうち、上記項目には含まれないデータが格納される領域である。
【００４２】
上述したように、業者仕様フォーマットは貸金業者システム固有のものであるから、各データ項目の順序や項目の分け方は貸金業者毎に異なる。この違いを吸収するために、情報機関仲介装置１０内では共通フォーマットで契約情報ファイルを処理する。共通フォーマットには、業者仕様フォーマットのデータ８０のうち業者固有情報以外のデータ項目が含まれる。
【００４３】
図４は、ファイル取込部２２の詳細な機能を説明する図である。ファイル取込部２２では、各貸金業者の基幹システム１２１ａ〜１２１ｃから業者仕様フォーマットの契約情報ファイルを取り込み、貸金業者毎に異なる業者仕様フォーマットを共通フォーマットに変換する機能を有する。
【００４４】
ファイル取込部２２は、ファイル振り分け部２３およびフォーマット変換部２５を含む。フォーマット変換部２５は、情報機関仲介装置１０に接続される各貸金業者の基幹システムで採用されている契約情報ファイルのフォーマット６０ａ、６０ｂを、共通フォーマット７０に変換する変換モジュール２５ａ、２５ｂを備える。この変換モジュールは、貸金業者毎に準備される。ファイル振り分け部２３は、各貸金業者の基幹システム１２１ａ〜１２１ｃから取り込んだ契約情報ファイルが業者仕様フォーマットであるか共通フォーマットであるかを判定する。図４に示すように、ファイル振り分け部２３は、基幹システム１２１ａから取り込んだ業者仕様フォーマット６０ａ、および基幹システム１２１ｂから取り込んだ業者仕様フォーマット６０ｂを、それぞれ各貸金業者に対応する変換モジュール２５ａ、２５ｂに渡す。フォーマット変換部２５は、各変換モジュールで変換された共通フォーマット７０を後続の登録・更新判定部２４に渡す。
【００４５】
契約情報ファイルは、操作端末から基幹システムを介して共通フォーマットで送信することも許容されている。したがって、例えば基幹システム１２１ｃから契約情報ファイルの共通フォーマット７０を取り込んだ場合、ファイル振り分け部２３は、この共通フォーマットに何の処理も施さずにそのまま後続の登録・更新判定部２４に渡す。
【００４６】
フォーマット変換部２５によって、業者使用フォーマットは共通フォーマットに変換される。この際、業者使用フォーマットに含まれるデータ項目のうち共通フォーマットに存在しない項目は削除される。また、共通フォーマットに含まれるが業者使用フォーマットに含まれないデータ項目については、ブランクにセットされる。ブランクにセットする代わりに、フォーマット変換部２５は、登録済データ保持部３４の契約情報マスタの中から同一の契約者に対する情報を検索し、欠落部分に対応するデータ項目を探して共通フォーマットに入力するようにしてもよい。
【００４７】
このように、貸金業者毎に異なるフォーマットを共通フォーマットに変換する変換モジュールをファイル取込部２２に備えることで、各貸金業者は共通フォーマットを作成する機能を自社システムに持たせる必要がなくなる。また、変換モジュールを各業者毎に分けて準備することで、情報機関仲介装置に新たな貸金業者の基幹システムを接続する際に、その業者対応の変換モジュールをフォーマット変換部２５に追加するだけで対応することができる。さらに、ファイル振り分け部２３を設け共通フォーマットについては処理しないようにすることで、業者仕様フォーマットと共通フォーマットが混在して取り込まれても処理可能になる。
【００４８】
図５は、報告ファイル作成部３０の詳細な機能を説明する図である。報告ファイル作成部３０は、共通フォーマットの契約情報ファイルを、各信用情報機関の要求する形式のファイルに変換する。
【００４９】
報告ファイル作成部３０は、報告先判定部２８と、各信用情報機関に対応した編集モジュール３１ｄ、３１ｅを含む。報告先判定部２８は、契約情報ファイルの報告先を特定し、対応する信用情報機関の編集モジュール３１ｄ、３１ｅに渡す。編集モジュール３１ｄ、３１ｅは、共通フォーマットの契約情報ファイルを各信用情報機関が要求する形式に変換する。例えば、Ｄ信用情報機関では、契約情報ファイルを単一の報告ファイルの形で要求する一方、Ｅ信用情報機関は、契約情報ファイルのデータ項目うち残高に関する情報のみを一つのファイルで要求し、残りのデータ項目を別のファイルの形で要求するとする。この場合、Ｄ機関用編集モジュール３１ｄは共通フォーマットからＤ機関用の単一の報告ファイル７２を作成し、Ｅ機関用編集モジュール３１ｅは、Ｅ機関用の残高ファイル７６とそれ以外の契約内容ファイル７４を作成する。
【００５０】
このように、共通フォーマットの契約情報ファイルを信用情報機関毎に異なる形式に変換する編集モジュールを報告ファイル作成部３０に備えることで、複数の信用情報機関に対し報告ファイルを作成することができる。また、編集モジュールを信用情報機関毎に分けて準備することで、情報機関仲介装置に新たな信用情報機関のサーバを接続する際に、その信用情報機関対応の編集モジュールを報告ファイル作成部３０に追加するだけで対応することができる。
【００５１】
図６は、名寄せ部５５の構成を示す。名寄せ候補特定部５６は、複数の信用情報機関のサーバ１４から送られてきた照会結果ファイルを参照して、借入残高を積算すべき貸金契約を特定する。ここで、「借入残高を積算すべき貸金契約」には、以下の場合が含まれる。
１．ある人物の貸金契約とその配偶者の貸金契約とが別々に信用情報機関に登録されている場合。貸金業法の総量規制では、同一世帯で生計をともにしている人物の借入残高は積算して対応する必要がある。そこで、名寄せ候補特定部５６は、照会結果ファイルに含まれる貸金契約に対して配偶者情報をキーとして検索を実行し、婚姻関係にある人物同士の貸金契約を名寄せ候補として特定する。
２．同一人物が異なる貸金業者（例えば、貸金業者Ａと貸金業者Ｂ）との間で結んだ貸金契約が複数の信用情報機関に別々に登録されている場合。この場合も、総量規制に対応するためにその人物の借入残高を積算する必要がある。名寄せ候補特定部５６は、照会結果ファイルに含まれる貸金契約の中から、氏名、生年月日、電話番号等の複数のデータ項目のうち所定数以上の項目が一致するものを選び出し、それらを名寄せ候補として特定する。
名寄せ候補特定部５６は、借入残高を積算すべき貸金契約として特定された貸金契約を区別できるように、メッセージまたはマーク等の名寄せ情報を照会結果ファイルに追加する。
【００５２】
名寄せ候補特定部５６は、さらに、サーバ１４から送られてきた照会結果ファイルの中から、同一人物の同一の貸金契約が誤って重複登録されているものを特定することが好ましい。複数の信用情報機関にまたがって登録された同一の貸金契約をダブルカウントしてしまうと、借入残高が実際より多く算出されるので、貸金業者にとっては貸し付けの機会損失が発生するおそれがある。そこで、名寄せ候補特定部５６は、照会結果ファイルに含まれる貸金契約の中から、氏名、生年月日、電話番号、契約日時、借入残高等の複数のデータ項目のうち所定数以上の項目が一致しており、同一人物の同一の貸金契約と推定されるものを選び出す。
名寄せ候補特定部５６は、同一の貸金契約として特定された貸金契約を区別できるように、メッセージまたはマーク等の名寄せ情報を照会結果ファイルに追加する。
【００５３】
総量規制判定部５８は、照会結果ファイルに含まれる各貸金契約の借入残高が、貸金業法の総量規制で定められる借入上限額以下になっているか否かを判定する。名寄せ候補特定部５６によって何の注釈情報も付けられていない貸金契約については、借入残高と借入上限額とを直接比較する。総量規制判定部５８は、名寄せ候補特定部５６によって借入残高を積算すべき貸金契約と特定された貸金契約については、それらの借入残高を積算した上で、借入上限額と比較する。さらに、名寄せ候補特定部５６によって同一人物の同一の貸金契約として特定されたものについては、それらを実質的に一件の貸金契約とみなした上で、借入上限額と比較する。そして、総量規制判定部５８は、上記比較の結果、借入残高が上限額を上回っている場合には、総量規制違反であることを示すメッセージまたはマーク等の注意喚起情報を照会結果ファイルに追加する。
【００５４】
なお、借入上限額は、契約者の収入、資産、勤務年数、職業等に応じて所定の計算式にしたがって契約者毎に予め決定されている。総量規制判定部５８は、契約者毎に信用情報機関サーバ１４に記録されている借入上限額を取得してもよいし、貸金業者の基幹システム１２１に記録されている借入上限額を取得してもよい。別の例では、総量規制判定部５８が照会結果ファイルに含まれている契約情報を参照して、独自に借入上限額を決定してもよい。
また、上述のように、婚姻関係にある人物同士がそれぞれ貸金契約を結んでおり借入残高を積算した場合の借入上限額は、収入の多い方の契約者について設定されている借入上限額を用いてもよいし、両者の借入上限額の合計を用いてもよい。
【００５５】
このように、複数の信用情報機関からの照会結果ファイルに含まれる契約情報を情報機関仲介装置において名寄せすることで、名目上は異なる貸金契約であるが、貸金業者の立場からは実質的に一つの貸金契約とみなして対応すべきである重複契約を発見し、総量規制の上限額を超える不適当な貸金契約を締結するリスクを軽減することができる。
【００５６】
図７は、情報機関仲介装置１０の報告ユニット２０の動作を説明するフローチャートである。まず、ファイル取込部２２は、各貸金業者の基幹システムから契約情報ファイルを一括して取り込む（Ｓ１０）。登録・更新判定部２４は、契約情報ファイルの内容が新規登録なのかまたは既存契約情報の更新なのかを判定し、契約情報マスタにデータを作成または更新する（Ｓ１２）。延滞判定部２６は、契約情報ファイルの内容に基づき、入金ステータスに変更があるか否かを判定する。変更があった場合には契約情報マスタのステータスを変更する（Ｓ１４）。報告ファイル作成部３０は、契約情報ファイルから各信用情報機関への報告ファイルを作成する（Ｓ１６）。送信タイミング判定部３２は、各信用情報機関のサーバ１４におけるファイル受領タイミングに合わせて、報告ファイルを送信する（Ｓ１８）。登録結果受領部３６は、信用情報機関のサーバ１４から信用情報の登録結果を受け取り、その内容を登録済データ保持部３４に記録し（Ｓ２０）、さらに登録が完了した旨のメッセージを貸金業者の基幹システムを介して操作端末１２に送信する（Ｓ２２）。
【００５７】
図８は、情報機関仲介装置１０の照会ユニット４０の動作を説明するフローチャートである。まず、クエリ取得部４２が、各貸金業者の基幹システム１２１から照会クエリを受け取る（Ｓ３０）。照会検索部４４は、受け取ったクエリを照会結果保持部５２内の照会結果ファイルと比較し、同一の人物に対する有効期限内の照会結果ファイルが存在しないか否かを確認する（Ｓ３２）。照会結果ファイルが存在する場合は、照会折返し部４６がその結果を貸金業者の操作端末１２に送る。続いて、照会ファイル作成部４８は、クエリから照会先の信用情報機関に対応する形式の照会ファイルを作成する（Ｓ３４）。順序判定部５０は、複数の照会ファイルが存在する場合に、照会ファイルを適切な順序で信用情報機関のサーバ１４に送信する（Ｓ３６）。照会結果受領部５４は、クエリに対する照会結果ファイルを受領する（Ｓ３８）。名寄せ部５５は、各信用情報機関からの照会結果ファイルの名寄せを実行したうえで、照会結果ファイルを貸金業者の基幹システムを介して操作端末１２に送信する（Ｓ４０）。
【００５８】
図９は、延滞判定部２６における延滞判定を説明するフローチャートである。延滞判定部２６は、契約情報ファイル内の入金予定日と借入残高を確認する（Ｓ５０）。さらに、契約情報ファイル内の異動情報を参照する（Ｓ５２）。この異動情報には、破産免責の結果や民事再生の状況についての結果が含まれる。続いて、延滞判定部２６は、次式が成り立つか判定する。
入金予定日＋Ｎ＜処理日      （１）
ここで、処理日とは延滞判定をしている日であり、Ｎは延滞と判定するまでの猶予期間（例えば３ヶ月）である。この猶予期間は貸金業者によって異なる期間であってよく、延滞判定部２６は、契約情報ファイルの送信者である貸金業者に応じて所定の期間を使用する。式（１）が不成立の場合（Ｓ５４のＮ）、このフローを終了する。
【００５９】
式（１）が成立する場合（Ｓ５４のＹ）、延滞判定部２６は、借入残高が所定の金額、例えば１０００円を超えるか否かを判定する（Ｓ５６）。１０００円を超える場合（Ｓ５６のＹ）、延滞判定部２６は、異動情報に基づき免責許可となっていないか否かを判定する（Ｓ５８）。免責許可となっていない場合（Ｓ５８のＮ）、延滞判定部２６は延滞が発生したと判定し（Ｓ６０）、契約情報ファイルおよび契約情報マスタの入金ステータスを「延滞」にセットする（Ｓ６２）。借入残高が１０００円以下の場合（Ｓ５６のＮ）、および免責許可となっている場合（Ｓ５８のＹ）、このフローを終了する。
【００６０】
図１０は、延滞判定部２６における延滞解消判定を説明するフローチャートである。延滞判定部２６は、契約情報ファイル内の入金日、入金ステータス、および異動情報を確認する（Ｓ７０）。そして、入金ステータスが「延滞」になっているか否かを判定する（Ｓ７２）。「延滞」となっていない場合（Ｓ７２のＮ）、このフローを終了する。「延滞」となっている場合（Ｓ７２のＹ）、延滞判定部２６は入金日がブランクであるか否かを判定する（Ｓ７４）。入金日に入力がある場合（Ｓ７４のＮ）、さらに異動情報に基づき免責許可となっていないかを確認する（Ｓ７６）。免責許可でない場合（Ｓ７６のＮ）、延滞判定部２６は延滞が解消したと判定し（Ｓ７８）、契約情報ファイルおよび契約情報マスタの入金ステータスを「延滞解消」にセットする（Ｓ８０）。入金日がブランクである場合（Ｓ７４のＹ）、または免責許可となっている場合（Ｓ７６のＹ）、このフローを終了する。
【００６１】
以上説明したように、本実施形態によれば、貸金業者からの契約情報の報告や信用情報の更新を代理して実行する信用情報機関への仲介装置を、貸金業者の基幹システムと信用情報機関のサーバとの間に配置するようにした。これによって、貸金業者が自社システムを信用情報機関のサーバに接続させるためのシステム構築負担を軽減することができる。
【００６２】
また、貸金業者の操作端末１２から顧客の信用情報を要求するクエリを受け取ると、照会検索部が、信用情報機関のサーバに送信する前に、情報機関仲介装置内に同一の人物に対する照会結果ファイルが存在しないかを確認するようにした。これにより、同一人物の照会結果ファイルが存在する場合には、操作端末への回答時間を短縮でき、また信用情報機関への接続料を節約することができる。また、照会検索部は、上記照会結果ファイルの記録日時が所定の有効期間内であるかを確認するので、鮮度が重要である信用情報を、古い記録に基づき貸金業者の操作端末に回答することを回避できる。
【００６３】
また、順序判定部が、一時蓄積された複数の照会ファイルのうち、いずれを優先して信用情報機関のサーバに送信するかを判定するようにした。例えば、時間的に余裕のある照会よりもリアルタイムの照会を優先させてサーバに送信することで、リアルタイム照会に対する回答の遅延を防止することができる。
【００６４】
以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６５】
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００６６】
実施の形態では、各貸金業者の基幹システムが情報機関仲介装置と接続される構成について説明したが、本発明は、各貸金業者の操作端末が情報機関仲介装置と直接接続される構成についても適用可能である。この場合、ファイル取込部またはクエリ取得部は、各貸金業者の操作端末から直接、契約情報ファイルまたは照会クエリを受け取るように構成される。また、登録結果受領部または照会結果受領部は、各貸金業者の操作端末に対して直接、登録結果ファイルまたは照会結果ファイルを送信するように構成される。
【図面の簡単な説明】
【００６７】
【図１】本発明の一実施形態に係る信用情報管理システムの全体概要図である。
【図２】図１の情報機関仲介装置の詳細な構成を示す機能ブロック図である。
【図３】契約情報ファイルのうち業者使用フォーマットに含まれるデータと、共通フォーマットに含まれるデータとを示す図である。
【図４】ファイル取込部の詳細な機能を説明する図である。
【図５】報告ファイル作成部の詳細な機能を説明する図である。
【図６】名寄せ部の構成を示す図である。
【図７】情報機関仲介装置の報告ユニットの動作を説明するフローチャートである。
【図８】情報機関仲介装置の照会ユニットの動作を説明するフローチャートである。
【図９】延滞判定部における延滞判定を説明するフローチャートである。
【図１０】延滞判定部における延滞解消判定を説明するフローチャートである。
【符号の説明】
【００６８】
１０  情報機関仲介装置、  １２  操作端末、  １４  サーバ、  ２０  報告ユニット、  ２２  ファイル取込部、  ２３  ファイル振り分け部、  ２４  登録・更新判定部、  ２５  フォーマット変換部、  ２６  延滞判定部、  ２８  報告先判定部、  ３０  報告ファイル作成部、  ３１  編集モジュール、  ３２  送信タイミング判定部、  ３４  登録済データ保持部、  ３６  登録結果受領部、  ３８  強制修正判定部、  ４０  照会ユニット、  ４２  クエリ取得部、  ４４  照会検索部、  ４６  照会折返し部、  ４８  照会ファイル作成部、  ５０  順序判定部、  ５２  照会結果保持部、  ５４  照会結果受領部、  ５５  名寄せ部、  ５６  名寄せ候補特定部、  ５８  総量規制判定部、  ６０  業者仕様フォーマット、  ７０  共通フォーマット、  ７２  報告ファイル、  ７４  契約内容ファイル、  ７６  残高ファイル、  １００  信用情報管理システム。
【図１】
2009301236.tif 000003
【図２】
2009301236.tif 000004
【図３】
2009301236.tif 000005
【図４】
2009301236.tif 000006
【図５】
2009301236.tif 000007
【図６】
2009301236.tif 000008
【図７】
2009301236.tif 000009
【図８】
2009301236.tif 000010
【図９】
2009301236.tif 000011
【図１０】
2009301236.tif 000012