JP7216466B2 - 金融資産管理システムと連携したサービスを提供するサービス提供システム - Google Patents

金融資産管理システムと連携したサービスを提供するサービス提供システム Download PDF

Info

Publication number
JP7216466B2
JP7216466B2 JP2021177081A JP2021177081A JP7216466B2 JP 7216466 B2 JP7216466 B2 JP 7216466B2 JP 2021177081 A JP2021177081 A JP 2021177081A JP 2021177081 A JP2021177081 A JP 2021177081A JP 7216466 B2 JP7216466 B2 JP 7216466B2
Authority
JP
Japan
Prior art keywords
user
information
lender
borrower
unit
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.)
Active
Application number
JP2021177081A
Other languages
English (en)
Other versions
JP2022009712A (ja
Inventor
真琴 城田
正士 須崎
克典 新井
祐一郎 豊崎
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.)
Nomura Research Institute Ltd
Original Assignee
Nomura Research Institute 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
Priority claimed from JP2016206040A external-priority patent/JP6800513B2/ja
Priority claimed from JP2020193056A external-priority patent/JP6971522B2/ja
Application filed by Nomura Research Institute Ltd filed Critical Nomura Research Institute Ltd
Priority to JP2021177081A priority Critical patent/JP7216466B2/ja
Publication of JP2022009712A publication Critical patent/JP2022009712A/ja
Priority to JP2023005773A priority patent/JP2023033547A/ja
Application granted granted Critical
Publication of JP7216466B2 publication Critical patent/JP7216466B2/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)

Description

