JP2019211978A - 決済情報による業績予測と外部情報とを活用した融資判断・融資提案システム - Google Patents

Abstract

【課題】決済情報による業績予測と外部情報を活用した融資判断・融資提案システムを提供する。【解決手段】本発明のシステムは、自社顧客の正式商号に対して名寄せ処理をして、当該自社顧客の正式商号と類似する類似商号を取得する手段と、前記自社顧客の正式商号に対して法人番号を付与する手段と、前記類似商号に対しても前記法人番号を付与する手段と、前記正式商号を前記法人番号と共に記憶すると共に前記類似商号も前記法人願号と記憶する手段と、を備える。正式【選択図】図１

Description

本発明は、決算情報を活用したシステムに関するものであり、特に、決済情報による決算予測と外部情報とを活用した融資判断・融資提案システムに関するものである。

銀行などの金融機関は、決算が良好な企業（法人）に融資をしたいと考えているが、そのような適格性のある融資先を探すのは非常に難しい。特に、融資判断をするにあたっては、直近の決算書が重要な情報として必要になってくるが、融資の依頼がある企業や融資実績のある企業であれば当該企業からすぐに決算書を入手することが可能である一方、金融機関の直接の顧客でない場合や融資実績のない企業の場合は、直近の決算書がすぐに入手できず、最新の決算日から３ヶ月経過しないと一般には開示されない。その一方で、他の金融機関に先駆けて企業の業績を見極めて、顧客からの申込を待つことなく、顧客開拓をしたいという金融機関からの要望もある。そのためには、決済情報による業績予測と外部情報を活用した融資判断・融資提案を検討する必要がある。

特許文献１、特許文献２、特許文献３はいずれも、決済情報による業績予測と外部情報を活用した融資判断・融資提案することまでは考慮されていない。

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

本発明の課題の一つは、決済情報による業績予測と外部情報を活用した融資判断・融資提案システムを提供することである。

本発明の一態様によると、自社顧客の正式商号に対して名寄せ処理をして、当該自社顧客の正式商号と類似する類似商号を取得する手段と、前記自社顧客の正式商号に対して法人番号を付与する手段と、前記類似商号に対しても前記法人番号を付与する手段と、前記正式商号を前記法人番号と共に記憶すると共に前記類似商号も前記法人願号と記憶する手段と、を備えるシステムを提供する。

本発明の一態様によれば、融資対象となる法人の対象範囲を今までの直接の顧客だけでなく今まで融資実績のなかった企業にも広げることができる。本発明の別の一態様によれば、広がった融資対象法人の業績予測を迅速に行うことができる。本発明の更に別の一態様によれば、新たな顧客からの申込がなくても、事前に、融資対象法人への融資内容を迅速に決定することができる。
本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。

本発明の一実施例による情報処理装置の機能ブロック図を示す。 本発明の一実施例による法人番号を付与してデータベースを作成するフローチャートの一例を示す。 本発明の一実施例による法人番号を付与してデータベースを作成するフローチャートの一例を示す。 本発明の一実施例による決算予測を判断するフローチャートの一例を示す。 本発明の一実施例による融資を提案するフローチャートの一例を示す。 本発明の一実施例によるデータ構造の一例を示す。 本発明の一実施例によるデータ構造の一例を示す。 本発明の一実施例による（ａ）来期の決算を予測する方法の概念図と、（ｂ）来期の決算を予測するフローチャートである。 本発明の一実施例におけるＭＣＩＦ共同化システムの概略図を示す。 本発明の一実施例におけるＭＣＩＦ共同化システムの概略図を示す。

本発明の一実施例について、図面を参照しながら説明する。本実施例は、決済履歴（金融決済データ）を基に融資判断をするという点で、トランザクションレンディング（Ｔｒａｎｓａｃｔｉｏｎ Ｌｅｎｄｉｎｇ）やオンライン・レンディング（Ｏｎｌｉｎｅ Ｌｅｎｄｉｎｇ）の一態様である。

図１は、本発明の一実施例による情報処理装置１０００の機能ブロック図を示す。
本実施例の情報処理装置１０００は、画面表示部１１１０、入力部１１２０、法人情報管理部１１３０、法人番号付与部１１４０、商号予測部１１５０、決算予測及び決算ランク判定部１１６０、金融口座ＤＢ１２１０、法人情報ＤＢ１２２０、法人番号ＤＢ１２３０、決済情報ＤＢ１２４０、金融機関所在地ＤＢ１２５０、自社顧客情報ＤＢ１２６０、他社顧客情報ＤＢ１２７０、法人決算情報ＤＢ１２８０、好決算法人ＤＢ１２９０、制御部１３１０、インターフェイス部１３２０から構成される。なお、本実施例において、ＤＢは、Ｄａｔａｂａｓｅ（データベース）を意味するが、物理的／仮想的にデータを記憶できる手段であれば、どのような態様の記憶手段でもよい。

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

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

