JP6839780B2 - 法人番号管理情報マップの生成方法およびそれを使用した法人評価方法 - Google Patents

Description

本発明は、法人番号管理情報マップの生成方法およびそれを使用した法人評価方法に関するものであり、特に、資産背景および商流把握の精緻化の観点から小規模の法人（小規模事業者）を評価するための情報処理装置、システムや方法に関するものである。

法人を評価するシステムは、従来から提案されてきた。しかしながら、従来のシステムにおいては、法人単体の計数資料（貸借対照表、損益計算書、預金残高・融資残高、ヒアリング情報等）に基づいて評価することに主眼をおいており、それ以外の要素に基づいて多面的に評価することまでは考慮されてこなかった。

また、小規模事業者である法人（中小企業等）の財務等を評価することは大企業、上場企業等に比べて一般的には難しいとされている。これは、社内外の監査が厳しい大企業、上場企業等とは違って、計数資料の内容が必ずしも事業の実態を十分に表していない（小規模事象者にとっての計数資料は法人税法等に基づく報告のためのものであり、事業実態と乖離している）場合が現実的には多々あるからである。すなわち、小規模事象者の計数資料には、小規模法人を評価するための情報が少ないまたは皆無だからである。

別の見方をすれば、情報開示が少ない小規模法人を適切に評価するための手法が確立されていないともいえる。そのためには、小規模法人を適切に評価するために情報を整理する方法やシステムについて検討する必要性もあるが、そのために収集すべき情報のひとつとして、評価対象となる法人の代表者の家系情報が考えられる。

法人評価の従来の一例として、特許文献１がある。特許文献１では、評価対象となる法人の信用度を判定するために、取引先の法人に関する評価情報を用いることが開示されているが、この取引先の法人は、評価できる情報が公開されていることが前提となっているが、評価対象を当該評価対象の法人と関係のある個人や法人（例えば、事業主の家系個人や当該個人が経営する法人）にまで拡張することまでは考慮されていなかった。これは、従来は、拡張された情報を推定して、推定された情報を整理したマップ（一覧）を生成することが困難であったことも一因である。

特開２０１８−１０６５５７号公報（特許６１６６８３４号）

本発明の目的のひとつは、評価の対象となる法人の代表者の情報および関連する情報を推定して、推定された情報を、法人番号で整理したマップを生成するシステムや方法を提供することである。

本発明の別の目的のひとつは、法人番号で整理されたマップの情報を用いて、法人を評価するシステムや方法を提供することである。

法人番号管理情報マップを生成する情報処理装置において、
法人情報と識別番号とを対応付けて格納するデータベースと、
対象法人を選択すると共に、当該対象法人との関係を示す区分を選択する手段と、
前記選択された区分に基づき、判定の際に参照する参照情報を決定する手段と、
前記対象法人の法人番号および識別番号を判定する手段と、
前記対象法人の代表者の識別番号を判定する手段と、
前記参照情報を基に、前記対象法人または前記代表者に関連する個人または法人の識別番号を判定する手段と、
前記対象法人の法人番号をキーとし、前記対象法人の識別番号、前記代表者の識別番号、前記判定された個人または法人の識別番号が、個人または法人の人格と、前記対象法人または前記代表者との関係を示す区分と共に特定された法人番号管理情報マップを生成する手段と、
を備えたことを特徴とする装置。

本発明の一態様によると、評価対象法人の代表者の情報を家系などの特定の観点から整理するためのマップを生成することができるので、評価対象法人を広い視点で評価することができるようになる。

本発明の別の一態様によると、公開情報が少ないまたは皆無の法人であっても、資産背景の観点から最大限の融資を行うことができるようになる。

本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。

本発明の一実施例による法人管理情報マップ生成のための情報処理装置のブロック図を概略的に示す。 本発明の一実施例による法人管理情報マップを生成するための情報処理の一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例によるテーブルの一例を示す。 本発明の一実施例による法人判定の情報処理の一例を示す。 本発明の一実施例による可能な融資を判定するためのテーブルおよびグラフの一例を示す。 本発明の一実施例による法人評価のための情報処理の一例を示す。 本発明の一実施例による商流把握の精緻化による評価高度化の一例を示す。 本発明の一実施例によるＭＣＩＦ共同化システムの概略図を示す。

本発明の一実施例について、図面を参照しながら説明する。

図１は、本発明の一実施例による法人評価をするための情報処理装置１０００のブロック図を概略的に示す。

本実施例の情報処理装置１０００は、画面表示部１１１０、入力部１１２０、顧客番号情報更新部１１３０、顧客番号属性情報取得部１１４０、情報検索生成部１１５０、財務情報生成部１１６０、金融取引判定部１１７０、融資判定部１１８０、金融口座ＤＢ１２１０、顧客番号属性情報ＤＢ１２２０、顧客番号更新情報ＤＢ１２３０、金融取引決済情報ＤＢ１２４０、法人番号管理情報マップＤＢ１２５０、財務情報ＤＢ１２６０、区分参照情報ＤＢ１２７０、法人番号ＤＢ１２８０、自社顧客番号ＤＢ１２９０、地理座標変換ＤＢ１３００、制御部１３１０、インターフェイス部１３２０から構成される。なお、本実施例において、ＤＢは、Ｄａｔａｂａｓｅ（データベース）を意味するが、物理的／仮想的にデータを記憶できる手段であれば、どのような態様の記憶手段でもよい。

画面表示部１１１０は、ユーザ等へ必要な情報をディスプレイなどの表示手段により提示する。

入力部１１２０は、ユーザによって入力されたデータ等を受信して、当該データを必要とする各ユニット（各部）へ送信する。入力部１１２０は、タッチパネルのような画面表示部１１１０の機能を兼ね備えてもよい。

顧客番号属性情報更新部１１３０は、顧客に対して付与されている顧客番号（本実施例においては、顧客の口座）の属性に関する情報（顧客番号属性とも称する）を更新する。

顧客番号属性情報取得部１１４０は、顧客の顧客番号属性を更新して、後述する顧客番号属性情報ＤＢ１２２０に格納する。更新の頻度は、定期的でもよく、何らかの項目が更新されたときでもよい。顧客番号属性の一例については、図４Ｂに示す。

情報検索生成部１１５０は、代表者や家系の口座情報や金融取引データ（為替取引情報など）などの参照情報を基に、例えば、代表者の家系（配偶者、親、子）を検索して、法人番号管理情報マップを生成する。

財務情報生成部１１６０は、計数資料や自社情報資源等から、代表者および当該代表者に関連する個人口座および法人口座の財務情報（例えば、残高）を取得するものである。ここで、財務情報は、現時点の情報だけではなく、ある一定期間の所定の財務情報の推移も取得できるものとする。

金融取引判定部１１７０は、代表者や関連個人／法人などを含め任意の顧客との金融取引を判定する。

融資判定部１１８０は、融資額や金利などを判定する。

金融口座ＤＢ１２１０は、金融口座の情報を格納する。

顧客番号属性情報ＤＢ１２２０は、自社顧客の金融口座の属性（個人の口座の場合は、自社顧客番号などの識別番号、苗字、名前、住所、生年月日、電話番号、性別などの情報）を格納する。個人の口座における自社顧客属性情報の一例については、図４Ｂに示す。また、法人の口座における自社顧客属性情報の一例については、図３Ｂに示す。

顧客番号更新情報ＤＢ１２３０は、顧客番号ごとに、更新された情報を（更新日を基準とした）時系列で格納する。

金融取引決済情報ＤＢ１２４０は、金融口座で取引されたデータを管理する。

法人番号管理情報マップＤＢ１２５０は、例えば、代表者とその家系の関係者（配偶者、親、子）の一覧をテーブル形式で法人番号管理情報として格納する。

財務情報ＤＢ１２６０は、金融口座を有する個人顧客および法人顧客毎の単独の財務情報や、複数の関連する顧客の総合的な財務情報（例えば、対象法人およびその代表者とその家系の関係者（配偶者、親、子）の顧客番号情報から得られる全体的な財務情報）を格納する。