本発明は、金融資産管理システムと連携したサービスを提供する技術に関する。
銀行、証券、保険などの各種の金融機関の口座情報を集約して、個人の資産を一元的に管理するPFM(Personal Financial Management:個人金融資産管理)システムが普及している。特許文献1には、PFMシステムに関する技術が開示されている。PFMシステムを用いると、個人の資産を正確に把握することができる。
また、PFMに類似したシステムとして、企業の収支、財務状況、資産状況を一元的に管理する会計システムも既に存在する。
特開2016-149103号公報
PFMシステム又は会計システムで得られた情報を用いた新しいサービスについては、これまで提案がなされていない。
本発明の一実施形態に係るサービス提供システムは、複数の種類の金融情報を集約した金融資産情報を管理する金融資産管理システムから、ユーザの金融資産情報を取得する取得部と、前記金融資産情報に基づいて、貸し手のユーザと借り手のユーザとをマッチングさせるマッチング部とを有する。
本発明によれば、PFMシステム又は会計システムで得られた情報を用いた新しいサービスを提供することができる。
サービス提供システムを含む全体のシステム構成の一例を示す図である。 ユーザ端末で表示される画面の一例を示す図である。 PF情報の一例を示す図である。 ユーザ端末で表示される画面の一例を示す図である。 マイクロファイナンスのコンセプトの例を示す図である。 貸し手ユーザと受け手ユーザとをマッチングさせる例を説明する図である。 セグメント化の一例を示す図である。 マッチング処理の一例を示すフローチャートである。 貸し手のユーザ端末の表示部で表示される画面一例を示す図である。 リスクプレミアムを説明する図である。 情報提供部によって公開される情報の一例を示す図である。 情報公開の例を示す図である。
以下、図面を参照しながら本発明の実施形態について詳細に説明する。なお、以下の実施形態において説明する構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
<<用語の説明>>
まず、最初に本明細書で用いる用語について説明する。
PFM(Personal Financial Management):銀行、クレジット会社、証券、保険などの各種の金融機関の口座情報を集約して、個人の資産を一元的に管理することである。
PF(Personal Financial)情報:PFMを行うPFMシステムにおいて得られる情報である。PFMシステムは、各種の金融機関のサーバと連携して情報を集約(アグリゲート)しており、PF情報は、このように複数の種類の金融機関から得られる情報が集約された情報のことを指す。PF情報には、例えば、日々の家計などの入出金情報が含まれる。この入出金情報には、使途、明細などの詳細事項が含まれる。また、PF情報には、預金、株式、投資信託などの各種の金融資産の情報が含まれる。
レンディング:お金を貸したい(投資したい)人および企業などと、お金を借りたい人および企業などとを結びつけることをいう。
ロボ・アドバイザー:コンピュータが、投資家(貸し手)のプロファイルに応じて自動的に資産運用を行うサービスのことをいう。一般に、投資家(貸し手)が複数の設問に回答することで、投資家(貸し手)のプロファイルが決定される。
サービス提供システム:本明細書で説明する主なサービスを提供するシステムのことである。例えば、レンディングや、ロボ・アドバイザーなどのサービスが提供される。
お金を貸す:サービス提供システムが提供するサービス(レンディング、ロボ・アドバイザー)に関して資金を供給することを示す。本明細書では、類似の表現として、出資、投資、貸出、貸付、資金提供、債権購入など、シーンに応じて様々な表現を用いる場合がある。
お金を借りる:サービス提供システムによって提供されるサービスによって上記の資金の供給を受けることを示す。
貸し手ユーザn:お金を貸したいユーザの集合、あるいは、既にお金を貸し付けたユーザの集合のことである。単に「貸し手ユーザ」と表記する場合には、単数の貸し手ユーザの場合もあれば、複数の貸し手ユーザの場合もある。
借り手ユーザm:お金を借りたいユーザの集合、あるいは、既にお金の貸付を受けたユーザの集合のことである。単に「借り手ユーザ」と表記する場合には、単数の借り手ユーザの場合もあれば、複数の借り手ユーザの場合もある。
<<目次>>
以下、本明細書の目次を記載する。
<1.システム構成>
<2.PFMシステム/会計システムから得られる情報>
<2-1.貸し手に関する情報>
<2-2.借り手に関する情報>
<2-3.貸し手または借り手に関する推測情報>
<3.レンディング>
<3-1.借り手のセグメント化>
<3-1-1.マイクロファイナンス>
<3-1-2.マッチングの例>
<3-1-3.セグメント化の例>
<3-1-4.マッチングの処理シーケンス>
<3-1-5.マッチングのUI画面>
<3-1-6.期待収益率>
<3-2.貸し手のセグメント化>
<3-3.目的別のレンディング(貸し手側)>
<3-4.目的別のレンディング(借り手側)>
<3-5.借り手の返済状況の管理>
<3-6.条件設定(貸し手側)>
<3-7.条件設定(借り手側)>
<3-8.マッチング>
<3-9.借り手(単数、複数) 対 貸し手(単数、複数)>
<3-10.公開制度>
<3-11.AIへの適用>
<4.ロボ・アドバイザー>
<4-1.余剰資産の選別>
<4-2.AIへの適用>
<4-3.金利情報に連動した助言>
<4-4.表示機能>
上記の目次に従って、以下の実施形態を記載する。ここで、PFMシステムを用いた構成を説明するが、PFMシステムの代わりに会計システムを用いたシステムも同様に構成することができる。会計システムでは、請求書・見積書作成、売掛・買掛管理、消込処理、会計分析レポート出力、会計帳簿等の機能を有する。
<1.システム構成>
図1は、本実施形態に係るサービス提供システム100を含む全体のシステム構成の一例を示す図である。このシステムは、サービス提供システム100と、PFMシステム150と、ユーザ端末160と、金融機関サーバ180とを有する。
サービス提供システム100は、各種の通信ネットワークを介してPFMシステム150およびユーザ端末160と接続される。図示していないがサービス提供システム100は、金融機関サーバ180と通信ネットワークを介して接続されてもよい。サービス提供システム100の構成については後述する。
PFMシステム150は、PFMサービスを提供するシステムであり、PFMに関する各種のデータベースやサーバなどを総称したものである。PFMシステム150は、銀行、クレジット会社、証券会社などの各種の金融機関のサーバである金融機関サーバ180と通信ネットワークを介して接続されている。PFMシステム150は、ユーザからの依頼により、ユーザに成り代わって金融機関サーバ180のそれぞれからユーザの入出金情報や金融資産情報を取得する。PFMシステム150は、取得した各種の入出金情報や金融資産情報を統合する。そして、統合した情報(PF情報)をユーザ端末160からの要求に応じてユーザ端末160に送信する。また、本実施形態においては、PFMシステム150は、ユーザ端末160からの指示により、あるいは、サービス提供システム100からの指示に応じて、PF情報をサービス提供システム100に送信する。
ユーザ端末160は、貸し手のユーザおよび借り手のユーザが使用する端末の総称である。なお、貸し手のユーザが、ある場面のおいては借り手のユーザにある場合もあれば、借り手のユーザが、ある場面においては貸し手のユーザとなる場合もある。複数のユーザが一台のユーザ端末160を共用する場合もあれば、一人のユーザが複数のユーザ端末160を用いることもあり得る。ユーザ端末160は、パーソナルコンピュータ、タブレット、モバイル端末など任意の種類の端末であってよい。サービス提供システム100およびPFMシステム150は、ユーザをログイン管理しており、ログインしたユーザに固有のサービスを提供する。
金融機関サーバ180は、前述のように、各種の金融機関のサーバである。金融機関サーバ180は、多種多様の金融機関のサーバを総称したものである。
本実施形態におけるサービス提供システム100、PFMシステム150、金融機関サーバ180は、情報処理装置として実現することができる。情報処理装置は、CPU、メモリ、HDD、及びネットワークインタフェースを有してよい。各システム(およびサーバ、以下同様)で行われる各種の処理は、例えば各システムのHDDに格納されたプログラムが一時的にメモリに読み出され、CPUがメモリに読み出されたプログラムを実行することで実現されることができる。
次に、サービス提供システム100の構成を説明する。サービス提供システム100は、制御部101、PF情報取得部102、資産特定部103、判定部104、マッチング部105、分類部106、管理部107、指示送信部108、指示受信部109、情報提供部111、契約処理部112、モデル構築部113、学習モデル114、および資産運用サポート処理部115を有する。
図1に示すサービス提供システム100の各部は、上述したように、サービス提供システム100の図示しないHDDに格納されたプログラムが一時的にメモリに読み出され、制御部101を構成するCPUが制御部101を構成するメモリに読み出されたプログラムを実行することで、CPUが図1に示す各部として機能してよい。また、図1に示す各部のうちの少なくとも一部が、各種のネットワークを介して相互に接続された複数の情報処理装置によって実現されてよい。また、図1に示す各部のうちの少なくとも一部は、複数の情報処理装置による分散処理によって実現されてよい。また、情報処理装置は、図示しないクラウドサーバなどからダウンロードしたプログラムに従って処理を実行してもよい。図1は構成の一例を示したものに過ぎず、他の構成を含んでもよい。また、図1に記載された構成の全てが必須の要件であるとは限らない。
制御部101は、サービス提供システム100の各種の制御を行う。制御部は、サービス提供システム100の各部に情報やデータを伝達したり、サービス提供システム100の全体的な処理の制御を行ったりするなどの処理を行う。
PF情報取得部102は、PFMシステム150からPF情報を取得する。PFMシステム150からは、ユーザ端末160からの指示に応じて各ユーザのPF情報が送られてよい。あるいは、ユーザ端末160からサービス提供システム100にユーザがログイン処理を行い、そのユーザの権限をサービス提供システム100に移譲させ、PF情報取得部102が、そのユーザに成り代わってPFMシステム150にアクセスして、そのユーザのPF情報を取得してもよい。取得されるPF情報は、貸し手ユーザのPF情報である場合もあれば、借り手ユーザのPF情報である場合もある。
資産特定部103は、PF情報取得部102で取得されるPF情報に基づいて資産を特定する。資産特定部103は、PF情報から直接的に得られる情報に基づいて資産を特定してもよいし、PF情報から間接的に得られる情報(例えば推測される情報)に基づいて資産を特定してもよい。
判定部104は、各種の判定処理を行う。
マッチング部105は、借り手ユーザと貸し手ユーザとを結びつける処理を行う。マッチング部105は、各種の条件に従って、借り手ユーザと貸し手ユーザとを結びつけることができる。詳細は後述する。
分類部106は、各種の分類(セグメント化ともいう)を行う。例えば、借り手ユーザをセグメント化したり、貸し手ユーザをセグメント化したりすることができる。あるいは、分類部106は、ユーザの資産を分類してもよい。
管理部107は、各種の管理を行う。例えば、管理部107は、各ユーザの管理を行う。また、管理部107は、レンディングで結びつけた貸し手と借り手との間の契約を管理する。また、管理部107は、レンディングに用いられる各種の資金を管理する。このように、管理部107は、各種のデータや情報の管理を行う。
指示送信部108は、PFMシステム150、ユーザ端末160、および金融機関サーバ180などに対する指示を送信する。
指示受信部109は、PFMシステム150、ユーザ端末160、および金融機関サーバ180などからの指示を受信する。
情報提供部111は、貸し手ユーザおよび借り手ユーザのユーザ端末160に各種の情報を提供する。貸し手ユーザおよび借り手ユーザのユーザ端末160からの要求に応じて情報を送信してもよい。また、情報提供部111は、各種の通知をユーザ端末160に通知してもよい。
契約処理部112は、契約を締結したり、変更したりした場合の各種の処理を行う。
モデル構築部113は、各種のデータに基づいて学習モデル114を構築する。
学習モデル114は、モデル構築部113によって構築される。構築された学習モデル114に各種のデータを入力すると、入力されたデータに対応するデータが出力される。
資産運用サポート処理部115は、資産運用をサポートする処理を行う。例えば、ロボ・アドバイザーのサービスを実行する。
なお、以降では、ユーザが、ユーザ端末160を用いてサービス提供システム100に各種の指示を送ったり、ユーザが、ユーザ端末160を通じてサービス提供システム100から各種の情報やデータの提供を受けたりする形態を前提に説明する。以降では、内容の説明に重点を置き、記載を簡略化して説明する場合がある。したがって、例えば「ユーザが、サービス提供システム100に指示をする」「ユーザが、サービス提供システム100に指示を送る」といった表現は、「ユーザがユーザ端末160に指示を入力し、指示を入力されたユーザ端末160が、その指示をサービス提供システム100に送信する」という意味を含むものとする。また、「ユーザが、サービス提供システム100(または、サービス提供システムに含まれる各部)から情報やデータの提供を受ける」といった表現は、「ユーザが使用するユーザ端末160に対してサービス提供システム100から情報が送られ、ユーザ端末160の表示画面に表示された情報やデータをユーザが確認する」という意味を含むものとする。同様に、「ユーザが、資金を提供する」という表現も、「ユーザが、ユーザ端末160に資金を提供する指示を入力し、ユーザ端末160がその指示をサービス提供システム100に送信し、サービス提供システム100が指示に応じて資金を提供する処理を行う」という意味を含むものである。その他、「ユーザが、債権を譲渡する」などの処理も同様である。
<2.PFMシステムから得られる情報>
次にPFMシステム150から得られる情報について説明する。すなわち、PF情報取得部102が取得するPF情報について説明する。
<2-1.貸し手に関する情報>
PF情報取得部102は、ユーザ端末160のユーザに関するPF情報を取得する。例えば、ユーザAは、ユーザ端末160を通じてPFMシステム150に対して、サービス提供システム100にユーザAのPF情報を送信するように指示する。PFMシステム150は、この指示に応じてユーザAのPF情報をサービス提供システム100に送信する。PF情報取得部102は、このようにして送信されたPF情報を取得することができる。あるいは、ユーザAは、ユーザAのPFMシステム150に対する権限をサービス提供システム100に移譲し、PF情報取得部102が、ユーザAに成り代わってユーザAのPF情報の送信要求をPFMシステム150に送信してもよい。
PF情報取得部102は、ユーザのPF情報が取得できればよく、詳細な情報を取得しなくてよい。例えば、銀行名、口座番号、クレジットカード番号、電話番号、生年月日、住所など、個人が特定できるような情報は、PFMシステム150から取得しなくてよい。PFMシステム150から得られる情報に、これらの情報が含まれている場合には、PF情報取得部102は、適宜マスク処理を施すなどした上で、これらの情報を取得してもよい。また、PF情報の中の入出金情報では、例えばAAA店などのように、店舗名が含まれる場合がある。このような情報からも、個人が特定される場合がある。そこで、PF情報取得部102は、カテゴリ名(例えばレストラン)に置き換えた情報を取得してもよい。このような情報の書き換えは、PFMシステム150で行われてもよいし、サービス提供システム100側(例えばPF情報取得部102)で行われてもよい。
図2は、ユーザAが、ユーザ端末160を用いてサービス提供システム100にログインした際に表示される画面200の例を示している。例えば、ユーザAのログイン要求指示が、ユーザ端末160からサービス提供システム100に送られる。指示受信部109は、このログイン要求指示を受信する。制御部101は、管理部107に管理されているユーザであると特定できた場合、図2に示すような画面を、情報提供部111を通じてユーザ端末160に送信する。ユーザAは、ユーザ端末160に表示される各操作ボタンをクリックないしタップする(以下、総称して押下すると呼ぶ)などによって選択することで、操作ボタンに対応する指示が、ユーザ端末160からサービス提供システム100に送信されることになる。そして、その指示に応じた画面が、情報提供部111からユーザ端末160に送信され表示されることになる。画面200においてボタン210がユーザによって選択された場合、余剰資産の確認処理がサービス提供システム100において実行される。
余剰資産の確認指示が指示受信部109で受信されると、制御部101は、資産特定部103に資産を特定する処理を行わせる。資産特定部103は、ログインしているユーザAのPF情報をPF情報取得部102から取得する。そして、取得したPF情報に基づいてユーザAの余剰資産を特定する。
図3は、PF情報の一例を示す図である。図3に示すように、PF情報には、日常的な入出金の履歴(PF情報I1)が含まれる。PF情報1の中には、詳細な明細(例えば、購入店舗名など)が含まれている場合もある。また、PF情報には、入出金の履歴だけではなく、貯金、株式、投資信託などのユーザAが保有する各種の金融資産の情報(PF情報I2)が含まれる。資産特定部103は、このようなPF情報を用いて余剰資産を特定することができる。PF情報によれば、ユーザの資産のほか、日常的な収支を特定することができるので、ユーザ毎の余剰資産を正確に特定することができる。情報提供部111は、資産特定部103によって特定された資産を示す情報を、ユーザAのユーザ端末160に送信することができる。
図4は、ユーザ端末160で表示される画面の一例を示す図である。例えば、情報提供部111は、図4に示すように、月々の余剰資産を特定してユーザに通知したり、他の月に比べて特別な臨時収入があった月であるので、今月の余剰資産は増えていることをユーザに通知したりすることができる。これにより、ユーザAは、自身の余剰資産を客観的に把握することができる。
<2-2.借り手に関する情報>
PF情報は、前述のとおり、借り手ユーザについても貸し手ユーザについても得られる情報である。借り手ユーザに対する観点から見ると、借り手ユーザは、借りたお金を返済する立場であるので、その返済を考慮した出費が行われていることが好ましい。PF情報を用いることで、借り手ユーザの返済が適切に行われているか、あるいは行うことができそうか、といったことを判定することができる。すなわち、判定部104は、PF情報取得部102で取得したPF情報を、必要に応じて参照して、好ましくない状態が発生しているかを判定することができる。例えば、借金の返済のために借り手ユーザになるということは好ましくない。したがって、判定部104は、PF情報を参照して、借金の返済が多数あるようなユーザに対しては、借り手ユーザとは認められないと判定することができる。
<2-3.貸し手または借り手に関する推測情報>
資産特定部103は、PF情報を参照して、PF情報に含まれていない資産を特定することもできる。例えば、不動産や自動車などといった資産を特定することができる。PF情報は、入出金の明細が含まれている。この明細を参照して例えば、ユーザAが固定資産税を支払っているような場合には、資産特定部103は、ユーザAが不動産を保有していると推定できる。また、ユーザAが自動車税を支払っているような場合には、資産特定部103は、ユーザAが自動車を保有していると推定できる。また、その支払い額によって、大まかな資産も推測できる。このように、資産特定部103はPF情報に含まれている各種の情報を用いることで、ユーザAの余剰資産を特定することができる。
この余剰資産は、例えばユーザAが貸し手となる場合に、無理なく出資(投資、貸金)できる金額である。また、例えばユーザAが借り手となる場合に、不可なく返済することができる金額でもある。ここでは、画一的に余剰資産として表示する例を示しているが、ユーザAが借り手となるのか貸し手となるかに応じて、異なる額の余剰資産を表示してもよい。
このように、PF情報に基づいて余剰資産が特定されるので、ユーザは、どの程度の額を貸したり、あるいは借りたりすることができるのかを容易に確認することができる。特に、PF情報を用いることで日々の生活の収支が正確に把握できるので、適切な余剰資金を特定することができる。例えば、ある収入が定期的な収入であるのか臨時収入であるか、などは、PF情報から特定することができる。
<3.レンディング>
上記で説明したように、PF情報を用いることでユーザの収支を、ユーザ自身及びサービス提供システム100のいずれにおいても正確に把握することができる。この結果、新たなサービスの提供が可能となる。例えば、今まで投資などに興味を有していない潜在的なユーザを呼び込むことができる。また、PF情報を用いることで、余裕を持って投資などを行うことができる金額(余剰資金)を、ユーザ毎に提示することができる。このような余剰資金は、その性質上、既存の金融サービスに提供される資金とは異なる性質を有する。具体的には、余剰資金は、極端な例においては、ユーザが無くなってしまってもよいと考える性質の資金である。このような余剰資金を用いることで、様々なサービスを提供することが可能となる。
以下では、サービス提供システム100が、お金を貸したい人および企業等と、お金を借りたい人および企業等とを結びつけるレンディングサービスを行う形態について説明する。お金を貸したいユーザは、図2のボタン220を押下することで、以降で貸し手ユーザとして説明する各種の処理の主体となる。お金を借りたい借り手ユーザは、図2のボタン230を押下することで、以降で借り手ユーザとして説明する各種の処理の主体となる。なお、図2の画面は一例に過ぎず、これに限られるものではない。
<3-1.借り手のセグメント化>
まず、借り手ユーザのセグメント化について説明する。セグメント化とは、ある種の単位に分類することである。本実施形態において分類部106は、PF情報を用いて、管理部107で管理されているユーザを分類(セグメント化)する。PF情報を用いることで、例えば堅実な生活支出をしているユーザであるか否かといったタイプや、不動産を保有しているか否かといったタイプなど、様々なタイプにユーザを分類することができる。堅実な生活支出をしているユーザや、不動産を保有しているユーザは、借り手になった場合に返済する可能性が高い。すなわち、借金を返済せずに踏み倒してしまう可能性が低い。このように、返済する可能性に応じて借り手をセグメント化し、そのセグメントに応じて利息を設定することができる。
貸し手ユーザは、お金を貸し出す際に、任意のセグメントを指定して、そのセグメントに属する借り手に貸すことを決めてもよい。貸し手がセグメントを指定した場合、マッチング部105がマッチング処理を行い、そのセグメントに属する借り手(お金を借りたいと希望しているユーザ)とのマッチングを行う。マッチングが成立した場合、マッチング部105は、貸し手と借り手とを結びつける。すなわち、マッチング部105は、契約処理部112にマッチングが成立した貸し手と借り手の情報を送る。契約処理部112は、マッチングが成立し貸し手ユーザAと借り手ユーザBとの間での金銭の貸借を仲介する。
なお、金銭の貸借は、様々な手法で実現することができる。例えば、サービス提供システム100が、貸し手ユーザAに成り代わって、貸し手ユーザAの口座が存在する金融機関サーバ180から、借り手ユーザBの口座が存在する金融機関サーバ180に送金処理を行ってもよい。あるいは、サービス提供システム100が、貸し手ユーザAの金融機関サーバ180から貸金を受け取ってもよい。つまり、一旦、サービス提供システム100に資金を移動させてもよい。そして、サービス提供システム100から、借り手ユーザBの金融機関サーバ180に送金処理を行ってもよい。あるいは、サービス提供システム100は、PFMシステム150を通じて上述した送金処理を行わせてもよい。本実施形態においては、任意の形態で金銭の貸借が行われよい。
<3-1-1.マイクロファイナンス>
次に、セグメント化の詳細例について説明する。先に説明したように、PF情報を用いることで、既存の投資ユーザのみならず、今まで投資を考えたことがないようなユーザであっても投資の意欲が出てくることが想定される。つまり、投資を行うユーザの裾野が広がる。なぜならば、日常の収支から、いわば無くなっても影響が大きくない程度の額を、各ユーザが把握できるからである。これまでは、比較的資産を有しているユーザが投資などを行う場合が多かったが、自身の資産を適切に把握できれば、比較的資産を有していないユーザであっても、少額投資を行う額を把握できる。
ここで、サービス提供システム100のマッチング部105による処理に従えば、様々な条件でのマッチングが可能になる。例えば、少額の資金を大口で集めることも可能である。いわゆるマイクロファイナンス(小規模金融)を行うことが可能である。マイクロファイナンスは、貧困層に対する融資という意味合いで用いられることもあるが、本実施形態においては、単純に、少額の資金を用いた金融という意味で用いる。例えば、これまで百万円の出資を行うことができるユーザは限られた存在であったが、マイクロファイナンスを用いると、例えば千円の出資をするユーザが千人集まれば、同様の金額の出資を行うことが可能となる。しかも、このような少額の資金を用いる出資というものは、一人のユーザが出資をする場合に比べて様々なメリットがあることになる。以下、詳細に説明する。
図5は、マイクロファイナンスのコンセプトの例を示す図である。図5(a)は、横軸が投資額であり、縦軸が許容できるデフォルトリスク(債務不履行リスク)を示している。図5(b)は、横軸が投資額であり、縦軸が、貸し手ユーザが出資したくなるリスクプレミアムを示している。リスクプレミアムとは、リスクを含む投資に対してそのリスク分に対して求める超過収益(上乗せ収益)のことである。
図5(a)は、投資額が大きくなるほど、許容できるデフォルトリスクは低くなることを示している。すなわち、貸し手ユーザは、大金を投資する以上、返済されない可能性が低い案件に投資する心理が働くことを示している。つまり、端的に言えば、大金を投資するのであれば、返済される蓋然性が高い案件に投資したいという心理が働くことになる。これに対して、少額を投資するような場合には、貸し手ユーザは、返済されない可能性が高い案件に投資しても構わないという心理が働く。例えば、百円や千円といった少額であれば、極端な例では、そのまま返済されなくてもよいという心理が働くことになる。
図5(b)は、投資額が高いほど、出資したくなるリスクプレミアムが高くなることを示している。つまり、大金を出資する以上、出資した金額に対する上積みが高くなることを期待する貸し手ユーザの心理を示している。一方、投資額が少ない少額投資をする場合、出資した金額に対する上積みがそれ程大きくなくても構わないという貸し手ユーザの心理を示している。例えば、百円や千円といった少額を出資した場合、その出資金額に対するリスクプレミアムが3%であっても5%であっても10%であっても、貸し手ユーザは気にしない。一方で、百万円や一千万円といった大金を出資した場合、その貸し手ユーザにとってリスクプレミアムは投資に対する重要なファクターとなる。このように、仮に、同一人であっても許容できるデフォルトリスクおよび出資したくなるリスクプレミアムというものは、投資額によって異なることになる。
典型的な例として、単独のユーザが1千万円を投資する場合と、マイクロファイナンスで多数(例えば千人)から集めた1千万円を投資する場合とを考える。マイクロファイナンスで多数から集めた資金は、その出資者にとってもいわば無くなってもよいと考えた少額資金の総計額である。無くなってもよいような額であるので、マイクロファイナンスで集めた資金に対するリスクプレミアムは低く設定することができる。一方、単独のユーザにとって大型投資となるので、図5(b)に示すようにリスクプレミアムを高く設定しないと、つまり、上積み収益を高く設定しないと出資する意味(すなわち、利息分などによる利益)が出てこなくなる。
以上を整理すると、マイクロファイナンスで集めた少額資金は、無くなっても構わない資金となる。このような無くなっても構わない少額資金であっても、多数から集めることで大型投資を行うことが可能となる。無くなっても構わない大型投資であれば、リスクプレミアムを既存の金融機関等よりも低く設定しても問題がない。つまり、借り手ユーザに資金を貸し出す場合、マイクロファイナンスで集められた資金の金利などを、既存の金融機関が設定する金利などよりも低く設定することができる。借り手ユーザからすれば、マイクロファイナンスで集められた資金を借りる方が、既存の金融機関から資金を借りるよりも低い金利などで借りることが可能である。このように、マイクロファイナンスを用いることで、新しい金融サービスの提供が可能となる。
<3-1-2.マッチングの例>
図6を用いて、貸し手ユーザnと受け手ユーザmとをマッチングさせる例を説明する。なお、貸し手ユーザnは、先に説明したように、マイクロファイナンスで集めた資金を貸すユーザの集合である。例えば貸し手ユーザA1、A2・・・Anという具合に、n人で一つの集団を構成することができる。なお、ここでは説明の便宜上、集団を構成すると説明しているが、貸し手の個々のユーザA1、A2・・・Anは、他の貸し手ユーザの情報を知る必要はない。ユーザの管理やマッチングは、サービス提供システム100の管理部107やマッチング部105が行う。
図6に示すように、本項の借り手ユーザは、各種の資金を取り扱う会社、団体などとすることができる。つまり、借り手ユーザのユーザ端末160は、これらの各種の資金を取り扱う会社、団体などのサーバであってよい。
図6を用いて、借り手ユーザとなり得る例を説明する。もちろん、図6に示す例に限定されるものではない。借り手ユーザは、特定の種類の債権などを引き渡し、代わりに資金を得る企業、機関、団体などが考えられる。サービス提供システム100の分類部106は、これらの特定の種類ごとに借り手を分類(セグメント化)することができる。なお、後述する図7で説明するセグメント化と区別して、特定の種類毎に借り手を分類することを第一のセグメント化と呼ぶ。以降で詳細を説明するように、貸し手ユーザnは、既存の金融機関などよりも有利な条件で(例えば安い金利で)債権を受け取り、資金を提供することができる。したがって、新しい金融サービス、あるいは既存の金融機関などから置き換わるような金融サービスを、サービス提供システム100が提供することが可能となる。
借り手ユーザの一例として、例えば電子債権の保有者を例に挙げる。電子債権は、でんさいネット上などで流通するもので、手形の一種である。手形は、期限が到来したら現金に換金することができる。その一方で、手形の振出元が、例えば倒産するなどして債務不履行になった場合、その手形を換金することができない。つまり、手形には、このようなデフォルトリスクが存在する。既存の金融機関(例えば銀行)では、このようなリスクを考慮した手形の割引率(手形の現在価値)を設定したうえで、その手形を支払期日前に買い取ることが行われている。これに対して、マイクロファイナンスの貸し手ユーザnは、先に説明したように、リスクプレミアムを低く設定することができるので、既存の金融機関が設定する割引率よりも低く割引率を設定することができる。この理由は、<3-1-1.マイクロファイナンス>で説明したように、いわばマイクロファイナンスの貸し手ユーザnは、無くなっても構わない少額投資のユーザの集合体であるので、同一金額に対して金融機関などが設定するリスクプレミアムよりも低いリスクプレミアムであっても出資意欲があるからである。
例えば、ある電子債権に対して、支払期日前に既存の銀行が額面の90パーセントの金額で債権を買い取るような場合に、マイクロファイナンスの貸し手ユーザnであれば、例えば額面の95パーセントの金額でその債権を買い取ることができる。つまり、借り手(電子債権の債権者)にすれば、マイクロファイナンスの貸し手ユーザnの方が、より高い金額で電子債権を引き取ってもらえることになる。
なお、債権を引き取った場合、名義の書き換えが行われる。本実施形態では、例えばサービス提供システム100の管理部107が仮想口座や仮想名義などを管理しているものとする。そして引き取った債権の名義を、このサービス提供システム100の仮想名義に書き換えることができる。この仮想名義には、その債権の引き取りに際して出資したユーザ、つまり、貸し手ユーザnのそれぞれが対応付けられる。このように、実際に資金を提供した貸し手ユーザnの名義ではなく、サービス提供システム100に関連する名義に変更することで、後述するように貸し手ユーザnの一部のユーザに変更が生じるような場合などにおいて、さらなる名義変更を行わずに済む。しかしながらこの例に限られるものではない。引き取った債権を、貸し手ユーザnのそれぞれの共同名義に書き換える形態でもよい。
次に、借り手ユーザが、金融機関や奨学金などのローンを借りようとしている形態を説明する。先に説明したように、本実施形態のマイクロファイナンスの貸し手ユーザnは、通常の金融機関などよりもリスクプレミアムが低くても投資したいという心理を有する。したがって、金銭消費貸借契約を結んでお金を借りたいという借り手ユーザは、既存の金融機関などよりも低い金利が設定されている、本実施形態のマイクロファイナンスの貸し手ユーザnから資金を借りることができる。
次に、クレジットカードの利用形態を説明する。クレジットカードのカード利用者は、店舗等においてカードで商品等の支払を行う。この場合、店舗等は、クレジットカード会社に対する債権を有することになる。そして、店舗等は、一定の期日後に、カード会社から金銭の支払いを受ける。このとき、一般に店舗等はカード会社に手数料を支払う。本実施形態においては、このカードの債権を、マイクロファイナンスの貸し手ユーザnが引き受ける形態を採用することができる。先に説明したように、本実施形態のマイクロファイナンスの貸し手ユーザnは、通常の金融機関などよりもリスクプレミアムが低くても投資したいという心理を有する。したがって、既存のクレジットカード会社よりも安い利用料を設定することが可能であるので、クレジットカードの加盟店舗は、本実施形態のマイクロファイナンスの貸し手ユーザnに債権を譲渡することも考えられる。つまり、いわばマイクロファイナンスの貸し手ユーザnが、カード会社の役割を引き受けることも可能である。
次に、社債の利用形態を説明する。例えば、社債を発行して資金を調達しようと考えている会社がある。本実施形態のマイクロファイナンスの貸し手ユーザnであれば、一般的な市場で要求される利回りよりも低い利回りで、その社債を引き受けることができる。したがって、引き受け手が見つからないような場合であっても、本実施形態のマイクロファイナンスの貸し手ユーザnであれば、そのような引き受け手となることができる。
次に、投資信託の利用形態を説明する。本実施形態のマイクロファイナンスの貸し手ユーザnは、先に説明したように、少額資金を用いることになる。したがって、例えば従来であれば1口1万円で運用しているような状態であるところを、1口100円で運用することができる。一般に、リスクとリターンとは、比例関係がある。つまり、リスクが高ければ上がればリターンが増える。リスクが下がればリターンも減る。本実施形態のマイクロファイナンスの貸し手ユーザnは、少額資金を用いた運用をすることができるので、高いリスクを採ることができる。つまり、無くなっても構わない金額なので、リスクが高くても気にしない傾向がある。したがって、少額資金を多数で集めて、期待利回りが高い投資信託を行うことができる。
以上説明したように図6で示す電子債権、ローン、クレジットカード、社債、投資信託などのように、借り手の種類をセグメント化することができる(第一のセグメント化)。また、図6に示す例に限られることはなく、任意のセグメントを設けることができる。
<3-1-3.セグメント化の例>
図6では、借り手ユーザの種類を説明した。貸し手は、貸し出し先の特定の種類の借り手ユーザを決定して、その特定の種類の借り手ユーザに出資をしてもよい。つまり、借り手ユーザの種類(例えば電子債権)を指定して出資をしてもよい。しかしながら、ある特定の種類に貸し手が出資すると、出資するタイミングによって不公平が生じる可能性がある。例えば、マッチング部105が、申込みが行われた順番で個別にマッチングをすると、当たり外れが出てしまうことがある。つまり、貸し手ユーザA1はきっちり返済される債権に当たったが、貸し手ユーザA2は不良債権に当たってしまうこともある。これを解消するために、テーマ毎にカテゴリを作ることができる。テーマ毎にカテゴリを作ることを第二のセグメント化と呼ぶ。
なお、セグメント化とは、ある分類毎に分かれていればよいので、先に説明したように、借り手ユーザの種類毎に分かれていてもよいし、これから説明するように特定のカテゴリ別に分かれていてもよい。つまり、セグメント化には、第一のセグメント化および第二のセグメント化が含まれる。
図7は、セグメント化(第二のセグメント化)の一例を示す図である。この例では、カテゴリとして「地域振興(日本)」、「進学・留学」、および「スポーツ」の3つのカテゴリを設定している例を示している。「地域振興(日本)」のカテゴリの中には、ある地域R1の会社の社債であったり、その地域R1の電子債権であったり、その地域R1のクレジットカードの加盟店などの債権が含まれている。「進学・留学」のカテゴリの中には、あるユーザのローン債権などが含まれている。「スポーツ」のカテゴリの中には、あるスポーツS1に関する用具代の債権や、そのスポーツS1に関するスポーツ留学を目的とするローン債権や、そのスポーツS1のプロスポーツチームの運営費などが含まれている。なお、図7で示すようなカテゴリは、例えば予め分類部106によって作成されている。あるいは、借り手ユーザまたは貸し手ユーザがサービス提供システム100にアクセスして、任意のカテゴリを作成してもよい。
図7の例においては、「地域振興(日本)」のカテゴリに対して複数のユーザから成る貸し手ユーザnが出資をしている例を示している。図7では簡略的に2人を例に示しているが、例えば200人や2000人といったように、多数のユーザから成る貸し手ユーザnによる出資が行われてもよい。
本実施形態においては、この「地域振興(日本)」のように、あるカテゴリに含まれる各債権を集合債権として扱う。そして、貸し手ユーザnを構成するそれぞれのユーザは、不可分債権を有することになる。それぞれのユーザが分割債権を有することとしても良い。貸し手ユーザnは、「地域振興(日本)」のカテゴリに対して出資を行う。つまり、貸し手ユーザnは、「地域振興(日本)」に含まれる個々の債権を具体的に指定して出資を行うわけではない。このようにセグメント化をすることで、ある種の曖昧さが醸成されることになる。このため、例えば「地域振興(日本)」に含まれる個々の債権のうち、返済がなされるものものあれば、返済がなされないものもあり得るが、貸し手ユーザnを構成するそれぞれのユーザが不公平感を感じることを低減できる。
図8は、図7で示すカテゴリに対して出資が行われる場合のマッチング部105によるマッチング処理の一例を示すフローチャートである。
ステップS810において、マッチング部105は、所定のカテゴリkについての債権Y(j)円を仮取得する。具体的には、カテゴリkは、図7の「地域振興(日本)」の例であるものとして説明をする。図7の「地域振興(日本)」では、3つの債権が含まれているので、j=1,2,3となる。つまり、ステップS810では、所定のカテゴリkに属するそれぞれの債権を仮取得する。
ステップS820において、マッチング部105は、所定のカテゴリkについて、貸し手ユーザiから出資X(i)を受け付ける。ここでは一口100円であるものとする。
ステップS830において、マッチング部105は、ステップS820で受け付けた出資総額が、ステップS810で仮取得した債権の債権額に達した場合、契約処理部112に通知する。ここで、出資総額は、100(円/口)*sum X(i)(i=1~n)(口)である。また、仮取得した債権の債権額Y(j)+α円に達した場合、契約処理部112に通知してもよい。ここで、α円は、解約率r(%)を想定したもので、(Y(j)+α)*(100-r)/100=Y(j)である。
契約処理部112は、この通知を受けて、その債権を本取得する。すなわち、でんさいネット上などで、その債権の名義書換を実行する。なお、先に説明したように、名義の書き換えは、管理部107で管理する仮想口座、仮想名義(仮の名義)に変更する形態でもよいし、貸し手ユーザの共同名義に書き換える形態でもよい。仮想名義に変更しておくと、それぞれのユーザが分割債権を有し、出資途中で貸し手ユーザが変更になった場合においても、でんさいネット上で、都度債権者の変更処理をせずに済む。契約処理部112は、契約の変更を実行する処理を行う。例えば、金融機関サーバなどに所定の通知を送ってもよい。このステップS830は、例えば1日単位で繰り返し行われてもよい。つまり、1日単位で出資額を受け付け、本取得できない場合には、契約が不成立となり、翌日に再度、ステップS810において債権を仮取得する処理を行ってもよい。
ステップS840において、契約処理部112は、ステップS830で本取得した債権に集合債権を設定する。この債権額S(k)は、[sum Y(j)(J=1~m)]円となる。すなわち、図7の「地域振興(日本)」の場合であれば、m=3で、3つの債権の総額が集合債権となる。例えば、債権e1aが1万円、債権e1bが10万円、債権e1cが3千円とする。すると、これらの合計の11万3千円が集合債権となる。
ステップS850は、その後の返済を含む、収益が得られた場合の処理である。ステップS850において管理部107は、得られた収益を持分に応じてそれぞれのユーザに分配する。例えば、ステップS840で設定した債権額S(k)をそれぞれのユーザが出資した債権の口数で割る。すなわち、ステップS840においては、それぞれのユーザ自身が出資した金額の比率に応じて分配がされる。例えば、債権e1bが返済不能となった場合、債権e1bは回収不能金になる。債権e1aが満期になっており、債権e1bは割引率に応じたプレミアム(利息)が加算されて回収される。債権e1cは期限が未到来であるので、債権e1cは回収されない。このような場合、債権e1aに関する分配が、そのカテゴリkに出資したユーザに対してなされることになる。
マッチング部105は、このような処理を、カテゴリごとに対して行う。
以上のように、複数のカテゴリにセグメント化を行い、そのカテゴリに対して出資する形態を採用することにより、貸し手ユーザの不公平感を緩和することができる。カテゴリとして、特定の目的や特定の種類に特化したカテゴリを設けることで、貸し手ユーザnは、自分の希望するカテゴリに積極的に出資することができる。例えば、スポーツが好きな貸し手ユーザは、半ば寄付のような気持ちで「スポーツ」のカテゴリに出資することもできる。
図9は、貸し手のユーザ端末160で表示される画面900の一例を示す図である。図9では、各カテゴリ別に、出資額と回収額とをグラフ表示するとともに、その額を数字で表示している。また、各フラグは、凡例910に示すように、「回収期限未到来」のものと「回収不能」のものと「回収済」のものとが分かるように、色、濃度、パターンなどが変更して表示される。また、トータルの額を示す領域が表示されている。図9に示すような画面を用いることで、貸し手は、自身の出資している額と回収した額とを、カテゴリ別に確認することができる。また、複数のカテゴリに出資している場合には、そのトータルの出資額と回収額とを確認することができる。貸し手は、「追加出資」ボタン920を押下することで、所望のカテゴリに追加出資することができる。また、「カテゴリを追加」ボタン930を押下することで、カテゴリを追加できる。カテゴリが追加される場合、追加されるカテゴリが既存の表示されているカテゴリの上下左右のいずれかに追加されてよい。
図9の画面900に表示される画像は、出資決定機能、出資金決定機能、期待収益率表示機能、回収金表示機能、または出資カテゴリ追加機能を有する電子計算機で表示される画像である。また、図9の画像は、情報入力操作用画像、機能実行操作用画像、情報閲覧表示用画像、または複合画像である。
また、画像の各カテゴリには、期待収益率が表示されても良い。その場合、貸し手は、出資するか否かの判断基準の一つとして期待収益率を用いることができる。
<3-1-6.期待収益率>
次に、期待収益率の算出モデルの例を説明する。ここでは、期待収益率をR(k)(t)と表す。ここで、kは、先に説明したように、カテゴリである。tは、日時である。つまり、期待収益率R(k)(t)は、カテゴリごとに異なるものであり、また、日時に応じても異なるものである。期待収益率は、以下の式(1)で表すことができる。
期待収益率R(k)(t)=[1/(1-割引率r(k)(t))]*(1-デフォルト率D(k)(t))*100(%)
式(1)
ここで、割引率r(k)(t)は、以下の式(2)で求められる。
割引率r(k)(t)=無リスク金利r0(t)+リスクプレミアムp(k)(t) 式(2)
この無リスク金利r0(t)は、例えば国債の金利を用いることができる。
また、デフォルト率D(k)(t)は、以下の式(3)で求められる。
デフォルト率D(k)(t)=Average(D(k)(t)(t=1,…t-1)) 式(3)
つまり、デフォルト率は、そのカテゴリの過去の平均値を用いることができる。式(1)から式(3)に示すように、期待収益率R(k)(t)は、リスクプレミアムp(k)(t)に依存することが分かる。
ここで、リスクプレミアムp(k)(t)については、たとえば、以下の式(4)の関係が成り立つように設定することができる。
△|出資額X(k)(t)-(申込)債権額Y(k)(t)|/△リスクプレミアムp(k)(t)=0 式(4)
図10は、上記の式(4)を説明する図である。つまり、リスクプレミアムが高ければ、出資(貸す)側は貸す額が増える。その一方、借りる側が借りる額は減る。逆に、リスクプレミアムが低ければ、出資(貸す)側は貸す額が減る。その一方、借りる側が借りる額は増える。このように、リスクプレミアムは、貸す側と借りる側との間ではトレードオフの関係になっている。そして、貸す側と借りる側との間で釣り合う部分が、設定すべき好適なリスクプレミアムであると考えることができ、上記の式(4)は、この考えにしたがっている。このような好適な値は、たとえば過去のそのカテゴリの出資金と債権額との関係から求められる。あるいは実証実験などを通じて得たデータを教師データとして、AIなどを用いて求めても良い。
割引率r(k)(t)の別の例は、以下の式(5)で求められる。
割引率r(k)(t)=Average(r(k)(t)(t=1,…t-1)) 式(5)
割引率r(k)(t)のさらに別の例は、借り手が割引率を提示して借入を申し込むことを前提に、カテゴリkに属する(申込)債権jについて提示された割引率r(k)(t)(j)の平均として、以下の式(6)で求められる。
割引率r(k)(t)=Average(r(k)(t)(j)(j∈k)) 式(6)
なお、<3-1-1.マイクロファイナンス>の項で説明したように、マイクロファイナンスの貸し手nの所望するリスクプレミアムは、既存の金融機関や市場のリスクプレミアムよりも低くなることが想定される。したがって、例えばサービス提供システムのプラットフォーム利用料を上乗せしたとしても、既存の金融機関や市場のリスクプレミアムよりも低い額で運用することが可能である。
<3-2.貸し手のセグメント化>
上記の<3-1>の項目では、借り手ユーザのセグメント化について説明してきた。本項目においては、貸し手ユーザのセグメント化を説明する。本実施形態においては、分類部106が貸し手ユーザを分類してセグメント化をする。例えば、貸し出す際の利息などの貸し出し条件や、貸し手ユーザの余剰資産の額など、様々な条件で貸し手ユーザを分類する。そして、マッチング部105は、同じ分類(セグメント)に属する貸し手ユーザn(個々の貸し手ユーザの集合)を、借り手ユーザとマッチングさせる。似たような貸し出し条件のユーザをセグメント化することができるので、貸し手ユーザnのうちの例えばユーザA3が急遽資金が必要になったので、資金を引き上げたいような場合にも、マッチング部105は、同じセグメントに属する別の貸し手ユーザAXに資金の提供の意思があるかを速やかに確認することができる。打診を受けた貸し手ユーザAXは、貸し出し条件などは、基本的に自身が希望するものと同等の内容であるので、意思決定が迅速に行われる。この貸し手ユーザAXに資金の提供の意思があれば、契約処理部112が速やかに貸主を変更することができる。
<3-3.目的別のレンディング(貸し手側)>
次に、借り手ユーザが使用目的を明示し、それに応じて貸し手ユーザがお金を貸す例を説明する。なお、<3-1>で説明したセグメント化と部分的に似た内容ではあるものの、本項では、借り手ユーザは、複数の借り手ユーザの集合である必要はない。本項では、単独の借り手ユーザの場合を例に挙げて説明する。
本項の形態では、情報提供部111が、借り手ユーザの情報を公開する。例えば、借り手は、特定の資金目的をサービス提供システム100に登録しておき、情報提供部111は、この情報を公開する。貸し手ユーザは、情報提供部111によって公開されている情報に基づいて、特定の資金目的を有する借り手ユーザを見つけ出す。
図11は、情報提供部111によって公開される情報の一例を示す図である。借り手ユーザは、自身が資金を借りたい目的を登録している。図11は、このように登録された情報がリスト化された例を示している。貸し手ユーザの中には、特定の資金目的のユーザを応援したいという気持ちを持つユーザもいる。そこで、貸し手ユーザは、このような特定の目的のユーザに資金を提供する旨の指示をサービス提供システム100に送信する。マッチング部105は、この指示に基づいてマッチングを行い、契約処理部112が契約を行う。
このような特定目的で資金を借りた場合、サービス提供システム100は、借り手ユーザのPF情報のうち、その特定目的に関連する項目の一部を抜粋して貸し手ユーザに対して、情報公開してもよい。図12は、このような情報公開の例を示す図である。この例では、借り手ユーザXXX1が気象予報士の資格の取得を目的として資金の提供を受け付けた場合の例である。このとき、情報提供部111は、その借り手ユーザXXX1のPF情報I3の中から、資格取得に関連しそうな項目のうち、個人が特定される恐れのある情報をマスクして、貸し手ユーザに公開する。図12の例では、資格講座に振り込みをしたという内容と、書籍を購入したという情報とが貸し手ユーザに公開されている。詳細な日時や購入店舗の情報は公開されない。貸し手ユーザの立場から見ると、自身が提供した資金がその目的に使用されていることがわかるので、安心感が得られる。また、このような特定目的で使用する場合には、貸し手ユーザは、借り手ユーザの後援者のような気分を味わうことができる。したがって、例えば、借り手ユーザの個人情報を知ることはないものの、その借り手ユーザの努力、成長、目標達成などを共有することができる。したがって、貸し手ユーザに対して、単にお金を貸し出すというだけではなく、借り手ユーザを応援するなどといった感情移入を喚起させることもできる。
上記の例は、借り手ユーザが個人の目的の場合を例に挙げて説明したが、会社、団体などの各種の組織、事業体などが特定の目的を有する借り手ユーザとなってもよい。
また、借り手ユーザの目的によっては、金利を変動金利にしてもよい。例えば、特定の目的が事業資金の場合には、成功報酬型にしてもよい。つまり、貸し手の元本を保証した上で、貸出期間の間、借り手ユーザである会社の営業利益×所定率を金利としてもよい。
また、特定の目的の中には、サービス提供システム100を通じて、他のユーザに資金を貸し出す目的も含まれる。つまり、借り手ユーザは、自身が貸し手ユーザとなるために資金を借りる目的であってもよい。
例えば、借り手ユーザB3は、過去に複数回、資金を借りており、常に滞りなく返済を行う、信頼性の高いユーザであると想定する。信頼性が高いユーザは、例えば後述するように、金利を安く設定することもできる。ここでは、この借り手ユーザB3が、貸し手ユーザA3から金利3%で100万円を借りたと想定する。借り手ユーザB3は、今度は自身が貸し手となり、例えば別の借り手である借り手ユーザC3に対して、金利5%で100万円を貸し出してもよい。つまり、借り手ユーザB3は、金利3%で資金を借り、自身が貸し手ユーザとなって金利5%で貸し出すといったことも可能である。なお、この場合、借り手ユーザB3は、自己資金の100万円に、貸し手ユーザA3からの100万円を加え、合計200万円を借り手ユーザD3に貸し出してもよい。
<3-4.目的別のレンディング(借り手側)>
上記の<3-3>においては、借り手ユーザが目的を公開して、その目的に賛同を示す貸し手ユーザが資金を貸し出す例を説明した。本項においては、貸し手ユーザが資金を貸し出したい目的を公開する。借り手ユーザは、その目的に応じて資金を借りることができる。
例えば、貸し手は、自分が行きたい店に行って、指定する料理を食べて写真を撮って欲しいと考えている場合、その条件を公開する。借り手は、公開されている条件を確認し、引き受ける場合には、その旨を、ユーザ端末160を通じて指示する。マッチング部105は、指示受信部109で受信した指示に基づいて、マッチングを行う。借り手ユーザは、その後、その使用目的を遂行する。ここで、借り手ユーザのPF情報は、情報提供部111によって貸し手ユーザに公開されてもよい。なお、全てのPF情報が公開されるのではなく、使用目的に関連する項目が、個人を特定しないような態様で公開されてもよい。借り手ユーザの生活収支はPF情報で正確にわかるので、借り手ユーザが実際に使用目的を遂行したか否かは、PF情報に基づいて判断できる。例えば、情報提供部111が、借り手から受け取った飲食写真の証拠画像を貸し手に送信するような場合、貸し手ユーザは、PF情報を参照することで、確かにその店で飲食した写真であることを、貸し手ユーザが判断できる。例えば、ネット上の画像を合成して嘘をついていないかなどを確認することができる。
なお、ここでは、PF情報が貸し手ユーザに公開され、貸し手ユーザが使用目的を遂行したかを判断する形態を説明したが、サービス提供システム100の判定部104が判定を行ってもよい。すなわち、契約設定された使用目的と、借り手ユーザのPF情報とに基づいて、判定部104が、使用目的が遂行されたであろう度合いを判定し、情報提供部がその情報を貸し手ユーザに公開してもよい。
なお、貸し手ユーザは、資金の目的に、希望返済率を併せて公開してもよい。つまり、貸し手ユーザが所望する目的を達成してもらえるのであれば、元本を返済されなくてもよいと考えるユーザもいる。したがって、目的の達成度に応じて返済額を変えるように構成してもよいし、その情報を公開してもよい。
<3-5.借り手の返済状況の管理>
次に、借り手ユーザの返済状況の管理について説明する。主に管理部107で行われる処理となる。管理部107は、日々、借り手ユーザとなっているユーザのPF情報を取得する。PF情報を参照することで、借り手ユーザの生活の実体を把握することができる。例えば、出費が継続的に高まっているような場合には、情報提供部111が借り手ユーザに注意、あるいは改善を促すメッセージを通知する。なお、返済のために他の金融機関から借りるのは好ましくない。したがって、PF情報に基づいて、他の金融機関とのやり取りが増えた場合には、借り手ユーザに警告を出してもよい。
なお、管理部107は、警告を出すとともに、契約処理部112に返済がされない可能性があることを知らせる。このように返済が困難になっているような状況においては、契約処理部112が契約の変更可能性を検討し、契約を変更してもよい。つまり、借り手ユーザと貸し手ユーザとの仲裁を行う。例えば、追加手数料(所定額や金利追加)を借り手ユーザが負担することで返済計画を見直すことができる(1か月保留や返済期間の延長)。このとき、仲裁が上手くいかない場合には、契約処理部112は、新規の貸し手ユーザの参加を募り、参加を表明した貸し手ユーザを当事者として参加させてよい。契約処理部112は、借り手ユーザに代わり新規の貸し手ユーザに現在の貸し手ユーザに対する全額返済を行わせる。新規の貸し手ユーザは、現在の貸し手ユーザから債権を譲渡して貰う。なお、借り手ユーザ側が新規の貸し手ユーザとのマッチングをマッチング部105に依頼する指示を送り、マッチング部105が新規の貸し手ユーザを見つけ出す処理を行ってもよい。
また、契約の中には、所定時期に全額を返済する一括返済を採る場合もあれば、毎月一定程度返済する方法も採る場合もある。毎月返済の場合には、貸し手側に金利が上乗せされた資金が振り込まれることになるが、この返済金を同一の借り手にそのまま貸し出してもよい。これにより、実質的に返済期間を猶予することになる。
<3-6.条件設定(貸し手側)>
借り手ユーザは、資金を借りる際に、各種の条件を設定することができる。例えば、返済条件、担保条件などである。これらの条件は、情報提供部111によって、個人が特定されない形態で公開される。貸し手ユーザは、公開情報を見て、所望する借り手ユーザを決定することができる。
<3-7.条件設定(借り手側)>
貸し手ユーザは、資金を貸す際に、各種の条件を設定することができる。貸し手は、貸金の対象として、過去の返済実績がある借り手や、過去の返金遅延がない借り手などの条件を設定できる。また、貸金の上限、借り手ユーザの学歴、年齢などを設定することもできる。また、例えば、貸し手ユーザは、借り手ユーザの生活状態を貸金の条件に含めてもよい。例えば、ギャンブルをしていないや、不必要な高級品を購入などである。これらの情報は、PF情報から特定することができるので、判定部104は、このような条件に合致するのか否かを判定することができる。なお、これら条件は情報提供部111によって、個人を特定しない形態で公開される。借り手は、公開情報を見て、貸し手を決めてよい。つまり、PFMシステムや会計システムからの情報を分析することで、個人特性や企業特性を把握した上で、借り手を特定又は決定することを容易に行うことができる。
<3-8.マッチング>
マッチング部105は、上記で示したようなマッチングを行うことができる。例えば貸し手ユーザの条件と借り手ユーザの条件とが一致した場合に、両者をマッチングする。そして、契約処理部112に通知する。マッチング部105は、先に説明したように、様々な情報に基づいて行うことができる。また、マッチング部105は、設定された各種の条件に基づいて、お勧めの相手ユーザや、お勧めのプランなどを各ユーザに提供してもよい。
<3-9.借り手(単数、複数) 対 貸し手(単数、複数)>
これまで説明したように、本実施形態においては、様々な形態の契約が成り立つ。例えば、以下の通りである。
(1)借り手ユーザが単数:貸し手ユーザが単数
(2)借り手ユーザが複数:貸し手ユーザが単数
(3)借り手ユーザが単数:貸し手ユーザが複数
(4)借り手ユーザが複数:貸し手ユーザが複数
このうち、貸し手ユーザが複数の場合に、市場の活性化が期待できる。つまり、先に説明したように、貸し手ユーザが複数(多数)であれば、個々のユーザが少額の出資をしたとしても、その総額は非常に大きくなる場合がある。また、このような少額を出資することは、個々のユーザの負担が小さい。これまでも特定の目的に対して寄付ないし出資をすることは行われているが、個々のユーザはどの程度の出資額であれば負荷がないのか、あるいは適切な出資額なのかが正しく把握できず、かつ、出資の敷居も高かった。しかしながら、本実施形態のサービス提供システムを用いると、個々のユーザのPF情報から適切な金額をユーザは把握することができる。また、希望する出資先を容易に探し出すことができる。したがって、これまで金融資産の活用が十分にされていない層のユーザを掘り起こすことができ、金融資産の流動性を高めることができる。
また、貸し手が複数人からなるグループを構成する場合に、複数の方法が考えられる。一の貸し手が他の貸し手を募集したり、招集したりすることができる。一の貸し手が他の貸し手を検索する場合には、これまでの実績を見て抽出することができる。例えば、過去の貸し出し実績件数が所定件数以上であり、且つ、回収率が105%を超えているなどである。実績件数、回収率、完済件数、未完済件数、完済率、未完済率を抽出条件とすることができる。このようにグループを構成して、グループで一又は複数の借り手に融資することで、全体で融資額を増額することができると共に、リスクを分散することができる。グループで借り手を特定する手法としては、グループのリーダー若しくは各メンバーが候補となる借り手を見つけ、他のメンバーに紹介することで借り手を追加する。
<3-10.公開制度>
情報提供部111は、借り手ユーザや貸し手ユーザの各種の条件を広く公開する例を説明した。また、借り手ユーザや貸し手ユーザの契約の相手方の情報を、特定の目的に応じて相手方ユーザに公開する例を説明した。
情報提供部111は、特定の目的に依らず、借り手ユーザのPF情報を貸し手ユーザに公開してもよい。公開するレベルは、個人が特定されないレベルの情報を公開する。そうでない情報は、例えばチェーン店名プラス店舗名のような支出が記載されている場合、単に「レストラン」とカテゴリ名を表示させるなどの工夫をした上で、公開してもよい。日々の状況を適宜確認することができるので、貸し手ユーザにとってみると、借り手ユーザの日々の生活、成長などの垣間見ることができるので、あたかも借り手ユーザを育成しているかのような疑似体験をすることもできる。また、このような情報を公開する代わりに、金利を安く設定するなどしてもよい。
また、貸し手ユーザを積極的に広く公開してもよい。例えば、社会貢献が大きい貸し手ユーザ、例えば、金額を多く貸している貸し手ユーザ、あるいは、多数の人に貸し付けを行っている貸し手ユーザを、公開してもよい。
<3-11.AIへの適用>
サービス提供システム100で行われる各種のサービスのデータを用いてモデル構築部113が学習モデル114を構築してもよい。つまり、いわゆる人工知能にこれまでのデータを覚え込ませてもよい。例えば、サービス提供システム100が行っている金銭の貸し出し情報に関する情報(例えば、適切な返済をするのか、返済が遅れるのか、返済できないのかなど)と、PF情報から得られる支出情報(生活支出)とを用いて学習モデル114を構築してもよい。このように構築された学習モデル114にPF情報を入力すると、返済の可能性を示すデータが学習モデル114から出力される。判定部104は、この結果に基づいて、返済の可能性を判定し、返済が滞りそうな場合には、情報提供部111に通知させてもよい。
<<4.ロボ・アドバイザー>>
これまでは、サービス提供システム100がレンディングのサービスを提供する形態を説明した。本項以降では、サービス提供システム100がロボ・アドバイザーのサービスを提供する形態を説明する。例えば、図2のボタン240を押下することで、ユーザは以降で説明するロボ・アドバイザーのサービスの提供を受けることができる。
なお、サービス提供システム100の構成は、図1に示したレンディングのサービスを提供する構成と同様とすることができる。
<4-1.余剰資産の選別>
先に説明したように、PFMシステム150から得られるPF情報を用いることで、余剰資金を特定することができる。資産特定部103は、余剰資産を特定する。分類部106は、特定した資産をさらに分類することができる。例えば、余剰資金のうち、老後に備える長期的な観点の資金、旅行資金に用いる短期的な観点の資金、あるいは、完全な余剰といった将来的な観点がない資金などに分類することができる。資産運用サポート処理部115は、この分類結果に従って、資産運用を行うことができる。例えば、長期的な観点の資金は、安定的な長期運用に回す一方、将来的な観点がない資金は、リスクが高い投資運用に回すなど、柔軟な資産運用を行うことができる。なお、日々の生活に応じて余剰は変動し得るものである。したがって、PF情報に基づいて適宜分類される資金が変動する。資産運用サポート処理部115は、変動する資金に応じて運用を適宜変更してもよい。
<4-2.AIへの適用>
本項においては、モデル構築部113は、例えば著名な投資家やレビュー数の多いユーザの学習モデル114を構築する。資産運用サポート部は、このように構築された学習モデルを用いて資産運用を行ってもよい。例えば、ユーザは、著名な投資家のうちの所望する投資家の学習モデル114を選択する指示を、ユーザ端末を介して送ってもよい。
<4-3.金利情報に連動した助言>
資産運用サポート処理部115は、各種の金利情報と連動して、ユーザに助言のメッセージを送信してもよい。例えば、金利が非常に低いような場合には、お金を借りてでも投資をすることを助言してもよい。
<4-4.表示機能>
自身が保有する資産に関連するようなニュースがあった場合、資産運用画面中において表示する(あるいはリンクを張る)処理をしてよい。資産運用画面に併せて関連するニュースを表示させることで、ユーザは様々な情報を得ることができるので、適切な投資判断を行うことができる。
以上の例においては、サービス提供システム100がレンディングサービスを行う場合や、ロボ・アドバイザーを行う場合を説明した。サービス提供システム100は、これらの両方を実行してもよいし、いずれかを実行してもよい。
上述した実施形態の機能を実現するための各部は、例えばハードウェアまたはソフトウェアによって実装することができる。ソフトウェアによって実装される場合、ハードウェアを制御するプログラムコードをCPU、MPUなどの各種のプロセッサによって実行されてもよい。プログラムコードの機能を実現するための回路等のハードウェアを設けてもよい。プログラムコードの一部をハードウェアで実現し、残りの部分を各種プロセッサが実行してもよい。
また、前記実施形態においては、日本円の賃借を例示として示しているが、日本円以外の外貨を取引対象とすることもできる。さらに、特に、明示していないが、貸し手、借り手共に、日本人でも、外国人でもよく、日本在住者でも、海外在住者であってもよい。
また、借り手が返済不可能(デフォルト)となった場合に備え、システム運用者若しくは第三者が貸し手を保護すべく、保証手数料(金利の一部等)を支払っている場合には、デフォルト時に返金されなかった元本部分を借り手に代わって貸し手に支払う仕組みを適用させてもよい。
100…サービス提供システム、101…制御部、102…情報取得部、103…資産特定部、104…判定部、105…マッチング部、106…分類部、107…管理部、108…指示送信部、109…指示受信部、111…情報提供部、112…契約処理部、113…モデル構築部、114…学習モデル、115…資産運用サポート処理部、150…システム、160…ユーザ端末、180…金融機関サーバ