法人情報管理部１１３０は、法人情報を管理する。法人情報については、後述する。

法人番号付与部１１４０は、法人番号ＤＢ１２４０または外部サーバに問いあわせて該当法人に対応する法人番号を取得して、自社顧客または他社顧客に対して付与する。ここで、法人番号とは、各法人に対して一意に付与される番号であり、例えば、国税庁が、「行政手続における特定の個人を識別するための番号の利用等に関する法律」に基づき、法人に対して指定した番号を使用してもよい。特に、国税庁の法人番号は、商号又は名称、本店又は主たる事務所の所在地とともに公表しているものであり、１法人１つの法人番号（１３桁の数字）が指定され、原則として公表されており、自由に利用できる。

商号予測部１１５０は、金融決済データ上のデータ上の仮の商号から、正式商号を予測する。

決算予測及び決算ランク判定部１１６０は、任意の法人の決算を予測する。また、予測の結果、好決算の場合は、好決算の程度をランク付けする。

金融口座ＤＢ１２１０は、自社顧客の金融口座を記憶する手段であって、金融機関に開設されている個々の金融口座（特に、法人名義の口座）の情報（口座番号や残高など）を管理する手段である。データ構造の一例を図５（ａ）に示す。例えば、口座名義（法人の口座の名義人）、口座番号、支店番号、口座残高などから構成されるデータ構造でもよい。

法人情報ＤＢ１２２０は、法人情報を記憶する手段であって、例えば、法人口座を有する法人の属性情報や金融情報などを記憶する手段である。ここで、法人の属性情報とは、法人の本社の所在地、若しくは、対象となる金融口座に関連する事業所の所在地などのである。法人の企業情報とは、その法人の財務、格付、業績、旧社名などである。また、法人情報ＤＢには、銀行が法人から預かっている金額に関する預金情報や、銀行が法人に貸し出している金額などに関する貸出情報などの金融情報を記憶してもよい。データ構造の一例を図５（ｂ）に示す。例えば、商号、属性情報、企業情報、金融情報などから構成されるデータ構造でもよい。

法人番号ＤＢ１２３０は、商号等と共に法人番号を記憶する。データ構造の一例を図５（ｃ）に示す。例えば、法人番号、商号、所在地、当該所在地に対応する緯度・経度情報などから構成されるデータ構造でもよい。

なお、法人番号ＤＢ１２３０は、本実施例の情報処理装置を有している金融機関の直接の顧客の法人番号等を有しているだけでなく、必要に応じて外部の任意のサーバにアクセスして、必要な法人番号等の情報を取得してもよい。

決済情報ＤＢ１２４０は、決済情報を記憶する手段であって、金融決済データに基づいて決済をしたり、予め定められた期間内の全て（若しくは所定回数以上の決済回数のある法人）の金融決済データを記録したりするための手段である。データ構造の一例を図６に示す。特に、図６は、他社（他の金融機関）経由で自社の所定の支店に口座を開いている自社顧客に振込手続がされたときのデータ構造を示す。図６の３１０は、受取人の法人名義を示す。３２０は、当該受取人の口座番号を示す。なお、実際のデータでは、受取人口座番号があれば、受取人の情報は不要でもよいが、本実施例では説明の便宜のために、受取人のデータ項目を設ける。３３０は、依頼人の名義（カナ表記）を示す。なお、本実施例では、図６の項目３３０に記載されたカナ表記の依頼人の名義を、「仮の商号」と称する。３４０は、依頼人の口座番号である。３５０は、通信種目である。３６０は、勘定日である。３７０は、依頼人から受取人への振込額である。３８０は、依頼元金融機関名および支店名等である。なお、実際のデータでは、依頼元金融機関名等は、所定の数字等で示されているが、本実施例では説明の便宜のために、漢字表記を用いる。