区分参照情報ＤＢ１２７０は、後述する法人番号管理情報マップを生成する際に、ユーザ等が所望する区分に応じて、参照すべき情報の所在に関するデータを格納する。

法人番号ＤＢ１２８０は、法人の名称（または法人を特定する別の番号：例えば、自社顧客番号などの私的な番号）と、当該法人を一意に特定できる番号（法人番号や公的な番号など）を格納する。なお、本実施例において、法人番号ＤＢ１２８０に記憶されている法人番号の情報は、確実性が高い情報として取り扱う。

自社顧客番号ＤＢ１２９０は、自社顧客番号に、法人番号を紐付けて格納する。ここで、自社顧客番号とは、本情報処理装置で管理する番号であり、金融口座を利用する個人または法人毎に割り当てられている番号である。

地理座標変換ＤＢ１３００は、地理的情報の変換情報を格納しており、例えば、住所と緯度経度との関係を格納する。なお、地理座標変換ＤＢ１３００に記憶されている住所は、必ずしも、番地まで記載されたような完全な住所でなくてもよく、例えば、ｘｘ県ｙｙ市のような一部だけの住所でもよい。一部だけの住所の場合は、任意の中心地や役所などの所在地に対応する緯度経度と対応づけて格納しておいてもよい。

制御部１３１０は、情報処理装置１０００内の各部を制御する。１つまたは複数のプロセッサから構成されてもよい。

インターフェイス部１３２０は、ネットワーク５００を介して、外部情報資源３００にアクセスしたりすることなどにより、情報処理装置１０００の内外のデータを送受信する。ここで、ネットワーク５００は、有線や無線などでもよく、汎用回線や専用回線などでもよい。

外部情報資源３０００は、法人番号および当該法人番号に関連するデータベースであり、例えば、国税庁が提供する法人番号公表サイトなどの無料の法人情報に関する情報提供資源でもよく、有料の情報提供資源でもよい。

なお、図１で説明した各部や各ＤＢは、説明の便宜上、個々に示したが、任意に統合分離等してもよい。

図２は、法人番号管理情報マップを生成するための情報処理の一例をＳ１０１０−Ｓ１０６０で示す。

Ｓ１０１０：法人番号管理情報マップを作成するにあたり、その対象となる法人（以下、対象法人）が、ユーザや外部からの信号により、入力手段を介して選択される。更に、法人番号管理情報マップを構成するための区分も選択する。区分が選択されると、その区分に応じた参照情報が取得される。ここで、参照情報とは、後述する個人や法人を特定するために参照すべき情報が記載されている。なお、選択対象となる法人のリストは、本実施例の情報処理装置のデータベースに記憶されている。

Ｓ１０２０：Ｓ１０１０で選択された区分に基づいて、データベースを構成する情報を判定する際に参照する参照情報を決定する。
Ｓ１０３０：対象法人の法人番号および識別番号を判定する。

Ｓ１０４０：対象法人の代表者の識別番号を判定する。

Ｓ１０５０：Ｓ１０２０で判定した参照情報を参照して、対象法人および／または代表者に関連する法人および／または個人の識別番号を判定する。例えば、対象法人の代表者の同一家系個人（すなわち、本実施例においては、妻、子、親のような、代表者から見て一親等にあたる個人を指す。）の識別番号を判定する。更に、同一家系個人が経営等する法人も判定する。

対象法人と関係のある個人と法人を判定する情報処理の一例について説明する。自社顧客については、自社顧客属性情報等を用いて判定してもよい。また、他社顧客の場合は、例えば、金融取引データの振込先または振込元の表記を確認して、株式会社等の法人が想起できる表記が含まれている場合は、法人であると判断すると共に、株式会社等の法人が想起できる表記が含まれていない場合は、個人であると判断するように構成してもよい。別の実施例として、該当する法人番号が検索できたときには、法人であると判断するように構成してもよい。

Ｓ１０６０：Ｓ１０３０−Ｓ１０５０での判定結果を基に、法人番号管理情報マップを生成する。

ここで、本実施例において、Ｓ１０１０で選択された「区分」は、上述した同一家系等を示す「家系」であるとする。検索される家系の口座は、Ｓ１０１０−Ｓ１０４０で示す４種類の情報（法人番号や自社顧客番号などの個人や法人を特定できる情報）である。そして、これら４種類の情報を検索して、これら情報を組み合わせることにより、家系情報マップを生成することができる。

以下、Ｓ１０１０からＳ１０５０の検索の一例について説明する。

Ｓ１０１０：対象法人の検索方法について説明する。

まず、対象法人の検索にあたっての前提は、以下である。検索対象は、自社顧客属性情報等の法人情報を含む自社情報資源（本実施例の情報処理装置内の任意のデータベース等が記憶している情報および／または本実施例の情報処理装置が何らかの手段によって取得可能な情報）に存在する全ての法人である。ここで、自社情報資源に存在する法人とは、自社顧客（法人）だけでなく、自社顧客と取引情報のある他社顧客（法人）も含むものであり、具体的には、図１のＤＢ１２１０等で例示するものである。そして、対象法人に対する法人番号の取得方法は、対象法人が自社顧客か他社顧客か等の条件で異なるところがあるので、以下のケース１から４に分けて、それぞれを説明する。なお、本実施例で説明する特徴的な情報処理を実施するために補完的な情報処理が必要になる場合は、例えば、特許６４８３３１１（特願２０１８−１０７１２４）に記載されたような実施例も参照されたい。

（ケース１）対象法人の法人番号が既知の場合（本発明のシステム内の法人番号ＤＢ１２８０に、対象法人の法人番号が記憶されている場合など）は、本システムが有する自社顧客番号を、既知の法人番号に紐付けて格納する。例えば、図３Ａにおいては、自社顧客番号ＡＡＡを法人番号ａａａａａａａａａａａに紐付けて、自社顧客番号ＤＢ１２９０に記憶する。なお、法人番号ＤＢ１２８０が自社顧客番号を記憶する場合には、法人番号ＤＢ１２８０の内容を、そのまま自社顧客番号ＤＢ１２９０に記憶するように構成されてもよい。

（ケース２）法人番号が未知の場合（本発明のシステム内の法人番号ＤＢ１２８０に、対象法人の法人番号が記憶されていない場合など）は、自社顧客属性情報等の法人情報を含む自社情報資源から法人番号を検索する。例えば、図３Ｂ（ａ）に示されるように、顧客番号属性情報ＤＢ１２２０などに記憶されている自社情報資源の住所と商号により法人番号を検索する。住所は揺らぎ（１丁目、一丁目、丁目省略表記などの数字表記や揺らぎや、建物名などの省略など）が存在するため、住所の記載方法によっては地理的位置の特定を誤る場合がある。そこで、ある程度の正確性を担保するために、最初の揺らぎが発生するところを予め設定した基準として、住所緯度経度の座標情報に変換する。ここで、最初の揺らぎが発生するところとは、例えば、市、区、町などの次の表記である「丁目」などである。ここで、地域によっては「丁目」がない場合や「大字ｘｘｘ」等で表記される場合があるが、その場合は「丁目」以外の任意の区切りを予め設定すればよい。そして、「丁目」を基準する場合、緯度経度の範囲がある程度存在するので、例えば、当該基準と緯度経度との対応関係を示した地理座標変換データベース１３００を予め用意し、そこから対応関係を読み出すように構成されてもよい。最初の揺らぎは、揺らぎの範囲が最小であり、且つ予測可能な範囲で揺らいでいることが多いので、地理的位置を比較的高い精度で特定できる範囲内ともいえる。具体的な情報処理の一例を、以下、図３Ｂを参照しつつ、図５のＳ２０１０−Ｓ２０７０で示す。