Claims (6)

  1. 複数の種類の金融情報を集約して管理する金融資産管理システムから、前記金融情報に含まれる、ユーザの入出金の履歴の情報である入出金情報を取得する取得部と、
    前記入出金情報に基づいて、貸し手のユーザと借り手のユーザとをマッチングさせるマッチング部と、
    前記借り手のユーザの前記金融情報に基づいて、前記借り手のユーザの預金残高が、前記借り手のユーザによる前記貸し手のユーザへの返済額に対して不足していると判定される場合、返済に関する警告を示すメッセージを前記借り手のユーザに通知する情報提供部と、
    を有する、サービス提供システム。
  2. 前記入出金情報は、前記ユーザの日常的な入出金の履歴の情報である、
    請求項1に記載のサービス提供システム。
  3. 前記入出金情報に基づいて、借り手となる前記ユーザを、返済に関するタイプごとに分類する分類部をさらに有する請求項1または請求項2に記載のサービス提供システム。
  4. 前記分類部で分類される返済に関するタイプに応じて利息を設定する利息設定部をさらに有する請求項3に記載のサービス提供システム。
  5. 前記取得部は、
    前記金融情報に含まれる、借り手となる前記ユーザの資金を借りたい目的に関する情報を取得し、
    貸し手となる前記ユーザから、所定の目的で資金を提供する旨の提供指示を取得し、
    前記マッチング部は、前記資金を借りたい目的と、前記所定の目的と、に基づいて、前記借り手となるユーザと、前記貸し手となるユーザと、をマッチングさせる、
    請求項1から請求項4のいずれか一項に記載のサービス提供システム。
  6. 前記マッチング部でマッチングされた前記貸し手となるユーザに対して、前記借り手となるユーザの前記借りたい目的に関連する情報を提供する情報提供部をさらに備える請求項5に記載のサービス提供システム。