金融機関所在地ＤＢ１２５０は、自社や他社の金融機関等の本店、支店、営業所等の所在地を記憶する。特に、本実施例では、当該所在地を住所表記と共に、当該住所から得られる緯度経度情報も記憶する。なお、住所表記から緯度経度情報を得るために、外部のサーバ／ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）などを利用してもよい。データ構造の一例を図５（ｄ）に示す。例えば、金融機関名、金融機関コード、店番号、所在地、当該所在地に対応する経度・緯度などから構成されるデータ構造でもよい。

自社顧客情報ＤＢ１２６０は、自社顧客の情報を記憶する。データ構造の一例を図５（ｅ）に示す。例えば、正式商号、仮商号、住所、当該住所に対応する経度・緯度、商号変更履歴などから構成されるデータ構造でもよい。

他社顧客情報ＤＢ１２７０は、他者顧客の情報を記憶する。データ構造の一例を図５（ｆ）に示す。例えば、他社顧客が利用している取引金融機関情報、正式商号、仮商号、住所、当該住所に対応する経度・緯度、商号変更履歴などから構成されるデータ構造でもよい。

法人決算情報ＤＢ１２８０は、法人の過去の決算情報を記憶する。データ構造の一例を図５（ｇ）に示す。例えば、商号（正式商号でも仮の商号でもよい）、決算情報（売上、経常利益、税引後利益など）などから構成されるデータ構造でもよい。

好決算法人ＤＢ１２９０は、好決算の法人を記憶する。データ構造の一例を図５（ｈ）に示す。例えば、商号や好決算ランクなどから構成されるデータ構造でもよい。

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

インターフェイス部１３２０は、情報処理装置１０００の内外のデータを送受信する。

図２Ａは、本発明の一実施例による法人番号を付与してデータベースを作成するフローチャートの一例を示す。

Ｓ２０１０〜Ｓ２０４０は、自社顧客に対して行われる情報処理である。本実施例では、自社、他社という用語を用いて説明するが、自社とは、例えば、自らの金融機関であり、他社とは、例えば、自社と金融決済データを送受信できる自社以外の金融機関である。

自社顧客の情報は、自社で口座を開設するときに取得できるが、時間の経過と共に、情報が変化する場合がある。例えば、企業同士の合併などで、社名が変更されることがあるが、旧社名の名義のまま口座が使用され続けることがある。

Ｓ２０１０では、自社顧客の利用履歴を取得する。

Ｓ２０２０では、自社顧客の（入金、出金、振込などの）利用履歴から他社顧客の正式商号を予測する。具体的には、利用された自社支店や自社営業所の所在地を緯度経度などの地理的な数値情報を基に、自社顧客情報ＤＢ、法人番号ＤＢなどの１つまたは複数の任意のデータベースから、利用された自社支店や自社営業所の所定範囲内に存在する法人を個々にピックアップして法人リスト（図示せず）を、作成する。更に、法人情報ＤＢなどを参照して、旧商号に関する情報を取得する。

Ｓ２０３０では、自社顧客へ法人番号を付与する。具体的には、自社顧客の正式商号と所在地をキーとして、情報処理装置１０００内または外にある所定のＤＢ（図示せず）問いあわせて、該当する法人番号を取得することにより、自社顧客へ法人番号を付与する。もし、法人番号が取得できなかった場合は、外部サーバに問いあわせるように構成されてもよいし、エラーを返すように構成されてもよいし、また、Ｓ２１１０以降で説明するように、法人の正式商号を推測して、該当する法人番号を取得するように構成されてもよい。

Ｓ２０４０では、Ｓ２０３０で取得した法人番号を、正式商号と住所と共に法人番号ＤＢ１２３０に記憶する。ここで、自社顧客の場合は、データベース上に正式商号が記憶されているので、まず、データベース上に記憶されている正式商号と、上述した情報処理により取得された正式商号とが異なっているか否かを判別し、もし、正式商号が互いに異なっていれば、上述した情報処理により取得された正式商号になるようにデータベースを記憶する。そして、上述した情報処理により取得された正式商号と紐付けて、対応する法人番号も記憶する。図示していないが、自社顧客の全てについてデータベースについて登録したか否かを判定するステップを設けてもよい。全て登録していない場合は、Ｓ２０１０に戻って処理を継続してもよい。

Ｓ２０５０〜Ｓ２０８０は、他社顧客に対して行われる情報処理である。ここで、自社の金融機関は、他社顧客に対する情報（特に、正式商号に関する情報）を取得する手段を持っていないため、他者顧客の正式商号を取得するための処理である。なお、Ｓ２０１０からＳ２０４０と類似の処理については、説明を省略する。

