JP2023135630A - 情報処理方法、情報処理プログラム及び情報処理装置 - Google Patents

情報処理方法、情報処理プログラム及び情報処理装置 Download PDF

Info

Publication number
JP2023135630A
JP2023135630A JP2023035838A JP2023035838A JP2023135630A JP 2023135630 A JP2023135630 A JP 2023135630A JP 2023035838 A JP2023035838 A JP 2023035838A JP 2023035838 A JP2023035838 A JP 2023035838A JP 2023135630 A JP2023135630 A JP 2023135630A
Authority
JP
Japan
Prior art keywords
information
data
platform
business
lending
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2023035838A
Other languages
English (en)
Other versions
JP7337298B1 (ja
Inventor
篤史 大塚
Atsushi Otsuka
伴之 寺田
Tomoyuki Terada
大典 久保
Daisuke Kubo
周子 橋本
Chikako Hashimoto
一樹 岩佐
Kazuki Iwasa
美穂 西園
Miho Nishizono
達也 林
Tatsuya Hayashi
優基 中町
Yuki Nakamachi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Senshu Ikeda Bank Ltd
Original Assignee
Senshu Ikeda Bank Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Senshu Ikeda Bank Ltd filed Critical Senshu Ikeda Bank Ltd
Priority to JP2023134799A priority Critical patent/JP2023153284A/ja
Application granted granted Critical
Publication of JP7337298B1 publication Critical patent/JP7337298B1/ja
Publication of JP2023135630A publication Critical patent/JP2023135630A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】財務指標以外の情報を用いてレンディング情報を生成することが可能な情報処理装置等を提供すること。【解決手段】情報処理方法は、プラットフォーマが事業者にサービスを提供するサイトに設定されたレンディングを申し込むためのリンクを、前記事業者が操作したことに起因して、前記レンディングにおける同意画面を事業者端末へ送信し、前記事業者端末から、前記事業者の同意情報を受信し、前記レンディングに関する前記事業者の登録情報、及び、該事業者の前記プラットフォーマのサービスの利用に関するサービスデータを取得し、取得した前記登録情報及び前記サービスデータに基づき、前記事業者向けのレンディングに関する情報を、前記事業者端末へ送信する処理をコンピュータが行う。【選択図】図１２

Description

本発明は、事業者向けのレンディングに関する情報を送信する情報処理方法等に関する。
企業においては、資金繰りが厳しくなった場合、金融機関から融資を受けることが行われている。融資に備え、自社の調達可能な資金を常時把握しておくということは行われているが、多くの中小企業にとっては、自社の調達可能な資金を経営のオプションとして把握しておくことは容易ではない。
そのような状況に対して、対象企業の財務データに基づく一又は複数の財務指標を当該財務データに関する一又は複数の信頼度とともに用いることで、当該企業に煩雑な手続をさせることなく、当該企業に対して可能な融資の融資条件を判定することができる情報処理装置が提案されている（特許文献１）。
特開２０２０－６７６８２号公報
しかし、特許文献１に記載の情報処理装置は、財務指標に基づき融資条件を判定しており、企業活動の一面から融資条件を判定しているに過ぎない。本発明はこのような状況に鑑みてなされたものである。その目的は、レンディング情報を生成する際に、財務指標以外の情報も用いることが可能な情報処理装置等の提供である。
本願の一態様に係る情報処理方法は、プラットフォーマが事業者にサービスを提供するサイトに設定されたレンディングを申し込むためのリンクを、前記事業者が操作したことに起因して、前記レンディングにおける同意画面を事業者端末へ送信し、前記事業者端末から、前記事業者の同意情報を受信し、前記レンディングに関する前記事業者の登録情報、及び、該事業者の前記プラットフォーマのサービスの利用に関するサービスデータを取得し、取得した前記登録情報及び前記サービスデータに基づき、前記事業者向けのレンディングに関する情報を、前記事業者端末へ送信する処理をコンピュータが行うことを特徴とする。
本願の一観点によれば、レンディング情報を生成する際に、財務指標以外の情報も用いることが可能となる。
エコシステムの構成例を示す説明図である。 サーバのハードウェア構成例を示すブロック図である。 端末のハードウェア構成例を示すブロック図である。 ユーザＤＢの例を示す説明図である。 連携アカウントＤＢの例を示す説明図である。 入出金ＤＢの例を示す説明図である。 プラットフォーマＤＢの例を示す説明図である。 代表者・事業主ＤＢの例を示す説明図である。 法人ＤＢの例を示す説明図である。 与信モデルの構造例を示す説明図である。 第３モデルの構造例を示す説明図である。 メイン処理の手順例を示すフローチャートである。 データ連携処理の手順例を示すフローチャートである。 仮審査処理の手順例を示すフローチャートである。 プラットフォーマ画面の一例を示す説明図である。 ログイン画面の一例を示す説明図である。 ホーム画面の一例を示す説明図である。 サービス選択画面の一例を示す説明図である。 ログイン情報入力画面の例を示す説明図である。 ホーム画面の他の例を示す説明図である。 ホーム画面の他の例を示す説明図である。 与信モデルの他の構造例を示す説明図である。 事業性評価モデルの構造例を示す説明図である。 評価結果ＤＢの例を示す説明図である。 事業性評価処理の手順例を示すフローチャートである。 ホーム画面の他の例を示す説明図である。 ホーム画面の他の例を示す説明図である。 一覧画面の例を示す説明図である。 一覧画面作成処理の手順例を示すフローチャートである。 付与条件ＤＢの例を示す説明図である。 特典ＤＢの例を示す説明図である。 付与履歴ＤＢの例を示す説明図である。 ポイント付与処理の手順例を示すフローチャートである。 付与通知画面の例を示す説明図である。 整合性確認処理の手順例を示すフローチャートである。 整合性がある関連データの例を示すテーブルである。 整合性がある関連データの例を示すグラフである。 整合性が疑われる関連データの例を示すテーブルである。 整合性が疑われる関連データの例を示すグラフである。 関連データ整合性確認処理の手順例を示すフローチャートである。 審査処理の手順例を示すフローチャートである。
以下実施の形態を、図面を参照して説明する。図１はエコシステムの構成例を示す説明図である。エコシステム１００は事業者向けにレンディングを行う金融機関が運営している。エコシステム１００はサーバ１及び端末２を含む。また、プラットフォーマ３はエコシステム１００とデータ連携が可能なシステムを示す。インターネット上で利用者とサービス提供者を結び付ける基盤（プラットフォーム）となるサービスやシステムなどを提供・運営する事業者のことをプラットフォーマというが、ここでは、プラットフォーマが運営するコンピュータシステムをプラットフォーマ３と記す。会計システム４は主としてクラウドサービスにより会計サービスを提供するシステムである。金融機関サーバ５は金融機関において口座の入出金情報等を管理するいわゆる勘定系サーバである。金融機関サーバ５には、エコシステム１００を運営する金融機関において、口座の入出金情報等を管理する勘定系サーバを含む。モデルベンダ６は信用リスクを判定するスコアリングモデル等を用いたサービスを提供する情報提供会社や信用情報機関である。その他ベンダ７は金融機関が業務を行う上で利用するサービスを提供する会社等である。金融機関が利用するサービスとして想定するのは、ＡＭＬ（Anti-Money Laundering）サービス、eKYC、個人信用情報提供サービス等である。ＡＭＬサービスはマネー・ローンダリングを防止するためのサービスである。eKYC（electronic Know Your Customer：電子本人確認）は、身元確認をオンラインで提供するサービスである。個人信用情報提供サービスは、信用情報機関による個人信用情報の提供サービスである。個人信用情報は、個人の年収や住宅情報、勤務先等の属性情報及び、ローンや公共料金等の支払い情報等である。サーバ１、端末２並びにプラットフォーマ３、会計システム４、金融機関サーバ５、モデルベンダ６及びその他ベンダ７はネットワークＮにより、互いに通信可能に接続されている。ネットワークＮはインターネット、一般公衆網、携帯電話網、又は、専用線網である。また、ネットワークＮは、これら複数種のネットワークを組み合わせたものや、ＶＰＮ（Virtual Private Network：仮想専用通信網）などの仮想ネットワークでもよい。
図２はサーバのハードウェア構成例を示すブロック図である。サーバ１は制御部１１、主記憶部１２、補助記憶部１３、通信部１５及び読み取り部１６を含む。制御部１１、主記憶部１２、補助記憶部１３、通信部１５及び読み取り部１６はバスＢにより接続されている。サーバ１はサーバコンピュータ、ワークステーション、ＰＣ（Personal Computer）等で構成する。また、サーバ１を複数のコンピュータからなるマルチコンピュータ、ソフトウェアによって仮想的に構築された仮想マシン又は量子コンピュータで構成しても良い。さらに、サーバ１の機能をクラウドサービスで実現してもよい。
制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有する。制御部１１は、補助記憶部１３に記憶された制御プログラム１Ｐ（プログラム、プログラム製品）を読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行い、第１送信部、受信部、取得部、及び、第２送信部等の機能部を実現する。
主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等である。主記憶部１２は主として制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。
補助記憶部１３はハードディスク又はＳＳＤ（Solid State Drive）等であり、制御部１１が処理を実行するために必要な制御プログラム１Ｐや各種ＤＢ（Database）を記憶する。補助記憶部１３は、ユーザＤＢ１３１、連携アカウントＤＢ１３２、入出金ＤＢ１３３、プラットフォーマＤＢ１３４、代表者・事業主ＤＢ１３５及び法人ＤＢ１３６等を記憶する。また、補助記憶部１３は与信モデル１４１、及び、事業性評価モデル１４２を記憶する。さらに、補助記憶部１３は評価結果ＤＢ１３７、付与条件ＤＢ１３８、特典ＤＢ１３９及び付与履歴ＤＢ１３Ａを記憶してもよい。補助記憶部１３はサーバ１と別体で、外部接続された外部記憶装置であってもよい。補助記憶部１３に記憶する各種ＤＢ等を、サーバ１とは異なるデータベースサーバやクラウドストレージに記憶してもよい。補助記憶部１３が記憶するデータベースは図２に示したものに限らず、必要に応じて、他のデータベースを補助記憶部１３は記憶してもよい。
通信部１５はネットワークＮを介して、端末２並びにプラットフォーマ３、会計システム４、金融機関サーバ５、モデルベンダ６及びその他ベンダ７と通信を行う。また、制御部１１が通信部１５を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、補助記憶部１３に記憶してもよい。
読み取り部１６はＣＤ（Compact Disc）－ＲＯＭ及びＤＶＤ（Digital Versatile Disc）－ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読み取り部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、補助記憶部１３に記憶してもよい。また、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでもよい。
図３は端末のハードウェア構成例を示すブロック図である。端末２はエンドユーザが使用する端末である。端末２はノートパソコン、パネルコンピュータ、タブレットコンピュータ、スマートフォン等で構成する。端末２は制御部２１、主記憶部２２、補助記憶部２３、通信部２４、入力部２５、及び、表示部２６を含む。各構成はバスＢで接続されている。
制御部２１は、一又は複数のＣＰＵ、ＭＰＵ、ＧＰＵ等の演算処理装置を有する。制御部２１は、補助記憶部２３に記憶された制御プログラム２Ｐ（プログラム、プログラム製品）を読み出して実行することにより、種々の機能を提供する。
主記憶部２２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等である。主記憶部２２は主として制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。
補助記憶部２３はハードディスク又はＳＳＤ等であり、制御部２１が処理を実行するために必要な各種データを記憶する。補助記憶部２３は端末２と別体で、外部接続された外部記憶装置であってもよい。補助記憶部２３に記憶する各種ＤＢ等を、データベースサーバやクラウドストレージに記憶してもよい。
通信部２４はネットワークＮを介して、サーバ１、プラットフォーマ３と通信を行う。また、制御部２１が通信部２４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム２Ｐをダウンロードし、補助記憶部２３に記憶してもよい。
入力部２５はキーボードやマウスである。表示部２６は液晶表示パネル等を含む。表示部２６はサーバ１が出力したレンディング情報などを表示する。また、入力部２５と表示部２６とを一体化し、タッチパネルディスプレイを構成してもよい。なお、端末２は外部された表示装置に表示を行ってもよい。
図４はユーザＤＢの例を示す説明図である。ユーザＤＢ１３１はエンドユーザの情報を記憶する。エンドユーザは法人や個人事業主であり、エコシステム１００を利用して、金融機関等から資金調達を行う。ユーザＤＢ１３１はユーザＩＤ列、種別列、名称・氏名列に及びメールアドレス列を含む。ユーザＩＤ列はエンドユーザを一意に特定可能なユーザＩＤを記憶する。種別列はエンドユーザが種別を記憶する。種別は例えば、法人又は個人事業主である。名称・氏名列は法人の名称又は個人事業主の氏名を記憶する。メールアドレス列はユーザの連絡先メールアドレスを記憶する。なお、ユーザＩＤとしてメールアドレスを使用してもよい。この場合、ユーザＩＤ列の値と、メールアドレス列の値とが、一致することもありうる。
図５は連携アカウントＤＢの例を示す説明図である。連携アカウントＤＢ１３２はプラットフォーマ３とデータ連携を行うために必要なエンドユーザの情報を記憶する。連携アカウントＤＢ１３２はユーザＩＤ列、Ｐｆｅｒ名称列、及び、トークン情報列を含む。ユーザＩＤ列はエンドユーザのユーザＩＤを記憶する。Ｐｆｅｒ名称列はデータ連携するプラットフォーマ３の名称を記憶する。トークン情報列は、プラットフォーマ３から付与されたアクセストークン、リフレッシュトークン等を記憶する。
図６は入出金ＤＢの例を示す説明図である。入出金ＤＢ１３３はエンドユーザが利用する銀行口座の入出金情報を記憶する。入出金ＤＢ１３３はユーザＩＤ列、銀行コード列、店番列、口座番号列、口座種別列、種別列、日時列、金額列、振替先列、及び、残高列を含む。ユーザＩＤ列はユーザＩＤを記憶する。銀行コード列は銀行を特定する銀行コードを記憶する。店番列は銀行店舗の番号を記憶する。口座番号列は口座番号を記憶する。口座種別列は口座の種別を記憶する。口座種別は例えば、普通、当座、定期、貯蓄である。種別列は取引の種別を記憶する。取引の種別は例えば、入金、出金、振替である。日時列は取引が行われた日時を記憶する。金額列は取引された金額を記憶する。振替先列は振替先を記憶する。残高列は口座残高を記憶する。入出金ＤＢ１３３が記憶する入出金情報は、金融機関サーバ５より取得する。なお、入出金ＤＢ１３３を一時的なデータベースとし、入出金情報が必要になった際に、金融機関サーバ５より必要な入出金情報を取得して入出金ＤＢ１３３を構築してもよい。また、ユーザがアグリゲーションサービスを利用しており、複数の金融機関における入出金情報をアグリゲーションサービスが保有している場合、アグリゲーションサービスから入出金情報を取得してもよい。
図７はプラットフォーマＤＢの例を示す説明図である。プラットフォーマＤＢ１３４はプラットフォーマ３が提供するプラットフォーマ３の情報を記憶する。プラットフォーマＤＢ１３４はＩＤ列、名称列、リンク列及びタグ列を含む。ＩＤ列はプラットフォーマ３を一意に特定するＩＤを記憶する。名称列はプラットフォーマ３の名称を記憶する。リンク列はプラットフォーマ３にアクセスするためのリンク情報を記憶する。リンク情報は例えばＵＲＬ（Uniform Resource Locator）である。タグ列はプラットフォーマ３を特徴づけるタグを記憶する。プラットフォーマＤＢ１３４はプラットフォーマ記憶部の一例である。
図８は代表者・事業主ＤＢの例を示す説明図である。代表者・事業主ＤＢ１３５はエンドユーザが法人である場合に、法人の代表者についての情報を、エンドユーザが個人事業主である場合に、個人事業主についての情報を、記憶する。代表者・事業主ＤＢ１３５はユーザＩＤ列、氏名列、電話番号列、メール列及び携帯電話列を含む。ユーザＩＤ列はユーザＩＤを記憶する。氏名列は代表者又は個人事業主の氏名を記憶する。電話番号列は電話番号を記憶する。メール列は代表者又は個人事業主のメールアドレスを記憶する。携帯電話列は、代表者又は個人事業主の携帯電話番号を記憶する。なお、代表者・事業主ＤＢ１３５が記憶する内容をユーザＤＢ１３１に持たせ、代表者・事業主ＤＢ１３５を設けなくともよい。
図９は法人ＤＢの例を示す説明図である。法人ＤＢ１３６は法人の情報を記憶する。法人ＤＢ１３６は法人番号列、ユーザＩＤ列、所在地列及び代表電話列を含む。法人番号列は法人の識別番号を記憶する。識別番号は例えば国税庁から付与される１３桁の法人番号である。それに限らず、識別番号として、信用調査機関が付与した企業識別コードや証券コードを利用してもよい。識別番号は記憶されていることが望ましいが、記憶されていなくともよい。ユーザＩＤ列はユーザＩＤを記憶する。所在地列は法人の所在地を記憶する。代表電話列は法人の代表電話番号を記憶する。電話番号については、代表電話番号以外の番号を記憶してもよい。なお、法人ＤＢ１３６が記憶する内容をユーザＤＢ１３１に持たせ、法人ＤＢ１３６を設けなくともよい。
図１０は与信モデルの構造例を示す説明図である。与信モデル１４１はエンドユーザの入出金データ、会計データ、サービスデータを入力すると、判定結果を出力する。サービスデータはプラットフォーマ３から得た利用履歴等である。入出金データは入出金ＤＢ１３３から取得する。会計データは会計システム４から取得する。判定結果は融資の可否、融資枠等である。例えば、融資枠は融資額、返済期間、利率を含む。与信モデル１４１は第１モデル１４１１、第２モデル１４１２、第３モデル１４１３及び結合器１４１４を含む。第１モデル１４１１は、入出金データをもとに所定の判定ロジックを用いて、エンドユーザへの融資の可否を判定する。第２モデル１４１２は、会計データをもとに所定の判定ロジックを用いて、エンドユーザへの融資の可否を判定する。第３モデル１４１３はサービスデータから、エンドユーザへの融資の可否を判定する。結合器１４１４は第１モデル１４１１の判定結果と、第２モデル１４１２の判定結果と、第３モデル１４１３の判定結果とを結合し、最終的な判定結果を出力する。また、与信モデル１４１が融資可と判定した場合、融資枠の設定を行う。融資枠の設定を与信モデル１４１が行ってもよいし、所定のロジックを用いて別途、行ってもよい。与信モデル１４１を構成する第１モデル１４１１、第２モデル１４１２、第３モデル１４１３を全て、サーバ１が備えるのではなく、モデルベンダ６が備えてもよい。この場合、モデルベンダ６から、第１モデル１４１１、第２モデル１４１２又は第３モデル１４１３の判定結果を、サーバ１は取得する。また、与信モデル１４１は、入出金データ、会計データ、サービスデータの３つのデータが揃っている場合だけでなく、任意の２つのデータ又は任意の１つのデータのみが入力された場合でも、適切な判定が行えることが望ましい。与信モデル１４１は３つのモデルを含むがそれに限らず、単一のモデルであってもよいし、２つのモデルを含む構成でもよい。
図１１は第３モデルの構造例を示す説明図である。第３モデル１４１３はエンドユーザのサービスデータを入力とし、エンドユーザの事業についての評価点を出力とするニューラルネットワークである。サービスデータはプラットフォーマ３から得た利用履歴等である。図１１では３つのプラットフォーマ３からサービスデータを得て、第３モデル１４１３へ入力する例を示している。プラットフォーマＡデータはプラットフォーマＡから得たサービスデータである。同様に、プラットフォーマＢデータ、プラットフォーマＣデータは、それぞれプラットフォーマＢ、プラットフォーマＣから得るサービスデータである。ニューラルネットワークは例えばＣＮＮ（Convolution Neural Network）であり、サービスデータの入力を受け付ける入力層と、評価点を出力する出力層とを有する。
入力層は、サービスデータを入力として受け付ける複数のニューロンを有し、入力された項目値を中間層に受け渡す。中間層は、入力層から入力された各値を畳み込むコンボリューション層と、コンボリューション層で畳み込んだ値をマッピングするプーリング層とが交互に連結された構成を有し、入力された情報を圧縮しながら最終的に評価値を抽出する。出力層は、中間層から出力された評価値に基づいて、評価点を出力する。評価点は例えば、０から１までの値を取る。評価点は離散値でもよく、例えば１から５までの整数値を取るようにしてもよい。
なお、以下の説明では第３モデル１４１３がＣＮＮであるものとして説明するが、第３モデル１４１３はＣＮＮに限定されず、ＣＮＮ以外のニューラルネットワーク、ベイジアンネットワーク、決定木など、他の学習アルゴリズムで構築されたモデルであってもよい。
第３モデル１４１３は、サービスデータ及びラベル（正解の評価点）からなる訓練データを用いて、以下のように生成する。サーバ１は、訓練データに含まれるサービスデータを入力層に入力し、中間層での演算処理を経て、出力層から評価点を取得する。サーバ１は、出力層から出力された評価点を、訓練データに含むラベル、すなわち正解値と比較し、出力ノードの出力値が正解値に近づくように、中間層での演算処理に用いるパラメータを最適化する。当該パラメータは、例えばニューロン間の重み（結合係数）、各ニューロンで用いられる活性化関数の係数などである。パラメータの最適化の方法は特に限定されないが、例えばサーバ１は誤差逆伝播法を用いて各種パラメータの最適化を行う。サーバ１は、全ての訓練データを用いて上記の学習処理を行い、学習済みの第３モデル１４１３を生成する。
次に、エコシステム１００で行われる情報処理について説明する。図１２はメイン処理の手順例を示すフローチャートである。メイン処理は、エンドユーザがプラットフォーマ３の画面において、レンディング開始のリンクを選択することで開始する。端末２の制御部２１はリンク情報に基づいて、開始要求をサーバ１へ送信する（ステップＳ１）。サーバ１の制御部１１は開始要求を受信する（ステップＳ２）。制御部１１は端末２へログイン画面を送信する（ステップＳ３）。端末２の制御部２１はログイン画面を受信する（ステップＳ４）。制御部２１はログイン画面を表示部２６に表示する（ステップＳ５）。エンドユーザはエコシステム１００に登録済であれば、ＩＤとパスワードとを入力し、ログイン操作をする。エンドユーザはエコシステム１００に未登録であれば、登録操作をする。制御部２１はユーザの操作が登録であるか否かを判定する（ステップＳ６）。制御部２１はユーザの操作が登録であると判定した場合（ステップＳ６でＹＥＳ）、ユーザ登録処理を行う（ステップＳ７）。ユーザ登録処理はサーバ１と協働して行う処理であるが、公知の技術であるので、説明を省略する。制御部２１はユーザの操作が登録でない判定した場合（ステップＳ６でＮＯ）、又はユーザ登録処理の完了後、ログイン要求をサーバ１へ送信する（ステップＳ８）。ログイン要求には、ＩＤとパスワードとが含まれている。サーバ１の制御部１１はログイン要求に含まれているＩＤとパスワードとによりユーザ認証を行う（ステップＳ９）。なお、エンドユーザがプラットフォーマ３とのデータ連携を許可している場合においては、ユーザ認証時にワンタイムパスワードによる認証を行うことが望ましい。不正アクセスによる情報流出のリスクをより低減する目的である。制御部１１はホーム画面を端末２へ送信する（ステップＳ１０）。端末２の制御部２１はホーム画面を受信する（ステップＳ１１）。制御部２１はホーム画面を表示部２６に表示する（ステップＳ１２）。エンドユーザはホーム画面において行いたい処理を選択する。ここで想定する処理は、データ連携処理、仮審査処理である。仮審査処理は、以前に少なくとも１回、データ連携処理を実行していないと実行できない。審査に必要なデータが得られないからである。制御部２１はエンドユーザがデータ連携処理を選択したか否かを判定する（ステップＳ１３）。制御部２１はエンドユーザがデータ連携処理を選択したと判定した場合（ステップＳ１３でＹＥＳ）、データ連携処理を行う（ステップＳ１４）。その後、制御部２１はステップＳ１３へ処理を戻す。データ連携処理の内容は後述する。制御部２１はエンドユーザがデータ連携処理を選択していないと判定した場合（ステップＳ１３でＮＯ）、エンドユーザが仮審査処理を選択した否かを判定する（ステップＳ１５）。制御部２１はエンドユーザが仮審査処理を選択したと判定した場合（ステップＳ１５でＹＥＳ）、仮審査処理を行う（ステップＳ１６）。その後、制御部２１はステップＳ１３へ処理を戻す。制御部２１はエンドユーザが仮審査処理を選択していないと判定した場合（ステップＳ１５でＮＯ）、メイン処理を終了する。
図１３はデータ連携処理の手順例を示すフローチャートである。端末２の制御部２１はデータ連携処理の開始要求をサーバ１へ送信する（ステップＳ３１）。ここでは、データ連携に３つ種別があると想定しており、開始要求にエンドユーザが選択した種別の情報が含まれている。３種別とは、金融機関の入出金情報のデータ連携、会計情報のデータ連携、その他のプラットフォーマ３が提供するサービスの利用データ等の連携である。サーバ１の制御部１１は開始要求を受信する（ステップＳ３２）。制御部１１は選択画面を端末２へ送信する（ステップＳ３３）。選択画面は種別に応じた画面である。金融機関の入出金情報のデータ連携の場合、金融機関を選択するための画面である。会計情報のデータ連携の場合、会計サービスを選択するための画面である。プラットフォーマ３の利用データ等の連携の場合、連携可能なプラットフォーマ３を選択するための画面である。端末２の制御部２１は選択画面を受信し、表示部２６に表示する（ステップＳ３４）。エンドユーザは選択画面でデータ連携先を選択する。制御部２１はエンドユーザがデータ連携先として選択したプラットフォーマ３へデータ連携の要求を送信する（ステップＳ３５）。プラットフォーマ３はデータ連携の要求を受信する（ステップＳ３６）。プラットフォーマ３は端末２へ入力画面を送信する（ステップＳ３７）。入力画面はプラットフォーマ３へログインするため情報を入力する画面である。多くの場合、ユーザＩＤとパスワードの入力を求める画面である。端末２の制御部２１は入力画面を受信し表示する（ステップＳ３８）。エンドユーザは入力部２５を介して、ユーザＩＤ、パスワード等を入力する。制御部２１はユーザＩＤ、パスワード等のログイン情報をプラットフォーマ３へ送信する（ステップＳ３９）。プラットフォーマ３はログイン情報を受信する（ステップＳ４０）。プラットフォーマ３はユーザ認証後に連携のためのトークンを発行し、サーバ１へ送信する（ステップＳ４１）。サーバ１の制御部１１はトークンを受信し、連携アカウントＤＢ１３２に記憶する（ステップＳ４２）。制御部１１はトークンを用いて、プラットフォーマ３にエンドユーザのデータ要求を送信する（ステップＳ４３）。要求にはエンドユーザのユーザＩＤが含まれている。プラットフォーマ３は要求を受信する（ステップＳ４４）。プラットフォーマ３はユーザＩＤに基づき、エンドユーザのデータを抽出する（ステップＳ４５）。プラットフォーマ３は抽出したデータをサーバ１へ送信する（ステップＳ４６）。連携の種別が金融機関の入出金情報の場合、金融機関のシステムがステップＳ３６及びＳ３７、Ｓ４０及びＳ４１、並びにＳ４４からＳ４６を行う。連携の種別が会計情報の場合、会計情報システムがステップＳ３６及びＳ３７、Ｓ４０及びＳ４１、並びにＳ４４からＳ４６を行う。サーバ１の制御部１１はデータを受信し、補助記憶部１３に記憶する（ステップＳ４７）。制御部１１は更新されたホーム画面を端末２へ送信する（ステップＳ４８）。端末２の制御部２１はホーム画面を受信し表示する（ステップＳ４９）。その後、制御部２１はデータ連携の呼び出し元へ処理を戻す。なお、制御部１１は、入力画面へ入力されたユーザＩＤ及びパスワードを連携アカウントＤＢ１３２に記憶する。
図１４は仮審査処理の手順例を示すフローチャートである。端末２の制御部２１は仮審査の要求をサーバ１へ送信する（ステップＳ６１）。サーバ１の制御部１１は要求を受信する（ステップＳ６２）。制御部１１はエンドユーザのデータを取得する（ステップＳ６３）。制御部１１は、入出金データ、会計データ、又は、サービスデータの中から、少なくとも一つのデータを取得する。制御部１１は取得した入出金データ、会計データ、サービスデータをモデルへ入力する（ステップＳ６４）。制御部１１は入出金データ、会計データ、サービスデータを与信モデル１４１へ入力する。制御部１１は与信モデル１４１から評価を取得する（ステップＳ６５）。制御部１１は与信モデル１４１からの評価に基づき、エンドユーザへの融資条件を生成する（ステップＳ６６）。制御部１１は融資条件を含む結果画面を生成し、端末２へ送信する（ステップＳ６７）。端末２の制御部２１は結果画面を受信し表示する（ステップＳ６８）。制御部２１は処理を呼び出し元へ戻す。
続いて、端末２に表示される画面について説明する。図１５はプラットフォーマ画面の一例を示す説明図である。プラットフォーマ画面ｄ０１は、エンドユーザがプラットフォーマ３の提供するサービスの利用時に、端末２に表示される画面である。プラットフォーマ画面ｄ０１には、連携する金融機関への借入申込の準備としての事前審査を案内する旨の案内表示ｄ０１１と、案内を参照するための参照ボタンｄ０１２とが表示されている。図１５はクラウドファンディングを提供するプラットフォーマ３の画面例であるが、クラウドファンディング以外のサービスを提供するプラットフォーマ３についても、同様に案内表示ｄ０１１と、参照ボタンｄ０１２とが表示される。エンドユーザが参照ボタンｄ０１２をクリックすると、事前審査についての案内ページが表示される。なお、プラットフォーマ３を運営する事業者が、銀行法に基づく銀行代理業の許可を取得している場合は、参照ボタンｄ０１２を、事前審査の申込ボタンとしてもよい。この場合、エンドユーザが当該申込ボタンをクリックすると、事前審査の開始要求が、端末２らサーバ１へ送信され、上述のメイン処理が開始される。例えば、申込ボタンにはサーバ１へ事前審査の開始要求を行うためのＵＲＬがハイパーリンクとして設定されている。端末２がエコシステム１００にログイン済みの状態であれば、エンドユーザが申込ボタンをクリックすると、事前審査の開始要求がされる。端末２がエコシステム１００へログインしていない状態の場合は、ログイン画面が表示され、ログインが完了すると、事前審査の開始要求がされる。
図１６はログイン画面の一例を示す説明図である。ログイン画面ｄ０２はエコシステム１００へのログインを行うための画面である。ログイン画面ｄ０２はＩＤ入力欄ｄ０２１、パスワード入力欄ｄ０２２、ログインボタンｄ０２３及び登録ボタンｄ０２４を含む。ＩＤ入力欄ｄ０２１はエコシステム１００でのログインＩＤを入力する欄である。ログインＩＤはエコシステム１００から付与されるＩＤ、又は、エンドユーザが使用するメールアドレスが使用される。パスワード入力欄ｄ０２２はログインパスワードを入力する欄である。エンドユーザがログインボタンｄ０２３を選択すると、ログイン要求がサーバ１へ送信される。エコシステム１００への登録が済んでいないエンドユーザは、登録ボタンｄ０２４を選択して、登録手続きを行う。
図１７はホーム画面の一例を示す説明図である。ホーム画面ｄ０３は、エコシステム１００にログインした後に表示される画面である。ホーム画面ｄ０３は仮審査ボタンｄ０３１、口座連携表示ｄ０３２、会計連携表示ｄ０３３、ＰＦｅｒ連携表示ｄ０３４、口座連携ボタンｄ０３５、会計連携ボタンｄ０３６、ＰＦｅｒ連携ボタンｄ０３７、申込ボタンｄ０３８、一覧ボタンｄ０３９及び金額表示ｄ０３Ａを含む。仮審査ボタンｄ０３１をエンドユーザが選択すると、上述の仮審査処理が起動し、端末２からサーバ１へ仮審査の要求が送信される。図１７では仮審査が申し込める状態ではないので、文字が細いフォントで表示され、ボタンの外形を点線としている。この場合、仮審査ボタンｄ０３１を選択しても、仮審査の申し込みはできない。口座連携表示ｄ０３２は金融機関との連携の状況を表示する。図１７では、いずれの金融機関との連携も行われていない状況を示している。会計連携表示ｄ０３３は会計サービスとの連携の状況を表示する。図１７では、いずれの会計サービスとの連携も行われていない状況を示している。本実施の形態においては、少なくとも、金融機関又は会計サービスとのデータ連携が行われていないと、仮審査、借入申込はできないようになっているので、上述したように仮審査ボタンｄ０３１は機能しない状態になっている。ＰＦｅｒ連携表示ｄ０３４は、プラットフォーマ３との連携の状況を表示する。図１７では、いずれのプラットフォーマ３との連携も行われていない状況を示している。口座連携ボタンｄ０３５は金融機関との連携を設定するためのボタンである。会計連携ボタンｄ０３６は会計サービスとの連携を設定するためのボタンである。ＰＦｅｒ連携ボタンｄ０３７はプラットフォーマ３との連携を設定するためのボタンである。口座連携ボタンｄ０３５、会計連携ボタンｄ０３６、又は、ＰＦｅｒ連携ボタンｄ０３７が選択されると、上述したデータ連携処理が起動し、端末２からサーバ１へ開始要求が送信される。申込ボタンｄ０３８をエンドユーザが選択すると、端末２からサーバ１へ借入申込の要求が送信される。図１７では借入申込みが行える状態ではないので、文字が細いフォントで表示され、ボタンの外形を点線としている。この場合、申込ボタンｄ０３８を選択しても、借入申込みは行えない。一覧ボタンｄ０３９を選択すると、データ連携が可能な金融機関、会計サービス、プラットフォーマ３の一覧が表示される。金額表示ｄ０３Ａはエンドユーザが借入可能な金額が表示される。図１７では、仮審査が行われていない状況なので、金額は表示されていない。なお、連携が行なわれているか否かに関わらず、仮審査ボタンｄ０３１は常に機能する状態としてもよい。この場合、仮審査ボタンｄ０３１が選択された際、仮審査に進むためにはデータ連携が必要な場合は、データ連携が必要な旨のメッセージを表示し、連携設定をエンドユーザへ促すことが望ましい。また、仮審査ボタンｄ０３１は画面の構成要素には含まず、データ連携が設定された時点や、エンドユーザがログインした時点で、仮審査が実行されるようにしてもよい。
図１８はサービス選択画面の一例を示す説明図である。サービス選択画面ｄ０４はデータ連携を行うサービスを選択する画面である。サービス選択画面ｄ０４は選択ボタンｄ０４１を含む。図１８では選択ボタンｄ０４１は４つ表示されているが、３つ以下、または、５つ以上であってもよい。また、連携可能なサービスが多数の場合、目的のサービスを選択するのが困難になるため、サービス名称の検索や、サービス内容による絞り込みが行えるようにしてもよい。さらに、サービス選択画面ｄ０４に表示するサービスには、エンドユーザが既にデータ連携を設定したサービスは含めないようにする。既にデータ連携を設定したサービスは、連携アカウントＤＢ１３２を参照すれば判定可能である。サービス選択画面は、プラットフォーマ３の一覧を表示する画面の一例である。
図１９はログイン情報入力画面の例を示す説明図である。ログイン情報入力画面（以下、「入力画面」と記す。）ｄ０５は、データ連携先のプラットフォーマ３へログインするためのログイン情報を入力する画面である。入力画面ｄ０５はメールアドレス入力欄ｄ０５１、パスワード入力欄ｄ０５２、承諾ボタンｄ０５３及びキャンセルボタンｄ０５４を含む。メールアドレス入力欄ｄ０５１にはログインＩＤとして用いるメールアドレスを入力する。ログインＩＤとしてメールアドレスが使用できないプラットフォーマ３については、メールアドレスの代わりにログインＩＤを入力する欄となる。パスワード入力欄ｄ０５２にはログインパスワードを入力する。エンドユーザが承諾ボタンｄ０５３を選択すると、プラットフォーマ３からデータを収集することを承諾したものとする。また、ログイン情報がプラットフォーマ３へ送信され、ユーザ認証が行なわれる。プラットフォーマ３は認証に成功すると、アクセスするためのトークンを発行し、サーバ１へ送信する。サーバ１は、プラットフォーマ３へデータの要求を行う。キャンセルボタンｄ０５４を選択すると、データ連携は行わず、ホーム画面へ戻る。入力画面ｄ０５は同意画面の一例である。また、承諾ボタンｄ０５３を選択した旨の情報は、サーバ１へ送信される。当該情報は同意情報の一例である。エンドユーザが承諾ボタンｄ０５３を選択したことを契機に、トークンが発行され、当該トークンをサーバ１が受信するので、当該トークンも同意情報とみなせる。
図２０はホーム画面の他の例を示す説明図である。ホーム画面ｄ０６は、仮審査の申込が可能である場合のホーム画面である。ホーム画面ｄ０６は仮審査ボタンｄ０６１、口座連携表示ｄ０６２、会計連携表示ｄ０６３、ＰＦｅｒ連携表示ｄ０６４、口座連携ボタンｄ０６５、会計連携ボタンｄ０６６、ＰＦｅｒ連携ボタンｄ０６７、申込ボタンｄ０６８、一覧ボタンｄ０６９及び金額表示ｄ０６Ａを含む。仮審査ボタンｄ０６１から金額表示ｄ０６Ａのそれぞれは、ホーム画面ｄ０３の仮審査ボタンｄ０３１から金額表示ｄ０３Ａと同様である。以下の説明では、主として図１７と異なる構成について説明する。図２０においては、仮審査が申し込める状態であるため、仮審査ボタンｄ０６１が選択可能に表示されている。上述したが、仮審査ボタンｄ０６１を常に選択可能に表示してもよい。エンドユーザは仮審査ボタンｄ０６１を選択して、上述の仮審査処理が起動することが可能である。図２０では、金融機関とのデータ連携が完了している。そのため、口座連携表示ｄ０６２には、連携口座における入出金情報に基づく、エンドユーザの評価値、ここでは７０が表示されている。図２０においても、いずれの会計サービスとの連携も行われていない状況であるため、会計連携表示ｄ０６３には評価値は表示されていない。図２０では、少なくとも一つのプラットフォーマ３との連携が完了しているので、ＰＦｅｒ連携表示ｄ０６４には、エンドユーザの評価値、ここでは１０が表示されている。図２０では、仮審査が完了していないため、図１７同様、申込ボタンｄ０６８は動作しないように表示されている。また、図１７同様に仮審査が行われていない状況なので、金額表示ｄ０６Ａには、依然として金額が表示されていない。
図２１はホーム画面の他の例を示す説明図である。ホーム画面ｄ０７は、借入申込が可能である場合のホーム画面である。ホーム画面ｄ０７は口座連携表示ｄ０７２、会計連携表示ｄ０７３、ＰＦｅｒ連携表示ｄ０７４、口座連携ボタンｄ０７５、会計連携ボタンｄ０７６、ＰＦｅｒ連携ボタンｄ０７７、申込ボタンｄ０７８、一覧ボタンｄ０７９及び金額表示ｄ０７Ａを含む。口座連携表示ｄ０７２から金額表示ｄ０７Ａのそれぞれは、ホーム画面ｄ０６の口座連携表示ｄ０６２から金額表示ｄ０６Ａと同様である。以下の説明では、主として図２０と異なる構成について説明する。図２１においては、仮審査が完了した状態であるため、仮審査ボタンｄ０７１が表示されていない。図２１では、仮審査が完了しているため、申込ボタンｄ０７８が選択可能に表示されている。エンドユーザは申込ボタンｄ０７８を選択することにより、借入の申込が可能である。また、金額表示ｄ０７Ａには、仮審査の結果、借入可能と判定された金額が表示されている。ホーム画面ｄ０７における金額表示ｄ０７Ａは融資条件の一例であり、レンディングに関する情報の一例でもある。
図２１において、エンドユーザが口座連携ボタンｄ０７５、会計連携ボタンｄ０７６又はＰＦｅｒ連携ボタンｄ０７７を操作し連携先を追加した場合、融資条件が変わる場合がある。この場合、エンドユーザが仮審査を申し込まなくとも、データ連携後に仮審査を実行した後に、仮審査結果を反映したホーム画面ｄ０７を表示してもよい。または、データ連携後に表示するホーム画面ｄ０７に、仮審査ボタンｄ０７１を表示し、エンドユーザが仮審査を申し込めるようにしてもよい。
また、エンドユーザが仮審査を受けた後や、借入申込した後に、エコシステム１００からログアウトし、数日後に再度、ログインした場合は、以下の処理を行う。ホーム画面を表示する際に、最新の入出金情報やプラットフォーマ３からのサービス情報（最新データ）に基づき、仮審査を実行し、その結果を反映したホーム画面を表示する。なお、エンドユーザがログインする度に、エンドユーザの操作を要することなく、最新データに基づく仮審査を行い、その結果を反映したホーム画面ｄ０７を表示してもよい。また、エンドユーザがログインしなくとも、例えば１ヶ月に１回、最新データに基づく仮審査の処理を、サーバ１がバッチ処理などで実行してもよい。ここで言うホーム画面は、図２１に示したホーム画面ｄ０７を想定している。
本実施の形態は、以下の効果を奏する。財務情報に限らず、金融機関の口座入出金情報、会計システムの会計データ、プラットフォーマ３の利用履歴などの情報を用いて、借入可能金額等のレンディング情報を生成することが可能となる。
（変形例）
上記の図１０により与信モデル１４１の例を示したが、与信モデル１４１を構成する３つのモデルを統合したモデルを用いて、仮審査をおこなってもよい。図２２は、与信モデルの他の構造例を示す説明図である。与信モデル１４１はエンドユーザの入出金データ、会計データ、サービスデータ等を入力とし、エンドユーザの評価点を出力とするニューラルネットワークである。サービスデータはプラットフォーマ３から得た利用履歴等である。ニューラルネットワークは、例えば、RNN（Recurrent Neural Network）、長短期記憶（LSTM：Long Short Term Memory）ネットワーク、又は、Transformerであり、入出金データ、会計データ、サービスデータの入力を受け付ける入力層と、評価点を出力する出力層とを有する。なお、与信モデル１４１がニューラルネットワーク以外のベイジアンネットワーク、決定木など、他の学習アルゴリズムで構築されたモデルであってもよい。
なお、与信モデル１４１へ、会計システムの利用情報である会計データを入力するのではなく、会計データより得られるキャッシュフローを入力してもよい。入出金データには、口座のその他の情報（アカウント）、例えば、開設してからの経過年月数や、所定期間毎の平均残高等を含めてもよい。また、与信モデル１４１へ入力するサービスデータとして、プラットフォーマ３の利用履歴等ではなく、利用履歴から求めた事業性評価値としてもよい。例えば、利用履歴から求めた利用頻度や利用金額などから事業性評価を行う。
入力層は、入出金データ、会計データ、サービスデータを入力として受け付ける複数のニューロンを有し、入力された項目値を中間層に受け渡す。中間層は、入力層から入力された各値を畳み込むコンボリューション層と、コンボリューション層で畳み込んだ値をマッピングするプーリング層とが交互に連結された構成を有し、入力された情報を圧縮しながら最終的に評価値を抽出する。出力層は、中間層から出力された評価値に基づいて、評価点を出力する。評価点は例えばデフォルト確率であり、０から１までの値を取る。または、評価点は格付けに相当する値としもよい。
与信モデル１４１は、入出金データ、会計データ、サービスデータ及びラベル（正解の評価点）からなる訓練データを用いて、以下のように生成する。サーバ１は、訓練データに含まれる入出金データ、会計データ、サービスデータを入力層に入力し、中間層での演算処理を経て、出力層から評価点を取得する。サーバ１は、出力層から出力された評価点を、訓練データに含むラベル、すなわち正解値と比較し、出力ノードの出力値が正解値に近づくように、中間層での演算処理に用いるパラメータを最適化する。当該パラメータは、例えばニューロン間の重み（結合係数）、各ニューロンで用いられる活性化関数の係数などである。パラメータの最適化の方法は特に限定されないが、例えばサーバ１は誤差逆伝播法を用いて各種パラメータの最適化を行う。サーバ１は、全ての訓練データを用いて上記の学習処理を行い、学習済みの与信モデル１４１を生成する。
与信モデル１４１を仮審査で用いる際は、サーバ１の制御部１１は、与信モデル１４１が出力した評価点、又は、格付け値を取得する。制御部１１は、評価点、又は、格付け値と、エンドユーザの口座残高や口座残高の変動、売上高や資本金などとから、融資額等を定める。
図２２に示した与信モデル１４１では、入出金データ、会計データ、プラットフォーマＡデータ、プラットフォーマＢデータの４種類のデータを入力としているが、入力データが１種類の場合でも、妥当な出力が得られるように、与信モデル１４１を学習することが望ましい。また、プラットフォーマのデータについては、２種類の場合のみならず、１種類、又は、３種類以上のデータを与信モデル１４１へ入力した場合であっても、妥当な出力が得られるように、与信モデル１４１を学習することが望ましい。
（実施の形態２）
本実施の形態は、エンドユーザの事業性評価を複数観点で行う形態に関する。図２３は事業性評価モデルの構造例を示す説明図である。事業性評価モデル１４２は、エンドユーザが利用するプラットフォーマ３のデータを入力とし、エンドユーザの事業性評価を複数の観点で行い、観点毎に評価値を出力するニューラルネットワークである。入力データは、プラットフォーマ３から得たプラットフォーマ３の利用履歴等である。ニューラルネットワークは例えばＣＮＮであり、データの入力を受け付ける入力層と、各観点の評価値を出力する出力層とを有する。観点は、例えば、経営の効率性、取引の機会、競合環境、市場規模、資金調達の必要性等である。他の観点のセットとして、商品力、生産力、営業販売力、顧客基盤、組織管理力等でもよい。なお、入力データとして、入出金データ、会計データを含めてもよい。
入力層は、各種データを入力として受け付ける複数のニューロンを有し、入力された値を中間層に受け渡す。中間層は、入力層から入力された各値を畳み込むコンボリューション層と、コンボリューション層で畳み込んだ値をマッピングするプーリング層とが交互に連結された構成を有し、入力された情報を圧縮しながら最終的に評価値を抽出する。出力層は、中間層から出力された評価値に基づいて、各観点の評価値を出力する。評価値は、１、２、３、４、５の何れかのように離散値であってもよいし、０から１までの連続値であってもよい。
なお、以下の説明では事業性評価モデル１４２がＣＮＮであるものとして説明するが、事業性評価モデル１４２はＣＮＮに限定されず、ＣＮＮ以外のニューラルネットワーク、ベイジアンネットワーク、決定木など、他の学習アルゴリズムで構築されたモデルであってもよい。
事業性評価モデル１４２は、入力する各種データ及び各観点のラベル（正解の評価値）からなる訓練データを用いて、以下のように生成する。サーバ１は、訓練データに含まれる各種データを入力層に入力し、中間層での演算処理を経て、出力層から各観点の評価値を取得する。サーバ１は、出力層から出力された各観点の評価値を、訓練データに含む各観点のラベル、すなわち各観点の正解値と比較し、出力ノードの出力値が正解値に近づくように、中間層での演算処理に用いるパラメータを最適化する。当該パラメータは、例えばニューロン間の重み（結合係数）、各ニューロンで用いられる活性化関数の係数などである。パラメータの最適化の方法は特に限定されないが、例えばサーバ１は誤差逆伝播法を用いて各種パラメータの最適化を行う。サーバ１は、全ての訓練データを用いて上記の学習処理を行い、学習済みの事業性評価モデル１４２を生成する。なお、事業性評価モデル１４２を、与信モデル１４１を構成する第３モデル１４１３として利用してもよい。
図２４は評価結果ＤＢの例を示す説明図である。評価結果ＤＢ１３７はエンドユーザ毎の事業性評価の結果を記憶する。評価結果ＤＢ１３７はユーザＩＤ列、総合評価点列、経営の効率性列、取引の機会列、競合環境列、市場規模列、及び、資金調達の必要性列を含む。ユーザＩＤ列はユーザＩＤを記憶する。総合評価点列は事業性評価の総合点を記憶する。総合点は観点毎の点数に基づいて計算される。例えば、総合点は各観点の評価の平均点である。総合点は観点毎の評価の合計点でもよい。経営の効率性列は経営の効率性についての評価点を記憶する。取引の機会列は取引の機会についての評価点を記憶する。競合環境列は競合環境についての評価点を記憶する。市場規模列は市場規模についての評価点を記憶する。資金調達の必要性列は資金調達の必要性についての評価点を記憶する。
図２５は事業性評価処理の手順例を示すフローチャートである。事業性評価処理はプラットフォーマ３のデータからエンドユーザの事業性を評価する処理である。サーバ１の制御部１１はデータを取得する（ステップＳ８１）。取得するデータは連携済みのプラットフォーマ３のデータである。制御部１１は取得したデータを事業性評価モデル１４２へ入力する（ステップＳ８２）。制御部１１は事業性評価モデル１４２から観点毎の評価値を取得する（ステップＳ８３）。制御部１１は観点毎の評価値から総合評価点を算出する（ステップＳ８４）。制御部１１は観点毎の評価値と総合評価点とを評価結果ＤＢ１３７に記憶し（ステップＳ８５）、処理を終了する。事業性評価処理はエンドユーザのログイン時に実行する。また、バッチ処理などにより定期的に実行する。
続いて、端末２が表示する画面について説明する。端末２が表示する画面の大半は実施の形態１と同様であるが、実施の形態１とは異なるホーム画面について説明する。図２６はホーム画面の他の例を示す説明図である。図２６に示すホーム画面ｄ０８はデータ連携及び仮審査を終了した状態で表示される画面である。ホーム画面ｄ０８は入出金情報表示ｄ０８１、入出金評価値ｄ０８２、会計情報表示ｄ０８３、会計評価値ｄ０８４、事業性評価表示ｄ０８５、事業性評価値ｄ０８６、銀行表示ｄ０８７、会計サービス表示ｄ０８８、申込ボタンｄ０８９、一覧ボタンｄ０８Ａ、及び、金額表示ｄ０８Ｂを含む。入出金情報表示ｄ０８１、会計情報表示ｄ０８３、及び、事業性評価表示ｄ０８５はエンドユーザの評価項目を示す。入出金評価値ｄ０８２、会計評価値ｄ０８４、及び、事業性評価値ｄ０８６は、それぞれ入出金情報、会計情報、プラットフォーマ３から取得したサービス情報に基づくエンドユーザの評価値を示す。銀行表示ｄ０８７は入出金情報の連携がされている銀行を示す。会計サービス表示ｄ０８８は会計情報の連携がされている会計サービスを示す。申込ボタンｄ０８９をエンドユーザが選択すると、端末２からサーバ１へ借入申込の要求が送信される。一覧ボタンｄ０８Ａを選択すると、データ連携が可能な金融機関、会計サービス、プラットフォーマ３の一覧が表示される。金額表示ｄ０８Ｂはエンドユーザが借入可能な金額を表示する。
本実施の形態は、以下の効果を奏する。事業性評価モデル１４２を利用することにより、複数のプラットフォーマ３から取得したサービスデータを用いて、共通する複数の観点（共通する評価軸）で、エンドユーザの事業性を評価することが可能となる。
（事業性評価の活用）
事業性評価の結果をエンドユーザ等が活用するために、エコシステム１００が提供する機能について説明する。図２７はホーム画面の他の例を示す説明図である。図２７に示すホーム画面ｄ０９の構成の中で、既に説明したものと同様な構成については符号及び説明を省略する。図２７に示すホーム画面ｄ０９は事業性評価の結果を観点別に示すものである。ホーム画面ｄ０９は、評価結果ｄ０９１及び連携サービス表示ｄ０９２を含む。評価結果ｄ０９１は事業性評価を観点別に示す。図２７に示す例では事業性評価の観点は、経営の効率性、取引の機会、競合環境、市場規模、及び、資金調達の必要性の５つである。これら５つの観点は、事業性評価モデル１４２と一致させている。各観点の評価値は、事業性評価モデル１４２からの出力に基づく。事業性評価の各観点は５段階評価であり、１が最低評価、５が最高評価である。黒星が評価値を示す。例えば経営の効率性は星２つ、評価値２を示している。図２７において、市場規模については評価できていないため、それを示すため、他の観点よりも文字が細いフォントで小さめに表示している。連携サービス表示ｄ０９２は、データ連携が可能なプラットフォーマ３提供のサービスを示す。連携サービス表示ｄ０９２の中で、通常の表示はエンドユーザが既にデータ連携を設定済みのサービスを示す。文字が細いフォントで小さめに表示しているサービスはデータ連携が未設定のサービスを示す。データ連携が未設定のサービスとして連携サービス表示ｄ０９２は、エンドユーザの事業性評価の結果に基づき、エンドユーザにデータ連携、及び、利用を推奨するサービスを選択して表示してもよい。なお、観点毎の評価値の表示方法は図２７に示したものに限らない。例えば、レーダチャートで示してもよい。また、観点毎の評価値を評価時点と対応付けて複数、記憶しておき、評価値の推移を折れ線グラフ等で表示できるようにしてもよい。
図２８は一覧画面の例を示す説明図である。一覧画面ｄ１０はデータ連携が可能な金融機関やプラットフォーマ３、又は、プラットフォーマ３の提供サービスを一覧表示する。一覧画面ｄ１０は連携先名称欄ｄ１０１、種別欄ｄ１０２、凡例表示ｄ１０３、処理選択欄ｄ１０４、ラジオボタンｄ１０５、及び、追加ボタンｄ１０６を含む。連携先名称欄ｄ１０１はデータ連携が可能な金融機関名称や提供サービス名称を表示する。種別欄ｄ１０２はデータ連携により得られる情報の種別、又は、評価可能となる事業性評価の観点を表示する。凡例表示ｄ１０３は種別欄ｄ１０２の凡例を表示する。種別欄ｄ１０２において、該当する観点は白黒反転表示となっている。例えば、ＩＪネットサービスとのデータ連携を行うと、市場規模及び資金調達の必要について、事業性評価を行うためのデータが得られることを示している。種別欄ｄ１０２を設定するためのデータは、予めプラットフォーマＤＢ１３４に記憶しておく。処理選択欄ｄ１０４は各データ連携先についての処理を選択する欄である。図２８では、新規利用、連携、解除の３種の処理が表示される。新規利用は口座開設又はユーザ登録を希望する場合に選択する。連携はデータ連携を希望する場合に選択する。選択した金融機関に口座がない場合や選択したサービスへのユーザ登録が完了していない場合に、連携を選択したときは、ログイン情報の入力画面において、口座開設やユーザ登録を行う画面に遷移するハイパーリンクをエンドユーザが選択することになる。解除を選択すると、データ連携を解除することができる。既にデータ連携を行なっている金融機関及び提供サービスについては、新規利用、連携は選択できないように表示され、解除のみが選択可能に表示されている。ラジオボタンｄ１０５は複数の金融機関又はプラットフォーマ３とデータ連携を開始する場合に、対象となる金融機関又はサービスを選択する。追加ボタンｄ１０６を選択すると、ラジオボタンｄ１０５で選択された金融機関又はプラットフォーマ３とのデータ連携を行うための設定処理、上述のデータ連携処理が実行される。図２８の例では、ＥＦネットサービス、ＩＪネットサービス、ＫＬネットサービス、ＭＮネットサービス、ＯＰネットサービスがラジオボタンｄ１０５により選択されているから、追加ボタンｄ１０６を選択すると、これら５つのサービスについてのデータ連携処理が順次、実行される。なお、種別欄ｄ１０２に表示する情報の種別、事業性評価の観点は一例であり、他の種別及び他の観点も採用可能である。
図２９は一覧画面作成処理の手順例を示すフローチャートである。サーバ１の制御部１１は端末２から、データ連携先一覧の要求を受信する（ステップＳ１０１）。制御部１１はエンドユーザが既にデータ連携を行なっているサービス（連携済サービス）を取得する（ステップＳ１０２）。連携済サービスは連携アカウントＤＢ１３２から取得可能である。制御部１１はデータ連携の候補となるサービス（候補サービス）を選択する（ステップＳ１０３）。制御部１１はプラットフォーマＤＢ１３４から連携可能サービスを抽出する。制御部１１が抽出したサービスから連携済サービスを除いたものが、候補サービスとなる。制御部１１は絞り込みを行う。候補サービスそれぞれについて、プラットフォーマＤＢ１３４から、データ連携により評価可能となる事業性評価の観点を取得する。また、エンドユーザの事業性評価の観点毎の評価値を評価結果ＤＢ１３７等から取得する。制御部１１は評価値を昇順に並べ替え、上位２つの観点を選択する。制御部１１は、候補サービスを選択した観点に対応するサービスに絞り込み（ステップＳ１０４）、絞り込んだサービスについての一覧を作成する（ステップＳ１０５）。制御部１１は作成した一覧を端末２へ送信し（ステップＳ１０６）、処理を終了する。
このように、データ連携を設定する候補サービス一覧を表示する際に、エンドユーザの事業性評価の結果を利用することにより、エンドユーザの成長に資するプラットフォーマ３の提供サービスを、一覧表示することが可能となる。当該一覧表示は推奨情報の一例である。それにより、エンドユーザがプラットフォーマ３のサービスの利用を開始し、事業性評価が向上することが期待される。その結果、エコシステム１００により、エンドユーザとプラットフォーマ３とはＷｉｎ－Ｗｉｎの関係を築くことが可能となる。
（インセンティブ付与）
エンドユーザがプラットフォーマ３とのデータ連携を行うことを促すために、インセンティブの付与を行なってもよい。以下、インセンティブ付与の例を説明する。
図３０は付与条件ＤＢの例を示す説明図である。付与条件ＤＢ１３８はインセンティブ、ここではポイントをエンドユーザへ付与する条件を記憶する。付与条件ＤＢ１３８は条件ＩＤ列、事業性評価列、付与間隔列、有効期限列及びポイント数列を含む。条件ＩＤ列は付与条件を一意に特定可能な条件ＩＤを記憶する。事業性評価列は付与を受けるための事業性評価の条件を記憶する。事業性評価列はさらに総合評価点列、経営の効率性列、取引の機会列、競合環境列、市場規模列、及び、資金調達の必要性列を含む。総合評価点列は事業性評価の総合点を記憶する。経営の効率性列、取引の機会列、競合環境列、市場規模列、及び、資金調達の必要性列はそれぞれ、経営の効率性の観点、取引の機会の観点、競合環境の観点、市場規模の観点、及び、資金調達の必要性の観点についての評価値を記憶する。付与間隔列はポイントを付与する間隔を記憶する。有効期限列はポイントの有効期限を記憶する。ポイント数列は付与するポイント数を記憶する。
図３１は特典ＤＢの例を示す説明図である。特典ＤＢ１３９はポイント使用により得られる特典の情報を記憶する。特典ＤＢ１３９は特典ＩＤ列、利用対象列、内容列及びポイント数列を含む。特典ＩＤ列は特典を一意に特定な可能な特典ＩＤを記憶する。利用対象列は特典を利用できる金融機関又はプラットフォーマ３のＩＤを記憶する。内容列は特典の内容を記憶する。ポイント数列は特典を利用するために必要なポイント数を記憶する。
図３２は付与履歴ＤＢの例を示す説明図である。付与履歴ＤＢ１３Ａはエンドユーザへのポイント付与の履歴を記憶する。付与履歴ＤＢ１３ＡはユーザＩＤ列、条件ＩＤ列、付与日列、期限列、状態列及びポイント列を含む。ユーザＩＤ列はポイントを付与したエンドユーザのユーザＩＤを記憶する。条件ＩＤ列はポイント付与の契機となった付与条件の条件ＩＤを記憶する。付与日列はエンドユーザへポイントを付与した日付を記憶する。期限列はポイントの使用期限を記憶する。状態列はポイントの状態を記憶する。状態は例えば、未使用、使用済である。ポイント列はエンドユーザへ付与したポイントの数量を記憶する。
図３３はポイント付与処理の手順例を示すフローチャートである。ポイント付与処理は、エンドユーザがログインした際、仮審査を実行した際などに実行される。サーバ１の制御部１１はエンドユーザの事業性評価の結果を取得する（ステップＳ１２１）。制御部１１は付与条件ＤＢ１３８を参照し、事業性評価の結果に適合する付与条件を抽出する（ステップＳ１２２）。制御部１１は抽出した付与条件の一つを選択する（ステップＳ１２３）。制御部１１は選択した付与条件による直近のポイント付与日を取得する（ステップＳ１２４）。制御部１１はポイントを付与するか否かを判定する（ステップＳ１２５）。取得した付与日と現在日付とから、付与条件に含まれる付与間隔の条件を満たしている場合、制御部１１はポイントを付与すると判定する。付与間隔の条件を満たしていない場合、制御部１１はポイントを付与しないと判定する。制御部１１はポイントを付与すると判定した場合（ステップＳ１２５でＹＥＳ）、付与するポイントを付与履歴ＤＢ１３Ａに記憶する（ステップＳ１２６）。ステップＳ１２６のあと、または制御部１１はポイントを付与しないと判定した場合（ステップＳ１２５でＮＯ）、未処理の付与条件があるか否かを判定する（ステップＳ１２７）。制御部１１は未処理の付与条件があると判定した場合（ステップＳ１２７でＹＥＳ）、処理をステップＳ１２３へ戻し、未処理の付与条件についての処理を行う。制御部１１は未処理の付与条件がないと判定した場合（ステップＳ１２７でＮＯ）、特典ＤＢ１３９を参照して、付与したポイントが利用可能な特典を抽出する（ステップＳ１２８）。制御部１１は利用可能な特典の情報とともに、ポイントが付与された旨の付与メッセージを端末２へ送信し（ステップＳ１２９）、処理を終了する。
図３４は付与通知画面の例を示す説明図である。付与通知画面ｄ１１は、例えばホーム画面等に重ねて、ポップアップ画面として表示する。付与通知画面ｄ１１は付与メッセージｄ１１１、利用可能特典表示ｄ１１２、及び、閉じるボタンｄ１１３を含む。付与メッセージｄ１１１はポイントの付与を知らせるメッセージであり、付与されたポイントの数量が含まれている。利用可能特典表示ｄ１１２は付与されたポイントで利用可能な特典を表示する。エンドユーザが閉じるボタンｄ１１３を選択すると、端末２の制御部２１は付与通知画面を閉じる。
エンドユーザはプラットフォーマ３が提供するサービスを利用することにより、事業性評価の上昇と、それに伴うポイントの獲得が期待できる。その結果、エンドユーザのプラットフォーマ３の利用数の増加と評価向上とを目指す動機づけとなる。
ポイント付与処理の結果は、エンドユーザが利用しているプラットフォーマ３へ通知してもよい。そして、エンドユーザがプラットフォーマ３へログインした際に、上述の付与通知画面を表示してもよい。また、付与履歴ＤＢ１３Ａをプラットフォーマ３は参照可能とし、プラットフォーマ３のユーザ画面においても、エンドユーザは保有ポイントの数量を確認可能とすることが望ましい。そして、ポイントを利用して受けることが可能な特典を、プラットフォーマ３のユーザ画面でも一覧表示することが望ましい。
ポイントの付与方法は上述したものに限らない。事業性評価の結果に関わらず、データ連携を行っているプラットフォーマ３の数や期間に応じたポイントを定期的に、例えば、月ごとに付与してもよい。特典についてもポイントに応じて利用可能とする場合に限らず、プラットフォーマ３とのデータ連携を行っているエンドユーザに対して、特典の利用を許可してもよい。
（本人データ整合性確認）
本人データの整合性確認は、以下の機能である。サーバ１が有するユーザの情報と、連携するプラットフォーマ３が有するユーザの情報との整合性を確認し、ユーザの情報の信頼性を高めることを目的とする機能である。具体的には、上述のデータ連携処理が実行されると、サーバ１はプラットフォーマ３から、ユーザの情報が取得可能となるので、本人データ整合性確認する処理を実行する。
図３５は整合性確認処理の手順例を示すフローチャートである。サーバ１の制御部１１は本人情報を取得する（ステップＳ１３１）。制御部１１は、予めデータ連携処理が完了しているプラットフォーマから本人情報を取得し、補助記憶部１３に記憶している。制御部１１はプラトッフォーマから取得しているエンドユーザの本人情報と、ユーザＤＢ１３１に記憶してあるエンドユーザの情報との整合性を確認する（ステップＳ１３２）。制御部１１は、氏名・名称、メールアドレス、所在地住所等、受信した本人情報とユーザＤＢ１３１に記憶してあるユーザ情報とで共通する項目間で、整合性を確認する。制御部１１は整合性の確認結果を記憶し（ステップＳ１３３）、処理を終了する。例えば確認結果は「整合性あり」、「整合性なし」である。
確認結果は点数化してもよい。複数のプラットフォーマとのデータ連携が完了しているエンドユーザにおいて、ユーザＤＢ１３１に記憶してある本人情報と整合性がある判定したプラットフォーマの本人情報の数により、点数を定める。また、プラットフォーマ３から本人情報を得る際に、eKYC等により確認済みか否かの情報も取得し、プラットフォーマ３での本人確認が未実行の場合に、点数を下げてもよい。
整合性確認処理は仮審査の後に行われる本審査において実行されることを想定している。そのため、整合性確認の結果は、整合性確認処理において、エンドユーザへの通知は行わない。なお、確認結果が「整合性なし」であり、その時点で「本審査」を打ち切る場合は、その旨をエンドユーザへ通知してもよい。
プラットフォーマ３がアカウントアグリーゲーション等を行っており、エンドユーザが利用している金融機関口座の入出金データを保有している場合、当該口座と紐付けられた本人情報を、プラットフォーマ３はサーバ１へ送信してもよい。金融機関では特に慎重に本人確認を行っているため、金融機関が保有するデータと整合していれば、情報の信頼性が高まることになる。
（関連データ整合性確認）
関連データ整合性確認は、以下の機能である。エンドユーザが、複数のプラットフォーマ３とのデータ連携を設定している場合に、プラットフォーマ３それぞれから提供されるデータ間の関連性を用いて、それぞれのデータが整合しているかを確認する機能である。データが整合していれば、それぞれのプラットフォーマ３から連携されたデータの保有者が同一人であるといえる。例えば、第１のプラットフォーマ３から在庫データを、第２のプラットフォーマ３から受発注データを、第３のプラットフォーマ３から口座データを、サーバ１は参照可能な場合、これら３種類のデータの関連性を用いて、データの整合性を確認することが可能である。以下の説明では、在庫データ、会計データ、口座データの整合性を確認する例について述べる。
図３６は整合性がある関連データの例を示すテーブルである。「在庫減少（販売）」、「在庫増加（仕入）」、「在庫金額（月末）」の各行は、在庫データである。「売上額」、「仕入額」の各行は、会計データである。「入金額」、「支払額」は口座データである。例えば、２０２２年１月に販売により在庫が減少し、「在庫減少（販売）」行の値が１００となっている。それに対応し、「売上額」行に売上１２０が計上されている。そして、２０２２年３月に売上に対応した入金１２０が、「入金額」行に計上されており、在庫データ、会計データ、口座データの整合性が取れていることが確認できる。また、２０２２年２月に販売により在庫が１２０減少したことが、「在庫減少（販売）」行の値からわかる。それに対応して、２０２２年３月に１２０の仕入れを行ったことが、「在庫増加（仕入）」行の値から読み取れる。それに応じて、「仕入額」行に１２０が計上されている。そして、２０２２年５月に仕入れに対する支払いがされ、「支払額」行に１２０が計上されている。このような流れでも、在庫データ、会計データ、口座データの整合性が取れていることが確認できる。
図３７は整合性がある関連データの例を示すグラフである。縦軸は金額であり、単位は例えば１００万円である。横軸は年月である。図３７は在庫減少（販売）額と入金額との時間推移を示している。上述したように、販売してから代金の入金までには時間差があり、金額は一致しないが、グラフの形状から両データは整合していることが、視覚的に確認可能である。
図３８は整合性が疑われる関連データの例を示すテーブルである。図３８においては、２０２２年９月度から「在庫減少（販売）」と「売上額」との関係が変化している。「売上額」と「入金額」とは関連していることから、「在庫減少（販売）」と「入金額」との関係が変化していることが検知でき、在庫データ、会計データ、口座データの整合性が疑われる。
図３９は整合性が疑われる関連データの例を示すグラフである。軸や示している値は、図３７と同様である。上述したように、「在庫減少（販売）」と「入金額」との間では時間差があり、金額は一致しないものの、グラフの形状は同じようなるはずであるが、楕円で囲った部分においては、明らかに２つのグラフ形状が異なっており、データ整合性が疑われることは明らかである。
図４０は関連データ整合性確認処理の手順例を示すフローチャートである。サーバ１の制御部１１は、データ連携によりプラットフォーマ３から得ているデータ項目（以下、「連携項目」という。）を取得する（ステップＳ１５１）。連携項目は補助記憶部１３に記憶している。制御部１１は連携項目（例えば、在庫データ、会計データ、口座データそれぞれに含まれるデータ項目）を用いて、整合性を確認するために利用できる規則を検索する（ステップＳ１５２）。規則は予め補助記憶部１３に記憶しておく。制御部１１は利用できる規則があるか否かを判定する（ステップＳ１５３）。検索にヒットしたら規則があると判定し、検索にヒットしなかったら規則がないと、制御部１１は判定する。制御部１１は利用できる規則があると判定した場合（ステップＳ１５３でＹＥＳ）、規則に基づき整合性を確認するためのデータを取得する（ステップＳ１５４）。制御部１１は取得したデータの整合性の確認を行う（ステップＳ１５５）。例えば、「売上÷在庫減少額」を月毎に算出する。算出した値について、全企業（もしくは同業種）の平均が１．２（標準偏差が０．１）を基準値として、１．０～１．４に収まっていない月が連続して３カ月発生した場合に、不整合があるものと判定する。制御部１１は整合性の確認結果を記憶し（ステップＳ１５６）、処理を終了する。例えば確認結果は「整合性あり」、「整合性なし」である。制御部１１は利用できる規則がないと判定した場合（ステップＳ１５３でＮＯ）、結果に確認できない旨を示す「不可」を設定し（ステップＳ１５７）、処理を終了する。
関連データ整合性確認処理は仮審査の後に行われる本審査において実行されることを想定している。そのため、整合性確認の結果は、関連データ整合性確認処理において、エンドユーザへの通知は行わない。なお、確認結果が「整合性なし」であり、その時点で「本審査」を打ち切る場合は、その旨をエンドユーザへ通知してもよい。また、エンドユーザに対して、エコシステム１００の利用制限を行ってもよい。
（複数モデルの結果の統合機能）
図１０に示したように、与信モデル１４１は複数のモデルの結果を結合して、融資の可否等の審査結果を出力する構成も取りうる。以下、複数モデルの結果を統合する機能について説明する。なお、図１０において、符号１４１４は結合器を示し、結合器１４１４は、第１モデル１４１１、第２モデル１４１２、第３モデル１４１３それぞれの判定結果を結合し、最終的な判定結果を出力すると述べたが、以下に説明する内容は、「統合」との表現がより適切であるため、「結合」ではなく、「統合」という。
以下の説明においては、Ａモデル、Ｂモデルの２つモデルの結果を統合する場合の例を示す。２つのモデルは、上述した会計モデル、入出金モデル、サービスモデルであってもよいし、そうでなくともよい。Ａモデル、Ｂモデルは、エンドユーザの会計データ、金融口座における入出金情報、在庫データ等を入力すると、判定結果を出力する。判定結果には、ＰＤ（Probability of Default：デフォルト確率）値と融資可能金額が含まれているとする。ＰＤ値が大きいほど、デフォルトする確率が高いということであり、ＰＤ値が小さいほど、デフォルトする確率が低いということである。Ａモデルが出力したＰＤ値をＰＤＡ、Ｂモデルが出力したＰＤ値をＰＤＢとする。このとき、エンドユーザのＰＤ値を以下のように計算する。
ＰＤ値＝α×ＰＤＡ＋β×ＰＤＢ
０≦α≦１、０≦β≦１
α、βは係数である。α、βはエンドユーザの業種や、ＰＤＡ及びＰＤＢの値域によって、変動させてもよい。
次に金利の決定方法について説明する。まずベース金利を算出する。例えば、ベース金利はＰＤ値と経費率と利鞘とを足し合わせたものとする。経費率と利鞘とは予め定めておくが、定期的に見直すことが望ましい。
次に、優遇金利を算出する。エンドユーザが、他のシステムとエコシステム１００とのデータ連携を認めることにより、得られたデータの数（提供データ種類数）や、データ連携により事業性評価を行えた数（事業性評価スコアの数）により、優遇金利の値が決まる。例えば、以下のように求める。
Ｘ＝ｒ１×（提供データ種類数）
Ｙ＝ｒ２×（事業評価スコア数）
０＜ｒ１＜１、０＜ｒ２＜１
優遇金利＝ｍｉｎ｛上限値，Ｘ＋Ｙ｝
ｍｉｎ｛値１，値２｝は、値１と値２のうち、小さい方の値が採用されることを意味する。貸出金利は、ベース金利－優遇金利とする。
なお、学習モデル（ここではＡモデル、Ｂモデル）が出力するＰＤ値が、提供データ種類数、事業評価スコア数を十分に考慮した上での値であると、評価できる場合は、優遇金利の算出を行わなくともよい。
融資可能額の決定方法について説明する。例えば、ＰＤ値と同様に、２つの学習モデルが出力した融資可能金額に重みをつけて足したものを融資可能金額とする。
融資可能金額＝γ×（モデルＡの融資可能金額）＋δ×（モデルＢの融資可能金額）
０≦γ≦１、０≦δ≦１、但し、γ≠０又はδ≠０
γ、δは係数である。γ、δはエンドユーザの業種や、ＰＤＡ及びＰＤＢの値域によって、変動させてもよい。なお、学習モデルが融資可能金額を出力しない場合は、当該学習モデルへ入力されるデータ等に基づいて、融資可能金額を算出してもよい。また、学習モデルが融資可能金額を判定した基準時点と、処理時点との間に、エンドユーザが借入をしている場合、学習モデルが出力した融資可能金額から、その借入額を差し引いた額を、当該学習モデルにより決定された融資可能金額とすることが望ましい。
続いて、複数モデルの結果の統合機能を用いた審査処理について説明する。図４１は審査処理の手順例を示すフローチャートである。審査処理はサーバ１で実行される処理であり、端末２等からの要求により、実行される。サーバ１の制御部１１は審査に必要なデータを収集する（ステップＳ１７１）。制御部１１は、データ連携しているプラットフォーマ３から得たデータが最新であるか否かを確認し、最新でない場合は、データを更新する。制御部１１は複数の学習モデルへ、各モデルが求めている入力データを入力し、各学習モデルが出力したＰＤ値を取得する（ステップＳ１７２）。制御部１１は複数のＰＤ値から、一つのＰＤ値（使用デフォルト確率）を決定する（ステップＳ１７３）。制御部１１は決定したＰＤ値を用いて、融資金利を算出する（ステップＳ１７４）。制御部１１は、融資可能額を算出する（ステップＳ１７５）。制御部１１は審査要求をした端末２へ結果（金利、融資可能額）を出力し（ステップＳ１７６）、処理を終了する。
各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
１００ エコシステム
１ サーバ
１１ 制御部
１２ 主記憶部
１３ 補助記憶部
１３１ ユーザＤＢ
１３２ 連携アカウントＤＢ
１３３ 入出金ＤＢ
１３４ プラットフォーマＤＢ
１３５ 代表者・事業主ＤＢ
１３６ 法人ＤＢ
１３７ 評価結果ＤＢ
１３８ 付与条件ＤＢ
１３９ 特典ＤＢ
１３Ａ 付与履歴ＤＢ
１４１ 与信モデル
１４２ 事業性評価モデル
１５ 通信部
１６ 読み取り部
１Ｐ 制御プログラム
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
２ 端末
２１ 制御部
２２ 主記憶部
２３ 補助記憶部
２４ 通信部
２５ 入力部
２６ 表示部
２Ｐ 制御プログラム
３ プラットフォーマ
Ｂ バス
Ｎ ネットワーク
本願の一態様に係る情報処理方法は、プラットフォーマが事業者にサービスを提供するサイトに設定されたレンディングを申し込むためのリンクを、前記事業者が操作したことに起因して、前記レンディングにおける同意画面を事業者端末へ送信し、前記事業者端末から、前記事業者の同意情報を受信し、前記事業者の登録情報、口座入出金情報、及び、会計システムの利用情報を取得し、前記プラットフォーマを含む複数のプラットフォーマより、各プラットフォーマのサービスの利用に関するサービスデータを取得し、前記各プラットフォーマの前記サービスデータに基づいて、複数観点の事業性評価の評価値を導出し、取得した前記登録情報、前記口座入出金情報、前記利用情報及び前記各プラットフォーマの前記サービスデータに基づき、前記事業者向けの融資条件を導出し、前記融資条件を含むレンディングに関する情報、複数観点の前記事業性評価の各評価値、及び、前記複数のプラットフォーマのリストを、前記事業者端末へ送信する処理をコンピュータが行うことを特徴とする。

Claims (16)

  1. プラットフォーマが事業者にサービスを提供するサイトに設定されたレンディングを申し込むためのリンクを、前記事業者が操作したことに起因して、前記レンディングにおける同意画面を事業者端末へ送信し、
    前記事業者端末から、前記事業者の同意情報を受信し、
    前記レンディングに関する前記事業者の登録情報、及び、該事業者の前記プラットフォーマのサービスの利用に関するサービスデータを取得し、
    取得した前記登録情報及び前記サービスデータに基づき、前記事業者向けのレンディングに関する情報を、前記事業者端末へ送信する
    処理をコンピュータが行うことを特徴とする情報処理方法。
  2. 前記登録情報又はサービスデータは、口座入出金情報、会計システムの利用情報、又は事業性評価結果の少なくとも一つを含み、
    前記レンディングに関する情報は、融資条件を含む
    ことを特徴とする請求項１に記載の情報処理方法。
  3. 前記事業者のキャッシュフロー、アカウント、又は事業性評価に基づき、前記融資条件を決定する
    ことを特徴とする請求項２に記載の情報処理方法。
  4. 前記サービスデータに基づき、前記事業性評価を行う
    ことを特徴とする請求項２又は請求項３に記載の情報処理方法。
  5. 前記事業者のログイン情報を受信し、
    前記登録情報、前記口座入出金情報、前記利用情報、及び、前記サービスデータの最新データに基づき、前記融資条件を更新し、前記事業者端末へ送信する
    ことを特徴とする請求項２又は請求項３に記載の情報処理方法。
  6. 前記プラットフォーマを含む前記事業者が利用するプラットフォーマを特定し、
    複数プラットフォーマの情報が記憶してあるプラットフォーマ記憶部を参照し、特定したプラットフォーマを除くプラットフォーマの一覧を作成し、
    作成した一覧を前記事業者端末へ送信する
    ことを特徴とする請求項１から請求項３のいずれか一項に記載の情報処理方法。
  7. 前記事業性評価に基づき、前記事業者の成長に資するプラットフォーマを選択し、
    選択したプラットフォーマの推奨情報を、前記事業者端末へ送信する
    ことを特徴とする請求項２から請求項３のいずれか一項に記載の情報処理方法。
  8. 前記サービスデータに加え、前記事業者から指定を受けたプラットフォーマのサービスデータを取得し、
    取得した２種類のサービスに基づき、レンディングに関する情報を更新する
    ことを特徴とする請求項１から請求項３のいずれか一項に記載の情報処理方法。
  9. 複数のプラットフォーマから取得した各サービスデータに基づく各事業性評価を、共通の評価軸により行い、
    統合した事業性評価を前記レンディング情報と共に前記事業者端末へ送信する
    ことを特徴とする請求項２又は請求項３に記載の情報処理方法。
  10. 前記一覧はプラットフォーマの利用登録画面へ遷移するリンク情報を含む
    ことを特徴とする請求項６に記載の情報処理方法。
  11. 前記事業性評価に基づき、銀行又は前記プラットフォーマから受けられる特典を決定し、
    決定した前記特典を前記事業者端末へ送信する
    ことを特徴とする請求項２又は請求項３に記載の情報処理方法。
  12. プラットフォーマが事業者にサービスを提供するサイトに設定されたレンディングを申し込むためのリンクを、前記事業者が操作したことに起因して、前記レンディングにおける同意画面を事業者端末へ送信し、
    前記事業者端末から、前記事業者の同意情報を受信し、
    前記レンディングに関する前記事業者の登録情報、及び、該事業者の前記プラットフォーマのサービスの利用に関するサービスデータを取得し、
    取得した前記登録情報及び前記サービスデータに基づき、前記事業者向けのレンディングに関する情報を、前記事業者端末へ送信する
    処理をコンピュータに行わせることを特徴とする情報処理プログラム。
  13. プラットフォーマが事業者にサービスを提供するサイトに設定されたレンディングを申し込むためのリンクを、前記事業者が操作したことに起因して、前記レンディングにおける同意画面を事業者端末へ送信する第１送信部と、
    前記事業者端末から、前記事業者の同意情報を受信する受信部と、
    前記レンディングに関する前記事業者の登録情報、及び、該事業者の前記プラットフォーマのサービスの利用に関するサービスデータを取得する取得部と
    取得した前記登録情報及び前記サービスデータに基づき、前記事業者向けのレンディングに関する情報を、前記事業者端末へ送信する第２送信部と
    を備えることを特徴とする情報処理装置。
  14. 前記プラットフォーマが有する前記事業者の本人情報を取得し、
    取得した前記本人情報と予め記憶してあるユーザ情報とにおいて、共通するデータ項目値の整合性を確認し、
    確認結果を出力する
    ことを特徴とする請求項１から請求項３の何れか一項に記載の情報処理方法。
  15. 異なるプラットフォーマから取得した前記サービスデータに含まれ、関連性のある複数のデータ項目値を取得し、
    前記関連性に基づいて、取得した複数の前記データ項目値の整合性を確認し、
    確認結果を出力する
    ことを特徴とする請求項１から請求項３の何れか一項に記載の情報処理方法。
  16. 取得した前記登録情報又は前記サービスデータを、登録情報又はサービスデータを入力した場合に、デフォルト確率を出力する複数の学習モデルへ入力し、
    複数の前記学習モデルそれぞれが出力したデフォルト確率に基づいて、使用する使用デフォルト確率を算出し、
    算出した前記使用デフォルト確率に基づいて、融資金利を算出する
    ことを特徴とする請求項２又は請求項３に記載の情報処理方法。
JP2023035838A 2022-03-15 2023-03-08 情報処理方法、情報処理プログラム及び情報処理装置 Active JP7337298B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023134799A JP2023153284A (ja) 2022-03-15 2023-08-22 情報処理方法、情報処理プログラム及び情報処理装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022040582 2022-03-15
JP2022040582 2022-03-15

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023134799A Division JP2023153284A (ja) 2022-03-15 2023-08-22 情報処理方法、情報処理プログラム及び情報処理装置

Publications (2)

Publication Number Publication Date
JP7337298B1 JP7337298B1 (ja) 2023-09-01
JP2023135630A true JP2023135630A (ja) 2023-09-28

Family

ID=87797925

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2023035838A Active JP7337298B1 (ja) 2022-03-15 2023-03-08 情報処理方法、情報処理プログラム及び情報処理装置
JP2023134799A Pending JP2023153284A (ja) 2022-03-15 2023-08-22 情報処理方法、情報処理プログラム及び情報処理装置

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023134799A Pending JP2023153284A (ja) 2022-03-15 2023-08-22 情報処理方法、情報処理プログラム及び情報処理装置

Country Status (1)

Country Link
JP (2) JP7337298B1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011215762A (ja) * 2010-03-31 2011-10-27 Rakuten Inc 資金提供代行システム
JP2020067682A (ja) * 2018-10-22 2020-04-30 フリー株式会社 融資条件を判定するための装置、方法及びそのためのプログラム
JP2020166866A (ja) * 2019-06-14 2020-10-08 株式会社ビジネスインテリジェンス 出力プログラム及び表示プログラム
JP2021101359A (ja) * 2019-06-06 2021-07-08 フリー株式会社 情報提供装置、情報提供方法及び情報提供プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011215762A (ja) * 2010-03-31 2011-10-27 Rakuten Inc 資金提供代行システム
JP2020067682A (ja) * 2018-10-22 2020-04-30 フリー株式会社 融資条件を判定するための装置、方法及びそのためのプログラム
JP2021101359A (ja) * 2019-06-06 2021-07-08 フリー株式会社 情報提供装置、情報提供方法及び情報提供プログラム
JP2020166866A (ja) * 2019-06-14 2020-10-08 株式会社ビジネスインテリジェンス 出力プログラム及び表示プログラム

Also Published As

Publication number Publication date
JP7337298B1 (ja) 2023-09-01
JP2023153284A (ja) 2023-10-17

Similar Documents

Publication Publication Date Title
US11995645B2 (en) Computer-implemented system and method for generating and extracting user related data stored on a blockchain
Chen et al. A trust model for online peer-to-peer lending: a lender’s perspective
JP5905544B2 (ja) オンライン評価システムおよび方法
AU2009324949B2 (en) Financial gadgets
US20070288355A1 (en) Evaluating customer risk
JP6262909B1 (ja) 算出装置、算出方法及び算出プログラム
US20150066739A1 (en) Adaptive credit network
JP6194092B1 (ja) 算出装置、算出方法及び算出プログラム
US20230169553A1 (en) Determining an automatic acquisition approach for an exchange item request
US7769629B1 (en) System and method for providing hierarchical reporting for online incentive programs
US20230222568A1 (en) Product transaction management computer, product transaction system, and product transaction method
JP2004054769A (ja) 貸出資産管理システム、貸出資産管理方法、その記録媒体およびプログラム
JP7337298B1 (ja) 情報処理方法、情報処理プログラム及び情報処理装置
John The influence of mobile money services usage on small and medium enterprises operations in Tanzania
JP4213692B2 (ja) 貸出資産管理システム
Oluoch Factors affecting internet banking adoption in Kenya: Case study of National Bank of Kenya and equity Bank
US20220327591A1 (en) Automatically determining an acquisition threshold for an exchange item
JP7359910B1 (ja) 情報処理装置、情報処理方法、およびプログラム
Mohammad et al. Banks’ distributional channel strategies, customer satisfaction and mediating role of trust
JP6839241B2 (ja) 情報管理システム、情報管理方法及び情報管理プログラム
Kimani Bitcoin adoption in South Africa, an end user perspective
TWI709923B (zh) 行為模式信評系統
Tadesse Challenges and opportunities of Ethiopay ATM service
SENIBITU THE PROSPECT AND CHALLENGES OF E-BANKING FROM CUSTEMER PERSPEPECTIVE: THE CASE OF COMMERCIAL BANK OF ETHIOPIA IN SOUTH ADDIS ABABA DISTRICT
Thinzar Customer Satisfaction and Continuance Use Intention Towards Credit Card Services of KBZ Bank (Aye Myat Thinzar, 2024)

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230418

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20230418

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230523

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230613

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230711

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230725

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230822

R150 Certificate of patent or registration of utility model

Ref document number: 7337298

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150