Ｓ２０１０では、自社情報資源の住所情報を緯度経度情報に変換する。本実施例においては、図３Ｂ（ａ）に示すように、自社顧客番号ＢＢＢの自社顧客属性情報の住所が「神奈川県横浜市西区みなとみらい３丁目Ｚ−Ｚ」であるが、上述した揺らぎを考慮して、「神奈川県横浜市西区みなとみらい３丁目Ｚ−Ｚ」の番地を省略した「神奈川県横浜市西区みなとみらい３丁目」のみを、地理座標変換データベース１３００に対して問いあわせを行い、対応する緯度経度（経度：３５．４５９度、緯度：１３９．６３度）を得る。ここで、「３丁目」は揺らぎが発生する可能性があるので、問いあわせるデータベースの仕様にあわせて、揺らぎを補正してもよい。例えば、データベース上の「丁目」が漢数字を使用することが仕様になっている場合は、「三丁目」に補正してから、緯度経度変換データベース１３００に問いあわせる。そして、緯度経度データベース１３００は、該当する住所があれば、該当する住所に相当する緯度経度情報を返す。仮に、該当する住所がなければ、ひとつ上位の住所（本実施例では、「神奈川県横浜市西区みなとみらい」）に相当する緯度経度を検索して、相当する緯度経度情報を返してもよい。その際には、一段落上の住所の緯度経度情報であるステータスを返してもよい。また、相当する緯度経度がデータベース上にない場合は、エラーを返してもよい。なお、別の実施例として、問い合わせるデータベースが、揺らぎを考慮したデータ構造を有する場合（例えば、「神奈川県横浜市西区みなとみらい３丁目」（アラビア数字を用いた町名表記）であっても「神奈川県横浜市西区みなとみらい三丁目」（漢数字を用いた町名表記）であっても、対応する緯度経度情報を有する場合）は、揺らぎ補正は不要である。

Ｓ２０２０では、自社顧客属性情報の顧客情報を法人種別と主法人名とに分割する。ここで、法人種別とは、株式会社やＮＰＯ法人などの法人の種別を指し、主法人名は、商号から法人種別を除いたものを指す。本実施例では、表記上の商号（正確な表記ではない可能性がある商号）が「株．横浜総合研究所」であるので、法人種別「株．」から「株式会社」であると推定し、「横浜総合研究所」が主法人名であると推定する。このような推定をする手法のひとつは、商号「株．横浜総合研究所」から、法人種別に相当する言葉（本実施例では、「株式会社」に相当する「株．」）が一般に商号の最初または最後にあるという前提に基づき、「株式会社」に相当する言葉（「株．」「（株）」など）を予め記録しておき、この予め記憶する言葉が、商号の最初か最後にあれば、その言葉を法人種別であると推定すればよい。そして、法人種別と推定された言葉を削除した商号が、主法人名であると推定すればよい。

なお、本実施例における「法人」は、法人番号を有する団体などを意味し、例えば、社団法人、財団法人、営利法人、公益法人、中間法人、内国法人、外国法人などの私法人だけではなく、地方公共団体などの公共上の法人（公法人）も含む。

Ｓ２０３０では、主法人名を用いて、例えば、外部情報資源３０００などに問いあわせて、法人番号および関連情報（住所）を検索する。

Ｓ２０４０では、Ｓ２０３０で得られた情報は、主法人名を用いて法人番号を検索するので、法人種別は考慮されていない。そこで、Ｓ２０４０では、まず、個別の法人番号毎に、検索したい法人種別一致するかを判定する。本実施例では、法人種別が株式会社である法人番号のみを有するレコードを抽出する。次に、抽出された法人番号に相当する商号から、Ｓ２０２０と同様の手法を用いて主法人名を推定し、主法人名が互いに一致する（原則は、完全一致する）レコードを抽出する。そして、法人種別と主法人名とが一致するレコードが１つのみであるときは、この１つのレコードを代表レコードとして抽出する。その一方で、一致するレコードが複数あるときには、「同名他法人」であるフラグをたてておき、Ｓ２０５０、Ｓ２０６０で代表レコードを判定すればよい。

Ｓ２０５０では、レコードの関連情報（住所）を緯度経度情報に変換する。緯度経度の変換にあたっては、Ｓ２０１０と同様の手法を用いてよい。

Ｓ２０６０では、Ｓ２０５０で複数のレコードが抽出された場合には、自社情報資源の住所から最も距離が近い緯度経度を有するレコードを代表レコードとして抽出する。本実施例では、法人番号ｄｄｄｄｄｄｄｄｄｄｄの緯度経度の方が、法人番号ａａａａａａａａａａの緯度経度よりも、自社顧客番号ＢＢＢの緯度経度よりも近いので、法人番号ｄｄｄｄｄｄｄｄｄｄｄを代表レコードとして抽出する。

Ｓ２０７０では、Ｓ２０６０で抽出された代表レコードにおける住所が、所定範囲内かを判定する。所定範囲内とは、例えば、同一県内、距離３０ｋｍ以内など予め決められた任意の範囲である。これらの所定範囲内の属否に関する判定は、緯度経度情報を用いればよい。そして、代表レコードにおける住所が所定範囲内にあるときは、当該代表レコードの法人番号が、自社顧客の法人番号である決定する。一方で、代表レコードにおける住所が所定範囲内にないときには、自社顧客の法人番号が見つからなかったことを示すエラーを返してもよい。本実施例では、法人番号ｄｄｄｄｄｄｄｄｄｄｄの緯度経度が、自社顧客番号ＢＢＢの緯度経度から見て所定範囲内（例えば、同一市内）にあると判断できるので、自社顧客番号ＢＢＢの法人番号は、ｄｄｄｄｄｄｄｄｄｄｄｄであると判定できる。そして、この判定結果を、図３Ｂ（ｃ）に示すようなデータ形式で格納する。なお、図３Ｂやその他の図で示す自社情報資源のデータ構造の形式は、各ＤＢに格納されているデータ項目を、説明の便宜上、必要に応じて結合して示しているにすぎず、必ずしも図示したようなデータ構造の形式でＤＢに格納されている必要性はない。

（ケース３）
以下、図３Ｃを参照しつつ、金融取引データ（為替取引情報など）による法人情報の取得について説明する。

商号や住所などの自社顧客属性情報等を含む自社情報資源が更新されず古い情報のままとなっていることがある。例えば、融資取引などがない自社法人顧客であっても、会社の合併などで商号が変更になっても変更届け提出されない場合もある。そこで、変更後の法人情報の使用が期待される直近の金融取引データの商号（依頼人名、受取人名）を用いて、法人番号を検索する手法の一例について以下に説明する。

以下、ケース２との主な違いについて説明する。

自社情報資源については、為替取引などの金融取引においては、取引先（図３Ｂの為替取引カナ名やカナ商号）にカナ文字が用いられるので、法人番号を検索したり、商号の一致を判定したりする際には、カナ文字に用いる。それ以外のデータ構造については、ケース２と同様であるので、説明を省略する。

本実施例においては、図３Ｃ（ａ）に示すように、自社顧客番号ＣＣＣについて、その住所から緯度経度情報を取得し、更に、顧客属性情報ＤＢ上に登録されている為替取引カナ名を、法人種別と主法人名と分解する。ここで、自社顧客番号ＣＣＣに対応する法人番号は、情報処理装置１０００内のＤＢには格納されておらず、不明であるものとする。

本実施例においては、図３Ｃ（ｂ）に示すように、複数（２つ）の法人が検索できたものとする。この２つの法人の法人種別が、いずれも株式会社であるので、図３Ｃ（ａ）の主法人名（ハマホールディングス）を用いて、外部情報資源３０００などの外部データベースに問いあわせて、法人番号および住所に関する情報を取得する。取得された住所については、緯度経度変換ＤＢに問いあわせをして、緯度経度情報を取得する。そして、図３Ｃ（ａ）の自社情報資源の緯度経度と、図３Ｃ（ｂ）の緯度経度とを比較して、互いに最も近く、且つ所定範囲内になる法人を検索する。本実施例においては、図３Ｃ（ｂ）の法人番号ｅｅｅｅｅｅｅｅｅｅの法人が、自社顧客番号ＣＣＣに相当するものと推定する。

推定結果に基づいて、図３Ｃ（ｃ）に示すような、自社顧客番号と法人番号との対応テーブルを生成して格納する。