Ｓ２０５０では、他社から自社への振り込みに関する金融決済データを基に、他社の「仮の商号」を取得する。ここで、金融決済データとは、為替、でんさい、手形、振込、手形、現金、ブロックチェーンなどの金融決済に適用できる手段を、本実施例の情報処理装置等で処理可能なように入力・変換等されたデータをいう。金融決済データの構造の一例については、図６を参照されたい。

Ｓ２０６０では、他社所在地から他社顧客の正式の商号を予測する。金融機関Ａの所在地を緯度経度などの地理的な数値情報に変換する。そして、変換された数値情報を基に、金融機関Ａの所在地から所定半径内に存在する法人を個々にピックアップして法人リストを取得する。取得された法人リストと、仮の商号とを個々に比較して、類似度が一番高い法人名を正式商号として選択する。類似度の判定方法の一例は、後述する。

Ｓ２０７０では、他社顧客に法人番号を付与する。他社顧客の正式商号（類似度が一番高い法人名）と所在地をキーとして、法人番号ＤＢ１２４０に問いあわせて、該当する法人番号を取得する。

Ｓ２０８０では、取得した法人番号を、他社顧客の正式商号と住所と共に他社顧客情報ＤＢ１２７０に記憶する。

Ｓ２０８０以降のオプションのステップ（図示せず）として、所定数の法人番号の付与作業が終わったと判断されたときには、本フローチャートによる作業を終了する。一方で、終わっていないと判断されたときには、例えば、Ｓ２０５０に戻って作業を続ける。

Ｓ２０１１〜Ｓ２０４１は、自社顧客に対して行われる情報処理である。なお、Ｓ２０１０〜Ｓ２０４０とは異なる実施例である。本実施例では、例えば、似たような商号（口座名義）を有するものを、名寄せ処理をおこなうことにより、実質的に、１つの法人名義であることを推定する処理である。ここで、似たような商号とは、例えば、商号の中の１文字だけが違う（一方が大文字、他方が小文字）ものを指す。
Ｓ２０１１では、正式商号の名寄せ処理をして、類似商号を取得する。名寄せ処理は、任意の手法を用いてよい。
Ｓ２０２１では、正式商号に法人番号を付与する。法人番号を付与する一例は、Ｓ２０３０等で説明した。
Ｓ２０３１では、類似商号にも、正式商号と同じ法人番号を付与する。
Ｓ２０４１では、正式商号を法人番号と関連付けて記憶させると共に、類似商号にも同じ法人番号と関連付けて記憶させる。
上述した処理を実施することにより、例えば、法人番号を検索しても完全一致しないような商号があっても、名寄せ処理をすることにより、（法人番号が付与できる）正式商号と関連性がある類似商号を見つけることができるようになる。そして、当該類似商号に対しても、（法人番号が付与できる）正式商号と同じ法人番号を付与することにより、上述した正式商号を有する顧客（金融口座）と類似商号を有する顧客（金融口座）とは、同一法人であることがわかるようになる。同一法人であることがわかれば、複数の金融口座がひとつの法人のものであることがわかり、後述する実施例において説明するように、金融決算データに基づく業績予測等が容易にできるようになる。

図２Ｂは、図２Ａ（ｂ）の一部の別実施例の詳細を説明するフローチャートである。

まず、他社顧客が自社顧客であることがあるので、金融決済データの仮の商号から、当該他社顧客が、自行顧客情報ＤＢを検索して、自社顧客であるか否かを検索する（Ｓ２１１０参照）。自行顧客情報ＤＢ内に一致する仮の商号があれば、検索された他社顧客の名称が、自社顧客である可能性が高いと判定する（Ｓ２１２０参照）。

更に、法人情報ＤＢを検索して、当該自社顧客の事業所情報を検索して、本社や事業所の所在地情報（例えば、所在地の緯度経度情報）を１つまたは複数（全て）取得する（Ｓ２１３０参照）。これらの所在地情報と、他社顧客が振り込みを依頼した他社（金融機関）の所在地情報との直線距離を計算し、その中で一番短い直線距離にある他社顧客が、他社の所在地から所定範囲内（例えば、他社所在地を中心に半径１０００ｍ以内）にあるか否かを判定する（Ｓ２１４０参照）。もし、当該所定範囲内にあれば、他社顧客は自社顧客であると判定する（Ｓ２１５０参照）。そして、該当する顧客の法人番号を取得して（Ｓ２１６０参照）、他社顧客情報ＤＢの金融口座情報に、法人番号の情報を紐付けて記憶させる（Ｓ２１７０参照）。一方、当該所定範囲内になければ、他社顧客は自社顧客ではないと判定して、次のステップ（自行顧客ではない他行顧客の正式商号を判定する手法）にすすむ。