JP2021177081A 2016-10-20 2021-10-29 金融資産管理システムと連携したサービスを提供するサービス提供システム Active JP7216466B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021177081A JP7216466B2 (ja) 2016-10-20 2021-10-29 金融資産管理システムと連携したサービスを提供するサービス提供システム
JP2023005773A JP2023033547A (ja) 2021-10-29 2023-01-18 金融資産管理システムと連携したサービスを提供するサービス提供システム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016206040A JP6800513B2 (ja) 2016-10-20 2016-10-20 金融資産管理システムと連携したサービスを提供するサービス提供システム
JP2020193056A JP6971522B2 (ja) 2016-10-20 2020-11-20 金融資産管理システムと連携したサービスを提供するサービス提供システム
JP2021177081A JP7216466B2 (ja) 2016-10-20 2021-10-29 金融資産管理システムと連携したサービスを提供するサービス提供システム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2020193056A Division JP6971522B2 (ja) 2016-10-20 2020-11-20 金融資産管理システムと連携したサービスを提供するサービス提供システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023005773A Division JP2023033547A (ja) 2021-10-29 2023-01-18 金融資産管理システムと連携したサービスを提供するサービス提供システム

Publications (2)

Publication Number Publication Date
JP2022009712A JP2022009712A (ja) 2022-01-14
JP7216466B2 true JP7216466B2 (ja) 2023-02-01