（ケース４）
ケース１からケース３までは、自社顧客に関するデータの検索について説明したが、ケース４では、他社顧客に関するデータの検索について、図３Ｄを参照しつつ、説明する。自社情報に存在する他社顧客とは、自社顧客と取引のある他社の法人顧客（以下、他社顧客）を意味する。他社顧客に関するデータの取得にあたっては、金融取引データ（為替取引情報など）により法人情報を取得する。具体的な取得手順は以下である。

金融取引データの一例を、図３Ｄ（ａ）に示す。まず、金融取引データの情報から金融取引カナ名に関する情報を検索し、この情報から、情報処理装置１０００の内部または外部にあるデータベースを利用して、法人番号を検索する。

法人番号を検索した結果、本実施例では、図３Ｄ（ｂ）に示すように、２つの法人が検索できたとする。そして、２つの法人の住所の情報を、それぞれ緯度経度変換する。緯度経緯度変換の手法については、前述した手法を用いてもよい。そして、図３Ｄ（ｂ）の検索された法人の緯度経度情報と、図３Ｄ（ａ）の取引店の緯度経度情報とを比較する。比較の手法については、前述した手法を用いてもよい。ここで、取引店の住所を利用する理由は、（法人の所在地は不明であるが、）当該法人は通常は地理的に近い銀行を利用することが多いという事実に基づく。そして、比較の結果、法人番号ｋｋｋｋｋｋｋｋｋｋｋの法人が、他社顧客であると判定できる。

上述した判定結果を基にしたデータ構造の一例を図３Ｄ（ｃ）に示す。図３Ｄ（ｃ）において、本実施例の他社顧客は、自社顧客番号を有していないので、他社情報（金融機関名、取引店名、科目および口座番号の組み合わせ）と、法人番号とを対応付けている。なお、他社顧客であっても、自社顧客番号を有していることが判定できた場合には、自社顧客番号を用いて特定する。

（最終成果：法人番号情報）
上述したケース１から４までの情報を基に、法人番号をキーとしたテーブルを、図３Ｅに示す。

本実施例で作成したテーブルは、テーブルの上から順番にケース１、２、３、４で作成した情報に基づいて作成されている。なお、ケース１−３で作成したテーブルは、自社顧客に対する情報であるので、自他区分が「自社」であると表示され、ケース４で作成したテーブルは、他社顧客に対する情報であるので、自他区分が「他社」であると表示される。これにより、法人番号をキーとした情報テーブルを生成することができる。なお、表中において、データなし（ヌル）は「−−−」で示してある。

Ｓ１０２０：対象法人の代表者の個人の検索方法について説明する。

本実施例において、対象法人の代表者の個人口座の対象は、自社の情報処理装置内で管理する個人顧客全てである。また、信用調査会社などの外部情報における代表者の属性情報から自社顧客が代表を務める法人の法人顧客番号を検索する。

Ｓ１０２０の検索手順の概要について説明する。まず、代表口座の属性情報として、氏名（名字、名前）、生年月日、住所、電話番号を取得する。ここで、少なくとも住所と電話番号については、時間（データ更新日時）と関連付けられて記憶されている。顧客番号の属性情報が記録されているテーブルの一例を図４Ｂに示す。なお、図４Ｂのテーブルは、定期的に更新されてもよく、住所や電話番号などが変更されたときに更新されてもよいが、更新された日時は記録されるものとする。

Ｓ１０２０の検索手順の具体例について説明する。代表者の氏名、生年月日、電話番号を活用して、外部情報資源から自社顧客である代表者を検索する。住所の揺らぎ（１丁目、一丁目、丁目の省略など）は前述したような補正をおこなう。自社情報資源と外部情報資源とが以下のような条件を満たした場合には、同一人物であると判定する。

ここで、一致条件の一例は、氏名（漢字表記またはカナ表記）が一致することであり、付加的には、住所または電話番号が一致すること、生年月日の年・月・日の２つ以上が一致することとする。

例えば、法人番号が検索できる外部情報資源にアクセスし、自社顧客属性情報の住所を使って、法人番号を検索する。ここで、自社顧客属性情報の住所には揺らぎがある可能性があるので、揺らぎを補正しながら検索をする。本実施例では、自社顧客属性情報の住所においては、代表者住所の「３丁目」の「丁目」が省略されて登録されていたので、「（省略）３−Ｐ−Ｑ」で検索しても検索結果がなかった場合には、揺らぎを補正して、「（省略）３丁目Ｐ−Ｑ」で再度検索すればよい。

そして、住所で検索できたので、次に、氏名（漢字表記またはカナ表記）が一致するか否かを判定する。漢字表記においては、例えば、戸籍上の漢字が常用漢字以外でないために、常用漢字に置き換えられている場合もあるので、漢字表記の揺らぎは適宜補正して、一致しているか否かを判定する。また、カナ表記においても、濁音等が誤って登録されている場合もあるので、同様に適宜補正して、一致しているか否かを判定する。

次に、生年月日が一致するか否かを判定する。生年月日が誤登録されている場合があるので、年・月・日のうち２つ以上一致してれば、生年月日が一致すると判定してもよい。

そして、最終的に代表者が一致すると判定できた場合には、自社顧客番号（本実施例：ＭＭＭ）と法人番号（本実施例：ｅｅｅｅｅｅｅｅｅｅｅ）とを紐付けて記憶する（図４Ａを参照）。

Ｓ１０３０：代表者から見た区分に基づき、対象法人の代表者の同一家系個人（配偶者、子、親）の検索方法について説明する。本実施例における区分は、家系であるので、代表者から見た、配偶者、親子などが検索対象である。

管理対象は、本実施例の情報処理装置のデータベース内で管理されている個人顧客全てである。過去情報を含め、代表者と同居実績のある顧客を同一家系個人顧客として検索する。更に、性別や年齢差から代表者との続柄を推定する。活用情報資源は、自社顧客属性情報である。

一致条件は、例えば、住所または電話番号などの所在に関する情報で一致し、苗字が一致することで同一家系個人顧客であることを判定する。更に、本実施例においては、性別と年齢差から代表者との続柄も推定する。例えば、代表者（本実施例では、夫）と性別が異なり、所定の年齢差の範囲内であれば、配偶者（本実施例では、妻）であると推定する。所定の年齢以上の差があれば、代表者の親または子であると推定できる。

なお、本明細書において、苗字とは、姓（上の名前）を称し、名前は、名（下の名前）を称し、姓と名からなるものを氏名（いわゆるフルネーム）と称するものとする。

Ｓ１０３０の概要について説明する。まずは、代表口座の配偶者の口座を検索する。検索方法の一例として、まずは、住所が一致する口座を検索する。なお、住所の揺らぎは考慮された上で、一致する住所を検索するものとする。ここで、住所が一致したか否かの判定においては期間が考慮される。例えば、現在は異なる住所であっても過去の一定期間において住所が一致している場合は、住所が一致したと判定する。一致する住所があった場合は、代表者と性別が異なっているかどうかを判定し、さらに、２つの口座において、その住所が有効であった期間が一致するかを判定する。これらが一致した場合は、その口座は、配偶者の口座であると判定することができる。すなわち、代表者口座の家系関連口座であると判定する。もし、一致する口座がなければ、配偶者の口座はないと判定される。

更に、Ｓ１０３０では、代表者の親または子供（すなわち、代表者から見て一親等の関係）の口座を検索する。検索方法の一例として、まずは、住所が一致する住所が一致する口座を検索する。なお、住所の揺らぎは考慮された上で、一致する住所を検索するものとする。一致する住所があった場合は、生年月日を取得して、代表者の生年月日と比較して、所定期間以上（例えば、１０年以上）離れているか否かを判断し、もし、所定期間以上年齢が離れていれば、親または子（性別は問わない）であると判定する。そして、代表者口座の家系関連口座であると判定する。もし、一致する口座がなければ、親または子の口座はないと判定される。