なお、本実施例の所定範囲は、法人を特定する推定精度に依存してもよい。例えば、推定精度を高く設定したい場合には、当該所定範囲が相対的に狭くなり、推定精度を低く設定したい場合には、当該所定範囲が相対的に広くなってもよい。

自行顧客ではない他行顧客の正式商号を判定する手法について説明する。

他社の所在地から所定範囲内にある法人の情報（例えば、法人の正式商号およびカナ表記の商号）の一覧を取得する（Ｓ２１８０参照）。取得されたカナ表記の商号を、仮の商号と比較して、一致度が高い法人を選択する（Ｓ２１９０参照）。上述した一覧は、例えば、他社顧客情報ＤＢ１２６０からのデータを基に作成される。

ここで、一致度の判定の一例について説明する。仮の商号のテキストデータを正規化処理（例えば、株式会社を意味する「カ」」などを削除）して、商号の主要部分を取得する。そして、当該主要部分を、一覧に含まれている商号のそれぞれと比較して、当該主要部分が含まれている商号を一覧から取得する。もし、複数の商号が取得された場合は、主要部分以外の文字数がどれだけあるかを調べ、差異が一番小さい方（主要部分の文字数の不一致がより少ない方であったり、いわゆる前株か後株かなどの主要部分と主要部分以外との関係がより一致している方であったりする方）が、一致度が高いと判定してもよい。すなわち、主要部分以外が全くなければ、完全一致である。

そして、当該一致度が高い法人の法人番号を選択した（Ｓ２２００参照）後は、顧客の法人番号を取得して（Ｓ２１６０参照）、他社顧客情報ＤＢの金融口座情報に、法人番号の情報を紐付けて記憶させる（Ｓ２１７０参照）。一方で、一致度が高い法人が見つからなかった場合は、Ｓ２２１０で判定不能の処理をおこない、終了する。

別の実施例として、Ｓ２２１０の判定不能の処理後に、ＭＣＩＦ共同システム（後述）で再判定する処理を設けてもよい。

更に別の実施例として、Ｓ２１１０−Ｓ２１５０の処理を省略して、Ｓ２１８０から処理が始まるように構成されてもよい。

図３は、本発明の一実施例による業績予測を判断するフローチャートの一例を示す。

Ｓ３０１０では、ユーザが業績を予測したい法人を選択する。

Ｓ３０２０では、選択された法人の法人番号を取得する。

Ｓ３０３０では、法人番号を基に、取得された法人の情報を取得する。

Ｓ３０４０では、対象法人における直近の決算情報を取得する。

Ｓ３０５０では、対象法人における直近の所定期間の金融決済データを取得する。なお、金融決済データを取得する際には、自社顧客情報ＤＢや他者顧客情報ＤＢなどの商号変更履歴を参照し、上述の所定期間内だけでなく上述の所定期間前後でも商号が変更されているかどうかも確認する。もし、商号が変更されていた履歴がある場合は、該当する仮の商号を使用している金融決済データも取得してもよい。

Ｓ３０６０では、企業情報と直近の決算情報と直近の金融決済データとから来期の決算を予測する。特に、直近の決算情報と比較して、来期の決算が良い決算（好決算）であるか否かを判定する。好決算であると判定するために比較する対象は、例えば、今期の売上高（公表された数値）と来期の売上高（予測された数値）である。来期の売上高が今期の売上高よりも高いと判定されたときは好決算であると判定する。好決算であると判定された場合は、好決算法人データベースに登録するように構成されてもよい。

Ｓ３０６０における今期の決算情報を予測する方法の一例について、図７を参照しながら、説明する。なお、図７（ａ）は、来期の決算を予測する方法の概念図であり、（ｂ）は、来期の決算を予測するフローチャートであり、（ｃ）は、決算情報の予測の一例を示す。

Ｓ７０１０では、業績を予測したい法人について、現時点から直近の決算日までの金融決済データ（以下、「今期のトランザクション」と称する）を取得する。

Ｓ７０２０では、業績を予測したい法人について、今期の決算日から前期の決算日までの金融決済データ（以下、「前期のトランザクション」と称する）を取得する。

Ｓ７０３０では、今期のトランザクションの期間と前期のトランザクションの期間とが異なる場合には、以前のトランザクションのデータを調整する。