Family

ID=87885013

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021177081A Active JP7216466B2 (ja) 2016-10-20 2021-10-29 金融資産管理システムと連携したサービスを提供するサービス提供システム

Country Status (1)

Country Link
JP (1) JP7216466B2 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009193100A (ja) 2008-02-12 2009-08-27 Nec Corp オークションシステム、オークション管理システム、オークション管理方法、プログラム、及び記録媒体
JP2010231664A (ja) 2009-03-27 2010-10-14 Promise Co Ltd 個人間融資仲介システム及びコンピュータプログラム
US20140067650A1 (en) 2012-08-28 2014-03-06 Clearmatch Holdings (Singapore) PTE. LTD. Methods and systems for consumer lending

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009193100A (ja) 2008-02-12 2009-08-27 Nec Corp オークションシステム、オークション管理システム、オークション管理方法、プログラム、及び記録媒体
JP2010231664A (ja) 2009-03-27 2010-10-14 Promise Co Ltd 個人間融資仲介システム及びコンピュータプログラム
US20140067650A1 (en) 2012-08-28 2014-03-06 Clearmatch Holdings (Singapore) PTE. LTD. Methods and systems for consumer lending

Also Published As

Publication number Publication date
JP2022009712A (ja) 2022-01-14

Similar Documents