Ｓ１０３０の具体例について説明する。本実施例では、図４Ｂのレコード（ａ）で示すような、自社顧客番号ＭＭＭを有する自社顧客（代表者：浜太郎）の家系について検索するための一例について説明する。まず、情報基準時点（本実施例では２０１８年１２月）を基準として、代表者と同じ住所を有する顧客を検索する。なお、住所の揺らぎについては適宜補正した上で検索してもよい。本実施例では、（ｂ）で示すようなレコードが抽出できたとする。次に、苗字が一致するか否かを判定する。本実施例では、レコード（ａ）とレコード（ｂ）との苗字が一致している。次に、性別を確認する。本実施例では、レコード（ａ）の性別が男性であり、レコード（ｂ）の性別が女性である。次に、年齢差（生年月日の差異）が所定範囲内（本実施例では、年齢差が１０歳以内、すなわち、生年月日の差異が１０年以内）か否かを確認する。本実施例では、年齢差が５年８ヶ月であると計算できたので、所定範囲内であると判定できる。これにより、自社顧客番号ＭＭＭを有する自社顧客（代表者：浜太郎）と、住所が同じであったことがあり、性別が異なり、年齢差が所定範囲内であると判定できたので、自社顧客番号ＷＷＷの顧客は、配偶者（妻）であると判定できる。

次に、情報基準時点を過去に遡って、自社顧客番号ＭＭＭの顧客と同じ住所を有する顧客を検索する。本実施例では、情報基準時点が２０１２年３月の時点で、レコード（ｃ）で特定するような（自社顧客番号ＴＴＴで特定される）顧客が抽出できた。これは、現在（本実施例：２０１８年１２月）は同居していないが過去（本実施例：２０１２年３月）に同居していた実績があることを示す。次に、苗字が一致するか否かを判定する。本実施例では、レコード（ａ）とレコード（ｃ）との苗字が一致している。次に、年齢差（生年月日の差異）が所定範囲を超えているか（本実施例では、年齢差が２０歳以上、すなわち、生年月日の差異が２０年以内）か否かを確認する。本実施例では、年齢差が２２年１０ヶ月あると計算できたので、自社顧客番号ＭＭＭの顧客の親または子であると判定できるが、本実施例では、自社顧客番号ＭＭＭの顧客からみると年齢が若いので、子であると判定できる。

上述したような判定結果を活用することにより、家系図情報を生成することができる。本実施例の家系図情報は、自社顧客番号、同一家系顧客番号、同一家系区分（本人、配偶者、親、子）から構成される。なお、同一家系区分において、配偶者や親子などの判定をしない場合は、単に、同一家系である旨のみを区分上に表示してもよい。

なお、本実施例では、代表者から見て一親等の個人（妻、子、親）について検索したが、更なる実施例として、代表者から見て二親等の個人（兄弟、祖父母、孫）等についても同様の手法を用いて検索してもよい。

Ｓ１０４０：対象法人の代表者と同一家系個人が代表である法人の検索方法について説明する。

管理対象は、自社顧客属性情報を含む自社情報資源に存在する法人全てである。

Ｓ１０４０の概要について説明する。まず、代表者口座の家系関連口座を基に、代表者の妻、親、子の関連会社（法人口座）の有無を検索する。検索するにあたっては、法人情報が記録されている法人情報データベースを使用する。そして、該当する法人が見つかった場合には、該当する法人名および当該法人の財務情報を取得する。なお、現時点の財務情報だけではなく、過去の財務情報も取得する。家系情報のテーブルの一例を図４に示す。

Ｓ１０４０の具体例について説明する。図４Ｃで示すように、上述した（１）（２）（３）で作成した情報を基に、同一家系個人が代表である法人を検索する。

ステップ（ａ）において、（１）で生成された情報を取得する。本実施例では、法人番号ｅｅｅｅｅｅｅｅｅｅｅの同一家系個人が代表である法人を検索する。その候補として、法人番号ｋｋｋｋｋｋｋｋｋｋｋがリストに掲載されている。

ステップ（ｂ）において、（２）で生成された情報を取得する。本実施例では、法人番号ｅｅｅｅｅｅｅｅｅｅと法人番号ｋｋｋｋｋｋｋｋｋｋに対応する自社顧客番号を検索する。

ステップ（ｃ）において、（３）で生成された情報を取得する。本実施例では、法人番号ｅｅｅｅｅｅｅｅｅｅｅすなわち自社顧客番号ＭＭＭに関係する、同一家系自社顧客番号及び同一家系区分を検索する。ここで、ステップ（ｃ）の同一家系自社顧客番号のＷＷＷについては、ステップ（ｂ）を参照すると、法人番号ｋｋｋｋｋｋｋｋｋｋｋであることがわかる。

上述した結果として、同一家系他法人情報（同一家系個人が代表である法人の法人番号情報）のレコードを生成することができるようになる（図４Ｄを参照）。

そして、上述した情報を基に最終生成情報資源を生成する。図４Ｄの最終生成情報資源（ａ）は、法人番号ｅｅｅｅｅｅｅｅｅｅｅをキーとして、法人の区分、人格（本実施例では、法人）、自社顧客番号、同一家系法人番号を項目として記載されている。これを、本実施例では、法人管理番号情報マップとも称する。生成された法人管理番号情報マップは、当該法人管理番号情報マップが生成された時間や法人の区分のカテゴリ（本実施例では、家計情報）と関連付けて、法人管理番号情報マップ・データベース（図示せず）などの任意のデータベースに記憶されるように構成されてもよい。また、（区分のカテゴリは同一でも異なっていてもよいが）キーとなる法人番号が同じ法人管理番号情報マップが、法人管理番号情報マップ・データベース内に既に存在すれば、既存の法人管理番号情報マップと結合する情報処理を施して、新たな法人管理番号情報マップとして記憶されるように構成されてもよい。

最終生成情報資源（ｂ）は、（ａ）の変形例である。（ａ）の情報に加えて、同一家系法人ｋｋｋｋｋｋｋｋｋｋｋに関連する金融機関名、取引店名、科目、口座番号が付加されている。

最終生成情報資源（ｃ）は、（ａ）の変形例であり、（ａ）の同一家系法人番号ｋｋｋｋｋｋｋｋｋｋｋを、新たな法人番号とする。この場合、法人番号ｋｋｋｋｋｋｋｋｋｋｋの代表者は、法人番号ｅｅｅｅｅｅｅｅｅｅｅの代表者の妻（自社顧客番号ＭＭＭ）であるので、（ａ）と（ｃ）とを比較すると、法人区分の代表者と配偶者とが入れ替わっており、当該法人と同一家系他法人とが入れ替わっている。

本実施例では、金融口座に付随する属性情報を基に、個人や法人を検索したが、別の実施例として、金融口座間で送受信される金融決済データを利用して個人／法人を検索してもよい。例えば、配偶者や親子などの関係があれば、互いの金融口座間で資金のやりとりがある可能性がある。この金融決済データの履歴を活用して、配偶者や親子の可能性のある口座を絞り、その絞られた口座の中から、配偶者の口座や親子の口座を検索するように構成されてもよい。

本実施例で示したように、評価対象企業の金融口座だけでなく、同一家系他企業に関する金融口座まで、残高対象を拡張して評価することにより、小規模事業所のような公開情報が乏しいような法人等であっても適切に評価でき、適切な融資を行うことができるようになる。

上述した実施例１では、「区分」を家系の観点から定義し、配偶者、親子などを使って、法人番号管理情報マップを生成したが（図４Ｄ（ａ）を参照。同図は、図４Ｅ（ａ）にも再掲。）、以下では、本実施例の「区分」に関する別の実施例について説明する。

例えば、別の実施例では、「区分」を商流の観点から定義して、法人番号管理情報マップを生成することができる。

以下、図２および図４Ｅ（ｂ）を参照しながら、商流情報に基づく法人番号管理情報マップを生成する情報処理の一例について、上述した実施例との違いを中心に、簡単に説明する。

図２のＳ１０１０では、法人番号管理情報マップ生成のための対象となる法人を選択すると共に、区分を選択する。実施例２では、区分として「商流」が選択される。実施例２における「商流」の区分の一例は、「仕入先」、「販売先」などである。

図２のＳ１０２０では、マップを構成する個人および法人を検索および判定するための参照情報として、金融取引データにおける送金元、送金先、送金額などを参照することを確認する。

図２のＳ１０３０、Ｓ１０４０では、対象法人の法人番号と、当該対象法人の代表者の自社顧客番号を判定するが、実施例１と概ね同様に処理できるので、詳細な説明は省略する。