Ｓ７０４０では、前期のトランザクション、今期のトランザクション情報、決算情報の情報量が所定以上あるか否か判定する。もし、所定以上あれば、Ｓ７０５０にすすみ、所定以上なければ、Ｓ７０６０で判定不能と処理を終了する。

Ｓ７０５０では、調整された今期のトランザクションデータと直近の決算との関係を、直近のトランザクションと今期の決算との関係にあてはまることによって、今期の決算を予測する。

例えば、法人番号Ｘを有する法人（以下、法人Ｘ）の前期売上が１００億円であり、前期の決算期間（すななわち、前々記の決算日以降から前期の決算日までの期間）における入金が９０億円＋αだったと仮定する。ここで、αとは、法人の事業による売上に関係する入金ではなく、例えば、銀行からの融資の入金、証券会社からの配当金等の入金、保険会社からの保険金の入金である。これらの入金に関しては、法人との事業上の関係性が薄い会社からの入金であることが任意のＤＢに登録されていることにより、αに含めることができる。本実施例では、決算期間のトランザクション情報によると、９０億円＋αの入金があったが、当該トランザクション情報を調整して、αを取り除くことにより、売上に関する入金が９０億円であったと判断することができる。

次に、決算情報を予測にあたって、必要な情報量が揃っているかを判定する。本実施例における必要な情報量は、前期決済入金情報と、今期決済入金情報である。例えば、前期決済入金情報に関しては、調整されたトランザクションすなわち決済入金の額が、前期決算情報の前期売上額に対して、どの程度の割合であるかを計算する。当該計算された割合が、所定の割合（例えば、８０％）を超えているか否かを判定して、所定の割合を超えていれば、引き続き、決算情報を予測できると判定する。一方で、所定の割合を超えていなければ、現時点では、決算情報を予測できないと判定して、処理を中止する。同様に、今期入金決済情報に関しては、前期入金決済情報に対する今期入金決済情報の割合を計算する。当該計算された割合が、所定の割合（例えば、８０％）を超えているか否かを判定して、所定の割合を超えていれば、引き続き、決算情報を予測できると判定する。一方で、所定の割合を超えていなければ、現時点では、決算情報を判定できないと判定して、処理を中止する。

決算情報が予測できる判定された場合の決算情報の予測方法の一例について、図７（ｃ）を参照しながら、説明する。図７（ｃ）によると、前期売上、前期決済入金情報、今期決済入金情報がわかっている。そして、今期決済入金情報（１００億円）が、前期決済入金情報（９０億円）よりも１１％増加していることが計算できるので、今期売上も前期売上（１００億円）よりも１１％増加する可能性が高いすなわち１１１億円であると計算することができる。

今期の営業利益を予測する一例について説明する。営業利益＝売上−経費であるので、経費がわかれば、営業利益を計算することができる。当該経費は、決済出金情報を取得することで知ることができる。図７（ｃ）によると、前期経費は、前期売上も前期営業利益も前期決算情報から知ることができる。すなわち、前期売上−前期営業利益で計算すればよい。そして、前期決済期間内のトランザクションから前期決済出金情報を取得する。このときに、事業上の関係性が薄い法人への振り込みがあった場合は、前期決済出金情報を調整する。そして、前述したような手法で、予測するにあたり十分な情報量を有しているか否かを判断して、十分な情報量を有していると判断した場合には、今期経費を予測する。今期経費を予測するにあたっては、今期決済出金（８０億円）が前期決済出金（６４億円）に比べて２５％増加しているので、今期経費も前期経費（８０億円）よりも２５％増加する可能性が高い、すなわち１００億円であると計算することができる。

前期経費が予測できれば、予測された今期売上から差し引くことにより、今期営業利益を予測することができる。もし、今期営業利益を予測するための十分な情報がないと判断された場合には、前期売上に対する割合を計算して、当該割合に基づいて、今期経費を計算してもよい。また、予測の情報をユーザに提示するにあたっては、トランザクションから計算した予測であるか、売上に対する比率から計算した予測であるかを表示画面上に提示してもよい。

また、本実施例を応用して、経常利益や純利益の予測についても適用可能である。例えば、経常利益の予測については、予測された営業利益から、今期のトランザクション内で、営業外利益（受取利息や借入利息）であると判断できる入金および出金に関するトランザクションを抜き出して、計算すればよい。また、純利益については、例えば、売上が予測できれば、過去数年間の売上高利益率の平均に基づいて計算されてもよい。

