以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
図1は、融資判定装置100の通信環境の一例を概略的に示す。融資判定装置100は情報処理装置の一例である。
本実施形態に係る融資判定装置100は、事業者に対する融資の可否を判定する。融資判定装置100は、例えば、事業者の通信端末20から、融資申込金額、融資希望日、及び融資期間等を含む融資申込データを受信して、当該事業者に対する融資の可否を判定する。融資判定装置100が融資の可否を判定する対象となる事業者を対象事業者と記載する場合がある。
通信端末20は、通信機能を有していればどのような端末であってもよく、例えば、PC(Personal Computer)、タブレット端末、及びスマートフォン等の携帯電話等である。融資判定装置100は、ネットワーク10を介して通信端末20と通信する。ネットワーク10は、インターネットを含んでよい。ネットワーク10は、電話網を含んでよい。ネットワーク10は、専用網を含んでよい。
融資判定装置100は、事業者の融資返済の蓋然性を示す蓋然性情報を生成して、当該蓋然性情報に基づいて事業者に対する融資の可否を判定してよい。蓋然性情報は、例えば、事業者の将来のキャッシュフロー(CFと記載する場合がある。)を示す将来CF情報である。また、蓋然性情報は、例えば、事業者の融資返済の蓋然性を示すスコアである。スコアは、事業者の融資返済の蓋然性の度合いを示すものであればどのようなものであってもよい。
融資判定装置100は、例えば、対象事業者の会計に関する会計データを用いて蓋然性情報を生成する。融資判定装置100は、複数の事業者の会計データを管理する会計データ管理装置210から、ネットワーク10を介して対象事業者の会計データを受信してよい。
会計データ管理装置210は、いわゆる会計ソフトウエア及びいわゆるクラウド型会計ソフトウエア並びにその関連ソフトウエアを用いて、事業者及び会計事務所等によって入力された会計データを管理してよい。会計データ管理装置210は、会計ソフトウエア、クラウド型会計ソフトウエア及びその関連ソフトウエアを介さずに、事業者及び会計事務所等から提供された会計データを管理してもよい。
融資判定装置100は、自らが複数の事業者の会計データを管理してもよい。すなわち、融資判定装置100は、会計データ管理装置210の機能を有してもよい。
融資判定装置100は、例えば、対象事業者による取引に関する取引データを用いて蓋然性情報を生成する。融資判定装置100は、複数の事業者の取引データを管理する取引データ管理装置220から、ネットワーク10を介して対象事業者の取引データを受信してよい。
取引データ管理装置220は、いわゆる販売管理ソフトウエア及びいわゆるクラウド型販売管理ソフトウエア、並びにその関連ソフトウエアを用いて事業者及び会計事務所等によって入力された取引データを管理してよい。取引データ管理装置220は、会計ソフトウエア及びクラウド型会計ソフトウエア、並びにその関連ソフトウエアを用いて事業者及び会計事務所等によって入力された取引データを管理してもよい。取引データ管理装置220は、販売管理ソフトウエア、クラウド型販売管理ソフトウエア、会計ソフトウエア、クラウド型会計ソフトウエア及びその関連ソフトウエアを介さずに、事業者及び会計事務所等から提供された取引データを管理してもよい。
融資判定装置100は、自らが複数の事業者の取引データを管理してもよい。すなわち融資判定装置100は、取引データ管理装置220の機能を有してもよい。
融資判定装置100は、例えば、対象事業者の金融機関口座に対する入出金の履歴を含む金融機関データを用いて蓋然性情報を生成する。金融機関口座とは、銀行及び信用金庫等の金融機関において管理される口座であってよい。融資判定装置100は、複数の事業者の金融機関データを管理する金融機関データ管理装置230から、ネットワーク10を介して対象事業者の金融機関データを受信してよい。
金融機関データ管理装置230は、複数の金融機関から、複数の事業者の金融機関データを受信して管理してよい。金融機関データ管理装置230は、複数の事業者のそれぞれから、金融機関による証明を受けている金融機関データを受信して管理してもよい。
融資判定装置100は、自らが複数の事業者の金融機関データを管理してもよい。すなわち融資判定装置100は、金融機関データ管理装置230の機能を有してもよい。
融資判定装置100は、例えば、第三者機関によって生成された対象事業者の信用情報データを用いて蓋然性情報を生成する。融資判定装置100は、複数の事業者の信用情報データを管理する信用情報管理装置240から、ネットワーク10を介して対象事業者の信用情報データを受信してよい。
信用情報管理装置240は、例えば、複数の事業者の信用情報データを生成して提供するサービスを実施する業者によって管理される。当該業者による信用情報データの生成法は任意の方法であってよい。
融資判定装置100は、自らが複数の事業者の信用情報データを管理してもよい。すなわち融資判定装置100は、信用情報管理装置240の機能を有してもよい。
融資判定装置100は、例えば、対象事業者に対応する事業者群のCFの特徴を示す特徴データを用いて蓋然性情報を生成する。融資判定装置100は、複数の事業者群の特徴データを管理する事業者群データ管理装置250から、ネットワーク10を介して対象事業者に対応する事業者群の特徴データを受信してよい。
事業者群とは、例えば、業種別の事業者のグループを示す。例えば、対象事業者が建築会社である場合、対象事業者に対応する事業者群は建築業であってよい。事業者群のCFの特徴は、例えば、建築業は3月に売り上げが向上する傾向にある等の業種毎のCFの変動の特徴であってよい。特徴データは、例えば、建築業の3月の売上を20%増にする等の、変動の内容を具体化したデータであってよい。
なお、事業者群は、業種別の事業者のグループに限らず、他のグループを示してもよい。例えば、事業者群は、系列毎の事業者のグループであってもよい。また、事業者群は、事業者のグループ分けを担う担当者によって決定された事業者のグループであってもよい。
事業者群データ管理装置250は、例えば、複数の事業者のそれぞれについて、各種データを分析することによって、特徴データを生成する。事業者群データ管理装置250は、例えば、複数の事業者の会計データを分析して、事業者群毎の特徴データを生成する。事業者群データ管理装置250は、独自に複数の事業者の会計データを収集してもよく、また、会計データ管理装置210から複数の事業者の会計データを受信してもよい。また、事業者群データ管理装置250は、特徴データの生成を担う担当者によって生成された特徴データを管理してもよい。
融資判定装置100は、自らが複数の事業者群の特徴データを管理してもよい。すなわち融資判定装置100は、事業者群データ管理装置250の機能を有してもよい。
融資判定装置100は、例えば、対象事業者の取引先による他事業者との取引に関する取引関係データを用いて蓋然性情報を生成する。取引関係データは、例えば、事業者間の回収実績及び支払実績等を含む。融資判定装置100は、複数の事業者間の取引関係データを管理する取引関係管理装置260から、ネットワーク10を介して、対象事業者の取引先の取引関係データを受信してよい。
取引関係管理装置260は、複数の事業者間の取引関係を管理する。そして、取引関係管理装置260は、複数の事業者のそれぞれについて、事業者とその取引先との取引に関する取引関係データを管理する。
複数の事業者間の取引関係は、例えば、ある事業者と、その事業者と取引関係にある事業者との対応付けを含む。取引関係管理装置260が管理する取引関係によれば、ある事業者と取引関係にある事業者を特定可能であり、また、さらにその取引関係にある事業者と取引関係にある事業者を特定可能である。このように、取引関係管理装置260が管理する取引関係によれば、ある事業者に対して、連鎖的に取引関係にある事業者を特定することができる。
融資判定装置100は、自らが複数の事業者間の取引関係及び取引関係データを管理してもよい。すなわち融資判定装置100は、取引関係管理装置260の機能を有してもよい。
融資判定装置100は、上述した複数種類のデータを用いて蓋然性情報を生成してよい。融資判定装置100は、生成した蓋然性情報を用いて、対象事業者への融資の可否を判定してよい。このように、本実施形態に係る融資判定装置100によれば、複数種類のデータを用いて生成された蓋然性情報を用いて対象事業者への融資の可否が判定されるので、融資をしたものの回収できないような事態の発生確率を低減することができる。また、融資するか否かについて過度に厳しい基準を設ける必要をなくすことができ、本来であれば融資を受けられる事業者がなかなか融資を受けられないような事態の発生確率を低減することができる。
口座管理装置300は、複数の事業者の口座を管理する。口座管理装置300は、事業者からの要求に応じて、当該事業者用の口座を開設してよい。口座管理装置300は、例えば、1又は複数の銀行口座内において、複数の事業者の口座残高を管理する。具体例として、口座管理装置300は、N個の銀行口座内において、N事業者又はNより多い数の事業者の口座残高を管理する。口座管理装置300は、口座管理装置300の管理者名義の銀行口座内において、複数の事業者の口座残高を管理してよい。
事業者は、口座管理装置300によって管理されている口座に対して銀行口座から入金したり、口座管理装置300によって管理されている口座から銀行口座に出金したりすることができる。また、事業者は、他の事業者との取引における決済口座として、口座管理装置300が管理している口座を指定できる。すなわち、事業者は、口座管理装置300によって管理されている口座を通じて、取引の対価として支払いを受けることができ、また、支払いをすることができる。
口座管理装置300は、任意の取引プラットフォームと連携可能であってよく、口座管理装置300と任意の取引プラットフォームとの間では、取引内容を一意に特定することができる。口座管理装置300と任意の取引プラットフォームが連携する代わりに、口座管理装置300が取引プラットフォームを兼ねてもよい。
口座管理装置300は、例えば、口座を管理している事業者から、他の事業者への支払要求を受け付けた場合に、口座残高が不足していなければ支払処理を実行する。口座管理装置300は、口座残高が不足している場合、事業者への融資可否を判定して、融資可と判定した場合、融資金額を口座残高に加算してよい。
口座管理装置300は、融資判定装置100と同様の手法を用いて、事業者の融資返済の蓋然性を示す蓋然性情報を生成し、当該蓋然性情報に基づいて事業者への融資の可否を判定してよい。例えば、口座管理装置300は、事業者から、不足分の金額に相当する融資申込金額を含む融資申込データを受信したときと同様に、当該事業者への融資の可否を判定する。
口座管理装置300は、不足分以上の融資金額を口座残高に加算した後、支払処理を実行してよい。また、口座管理装置300は、支払処理実行後、予め定められた返済ルールに従って、融資返済処理を実行してよい。例えば、口座管理装置300は、事業者の口座残高が融資金額よりも多い場合に、融資金額の全額を返済する融資返済処理を実行する。また、例えば、口座管理装置300は、事業者の口座残高が融資金額よりも少ない場合に、融資金額の一部を返済する融資返済処理を実行する。また、口座管理装置300は、支払処理実行後、事業者の口座残高が融資金額よりも少ない場合に、予め定められた金利ルールに従って、金利支払処理を実行してよい。
このように、口座管理装置300は複数の事業者の口座を管理し、事業者から他の事業者への支払要求を受け付けたときに、口座残高が不足している場合には、当該事業者への融資の可否を自動的に判定して、融資処理を実行する。これにより、従来よりも少ない手順で、事業者が融資を受けて取引を行うことができる仕組みを提供できる。
図2は、過去CF情報182及び将来CF情報184の一例を概略的に示す。ここでは、融資判定装置100による過去CF情報182及び将来CF情報184の生成処理の流れの一例を説明する。
融資判定装置100は、対象事業者の会計データに含まれる預貯金に関連する勘定科目のデータを用いて、対象事業者の過去のキャッシュフローを示す過去CF情報182を生成する。融資判定装置100は、過去CF情報182と対象事業者の金融機関データとを比較して、不整合がある場合には、金融機関データに合わせて過去CF情報を補正してよい。
融資判定装置100は、過去CF情報182に基づいて将来CF情報184を生成する。融資判定装置100は、例えば、複数年分の過去CF情報182から1年分の将来CF情報184を生成する。融資判定装置100は、複数年分の過去CF情報182を平均化したり、複数年分の過去CF情報182から予測したりすることによって、将来CF情報184を生成してよい。融資判定装置100は、例えば、過去CF情報182における売上高の発生パターン、仕入れの発生パターン、及び経費の発生パターン等を導出して、これらを用いて将来CF情報184を生成してよい。
融資判定装置100は、会計データに含まれる勘定科目のうち、将来の預貯金残高の増減に関する勘定科目のデータをさらに用いて将来CF情報184を生成してよい。融資判定装置100は、例えば、売上債権に関する勘定科目及び仕入債務に関する勘定科目を用いて、将来CF情報184を生成する。
融資判定装置100は、対象事業者の取引データを用いて将来CF情報184を補正してよい。融資判定装置100は、例えば、取引データに含まれる見積データ及び受注データを用いて将来CF情報184を補正する。融資判定装置100は、見積データ及び受注データから、対象事業者の、見積りに対する受注の確率を示す受注率を算出し、当該受注率を用いて将来CF情報184を補正してよい。また、融資判定装置100は、例えば、取引データに含まれる請求データ及び見積データを用いて将来CF情報184を補正する。融資判定装置100は、請求データ及び見積データから、対象事業者の、見積りに対する受注の確率を示す受注率を算出し、当該受注率を用いて将来CF情報184を補正してよい。また、融資判定装置100は、請求データに基づいて、対象事業者の、請求に対する入金の確率を示す請求入金率を算出し、当該請求入金率を用いて将来CF情報184を補正してよい。
融資判定装置100は、対象事業者の取引相手を特定し、取引相手による他事業者との取引に関する取引関係データを用いて、将来CF情報184を補正してよい。融資判定装置100は、例えば、取引相手による他事業者への入金状況を用いて将来CF情報184を補正する。また、融資判定装置100は、例えば、取引相手の取引相手の属性情報を用いて将来CF情報184を補正する。属性情報とは、事業者の規模及び事業者の信用度等である。
融資判定装置100は、対象事業者に対応する事業者群の特徴データを用いて将来CF情報184を補正してよい。融資判定装置100は、例えば、特徴データが示す売上高の発生パターン、仕入れの発生パターン、及び経費の発生パターン等を用いて将来CF情報184を補正する。
上述したように、融資判定装置100は、複数種類のデータを用いて将来CF情報184を生成する。なお、複数種類のデータを用いて将来CF情報184を生成するとは、上述したように、複数種類のデータの一部を用いて将来CF情報184を生成し、生成した将来CF情報184を複数種類のデータの他のデータを用いて補正することによって、最終的な将来CF情報184を生成することを含む。
融資判定装置100は、例えば、対象事業者から受信した融資申込データから融資の返済予定を作成し、将来CF情報184によって当該返済予定が実現可能か否かを判定することによって、融資の可否を判定してよい。融資判定装置100は、信用情報データをさらに用いて融資の可否を判定してもよい。また、融資判定装置100は、対象事業者に対する融資の履歴をさらに用いて融資の可否を判定してもよい。
図3は、融資申込データのデータ項目22の一例を概略的に示す。図3では、各データ項目22のデータ値の例もともに示す。
融資申込データは、対象者を識別するための対象者IDを含んでよい。融資申込データは、対象者の名称を含む対象者情報を含んでよい。融資申込データは、融資申込額を含んでよい。融資申込データは、融資希望日を含んでよい。融資申込データは、融資期間を含んでよい。融資申込データは、これら以外のデータ項目を含んでもよい。
図4は、会計データに含まれる仕訳データのデータ項目212の一例を概略的に示す。図4では、各データ項目212のデータ値の例もともに示す。
仕訳データは、仕訳データを識別するためのデータIDを含んでよい。仕訳データは、取引日付を含んでよい。仕訳データは、借方/貸方区分を含んでよい。仕訳データは、勘定科目を含んでよい。仕訳データは、金額を含んでよい。仕訳データは、これら以外のデータ項目を含んでもよい。
図5は、会計データに含まれる残高データのデータ項目214一例を概略的に示す。図5では、各データ項目214のデータ値の例もともに示す。
残高データは、残高データを識別するためのデータIDを含んでよい。残高データは、残高日付を含んでよい。残高データは、借方/貸方区分を含んでよい。残高データは、勘定科目を含んでよい。残高データは、金額を含んでよい。残高データは、これら以外のデータ項目を含んでもよい。
図6は、取引データに含まれる請求データのデータ項目222の一例を概略的に示す。図6では、各データ項目222のデータ値の例もともに示す。
請求データは、請求データを識別するためのデータIDを含んでよい。請求データは、取引日付を含んでよい。請求データは、請求先の名称を含む請求先情報を含んでよい。請求データは、請求内容を含んでよい。請求データは、金額を含んでよい。請求データは、これら以外のデータ項目を含んでもよい。
図7は、取引データに含まれる見積データのデータ項目224の一例を概略的に示す。図7では、各データ項目224のデータ値の一例もともに示す。
見積データは、見積データを識別するためのデータIDを含んでよい。見積データは、見積日付を含んでよい。見積データは、見積先の名称を含む見積先情報を含んでよい。見積データは、見積内容を含んでよい。見積データは、金額を含んでよい。見積データは、これら以外のデータ項目を含んでもよい。
図8は、金融機関データのデータ項目232の一例を概略的に示す。図8は、各データ項目232のデータ値の一例もともに示す。
金融機関データは、口座を識別する口座IDを含んでよい。金融機関データは、残高日付を含んでよい。金融機関データは、入金/出金区分を含んでよい。金融機関データは、金額を含んでよい。金融機関データは、これら以外のデータ項目を含んでもよい。
図9は、信用情報データのデータ項目242の一例を概略的に示す。図9は、各データ項目242のデータ値の例もともに示す。
信用情報データは、信用情報データを識別するためのデータIDを含んでよい。信用情報データは、対象者の名称を含む対象者情報を含んでよい。信用情報データは、対象者の信用度を示す評点を含んでよい。信用情報データは、これら以外のデータ項目を含んでもよい。
図10は、過去履歴データのデータ項目170の一例を概略的に示す。図10は、各データ項目170のデータ値の例もともに示す。
過去履歴データは、対象者を識別するための対象者IDを含んでよい。過去履歴データは、対象者の名称を含む対象者情報を含んでよい。過去履歴データは、融資金額を含んでよい。過去履歴データは、融資日を含んでよい。過去履歴データは、返済履歴を含んでよい。過去履歴データは、これら以外のデータ項目を含んでもよい。
図11は、事業者群の特徴データのデータ項目252の一例を概略的に示す。図11は、各データ項目252のデータ値の例もともに示す。
特徴データは、事業者群の業種を識別する業種IDを含んでよい。特徴データは、補正する対象の期間を示す補正期間を含んでよい。特徴データは、補正する対象の項目を示す補正対象を含んでよい。特徴データは、補正の内容を示す補正情報を含んでよい。図11に示すデータ値は、業種IDが00001の事業者群について、3月の売上高を20%増加させる例を示す。特徴データは、これら以外のデータ項目を含んでもよい。
図12は、取引関係データのデータ項目262の一例を概略的に示す。図12は、各データ項目262のデータ値の一例もともに示す。
取引関係データは、事業者を識別する事業者IDを含んでよい。取引関係データは、事業者名を含んでよい。取引関係データは、事業者IDによって識別される事業者の取引先の事業者IDである取引先事業者IDを含んでよい。取引関係データは、取引先事業者名を含んでよい。取引関係データは、事業者IDによって識別される事業者による取引先事業者IDによって識別される事業者に対する回収履歴を含んでよい。回収履歴は、例えば、事業者IDによって識別される事業者による、取引先事業者IDによって識別される事業者に対する請求回数と、請求金額の回収数との割合である。取引関係データは、これら以外のデータ項目を含んでもよい。
図13は、融資判定装置100による処理の流れの一例を概略的に示す。ここでは、融資判定装置100が、通信端末20から融資申込データを取得して、当該融資申込データに対する結果を通信端末20に通知するまでの流れの一例を説明する。図13に示す各処理は、融資判定装置100が備える制御部が主体となって実行される。
ステップ(ステップをSと省略して記載する場合がある。)1302では、融資を希望する事業者が通信端末20によって送信した融資申込データを取得する。S1304では、対象事業者の会計データを取得する。S1306では、会計データに基づいて過去CF情報を生成する。
S1308では、各種データを取得する。融資判定装置100は、対象事業者の取引データ、金融機関データ、信用情報データ、及び過去履歴データと、対象事業者に対応する事業者群の特徴データと、対象事業者の取引先の取引関係データとのうちの少なくともいずれかを取得する。S1310では、S1306において生成した過去CF情報と、S1308において取得した各種データとを用いて将来CF情報を生成する。
S1312では、S1310において生成した将来CF情報に基づいて、対象事業者に対する融資可否を判定する。融資可と判定した場合、S1314に進み、融資否と判定した場合、S1316に進む。
S1314では、融資判定装置100が、対象事業者に対して融資手続を開始する。融資判定装置100は、例えば、S1302において取得した融資申込データに対して、融資可であることを通知する内容と、融資に必要となる情報を要求する内容とを含む融資手続データを通信端末20に送信する。融資手続データに含まれる融資に必要となる情報は、通常の融資申込に必要な情報よりも少ない情報であってよい。
S1316では、対象事業者に対して融資否である旨を通知する。融資判定装置100は、例えば、S1302において取得した融資申込データに対して、融資否であること通知する通知データを通信端末20に送信する。
図14は、融資判定装置100による処理の流れの他の一例を概略的に示す。ここでは、図13に示す例に対して、融資判定装置100が会計データを用いずに処理を実行する場合の流れを説明する。ここでは、図13に示す処理の流れと異なる点を主に説明する。
S1402では、通信端末20によって送信された融資申込データを取得する。S1404では、対象事業者の取引データを取得する。S1406では、対象事業者の金融機関データを取得する。
S1408では、S1406において取得した金融機関データを用いて、過去CF情報を生成する。S1410では、各種データを取得する。融資判定装置100は、対象事業者の信用情報データ及び過去履歴データと、対象事業者に対応する事業者群の特徴データと、対象事業者の取引先の取引関係データとのうちの少なくともいずれかを取得する。S1412では、S1408において生成した過去CF情報と、S1410において取得した各種データとを用いて将来CF情報を生成する。
S1414では、S1412において生成した将来CF情報に基づいて、対象事業者に対する融資可否を判定する。融資可と判定した場合、S1416に進み、融資否と判定した場合、S1418に進む。S1416では、対象事業者に対して融資手続を開始する。S1418では、対象事業者に対して融資否である旨を通知する。
図15は、融資判定装置100の機能構成の一例を概略的に示す。融資判定装置100は、申込データ取得部102、会計データ取得部104、金融機関データ取得部106、取引データ取得部108、受注率算出部110、請求入金率算出部112、取引関係データ取得部114、事業者群特定部116、特徴データ取得部118、過去CF情報生成部120、蓋然性情報生成部130、要求データ送信部142、融資可否判定部144、信用度取得部146、融資処理実行部148、融資後管理部150、返済情報生成部152、及び返済情報送信部154を備える。なお、融資判定装置100がこれらのすべての構成を備えることは必須とは限らない。
申込データ取得部102は、融資申込データを取得する。申込データ取得部102は、通信端末20から融資申込データを受信してよい。申込データ取得部102は、通信端末20から受信して格納していた融資申込データを読み出してもよい。
会計データ取得部104は、対象事業者の会計データを取得する。会計データ取得部104は、例えば、申込データ取得部102が取得した融資申込データによって対象事業者を特定し、当該対象事業者の会計データを会計データ管理装置210に要求して、会計データ管理装置210から会計データを受信する。また、融資判定装置100が複数の事業者の会計データを管理している場合、会計データ取得部104は、管理下の会計データから対象事業者の会計データを読み出してよい。また、会計データ取得部104は、融資申込データを送信した通信端末20から会計データを受信してもよい。
金融機関データ取得部106は、対象事業者の金融機関データを取得する。金融機関データ取得部106は、例えば、申込データ取得部102が取得した融資申込データによって対象事業者を特定し、当該対象事業者の金融機関データを金融機関データ管理装置230に要求して、金融機関データ管理装置230から金融機関データを受信する。また、融資判定装置100が複数の事業者の金融機関データを管理している場合、金融機関データ取得部106は、管理下の金融機関データから対象事業者の金融機関データを読み出してよい。また、金融機関データ取得部106は、融資申込データを送信した通信端末20から、金融機関による証明を受けている金融機関データを受信してもよい。
取引データ取得部108は、対象事業者の取引データを取得する。取引データ取得部108は、例えば、申込データ取得部102が取得した融資申込データによって対象事業者を特定し、当該対象事業者の取引データを取引データ管理装置220に要求して、取引データ管理装置220から取引データを受信する。また、融資判定装置100が複数の事業者の取引データを管理している場合、取引データ取得部108は、管理下の取引データから対象事業者の取引データを読み出してよい。また、取引データ取得部108は、融資申込データを送信した通信端末20から、取引データを受信してもよい。取引データ取得部108は、取引データとして、見積データを取得してよい。また、取引データ取得部108は、取引データとして、請求データを取得してよい。また、取引データ取得部108は、取引データとして、受注データを取得してもよい。受注データは、他の事業者等から受注したことを示すデータであってよい。例えば、受注データは、見積データが示す見積りに対して受注したことを示す。受注データは、受注データを識別するためのデータIDを含んでよい。受注データは、受注日付を含んでよい。受注データは、発注元の名称を含む発注元情報を含んでよい。受注データは、受注内容を含んでよい。受注データは、金額を含んでよい。受注データは、これら以外のデータ項目を含んでもよい。
受注率算出部110は、取引データ取得部108が取得した取引データに基づいて、対象事業者の受注率を算出する。受注率算出部110は、取引データに含まれる見積データ及び受注データを用いて受注率を算出してよい。例えば、受注率算出部110は、見積りの回数を、見積りに対応する受注の回数で除算することによって受注率を算出する。受注率算出部110は、取引データに含まれる見積データ及び請求データを用いて受注率を算出してもよい。例えば、受注率算出部110は、見積りの回数を、見積りに対応する請求の回数で除算することによって受注率を算出する。受注率算出部110は、例えば、見積データに対応する受注データがない場合に、見積データ及び請求データを用いて受注率を算出してよい。
取引データは、見積りと受注の対応関係を含んでよく、受注率算出部110は、当該対応関係を参照することによって、見積りに対応する受注の回数を特定してよい。取引データが見積りと受注の対応関係を含まない場合、受注率算出部110は、見積データ中の見積日付と受注データ中の受注日付との関係と、見積データ中の見積先、見積内容、及び金額と、受注データ中の発注元、受注内容、及び金額との一致とを確認することによって、見積りに対応する受注を特定してよい。取引データは、見積りと請求の対応関係を含んでよく、受注率算出部110は、当該対応関係を参照することによって、見積りに対応する請求の回数を特定してよい。取引データが見積りと請求の対応関係を含まない場合、受注率算出部110は、見積データ中の見積日付と請求データ中の請求日付との関係と、見積データ中の見積先、見積内容、及び金額と、請求データ中の請求先、請求内容、及び金額との一致とを確認することによって、見積りに対応する請求を特定してよい。
請求入金率算出部112は、取引データ取得部108が取得した取引データに基づいて、対象事業者の請求入金率を算出する。請求入金率算出部112は、取引データに含まれる請求データを用いて請求入金率を算出してよい。例えば、請求入金率算出部112は、請求の回数を、入金が行われた請求の回数で除算することによって請求入金率を算出する。
請求データは、入金が行われたか否かの情報を含んでよく、請求入金率算出部112は、当該情報を参照することによって入金が行われた請求の回数を特定してよい。請求データが当該情報を含まない場合、請求入金率算出部112は、例えば、金融機関データ取得部106が取得した金融機関データを参照することによって、請求に対して入金が行われたか否かを特定してよい。
取引関係データ取得部114は、対象事業者の取引相手の取引関係データを取得する。取引関係データ取得部114は、取引データ取得部108が取得した取引データを用いて対象事業者の取引相手を特定し、特定した取引相手の取引関係データを取引関係管理装置260に要求して、取引関係管理装置260から取引関係データを受信してよい。また、融資判定装置100が複数の事業者間の取引関係及び取引関係データを管理している場合、取引関係データ取得部114は、管理下の取引関係データから、対象事業者の取引相手の取引関係データを読み出してよい。
事業者群特定部116は、対象事業者に対応する事業者群を特定する。事業者群特定部116は、例えば、複数の事業者群が登録されているリストを参照して、当該リストに含まれる事業者群のうち、対象事業者に対応する事業者群を選択する。また、事業者群特定部116は、複数の事業者群のそれぞれに対応する事業者が登録されているリストを参照して、対象事業者に対応する事業者群を特定してもよい。
事業者群特定部116は、対象事業者の業種情報及び規模情報等を用いて、対象事業者に対応する事業者群を特定してもよい。事業者群特定部116は、対象事業者の業種情報及び規模情報を、通信端末20から受信してよい。また、事業者群特定部116は、複数の事業者の業種情報及び規模情報を含む事業者情報を予め格納しておき、当該事業者情報から、対象事業者の業種情報及び規模情報を取得してもよい。
特徴データ取得部118は、事業者群特定部116によって特定された事業者群の特徴データを取得する。特徴データ取得部118は、例えば、事業者群特定部116によって特定された事業者群の特徴データを事業者群データ管理装置250に要求して、事業者群データ管理装置250から特徴データを受信する。また、融資判定装置100が複数の事業者群の特徴データを管理している場合、特徴データ取得部118は、管理下の特徴データから、事業者群特定部116によって特定された事業者群の特徴データを読み出してよい。
過去CF情報生成部120は、対象事業者の過去CF情報を生成する。過去CF情報生成部120は、例えば、会計データ取得部104によって取得された会計データに基づいて、過去CF情報を生成する。過去CF情報生成部120は、会計データに含まれる預貯金に関連する勘定科目のデータを用いて、基準日の現預金残高を起点として異動明細を加減算していくことによって、予め定められた期間毎の現預金残高を示す過去CF情報を生成してよい。例えば、過去CF情報生成部120は、年頭の現預金残高を起点として、移動明細を加減算していくことによって、日毎、週毎又は月毎の現預金残高を示す過去CF情報を生成する。なお、ここでいう現預金残高は、現金と預貯金の合計を示すが、現金が0の場合も含んでよい。すなわち、現預金残高は、預貯金残高のみを示してもよい。
過去CF情報生成部120は、金融機関データ取得部106によって取得された金融機関データに基づいて過去CF情報を生成してもよい。過去CF情報生成部120は、例えば、会計データ取得部104が会計データを取得できなかった場合に、金融機関データ取得部106が取得した金融機関データを用いて過去CF情報を生成する。過去CF情報生成部120は、例えば、基準日の現預金残高を起点として、金融機関データに含まれる入金及び出勤に基づいて異動明細を加減算していくことによって、予め定められた期間毎の現預金残高を示す過去CF情報を生成する。
蓋然性情報生成部130は、対象事業者の融資返済の蓋然性を示す蓋然性情報を生成する。蓋然性情報生成部130は、将来CF情報生成部132、スコア生成部134、及び整合性確認部136を有する。なお、蓋然性情報生成部130がこれらのすべての構成を有することは必須とは限らない。
将来CF情報生成部132は、対象事業者の将来CF情報を生成する。将来CF情報生成部132は、会計データ、金融機関データ、取引データ、特徴データ、取引関係データ、過去CF情報、受注率、及び請求入金率を用いて将来CF情報を生成してよい。将来CF情報生成部132は、これらのすべてを用いて将来CF情報を生成してもよく、これらの一部を用いて将来CF情報を生成してもよい。
将来CF情報生成部132は、例えば、過去CF情報に基づいて将来CF情報を生成する。将来CF情報生成部132は、複数年分の将来CF情報を平均化したり、複数年分の過去CF情報から予測したりすることによって、将来CF情報を生成してよい。将来CF情報生成部132は、例えば、過去CF情報における売上高の発生パターン、仕入れの発生パターン、及び経費の発生パターン等を導出して、これらの少なくとも1つを用いて将来CF情報を生成する。
将来CF情報生成部132は、会計データに含まれる勘定科目のうち、将来の預貯金残高の増減に関する勘定科目のデータを用いて将来CF情報を生成してよい。例えば、融資判定装置100は、売上債権に関する勘定科目及び仕入債務に関する勘定科目を用いて、将来CF情報を生成する。
具体例として、将来CF情報生成部132は、売掛金のデータを用いて将来CF情報を生成する。将来CF情報生成部132は、例えば、売掛金の回収予定日に現預金が増加するものとして、将来CF情報を生成する。
また、将来CF情報生成部132は、買掛金のデータを用いて将来CF情報を生成してよい。将来CF情報生成部132は、例えば、買掛金の支払い予定日に現預金が減少するものとして、将来CF情報を生成する。
また、将来CF情報生成部132は、未払金のデータを用いて将来CF情報を生成してよい。将来CF情報生成部132は、例えば、未払金の支払い予定日に現預金が減少するものとして、将来CF情報を生成する。
また、将来CF情報生成部132は、前払金のデータを用いて将来CF情報を生成してよい。将来CF情報生成部132は、例えば、前払金のデータによって前払金があることが示されている場合、料金の支払い予定日に現預金が減少しないものとして、将来CF情報を生成する。具体例として、将来CF情報生成部132は、料金よりも前払金の方が多い場合、現預金が減少しないものとして将来CF情報を生成してよい。また、将来CF情報生成部132は、料金よりも前払金の方が少ない場合、現預金から、料金と前払金との差分が減少するものとして、将来CF情報を生成してよい。
将来CF情報生成部132は、見積データ及び受注率を用いて将来CF情報を生成してよい。例えば、将来CF情報生成部132は、複数の見積データのうち、受注率に見合う見積データについて、受注して入金されるものとして将来CF情報を生成する。例えば、見積りデータの数が5個であり、受注率が80%である場合、5個の見積データのうち4個について、受注して入金されるものとして将来CF情報を生成する。
将来CF情報生成部132は、請求データ及び請求入金率を用いて将来CF情報を生成してよい。例えば、将来CF情報生成部132は、複数の請求データのうち、請求入金率に見合う請求データについて、入金されるものとして将来CF情報を生成する。例えば、請求データの数が20個であり、請求入金率が95%である場合、20個の見積データのうち19個について、入金されるものとして将来CF情報を生成する。
将来CF情報生成部132は、見積データ、請求データ、受注率、及び請求入金率を用いて将来CF情報を生成してよい。例えば、将来CF情報生成部132は、複数の見積データのうち、受注率に見合う見積データについて、受注して請求するものとし、請求するものとした見積データのうち、請求入金率に見合う見積データについて、入金されるものとして将来CF情報を生成する。
将来CF情報生成部132は、対象事業者の取引相手の取引関係データを用いて、将来CF情報を生成してよい。例えば、将来CF情報生成部132は、取引関係データを用いて、対象事業者の取引相手による他事業者への入金状況を特定し、当該入金状況を用いて将来CF情報を生成する。具体例として、将来CF情報生成部132は、対象事業者の請求データの請求先となっている取引相手の取引関係データを参照し、当該取引相手の他事業者への入金状況を特定し、特定した入金状況に応じて、請求データに対する入金がなされるか否かを判定する。例えば、当該取引相手の他事業者への入金率が予め定められた閾値より低い場合、請求データに対する入金がなされないものとして、将来CF情報を生成する。これにより、対象事業者の取引相手が、対象事業者に対して入金を行わない可能性を考慮して、将来CF情報を生成することができる。なお、将来CF情報生成部132は、取引相手の他事業者への入金率に加えて、入金の対象となる金額をさらに考慮して将来CF情報を生成してもよい。
また、例えば、将来CF情報生成部132は、取引関係データを用いて、対象事業者の取引相手の取引相手を特定し、特定した取引相手の属性情報を用いて将来CF情報を生成する。具体例として、将来CF情報生成部132は、対象事業者の請求データの請求先となっている取引相手の取引関係データを参照し、当該取引相手の取引相手を特定し、特定した取引相手の属性情報に応じて、請求データに対する入金がなされるか否かを判定する。例えば、特定した取引相手の事業者規模及び信用度の少なくともいずれかと閾値とを比較し、閾値より低い場合、請求データに対する入金がなされないものとして将来CF情報を生成する。これにより、対象事業者の取引相手が、当該取引相手の取引相手から回収できない可能性を考慮して、将来CF情報を生成することができる。
また、例えば、将来CF情報生成部132は、過去CF情報と金融機関データとの差異を用いて、将来CF情報を生成する。例えば、将来CF情報生成部132は、過去CF情報と金融機関データとの差異に基づいて過去CF情報を補正し、補正後の過去CF情報を用いて将来CF情報を生成する。将来CF情報生成部132は、例えば、過去CF情報と金融機関データとの差異について、金融機関データに近づけるように過去CF情報を補正してよい。
スコア生成部134は、対象事業者の融資返済の蓋然性を示すスコアを生成する。スコア生成部134は、会計データ、金融機関データ、取引データ、特徴データ、取引関係データ、過去CF情報、受注率、及び請求入金率を用いてスコアを生成してよい。スコア生成部134は、これらのすべてを用いてスコアを生成してもよく、これらの一部を用いてスコアを生成してもよい。スコア生成部134は、任意の手法を用いてスコアを生成してよい。
整合性確認部136は、通信端末20から受信した融資申込データに対して、対象事業者への融資の可否を判定するにあたり、収集した各種データの整合性を確認する。例えば、整合性確認部136は、会計データ取得部104が取得した残高データと、金融機関データ取得部106が取得した金融機関データとの整合性を確認する。また、例えば、整合性確認部136は、取引データ取得部108が取得した請求データと、金融機関データ取得部106が取得した金融機関データ中の入金データとの整合性をチェックする。
整合性確認部136は、例えば、整合性を確認した結果、データの不整合を検出した場合、当該データを不正データと判定する。整合性確認部136は、整合の度合いに基づいて、各データについて、データの正当性の評点を生成してもよい。
整合性確認部136は、不正データと判定したデータを、要求データ送信部142に通知してよい。要求データ送信部142は、整合性確認部136によって不正データと判定されたデータについて、データの補正及びデータの追加提出依頼の少なくともいずれかを含む要求データを通信端末20に対して送信してよい。整合性確認部136は、要求データに対して、データの補正内容及び追加データを受け付けた場合、これらを用いてデータを補正してよい。
整合性確認部136は、データの正当性の評点が予め定められた閾値より低いデータを、要求データ送信部142に通知してよい。要求データ送信部142は、整合性確認部136によって、データの正当性の評点が予め定められた閾値より低いと判定されたデータについて、データの補正及びデータの追加提出依頼の少なくともいずれかを含む要求データを通信端末20に対して送信してよい。整合性確認部136は、要求データに対して、データの補正内容及び追加データを受け付けた場合、これらを用いてデータを補正してよい。
上述したように、整合性確認部136によって、対象事業者への融資可否を判定するにあたって収集したデータの整合性が確認されるので、例えば、不正申し込みを検知することができる。また、誤ったデータに基づいて、融資の可否を判定してしまうことを防止することができる。
融資可否判定部144は、蓋然性情報生成部130によって生成された蓋然性情報を用いて、申込データ取得部102が取得した融資申込データに対する、対象事業者への融資可否を判定する。例えば、融資可否判定部144は、まず、融資申込データ中の融資申込金額、融資希望日、及び融資期間を用いて融資の返済予定を作成する。具体例としては、月毎の返済額を示す返済予定を作成する。
そして、融資可否判定部144は、将来CF情報生成部132によって生成された将来CF情報によって、当該返済予定が実現可能か否かを判定することによって、融資可否を判定する。例えば、融資可否判定部144は、将来CF情報が示す各月の現預金に対して、返済予定の月毎の返済額を減算していった場合に、現預金が不足しないかを判定する。
信用度取得部146は、対象事業者の信用度を取得する。信用度取得部146は、例えば、対象事業者の信用情報データ中の評点を対象事業者の信用度として取得する。信用度取得部146は、対象事業者の信用情報データを信用情報管理装置240に要求して、信用情報管理装置240から信用情報データを受信してよい。また、融資判定装置100が複数の事業者の信用情報データを管理している場合、信用度取得部146は、管理下の信用情報データから対象事業者の信用情報データを読み出してよい。また、信用度取得部146は、金融機関による対象事業者の信用格付けを示す信用格付情報を、対象事業者の信用度として取得してもよい。信用度取得部146は、対象事業者の信用格付情報を金融機関に要求して、金融機関から信用格付情報を受信してよい。また、信用度取得部146は、複数の事業者の信用格付情報を金融機関から受信して格納しておき、格納している信用格付情報から対象事業者の信用格付情報を読み出してもよい。
信用度取得部146は、対象事業者の取引先の信用情報データを用いて、対象事業者の信用度を生成してもよい。例えば、信用度取得部146は、対象事業者の取引先の評点が予め定められた閾値より低い場合、対象事業者の評点を減点する。また、例えば、信用度取得部146は、対象事業者の取引先の評点が予め定められた閾値より高い場合、対象事業者の評点に加点する。また、信用度取得部146は、対象事業者の取引先の評点に応じた点数を対象事業者の評点に加算する。また、信用度取得部146は、対象事業者の取引先の信用格付情報を用いて、対象事業者の信用度を生成してもよい。例えば、信用度取得部146は、対象事業者の取引先の信用格付情報が予め定められた閾値より低い場合、対象事業者の信用度を減点する。また、例えば、信用度取得部146は、対象事業者の取引先の信用格付情報が予め定められた閾値より高い場合、対象事業者の信用度に加点する。また、信用度取得部146は、対象事業者の取引先の信用格付情報に応じた点数を対象事業者の信用度に加算する。
信用度取得部146は、対象事業者に対して、連鎖的に取引関係にある事業者の信用情報データを用いて、対象事業者の信用度を生成してもよい。例えば、信用度取得部146は、対象事業者の評点に対して、対象事業者に対して連鎖的に取引関係にある事業者の評点に重み付けをして加算する。重み付けとして、例えば、連鎖関係がより対象事業者から遠い事業者の評点の重みを低くしてよい。また、信用度取得部146は、対象事業者に対して、連鎖的に取引関係にある事業者の信用格付情報を用いて、対象事業者の信用度を生成してもよい。例えば、信用度取得部146は、対象事業者の信用度に対して、対象事業者に対して連鎖的に取引関係にある事業者の信用格付情報に対応する値に重み付けをして加算する。重み付けとして、例えば、連鎖関係がより対象事業者から遠い事業者の評点の重みを低くしてよい。
信用度取得部146は、インターネット上に存在する複数のデータを組み合わせることによって、対象事業者の信用度を生成してもよい。信用度取得部146は、例えば、対象事業者が運営するウェブサイトの更新頻度及びサイト訪問者数等の情報を用いて対象事業者の信用度を生成する。また、信用度取得部146は、第三者が運営するウェブサイト上の対象事業者が営む事業に関する評価を示す評価情報を用いて対象事業者の信用度を生成してよい。また、信用度取得部146は、対象事業者の代表者等、対象事業者に関連する者に関する情報を用いて対象事業者の信用度を生成してよい。例えば、信用度取得部146は、対象事業者の代表者のSNS(Social Networking Service)の情報を用いて対象事業者の信用度を生成する。
融資可否判定部144は、信用度取得部146によって生成された対象事業者の信用度を用いて、対象事業者に対する融資可否を判定してもよい。例えば、融資可否判定部144は、返済予定に対して、将来CF情報が示す現預金が多い場合であっても、対象事業者の信用度が低い場合には融資否と判定する。例えば、融資可否判定部144は、返済予定と将来CF情報が示す現預金との差額毎に、融資否と判定する信用度を対応付けて登録しておき、信用度取得部146によって生成された信用度が、差額に対応する信用度よりも低い場合には、融資否と判定する。
また、例えば、融資可否判定部144は、返済予定に対して、将来CF情報が示す現預金が少ない場合であっても、対象事業者の信用度が高い場合には融資可と判定する。例えば、融資可否判定部144は、返済予定と将来CF情報が示す現預金との差額毎に、融資可と判定する信用度を対応付けて登録しておき、信用度取得部146によって生成された信用度が、差額に対応する信用度よりも高い場合には、融資可と判定する。
融資処理実行部148は、融資可否判定部144による判定結果に従って、融資処理を実行する。例えば、融資可否判定部144によって融資可と判定された場合、融資処理実行部148は、融資手続を開始する。融資処理実行部148は、対象事業者の通信端末20に対して、融資可である旨を通知する内容と、融資に必要となる情報を要求する内容とを含む融資手続データを通信端末20に送信してよい。また、例えば、融資可否判定部144によって融資可と判定された場合、融資処理実行部148は、対象事業者に対して融資オファーを行う。融資処理実行部148は、対象事業者の通信端末20に対して、融資可である旨を通知する内容と、融資に必要となる情報を要求する内容とを含む融資オファーデータを通信端末20に送信してよい。
融資処理実行部148は、融資可否判定部144によって融資否と判定された場合、対象事業者に対して融資否である旨を通知してよい。融資処理実行部148は、例えば、対象事業者の通信端末20に対して、融資否であることを通知する通知データを送信する。
融資後管理部150は、融資が行われた後に、対象事業者を管理する。融資後管理部150は、例えば、融資が行われた後、将来CF情報生成部132に対して、継続的に対象事業者の将来CF情報を生成させる。そして、融資後管理部150は、将来CF情報に基づいて、融資返済に支障が出る可能性があることが検知された場合、融資の回収を担当する担当者等にその旨を通知する。融資後管理部150は、例えば、新たに生成された将来CF情報の各月の現預金が、月毎の返済額より少ない場合に、融資返済に支障が出る可能性があると判定する。
融資後管理部150は、融資返済に支障が出る可能性があることが検知された場合に、対象事業者に送信するリマインドの時期を早める等の処理を実行してもよい。融資後管理部150は、貸金業法の趣旨を逸脱しない方法で、各種処理を実行する。
返済情報生成部152は、返済情報を生成する。返済情報は、例えば、融資の返済スケジュールである。返済情報生成部152は、将来CF情報を用いて、目的に応じた返済スケジュールを生成してよい。例えば、返済情報生成部152は、利益で返済する場合の返済スケジュール及び資金繰りで返済する場合の返済スケジュール等を生成する。
返済情報生成部152は、融資可否判定部144によって融資可と判定された場合に、将来CF情報を用いて、融資の返済スケジュールを生成してよい。例えば、返済情報生成部152は、将来CF情報を参照して、現預金の額が他の月よりも多い月を特定し、当該月の返済額を他の月よりも多くした返済スケジュールを生成する。
返済情報送信部154は、返済情報生成部152によって生成された返済情報を、対象事業者の通信端末20に送信してよい。これにより、対象事業者に対して、フレキシブルに返済スケジュールを提案することができる。
返済情報生成部152は、融資可否判定部144によって融資否と判定された場合に、将来CF情報を用いて、融資可能な返済スケジュールを生成してよい。例えば、返済情報生成部152は、融資申込データの少なくとも一部を変更した返済スケジュールを生成する。
例えば、返済情報生成部152は、将来CF情報を用いて、融資申込データに含まれる融資希望日を変更することによって融資可と判定できる場合には、融資日を変更した場合の返済スケジュールを生成する。具体例として、融資申込データに含まれる融資希望日が2017年4月であり、そのままでは融資否だが、融資日を2017年7月に変更することによって融資可となる場合、2017年7月を融資日とする返済スケジュールを生成する。
また、返済情報生成部152は、将来CF情報を用いて、融資申込データに含まれる融資期間を変更することによって融資可と判定できる場合には、融資期間を変更した返済スケジュールを生成する。具体例として、融資申込データに含まれる融資期間が6月であり、そのままでは融資否だが、融資期間を10月に変更することによって融資可となる場合、融資期間を10月とする返済スケジュールを生成する。
返済情報送信部154が返済情報を対象事業者の通信端末20に送信することによって、対象事業者に、融資申込データの条件を変更することによって融資が可能になることを伝えることができる。例えば、対象事業者の事業が農業の場合、融資金額を各月に均等に分配して返済していくことは難しいが、収穫期にまとめて返済することはできる場合がある等、対象事業者の事業によって、返済能力の特性が異なる。本実施形態に係る返済情報生成部152によれば、対象事業者の将来CF情報が示すキャッシュフローに適した返済スケジュールを生成できるので、対象事業者の状況に合わせてフレキシブルに返済スケジュールを提供することができる。
図16は、口座管理装置300の機能構成の一例を概略的に示す。口座管理装置300は、口座管理部302、データ取得部304、将来CF情報生成部306、支払要求取得部308、支払処理実行部310、融資可否判定部312、融資返済実行部314、金利処理実行部316、及び指示受信部318を備える。なお、口座管理装置300がこれらのすべての構成を備えることは必須とは限らない。
口座管理部302は、複数の事業者の口座残高を管理する。口座管理部302は、事業者からの要求に応じて、当該事業者用の口座を開設してよい。口座管理部302は、例えば、1又は複数の銀行口座内において、複数の事業者の口座を管理する。具体例として、口座管理部302は、N個の銀行口座内において、N事業者又はNより多い数の事業者の口座残高を管理する。口座管理部302は、例えば、口座管理装置300の管理者名義の銀行口座内において、複数の事業者の口座を管理する。
データ取得部304は、各種データを取得する。データ取得部304は、会計データ、金融機関データ、取引データ、特徴データ、取引関係データ、過去CF情報、受注率、及び請求入金率を取得してよい。データ取得部304は、これらの全てを取得してよく、これらの一部を取得してもよい。
将来CF情報生成部306は、データ取得部304が取得したデータを用いて、口座を管理している事業者の将来CF情報を生成する。将来CF情報生成部306は、会計データ及び取引データの少なくともいずれかに基づいて、当該事業者の将来CF情報を生成してよい。将来CF情報生成部306は、将来CF情報生成部132と同様の処理を実行することによって将来CF情報を生成してよい。
支払要求取得部308は、口座を管理している事業者から、取引先への支払要求を取得する。支払要求は、例えば、支払先の口座番号及び支払額を含む。支払要求取得部308は、例えば、通信端末20によって送信された支払要求を受信する。支払要求を行った事業者を対象事業者と記載する場合がある。
支払処理実行部310は、支払要求取得部308が取得した支払要求に応じて支払処理を実行する。支払処理実行部310は、支払要求の支払額よりも、対象事業者の口座残高が多い場合、支払処理を実行してよい。支払処理実行部310は、例えば、支払要求の支払先の口座番号に対して支払額を送金する。支払処理実行部310は、支払要求の支払先の口座番号に対して支払額を送金する指示を、口座管理装置300のオペレータ等に提示してもよい。支払処理実行部310は、支払に伴って支払額を口座残高から減算する。支払処理実行部310は、支払要求の支払額よりも、対象事業者の口座残高が少ない場合、対象事業者への融資の可否を融資可否判定部312に判定させる。
融資可否判定部312は、対象事業者への融資の可否を判定する。融資可否判定部312は、将来CF情報生成部306によって生成された対象事業者の将来CF情報に基づいて、対象事業者への融資の可否を判定してよい。融資可否判定部312は、融資可否判定部144と同様の処理を実行することによって融資可否を判定してよい。
融資可否判定部312は、支払処理実行部310からの要求に応じて、対象事業者への融資の可否を判定してよい。例えば、融資可否判定部312は、支払要求の支払額と、対象事業者の口座残高との差分以上の融資金額を融資することの可否を判定する。
融資可否判定部312は、例えば、支払要求の支払額と、対象事業者の口座残高との差額を融資することの可否を判定する。また、融資可否判定部312は、支払要求の支払額と、対象事業者の口座残高との差額に予め定められた金額を加算した額を融資することの可否を判定してもよい。予め定められた金額は、対象事業者の口座残高として最低限必要な金額として、口座管理装置300の管理者及び対象事業者等によって定められてよい。
口座管理部302は、融資可否判定部312によって融資可と判定された場合、対象事業者の口座残高に融資金額を加算してよい。口座管理部302は、例えば、支払要求の支払額と対象事業者の口座残高との差額を、対象事業者の口座残高に加算する。また、口座管理部302は、例えば、支払要求の支払額と対象事業者の口座残高との差額に予め定められた金額を加算した額を対象事業者の口座残高に加算する。
融資可否判定部312は、口座を管理している事業者への融資の可否を定期的に判定してもよい。融資可否判定部312は、例えば、口座を管理している事業者への融資可能枠を定期的に判定する。融資可否判定部312は、融資可能額を口座管理部302に通知してよい。口座管理部302は、口座を管理している事業者に対して、融資可否判定部312によって判定された融資可能枠を提示してよい。これにより、事業者は、現時点において、どの程度の融資を受けることができるかを把握することができる。
融資返済実行部314は、口座管理部302によって融資金額が口座残高に加算され、支払処理実行部310によって支払処理が実行された後、対象事業者の口座残高を監視する。そして、融資返済実行部314は、予め定められた条件に従って、口座残高からの返済処理を実行する。例えば、融資返済実行部314は、対象事業者の口座残高が融資金額よりも多い場合に、口座残高から融資金額を減算する。減算された融資金額は、融資の返済に充てられる。また、融資返済実行部314は、融資金額を段階的に返済すべく返済処理を実行してよい。例えば、融資返済実行部314は、対象事業者の口座残高が融資金額よりも少ない場合に、口座残高と予め定められた閾値との差分を口座残高から減算する。具体例として、融資金額が1,000であり、口座残高が500であり、予め定められた閾値が300である場合、融資返済実行部314は、口座残高と閾値との差分である200を口座残高から減算する。減算された金額は、融資の返済に充てられる。
金利処理実行部316は、口座管理部302によって融資金額が口座残高に加算され、支払処理実行部310によって支払処理が実行された後、対象事業者の口座残高を監視する。そして、金利処理実行部316は、対象事業者の口座残高が融資金額よりも少ない場合に、予め定められた金利ルールに従って決定した金利額を口座残高から減算してよい。減算された金利額は、融資金額に対する金利の支払いに充てられる。金利処理実行部316は、対象事業者の口座残高の多寡を問わず、予め定められたタイミングに従って、口座残高から金利額を減算する。例えば、金利額が50であり、対象事業者の口座残高が、300の貸出残があって−300の状態であっても、タイミングがきた場合、316は、50を減算して、口座残高を−350とする。なお、与信枠の範囲に収まっている限り、実際に返済されるのは、口座残高が予め定められた閾値を超えたときであってよい。
指示受信部318は、管理している口座に対する指示を事業者の通信端末20から受信する。指示受信部318は、例えば、管理している口座から、事業者によって指定された口座への出金を行う。
図17は、融資判定装置100又は口座管理装置300として機能するコンピュータ1000のハードウエア構成の一例を概略的に示す。本実施形態に係るコンピュータ1000は、ホストコントローラ1092により相互に接続されるCPU1010、RAM1030、及びグラフィックコントローラ1085を有するCPU周辺部と、入出力コントローラ1094によりホストコントローラ1092に接続されるROM1020、通信I/F1040、ハードディスクドライブ1050、DVDドライブ1070及び入出力チップ1080を有する入出力部を備える。
CPU1010は、ROM1020及びRAM1030に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ1085は、CPU1010などがRAM1030内に設けたフレーム・バッファ上に生成する画像データを取得し、ディスプレイ1090上に表示させる。これに代えて、グラフィックコントローラ1085は、CPU1010などが生成する画像データを格納するフレーム・バッファを、内部に含んでもよい。
通信I/F1040は、有線又は無線によりネットワークを介して他の装置と通信する。また、通信I/F1040は、通信を行うハードウエアとして機能する。ハードディスクドライブ1050は、CPU1010が使用するプログラム及びデータを格納する。DVDドライブ1070は、DVD−ROM1072からプログラム又はデータを読み取り、RAM1030を介してハードディスクドライブ1050に提供する。
ROM1020は、コンピュータ1000が起動時に実行するブート・プログラム及びコンピュータ1000のハードウエアに依存するプログラムなどを格納する。入出力チップ1080は、例えばパラレル・ポート、シリアル・ポート、キーボード・ポート、マウス・ポートなどを介して各種の入出力装置を入出力コントローラ1094へと接続する。
RAM1030を介してハードディスクドライブ1050に提供されるプログラムは、DVD−ROM1072、又はICカードなどの記録媒体に格納されて利用者によって提供される。プログラムは、記録媒体から読み出され、RAM1030を介してハードディスクドライブ1050にインストールされ、CPU1010において実行される。
コンピュータ1000にインストールされ、コンピュータ1000を融資判定装置100又は口座管理装置300として機能させるプログラムは、CPU1010などに働きかけて、コンピュータ1000を、融資判定装置100又は口座管理装置300の各部としてそれぞれ機能させてよい。これらのプログラムに記述された情報処理は、コンピュータ1000に読込まれることにより、ソフトウエアと上述した各種のハードウエア資源とが協働した具体的手段である申込データ取得部102、会計データ取得部104、金融機関データ取得部106、取引データ取得部108、受注率算出部110、請求入金率算出部112、取引関係データ取得部114、事業者群特定部116、特徴データ取得部118、過去CF情報生成部120、蓋然性情報生成部130、要求データ送信部142、融資可否判定部144、信用度取得部146、融資処理実行部148、融資後管理部150、返済情報生成部152、及び返済情報送信部154として機能する。また、これらのプログラムに記述された情報処理は、コンピュータ1000に読込まれることにより、ソフトウエアと上述した各種のハードウエア資源とが協働した具体的手段である口座管理部302、データ取得部304、将来CF情報生成部306、支払要求取得部308、支払処理実行部310、融資可否判定部312、融資返済実行部314、金利処理実行部316、及び指示受信部318として機能する。そして、これらの具体的手段によって、本実施形態におけるコンピュータ1000の使用目的に応じた情報の演算又は加工を実現することにより、使用目的に応じた特有の融資判定装置100又は口座管理装置300が構築される。
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
特許請求の範囲、明細書、および図面中において示した装置、システム、プログラム、および方法における動作、手順、ステップ、および段階などの各処理の実行順序は、特段「より前に」、「先立って」などと明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず、」、「次に、」などを用いて説明したとしても、この順で実施することが必須であることを意味するものではない。