図２のＳ１０５０の判定の一例について説明する。参照情報に基づき、金融取引データを参照して、対象法人からの振込が多い法人（自社顧客または他社顧客）であれば、対象法人は、仕入先の法人から商品や部品を購入していると考えられるので、「仕入先」であると判定できる。また、対象法人への振込が多い法人（自社顧客または他社顧客）であれば、対象法人は、販売先の法人や個人に商品を販売していると考えられるので、「販売先」であると判定できる。

更に、所定期間において、所定の法人等から別の法人等への送金額の合計を計算して、所定額以上である場合に限って、「販売先」「仕入先」などの区分を判定するように構成してもよい。

また、区分を判定された法人（以下、「取引関連法人」とも称することがある。）および取引関連法人の代表者等（個人）については、自社の顧客であるかどうかも判定する。自社顧客であれば、予め割り振られた自社顧客番号を検索する。もし、取引関連法人の自社顧客番号が検索できなければ、自社顧客番号以外の別の識別方法で特定をする。別の識別方法とは、例えば、金融取引データを参照して、取引関連法人が金融口座を有している他法人名（支店名等を含めてもよい）や口座番号（口座種別を示す科目を含む）等の組み合わせを用いて、特定してもよい。

図２のＳ１０６０では、Ｓ１０５０までの結果を基に、商流情報に基づく法人管理番号情報マップを生成する。本実施例で生成された法人管理番号情報マップの一例を、図４Ｅ（ｂ）に示す。図４Ｅ（ｂ）の法人管理番号情報マップでは、対象法人の法人番号をキーとして、当該対象法人自身、当該対象法人と取引関係にある法人、法人の代表者のそれぞれの自社顧客番号などの識別番号と、個人または法人の人格と、前記対象法人との取引の関係を示す区分（「仕入先」など）と共に特定されている。生成された法人管理番号情報マップは、当該法人管理番号情報マップが生成された時間や法人の区分のカテゴリ（本実施例では、家計情報）と関連付けて、法人管理番号情報マップ・データベース（図示せず）などの任意のデータベースに記憶されるように構成されてもよい。また、（区分のカテゴリは同一でも異なっていてもよいが）キーとなる法人番号が同じ法人管理番号情報マップが、法人管理番号情報マップ・データベース内に既に存在すれば、既存の法人管理番号情報マップと結合する情報処理を施して、新たな法人管理番号情報マップとして記憶されるように構成されてもよい。例えば、図４Ｅ（ａ）の法人管理番号情報マップが既に記憶されていた場合には、図４Ｅ（ｂ）の法人管理番号情報マップと図４Ｅ（ａ）の法人管理番号情報マップとは、キーとなる法人番号が同一であるので結合して新たな法人管理番号情報マップとして記憶してもよい。

実施例１、実施例２の別の実施例として、実施例３では、「区分」を資本関係の観点から定義して、法人番号管理情報マップを生成することができる。

以下、図３および図４Ｅ（ｃ）を参照しながら、資本関係に基づく法人番号管理情報マップを生成する情報処理の一例について、上述した実施例との違いを中心に、簡単に説明する。

図２のＳ１０１０では、法人管理情報マップ生成のための対象となる法人を選択すると共に、区分を選択する。実施例３では、区分として「資本関係」が選択される。実施例３における「資本関係」の区分の一例は、いわゆるステークホルダーである持株会社、グループ企業、取締役だけでなく、従業員（契約社員等を含む）が関係する企業（従業員関連企業）なども含む。

図２のＳ１０２０では、マップを構成する個人および法人を検索および判定するための参照情報として、属性情報や金融取引データにおける送金元、送金先、送金額などを参照することを確認する。

図２のＳ１０３０、Ｓ１０４０では、対象法人の法人番号と、当該対象法人の代表者の自社顧客番号を判定するが、実施例１と概ね同様に処理できるので、詳細な説明は省略する。

図２のＳ１０５０の判定の一例について説明する。持株会社やグループ企業に関しては、属性情報などを参照して、会社名から判定できる。取締役については、法人の属性情報から判定できる。従業員については、従業員の属性情報から、従業員が勤務している会社等の法人の情報を参照して、判定できる。そして、該当する従業員または当該従業員が代表を務める法人と、従業員が勤務している法人との間で、ある程度の資金の流れがあれば（または所定の送金額以上があれば）、対象法人と従業員とが互いに関係する企業であると判定できる。

更に、所定期間において、所定の法人等から別の法人等への送金額の合計を計算して、所定額以上である場合に限って、「従業員関連企業」などの特定の区分を判定するように構成してもよい。

また、区分を判定された法人（以下、「資本関連法人」とも称することがある。）および取引関連法人の代表者等（個人）については、自社の顧客であるかどうかも判定する。自社顧客であれば、予め割り振られた自社顧客番号を検索する。もし、資本関連法人の自社顧客番号が検索できなければ、自社顧客番号以外の別の識別方法で特定をする。別の識別方法とは、例えば、金融取引データを参照して、資本関連法人が金融口座を有している他法人名（支店名等を含めてもよい）や口座番号（口座種別を示す科目を含む）等の組み合わせを用いて、特定してもよい。

図２のＳ１０６０では、Ｓ１０５０までの結果を基に、資本関係に基づく法人管理番号情報マップを生成する。本実施例で生成された法人管理番号情報マップの一例を、図４Ｅ（ｃ）に示す。図４Ｅ（ｃ）の法人管理番号情報マップでは、対象法人の法人番号をキーとして、当該対象法人自身、当該対象法人と資本関係にある法人、法人の代表者のそれぞれの自社顧客番号などの識別番号と、個人または法人の人格と、前記対象法人との資本関係を示す区分（「グループ企業」など）と共に特定されている。生成された法人管理番号情報マップは、当該法人管理番号情報マップが生成された時間や法人の区分のカテゴリ（本実施例では、家計情報）と関連付けて、法人管理番号情報マップ・データベース（図示せず）などの任意のデータベースに記憶されるように構成されてもよい。また、（区分のカテゴリは同一でも異なっていてもよいが）キーとなる法人番号が同じ法人管理番号情報マップが、法人管理番号情報マップ・データベース内に既に存在すれば、既存の法人管理番号情報マップと結合する情報処理を施して、新たな法人管理番号情報マップとして記憶されるように構成されてもよい。例えば、図４Ｅ（ａ）と図４Ｅ（ｂ）とが結合された法人管理番号情報マップが既に記憶されていた場合には、図４Ｅ（ａ）と図４Ｅ（ｂ）と図４Ｅ（ｃ）の法人管理番号情報マップは、キーとなる法人番号が同一であるので結合して新たな法人管理番号情報マップとして記憶してもよい。

なお、Ｓ１０１０「区分」を選択する処理が設けられているが、予め検索対象となる区分（例えば、商流に関する区分であること）が決まっていれば、当該処理を実行しなくてもよい。

図６は、本発明の一実施例による可能な融資を判定するためのテーブルおよびグラフの一例を示しており、資産把握の精緻化による評価高度化の一例を示す。

図７は、本発明の一実施例による可能な融資を判定するための情報処理の一例を示す。

Ｓ７０１０では、代表者口座および家系関連口座から、経時的な財務情報を計算する。経時的な財務情報の一例を図６のテーブルに示す。

Ｓ７０２０では、経時的な財務情報を基に、最小残高水準閾値を計算する。ここで、最小残高水準閾値とは、ある一定期間で時系列に合計額の推移を計算した上で、その中の最小の合計残高でもよいし、ある一定期間上のある時点での最小の合計残高（各金融口座の最小残高が発生した異なる時期合算）でもよい。

ひとつの法人だけでは十分な資産背景が確認できない可能性がある。ただし、そのような場合においても、実務においては、代表者が保証人となり与信提供することも珍しくはない。そこで、当該法人だけでなく、代表者を含む同一家系内の他口座の資産背景も考慮することで評価をする手法について説明する。