別の実施例として、今期の決算日後の時点で、今期の決算を予測してもよい。一般に企業（法人）の決算情報は、決算日直後に公開されるものではなく、一部の関係者しか知らない場合もある。本実施例によれば、融資をしていない金融機関でも、一定数の金融決済データ（トランザクション）を取得することができれば、今期の決算情報を予想することができ、ひいては、企業からの申込がなくても金融機関側から融資を依頼することができるようになる。
なお、別の実施例として、Ｓ２２１０の判定不能の処理後に、ＭＣＩＦ共同システム（後述）で再判定する処理を設けてもよい。

図４は、本発明の一実施例による融資を提案するフローチャートの一例を示す。

Ｓ４０１０では、来期の決算が好決算であると期待できると予測された法人を取得する。

Ｓ４０２０では、（少なくとも２段階で）好決算のランクを判定する。好決算のランクの判定基準は、例えば、今期決算と来期決算との差異が所定以上あれば、Ａランクの好決算であると判定する一方で、それ以外であれば、Ｂランクの好決算であると判定してもよい。別の態様では、売上高が増えて（増収）且つ最終利益が増えた（増益）場合をＡランクとし、増収のみ又は増益のみの場合をＢランクとしてもよい。

Ｓ４０３０では、判定ランクに基づいて、予め決まった融資期間と融資額を決定する。更に、判定ランクの高いＡランクの法人に対しては、Ｂランクの法人よりも長期間の融資期間で且つ高額の融資金額を提供することができるようにしてもよい。

また、融資先から正確な決算情報を入手した場合には、予測された融資額の基礎となったデータを上書きすることにより、改めて、決算予測したりランクを判定したりするように構成してもよい。

図６は、本発明の一実施例における金融決済データの構造を示す。

本実施例のデータの構造は、受取人（名称）３１０、依頼人（名称）３２０、通信種目３３０、勘定日３４０、決済金額３５０、依頼元金融機関３６０からなる。受取人３１０は、金融決済の依頼先の法人の名称を示す（ここでは、法人Ｃ、Ｙは、金融機関Ｚに口座を有していると仮定する。）。依頼人３２０は、金融決済の依頼元の法人の名称を示す。通信種目３３０は、金融決済の種類を示している。勘定日３４０は、金融機関が金融処理を行った日を示す。決済金額３５０は、支払元（依頼人）から支払先（受取人）に支払われた金額を示す。依頼元金融機関３６０は、依頼人が口座を有している金融機関である。

特に、図６は、他の金融機関から振り込みがあった場合の金融決済データの構造を示している。図６に示されているように、一般に、振り込み元（依頼人）は、カタカナで表記されており、漢字若しくはその他で表記された正式商号は不明である。
本実施例によれば、迅速な事業性評価が可能になる。

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

本実施例のＭＣＩＦ共同化システム２０００は、管理サーバ４００と、商号予測部１１５０と、金融機関所在地ＤＢ１２５０と、複数の共用顧客情報ＤＢ１３００とを備える。

共用顧客情報ＤＢ１３００は、ＭＣＩＦ共同化システム２０００とネットワークに接続されている各金融機関の情報処理装置から提供される。共用顧客情報ＤＢ１３００に記憶されているデータは、例えば、対応する金融機関（Ａ銀行、Ｂ銀行など）の他社顧客情報ＤＢ１２７０から提供される。

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

ＭＣＩＦ共同化システム２０００の金融機関所在地ＤＢ１２５０は、各金融機関の情報処理装置１０００から提供されたデータを取得するように構成される。

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

本実施例では、実施例１のＳ２２１０で商号予測が判定不能となった場合に、ＭＣＩＦ共同システムを用いて、商号を予測する処理を説明する。

一致度の高い商号がみつからなかった場合は、ある金融機関の情報処理装置１０００は、ＭＣＩＦ共同システムに対して、判定したい仮の商号について、他社の金融機関情報を提供すると共に、正式商号を問いあわせる。ＭＣＩＦ共同システムは、当該問いあわせを受けると、他社の金融機関の所在地を基に、当該所在地から所定範囲内にある法人一覧を各金融機関のＤＢから取得する。そして、最も一致度の高い法人を特定して、そのデータを情報処理装置１０００に送信する。もし、ＭＣＩＦ共同システムでも判定不能の場合は、判定不能である旨を情報処理装置１０００に返信し、情報処理装置１０００は、再度、判定不能であるとして、処理を終了してもよい。

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