Publication Publication Date Title
KR101277385B1 (ko) 트랜잭션을 해결하는 시스템 및 방법
JP5505897B2 (ja) 分散型資本システムの方法、金融サービス・システム、記録媒体、及び、コンピュータ・システム
US6233566B1 (en) System, method and computer program product for online financial products trading
US20030018558A1 (en) System, method and computer program product for online financial products trading
JP6800513B2 (ja) 金融資産管理システムと連携したサービスを提供するサービス提供システム
US10776882B2 (en) Principal guaranteed savings and investment system and method
JP2005518011A5 (ja)
JP2003510708A (ja) 複数投資家の集積された個別選好に基づき選択された投資集合に投資するための方法及びシステム
JP2007095071A (ja) 資金貸借の同時競売プラットフォーム
US20110178860A1 (en) System and method for resolving transactions employing goal seeking attributes
Lyons et al. 24 The Evolution of Financial Services in the Digital Age
TW201926195A (zh) 資金交易平台
US20140172669A1 (en) Multi-Variable, Multi-Party Auction and Process to Prop-up Underwater Mortgages and Stabilize/Restore Market Values
TWI341996B (ja)
US20130085937A1 (en) Methods and Apparatus for Allocating Funds Based on Payment Obligations
JPWO2006087810A1 (ja) オークションシステム及び保険金受領権を含んだ投資信託商品の構築システム
TW200844892A (en) One-price home mortgage lending method and platform
JP6971522B2 (ja) 金融資産管理システムと連携したサービスを提供するサービス提供システム
US20110178859A1 (en) System and method for resolving transactions employing optional benefit offers
JP2011054210A (ja) 金融商品を構築する情報処理装置
TW200903373A (en) From indirect finance to direct finance debt-clearing system and method
JP7216466B2 (ja) 金融資産管理システムと連携したサービスを提供するサービス提供システム
JP2023033547A (ja) 金融資産管理システムと連携したサービスを提供するサービス提供システム
JP2009295141A (ja) 資本プールの自主的利率による資金取引プラットフォーム及びその方法
TWI374395B (ja)

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211126

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211126

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220930

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221118

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: 20221220

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230118

R151 Written notification of patent or utility model registration

Ref document number: 7216466

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151