図６に示すように、ある基準時点毎に、どの程度の資産を有するかを調べる。本実施例においては、例えば、２０１８年１月の時点において、当該法人は１９４万円の資金が口座にあり、その代表者は７１４万円の資金が口座にあり、その他個人（代表者の配偶者や子）は合計で３００万円の資金が口座にあるとする。これらの資金を合計すると、１２０８万円の資産を有することがある。

同様に、基準時点を、例えば、１ヶ月毎にずらしていき、その推移を調べる（例えば、年間の平均を求める）ことにより、大凡の資産規模を推定することがある。

当該法人だけに着目すると、年間平均で１９３万円の資産規模であることがわかるが、法人番号キーにした資産背景を合算評価（代表者や、その他の資産背景を考慮）すると、年間平均で、１２０７万円の資産規模を有することがわかる。合算評価を用いることにより、資産規模が増大するように評価できれば、貸倒リスクが軽減することがわかるので、金融機関は、大きく評価された資産規模に基づいて、与信提供が可能になる。

そして、計算された最小残高水準閾値を基に融資可能額および金利を判定する。また、融資可能額の判定にあたっては、例えば、最小残高水準閾値までであれば、判定時点の通常金利とし、最小残高水準閾値を超える額であれば、通常金利＋超過金利のような判定でもよい。また、返済期間を考慮して金利を変動させてもよい。

本実施例で示したように、評価対象企業の金融口座だけでなく、同一家系他企業に関する金融口座まで、残高対象を拡張しても、保全性の観点から考えても最大限の融資をおこなうことができるようになる。すなわち、当該法人のみを評価した場合、高額を融資するのも難しいが、本実施例のデータ構造を用いて、当該法人だけでなく、その代表者個人やその家族および関連会社を合算して評価することにより、より高額の融資を行うことができるようになる。

図８は、本発明の一実施例による商流把握の精緻化による評価高度化の一例を示す。

まず、（ａ）に示しように、特定の法人に関連した商流を把握する。本実施例においては、自社顧客番号ＣＣＣ（法人番号ｅｅｅｅｅｅｅｅｅｅｅ）が、他社金融機関（Ｒ銀行八重洲支店）から資金（５００万円）が振り込まれた金融取引データがある。従来は、特定の法人に関連した商流を評価するにあたっては、（ａ）のような金融取引データを用いていた。

本実施例においては、実施例１で説明したような、法人番号ｅｅｅｅｅｅｅｅｅｅｅをキーとしたテーブルを参照することにより、自社顧客番号ＣＣＣの法人の代表者（自社顧客番号ＭＭＭ）の商流も参照することができる。

そして、（ｃ）に示すように、（ａ）と（ｂ）の情報を統合した金融取引データを生成することができる。このような金融取引データを利用することにより、当該法人ＣＣＣの商流を精緻に把握することが可能になる。これにより、優良な法人との取引など、当該法人だけに着目していては把握できなかった情報から、当該法人を評価することが可能になる。例えば、評価対象法人の金融取引だけでなく、評価対象法人の関連法人の金融取引も評価対象としてもよい。すなわち、関連法人が優良な法人（他社顧客）と取引がある場合には、優良な法人の資産や関連法人と優良な法人との間の取引実績（取引金額や取引回数など）に応じて、対象法人の融資に対する金利を低く変動したり、より高額の融資を行ったりするように構成されてもよい。優良な法人であることの判定は、例えば、法人の資産規模が所定以上ある情報（任意の法人資産情報データベース（図示せず）から取得した情報）に基づいてもよい。また、優良な法人との取引実績が所定以上であれば、融資額が増加（例えば、１０％増加）するように構成されてもよく、金利が減少（例えば、０．５％減少）するように構成されてもよい。

図９は、本発明の一実施例によるＭＣＩＦ共同化システム２０００の概略図を示す。なお、実施例の図１と同じ参照符号は、同じ機能を有するものを指し示すので、説明を省略する。

本実施例のＭＣＩＦ共同化システムとは、特定の情報（ＭＣＩＦ）を複数の金融機関などで共同管理するためのシステムを意味する。ここで、ＭＣＩＦとは、Ｍａｒｋｅｔｉｎｇ Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｉｌｅの略称であり、マーケティング用の顧客情報のファイルを意味する。本実施例によれば、共有サーバを設けて、所定の情報を共有することにより、互いの情報を組み合わせて所望の情報を自動的に構築することができるようになる。

本実施例のＭＣＩＦ共同化システム２０００は、管理サーバ４００と、家系情報検索生成部１１５０と、複数の銀行用法人番号管理情報マップＤＢ１２５０とを備える。ここで、複数の銀行用法人番号管理情報マップＤＢ１２５０は、銀行毎に個別に用意されており、定期的または任意のタイミングで、銀行毎に設置されている家系情報マップＤＢ（図９では図示せず）からデータが送信されて、互いに同期をとるように構成されている。

管理サーバ４００は、各金融機関の情報処理装置１０００とデータを送受信したり（インターフェイスの機能を有する）、ＭＣＩＦ共同化システム２０００内部の各部を制御したりする。

本実施例のＭＣＩＦ共同化システム２０００は、単体の情報処理装置１０００では不明な情報を補間することができ、例えば、図２のＳ１０４０において親／子／配偶者の関連会社の口座が自社にない場合であっても、関連会社と思われる口座の情報を推定することで、融資判断の材料とすることができる。

以上のように本発明の実施形態の一部について説明したが、本発明の趣旨を逸脱しない範囲において、上述の説明に基づいて当業者が種々の修正又は変形が可能である。例えば、ハードウェアによる構成をソフトウェア（プログラム）で実現できるように構成されてもよい。

以上のように本発明の実施態様について説明したが、上述の説明に基づいて当業者にとって種々の代替例、修正又は変形が可能であり、本発明はその趣旨を逸脱しない範囲で前述の種々の代替例、修正又は変形を包含するものである。例えば、任意の複数の実施例を組み合わせることもできる。

また、上述した実施例では、為替取引情報に関する金融取引データを利用して、家系に関する情報を特定してマップを生成したが、個人名や法人名、年齢などの情報が利用できるのであれば、金融取引データ以外のデータを利用しても本発明が適用可能である。例えば、別の実施例として、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅｓ）でも適用可能であり、ＳＮＳのユーザ間で送受信されたデータ内の情報（送信先／受信先情報や送金情報など）や、各ユーザの属性情報（氏名、生年月日、住所、活動履歴など）を用いて、法人管理番号情報マップを作成してもよい。

本発明は、本願明細書で示した実施例以外の様々な産業や技術分野で利用することが可能である。例えば、本発明は、イベント・ベースド・マーケティング（ＥＢＭ：Ｅｖｅｎｔ Ｂａｓｅｄ Ｍａｒｋｅｔｉｎｇ）やフィンテック（Ｆｉｎａｎｃｉａｌ Ｔｅｃｈｎｏｌｏｇｙ）やトランザクションレンディング（Ｔｒａｎｓａｃｔｉｏｎ Ｌｅｎｄｉｎｇ）関連の装置やプログラムとして、様々な金融機関のスコアリングや営業支援システムに組み込むことが可能である。

情報処理装置１０００、画面表示部１１１０、入力部１１２０、顧客番号情報更新部１１３０、顧客番号属性情報取得部１１４０、情報検索生成部１１５０、財務情報生成部１１６０、金融取引判定部１１７０、融資判定部１１８０、金融口座ＤＢ１２１０、顧客番号属性情報ＤＢ１２２０、顧客番号更新情報ＤＢ１２３０、金融取引決済情報ＤＢ１２４０、法人番号管理情報マップＤＢ１２５０、財務情報ＤＢ１２６０、区分参照情報ＤＢ１２７０、法人番号ＤＢ１２８０、自社顧客番号ＤＢ１２９０、地理座標変換ＤＢ１３００、制御部１３１０、インターフェイス部１３２０、ＭＣＩＦ共同化システム２０００、管理サーバ４００

Claims (7)