本実施例のＭＣＩＦ共同化システム２０００は、管理サーバ４００と、決算予測および決算ランク判定部１１６０と、複数の共用顧客情報ＤＢ１３００とを備える。

本実施例では、実施例１のＳ７０６０で決算予測が判定不能となった場合に、ＭＣＩＦ共同システムを用いて、来期の決算情報を再判定する処理を説明する。

特に今期のトランザクション量が足りない場合は、ある金融機関の情報処理装置１０００は、ＭＣＩＦ共同システムに対して、判定したい法人のトランザクションについての入金総額、出金総額について問いあわせる。ＭＣＩＦ共同システムは、当該問いあわせを受けると、ＭＣＩＦ共同化システム２０００の各社の共用顧客情報ＤＢ１３００から資金の送受信に関する金融決済データを取得する。ここでは、個別の金融決済データは提供されておらず、各金融機関が把握している入金総額、出金総額は、決算情報（法人の売上）に関するものであるとし、保険の支払い等の売上以外の情報は含まれない。そして、全ての共用顧客情報ＤＢ１３００から取得したデータを合計した入金総額、出金総額のみのデータを、問い合わせを送信した情報処理装置１０００に送信する。情報処理装置１０００は、当該データを受信すると、当該受信データを追加して、再度、来期の決算情報を計算する。ここで、もし、受信データを追加してもデータ量が不十分であると判定したときは、再度、判定不能であるとして、処理を終了してもよい。

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

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

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

情報処理装置１０００、画面表示部１１１０、入力部１１２０、法人情報管理部１１３０、法人番号付与部１１４０、商号予測部１１５０、決算予測及び決算ランク判定部１１６０、金融口座ＤＢ１２１０、法人情報ＤＢ１２２０、法人番号ＤＢ１２３０、決済情報ＤＢ１２４０、金融機関所在地ＤＢ１２５０、自社顧客情報ＤＢ１２６０、他社顧客情報ＤＢ１２７０、法人決算情報ＤＢ１２８０、好決算法人ＤＢ１２９０、共用顧客情報ＤＢ１３００、ＭＣＩＦ共同化システム２０００、管理サーバ４００

Claims (6)

1. 自社顧客の正式商号に対して名寄せ処理をして、当該自社顧客の正式商号と類似する類似商号を取得する手段と、
   前記自社顧客の正式商号に対して法人番号を付与する手段と、
   前記類似商号に対しても前記法人番号を付与する手段と、
   前記正式商号を前記法人番号と共に記憶すると共に前記類似商号も前記法人願号と記憶する手段と、
   を備えることを特徴とする情報処理装置。
2. 金融決済データを送受信する情報処理装置において、
   金融決済データから他社顧客の仮の商号を取得する手段と、
   前記他社の店舗の所在地情報を基に、前記仮の商号から正式商号を予測する手段と、
   他社顧客に対して法人番号を付与する手段と、
   前記正式商号を、他社顧客の法人番号と共に記憶する手段と、
   を備えることを特徴とする情報処理装置。
3. 法人番号を取得する手段と、
   金融決済データの変化に応じて、法人番号を基に、企業業績データベースから、対象法人の前期の決算情報と前期決算期間の金融決済データとを取得する手段と、
   前記決算情報と金融決済データとに基づいて、対象となる法人の今期の決算情報を予測する手段と、
   を備えることを特徴とする情報処理装置。
4. 請求項１〜３のいずれか一項記載の情報処理装置において、前記予測された決算情報の結果に応じて、
   前記予測された業績を基に、融資の可否を判断する手段と、
   融資可能と判断された場合には、前記予測された業績を基に、融資内容を決定する手段を備えることを特徴とする情報処理装置。
5. 複数の情報処理装置とサーバとからなるシステムにおいて、
   前記サーバは、
   仮の商号から正式商号を予測する手段と、
   金融機関の所在地を記憶する手段と、
   前記複数の情報処理装置から受信した顧客情報を記憶する手段と、
   を備え、
   前記サーバは、前記複数の情報処理装置のひとつから仮の商号に関するデータを受信すると、前記金融機関の店舗の所在地情報を基に、前記仮の商号から正式商号を予測することを特徴とするシステム。
6. 複数の情報処理装置とサーバとからなるシステムにおいて、
   前記サーバは、
   決算を予測する手段と、
   前記複数の情報処理装置から受信した顧客情報を記憶する手段と、
   を備え、
   前記サーバは、前記複数の情報処理装置のひとつから商号を受信すると、当該商号に対応する決算情報を予測することを特徴とするシステム。