1. 家系情報に基づく法人番号管理情報マップを生成する情報処理装置において、
   前記情報処理装置は、法人の名称、苗字および名前からなる法人の代表者名、法人の属性、代表者の属性に関する情報を法人番号と紐付けて格納する情報資源データベースと接続されており、
   前記情報処理装置は、
   法人の名称または自社顧客番号と、これを一意に特定できる法人番号とを対応付けて格納する法人番号データベースと、
   自社顧客の苗字および名前と年齢と所在地とに関する個人の顧客属性情報または法人の代表者名に関する法人の顧客属性情報と自社顧客番号とを対応付けて格納する顧客番号属性情報データベースと、
   対象法人を選択すると、前記法人番号データベースを用いて、当該対象法人の法人番号を取得すると共に、前記顧客番号属性情報データベースを用いて、前記対象法人の自社顧客番号を判定する手段と、
   前記対象法人の属性に関する情報を基に、前記情報資源データベースを用いて、前記対象法人の代表者名を判定すると共に、前記顧客番号属性情報データベースを用いて、前記対象法人の前記代表者の自社顧客番号を判定する手段と、
   前記代表者の少なくとも苗字および年齢に関する情報を基に、前記顧客番号属性情報データベースを用いて、前記代表者の家系に関連する家系関連個人の自社顧客番号を判定すると共に前記対象法人と関係する家系の関係者の区分を判定する手段と、
   前記代表者の少なくとも苗字および名前に関する情報を基に、前記顧客番号属性情報データベースおよび前記法人番号データベースを用いて、前記対象法人に関連する家系関連法人の自社顧客番号または法人番号を判定すると共に、予め定義された家系に関する区分の一覧から、前記対象法人との関連を示す前記家系関連法人の区分を判定する手段と、
   前記対象法人の法人番号をキーとし、前記対象法人の自社顧客番号、前記家系関連個人の自社顧客番号、前記代表者の自社顧客番号、前記判定された家系関連法人の自社顧客番号または法人番号が、個人または法人の人格と、前記区分とが特定された、家系情報に関する法人番号管理情報マップを生成する手段と、
   を備えた装置。
2. 前記装置は、更に、金融口座に関する情報を有する金融口座データベースを備え、
   前記法人番号管理情報マップを基に、ある期間における、前記対象法人の資産に加えて、前記家系関連個人の資産、前記代表者の資産および前記家系関連法人の資産の少なくとも１つを前記金融口座データベースの残高から取得して、当該取得された資産の合計を計算する手段と、
   前記ある期間における合計された資産の最小額である最小残高水準を判定する手段と、
   を備えたことを特徴とする請求項１に記載の装置。
3. 請求項２に記載の装置において、更に、
   前記最小残高水準に基づいて、融資額および金利を判定する手段を備え、
   当該判定する手段は、前記最小残高水準を超える金額を融資する場合には、前記金利は、通常よりも高い金利とすることを判定することを特徴とする装置。
4. 更に、前記自社顧客番号が存在しない他社顧客を、前記他社顧客の金融口座と前記自社顧客の金融口座との間の金融取引データから得られた金融機関名、取引店名、科目および口座番号の組み合わせからなる他社情報を用いて、識別する手段と、
   前記識別された他社顧客の資産および前記識別された他社顧客との取引実績に基づいて、前記判定された融資額および金利の少なくとも一方を変動させる手段とを備えた、請求項３に記載の装置。
5. 情報資源データベースとサーバと複数のクライアントとを備えた、家系情報に基づく法人番号管理情報マップを生成する情報処理システムにおいて、
   前記情報資源データベースは、法人の名称、苗字および名前からなる法人の代表者名、法人の属性、代表者の属性に関する情報を法人番号と紐付けて格納しており、
   前記複数のクライアントのそれぞれは、
   法人の名称または自社顧客番号と、これを一意に特定できる法人番号とを対応付けて格納する法人番号データベースと、
   自社顧客の苗字および名前と年齢と所在地とに関する個人の顧客属性情報または法人の代表者名に関する法人の顧客属性情報と自社顧客番号とを対応付けて格納する顧客番号属性情報データベースと、
   対象法人を選択すると、前記法人番号データベースを用いて、当該対象法人の法人番号を取得すると共に、前記顧客番号属性情報データベースを用いて、前記対象法人の自社顧客番号を判定する手段と、
   前記対象法人の属性に関する情報を基に、前記情報資源データベースを用いて、前記対象法人の代表者名を判定すると共に、前記顧客番号属性情報データベースを用いて、前記対象法人の前記代表者の自社顧客番号を判定する手段と、
   前記代表者の少なくとも苗字および年齢に関する情報を基に、前記顧客番号属性情報データベースを用いて、前記代表者の家系に関連する家系関連個人の自社顧客番号を判定すると共に前記対象法人と関係する家系の関係者の区分を判定する手段と、
   前記代表者の少なくとも苗字および名前に関する情報を基に、前記顧客番号属性情報データベースおよび前記法人番号データベースを用いて、前記対象法人に関連する家系関連法人の自社顧客番号または法人番号を判定すると共に、予め定義された家系に関する区分の一覧から、前記対象法人との関連を示す前記家系関連法人の区分を判定する手段と、
   を備え、
   前記サーバは、
   前記対象法人の法人番号をキーとし、前記対象法人の自社顧客番号、前記家系関連法人の自社顧客番号、前記代表者の自社顧客番号、前記判定された家系関連法人の自社顧客番号または法人番号が、個人または法人の人格と、前記区分とが特定された法人番号管理情報マップを生成する手段と、
   を備えたことを特徴とするシステム。
6. 法人番号管理情報マップを生成するプログラムにおいて、
   法人の名称、苗字および名前からなる法人の代表者名、法人の属性、代表者の属性に関する情報を法人番号と紐付けて格納する情報資源データベースにアクセスする手段と、
   法人の名称または自社顧客番号と、これを一意に特定できる法人番号とを対応付けて格納する法人番号データベースにアクセスする手段と、
   自社顧客の苗字および名前と年齢と所在地とに関する個人の顧客属性情報または法人の代表者名に関する法人の顧客属性情報と自社顧客番号とを対応付けて格納する顧客番号属性情報データベースと、
   対象法人を選択すると、前記法人番号データベースを用いて、当該対象法人の法人番号を取得すると共に、前記顧客番号属性情報データベースを用いて、前記対象法人の自社顧客番号を判定する手段と、
   前記対象法人の属性に関する情報を基に、前記情報資源データベースを用いて、前記対象法人の代表者名を判定すると共に、前記顧客番号属性情報データベースを用いて、前記対象法人の前記代表者の自社顧客番号を判定する手段と、
   前記代表者の少なくとも苗字および年齢に関する情報を基に、前記顧客番号属性情報データベースを用いて、前記代表者の家系に関連する家系関連個人の自社顧客番号を判定すると共に前記対象法人と関係する家系の関係者を判定する手段と、
   前記代表者の少なくとも苗字および名前に関する情報を基に、前記顧客番号属性情報データベースおよび前記法人番号データベースを用いて、前記対象法人に関連する家系関連法人の自社顧客番号または法人番号を判定すると共に、予め定義された家系に関する区分の一覧から、前記対象法人との関連を示す前記家系関連法人の区分を判定する手段と、
   前記対象法人の法人番号をキーとし、前記対象法人の自社顧客番号、前記家系関連法人の自社顧客番号、前記代表者の自社顧客番号、前記判定された家系関連法人の自社顧客番号または法人番号が、個人または法人の人格と、前記区分とが特定された法人番号管理情報マップを生成する手段と
   して、コンピュータを機能させるためのプログラム。
7. 前記対象法人の法人番号をキーとし、前記対象法人、商流または資本関係に関する関連法人、前記関連法人の自社顧客番号が、個人または法人の人格と、前記商流または資本関係に関する区分と共に特定された、前記商流または資本関係に関する法人番号管理情報マップを記憶している法人番号管理情報マップ・データベースを更に備え、
   前記商流または資本関係に関する法人番号管理情報マップ・データベースと、前記家系情報に関する法人番号管理情報マップとのキーとなる法人番号が一致するときに、商流または資本関係に関する法人番号管理情報マップ・データベースと、前記家系情報に関する法人番号管理情報マップとのキーとを結合することを特徴とする、請求項１の装置。