ピアツーピア貸付プラットフォームデータモデル

投資家が個々の借り手に直接お金を貸すことができる多くのオンラインポータルがあります-仲介者として機能する銀行はありません。そのようなサイトの根底にあるデータモデルは何ですか？

オンライン貸付プラットフォームは、借り手と投資家を結びつけ、誰にお金を貸したいか（投資家の場合）、誰からお金を借りたいか（借り手の場合）を選択できるようにします。一部のピアツーピア貸付サイトでは、借り手と投資家が貸付金利（つまり金利）と貸付期間に関して独自の取引を行うこともできます。

これらのポータルがどのように機能するかを簡単に見てから、それらをサポートできるデータモデルに移りましょう。

ピアツーピア貸付プラットフォームはどのように機能しますか？

借り手は、希望するローン金額と、年齢、雇用、現在の収入、現在のローン、クレジットスコア、月間平均銀行残高、過去6か月間の給与スケジュール、過去12年間のアカウントに関する問い合わせやデフォルトなどの関連情報を提供します。月、借りる理由、支払う意向など。
投資家は、投資したい合計金額など、関連する詳細を入力して登録します。 KYC（Know Your Customer）および税法に準拠する必要があることに注意してください。 KYCは、金融機関で広く使用されているプロセスであり、借り手/顧客の身元に関する簡単な情報を取得します。
ポータルは借り手のプロファイルを選別し、現在および最近の過去の財務統計と借入要件に基づいて、リスク評価（AからF、Aは最高の評価、Fは最低の評価）を割り当てます。
ポータルは、ローンの保有期間と金利を決定する場合もあります。これらは主に顧客のリスク評価に基づいています。
借り手のローン要求（今後は「ローンチケット」と呼びます）は、その顧客のスクリーニングプロセスが完了した後にのみ一覧表示されます（ポータルに表示されます）。
登録された投資家は、リストされたローンチケットとそれに関連するリスク評価、借入要件、およびその他の関連する詳細を表示できます。これらは、投資に関する決定を下すのに役立ちます。
ローンチケットを履行するために、投資家はポータルの最低額（たとえば、50ドル）からローンの合計額まで、任意の金額を寄付できます。
ローンチケットが履行されると、ローンチケットに貢献した投資家は借り手に資金を解放する必要があります。通常、すべての貸付サイトの金融取引はエスクロー口座を使用します。
ローンの金額が支払われると、借り手はEMI（Equated Monthly Installment）の形式でその金額を返済します。 EMIはエスクロー口座に集められ、最終的にはローンチケットのシェアに基づいて投資家に分配されます。
EMIの支払いには、ローンの元本と利息の両方に対する拠出が含まれます。初期段階では、利息の支払いがEMIの主要な部分を構成します。
2つの可能なローンシナリオがあります。借り手が未払いの金額の一部またはすべてを前払いするか、EMIの支払いが遅れます。これらの遅延は、数日から数か月の範囲で発生する可能性があります。支払いが遅れた場合、借り手は追加の利息とデフォルトのEMIに対するペナルティの対象となります。
借り手が未払いのローン金額の一部を支払う場合、ローンチケットのシェアに基づいて投資家に分配されます。

データモデル

以下に完全なデータモデルを示します。それは主に2つのエンティティを中心に展開します：お金を貸す投資家とそれを要求する借り手です。

セクション1：投資家

オンラインピアツーピア（P2P）貸付プラットフォームでは、支払い方法や候補者などの基本的な詳細を入力することで、投資家として登録できます。また、P2Pプラットフォームを使用してエスクローアカウントに対して行うすべてのトランザクションをキャプチャします。

investor テーブルには投資家の基本的な詳細が格納されます。この表のほとんどの列は、次の点を除いて自明です。

id –個々の投資家に与えられる一意の識別子。
tax_id –投資家の政府の納税者番号（または、米国では社会保障番号（SSN））。この列は、プラットフォームが税法に準拠し続けるのに役立ちます。
kyc_complete – KYCプロセスは、投資家の完全な詳細を取得するために実行されます。この列には、その投資家のプロセスが完了したかどうかに応じて、YまたはNが表示されます。
escrow_account_number –すべての投資家には固有のエスクローアカウントが割り当てられます。投資家と借り手の間のすべての金融取引は、このエスクロー口座を通じて行われます。
fund_committed –投資家が投資のためにコミットした金額（これまでのところ）。

nominee 表には、投資家の候補者に関する情報が含まれています。すべての投資家は、自分のプロファイルに候補者を登録できます。候補者とは、投資家に知られている人々であり、おそらくその家族や友人であり、投資家が死亡した場合に支払いを受ける権利があります。この表のすべての列は自明です。

account_statement 表には、投資家によって実行されたすべてのトランザクションの詳細が格納されます。トランザクションは、預金または引き出しのいずれかです。投資家がエスクロー口座にいくらかのお金を入れるとき、これは「預金」取引です。「引き出し」取引は、投資家がエスクロー口座のお金の一部またはすべてを引き出すときに発生します。いずれの場合も、closing_balance それに応じて更新されます。

payment_method 表には、エスクロー口座に資金を追加するために使用される支払い方法に関する情報が含まれています。投資家は、複数の銀行口座を追加して、お金を預けたり引き出したりすることができます。この表の列は一目瞭然です。

セクション2：借り手

この主題分野では、借り手の詳細を取得して維持する方法について説明します。また、借り手の検証に関連するプロセス、または借り手の返済能力と意欲を理解することについても教えてくれます。

プロセスは、サイトに借り手を登録することから始まります。私たちは彼らの教育、職業、財政状態、および借入要件に関する情報を収集します。ポータルは通常、投資家の意思決定プロセスで重要な役割を果たすため、特に借り手が有利な雇用の詳細を持っていない場合に、教育の詳細をキャプチャします。財務の詳細には、月収、現在の未払いの債務、過去6か月間の銀行取引明細書、最近返送された小切手、および定期的な収入があるかどうかが含まれます。

この検証プロセスが完了すると、借り手にはリスク評価が割り当てられます。それらの借入要件（つまり、ローンチケット）は、ポータルで公開されて公開されます。任意の時点で、投資家はすべてのオープンローンチケット、つまりまだ100％資金が提供されていないものを表示できます。

borrower テーブルには、登録プロセスで取得される借り手のプロファイルの詳細が保持されます。この表の列は、次の点を除いて自明です。

kyc_complete –この借り手に対してKYCプロセスが完了したかどうかに応じて、YまたはNを保持します。
highest_qualification –この借り手の最高の教育資格。例えば学部の学位、大学院の学位など
passout_year –借り手が最高の資格を取得した年。
university_name –借り手が最高の資格を取得した大学。

employment_detail テーブルには、借り手の雇用の詳細が格納されます。この表の列は一目瞭然です。

ポータルは借り手の基本的な詳細を確認すると、要件のローンチケットを作成し、資産と負債を取得します。資産と負債の詳細は、投資家が参照できるようになっています。投資家は、借り手の返済能力を判断するためにこれらの詳細を参照する必要がある場合があります。

ローン要件ごとにローンチケットが作成されます。この情報はloan_ticketに保存されますテーブル。列は次のとおりです。

id –各ローンチケットに付けられた一意の番号。
borrower_id –借り手テーブルからの参照列。
loan_amount –希望するローン金額。
loan_tenure_in_months –ローンが返済される月数。
interest_rate –そのローンの利率。
risk_rating –リスク評価は各借り手に割り当てられます。それは彼らの資産、負債、およびその他の財務上の詳細に依存します。
reason_for_loan –借り手がこのローンを必要とする理由。ローンの理由は、一部の投資家にとって重要な要素です。たとえば、教育上の理由や借金の整理のために投資することを好む投資家もいますが、休暇に資金を提供しているローンには近づかない場合があります。
ability_to_repay –ポータルは、借り手がローンを返済する能力に言及する箇条書きをキャプチャします。これらの箇条書きは、投資家が意思決定プロセスで検討します。
risk_factors –この列には、このローンへの投資に関連するリスクに関してポータルによって取得された情報が格納されます。

リスク格付けは、借り手から提出された詳細に基づくアルゴリズムによって計算されます。プラットフォームの従業員は、各借り手のプロファイルを確認し、財務の詳細（クレジットスコアを含む）を検証し、ローン申請の処理中にリスク評価、ローン金額（必要に応じて金額を下げるなど）、およびローン保有期間を操作できます。

borrower_liability 表には、借り手の未払いのローンに関する詳細が含まれています。この表の列は次のとおりです。

id –テーブルの主キー。
loan_ticket_id – loan_ticketを参照しますテーブル。
liability_cost –ローンの未払い額。
liability_type –責任の種類。例：住宅ローン、自動車ローン、個人ローンなど
liability_start_date –ローンが実行された日付。
liability_end_date –ローンが全額返済される日付。

borrower_asset テーブルには、借り手の資産と投資に関する情報が格納されます。これらの資産は、借り手が完全にまたは部分的に所有する固定預金、不動産、および投資（株式/負債）である可能性があります。実際にはローンの担保ではありませんが、必要に応じて清算することができます。さらに、資産の詳細を提供することで、借り手のプロファイルが強化されます。この表の列は次のとおりです。

id –テーブルの主キー。
loan_ticket_id –loan_ticketテーブルを参照します。
asset_type –資産の種類。例：不動産、固定預金、投資信託、株式など
asset_value –資産の現在の市場価値。
ownership_percentage –借り手の所有割合。一部の資産は、他の人と提携して購入されます。
possession_since –借り手がこの資産を取得した日付。

セクション3：ローンの履行と返済

このサブジェクトエリアには、ローンの提案、履行、および返済の詳細が含まれます。

investor_proposal テーブルには、ローンチケットに関する投資家の提案に関連するデータが格納されます。ローンチケットがポータルに投稿された後、投資家はそれらに提案を提出することができます。この表のほとんどの列は、次の点を除いて自明です。

proposal_amount –投資家が貸したい金額。投資家はローンチケットの100％までの金額を提案できます。
proposal_date –提案が提出された日付。
cancel_date –投資家は、支払い要求に変換されていない提案をキャンセルできます。この列には、提案がキャンセルされた日付（ある場合）が表示されます。
last_update_date –投資家は提案の金額を変更することもできますが、それは支払い要求に変換される前に限ります。この列には、最新のプロポーザル更新の日付が表示されます。

それでは、loan_ticket_fulfilmentに移りましょう。テーブル。ローンチケットが完全に資金提供されると、ローンチケットを履行するための履行要求が作成されます。これらの履行要求は、支払い要求とも呼ばれます。つまり、投資家が借り手の口座に資金を解放するためのものです。（注：この表には、EMIと閉鎖前の情報も含まれています。これらについては、個別に説明します。）この表の列は次のとおりです。

id –各フルフィルメントリクエストに割り当てられた一意の番号。ローンチケットに貢献している投資家が10人いる場合、このテーブルにはそのローンチケットを参照する10件のレコードがあります。
investor_proposal_id –ローンチケットに貢献した各投資家のID。これは、投資家がリリースする必要のある金額も参照します。
release_date_from_investor –投資家がエスクロー口座に資金をリリースした日付。
disburse_date_to_borrower –金額が借り手の口座に入金される日付。通常、これらのトランザクションは両方とも同じ日に発生するか、1営業日のギャップがあります。
last_update_date –この列は、レコードが更新されると更新されます。

loan_ticket_fulfillment 表には、EMI前およびEMIの支払いにおける各投資家のシェアに関する情報も含まれています。借り手がローン金額の一部にしかアクセスしていない場合、（ローンの全額が利用可能になるまで）支払われた金額に対してのみ利息を支払う必要があります。この利息は、EMI前利息（PEMI）と呼ばれ、最終的な支払いが行われるまで毎月支払われます。その後、EMIが開始されます。

pre_emi_due_date –プレエミの期日。通常、それはそのローンが履行された月の最後の日です。
pre_emi_amount –プレエミの計算量。
emi_amount –借り手が毎月の分割払いとして支払う金額。
emi_start_date –EMIが開始する日付。通常、それは翌月の初日です（たとえば、ローンは1月13日に履行され、EMIは2月1日に開始されます）。
emi_end_date –借り手が最後のEMIを支払う予定の日付。これは、ローンが履行されたときに更新される計算列です。ローンの保有期間が12か月で、EMIの開始日が2019年2月1日の場合、最後のEMIは2020年1月1日に支払われます。
number_of_total_emi –このローンで支払われるEMIの数。

借り手は、元本残高全体を支払うことで、ローンを早期に返済（返済）することができます。銀行用語では、これはローンの「事前閉鎖」として知られています。借り手は、未払いの元本のその貸し手のシェアを支払うことによって、一度に1つ以上の貸し手のためのローンを事前に閉じることができます。このケースを処理するために、テーブルに2つの列を追加しました：

pre_closure_flag –この列は、ローンが事前にクローズされているかどうかを示します。デフォルトでは、この列は空白のままです。
pre_closure_date –ローンが事前に締め切られた日付。進行中のローンの場合、この列は空白のままです。

loan_repayment_schedule 表には、ローン返済に関する詳細が含まれています。ローンが実行されるとすぐに、EMI支払いスケジュールごとにレコードがこのテーブルに挿入されます。たとえば、1つのローンチケットに投資した投資家が10人いる場合、loan_ticket_fulfillmentには10個のレコードがあります。テーブル。そのローンの保有期間が12か月の場合、loan_repayment_schedule テーブルには120レコード（10レコードx 12か月）が含まれます。

続行する前に、返済スケジュールの例をご覧ください。

loan_repayment_scheduleのいくつかの列表は金額の列であり、さまざまなEMIコンポーネントに対して支払われるべき金額と支払われる金額を格納するために作成されます。他の列のいくつかは次のとおりです：

id –各支払いに割り当てられた一意の番号。
loan_ticket_fulfillment_id –この列には、投資家、ローンチケット、および借り手に関連する詳細が表示されます。
is_emi_payment_defaulted – EMIが期日までに支払われない場合、この列は「Y」で更新されます。デフォルトでは、この列は空白のままです。
is_emi_payment_advanced – 1つ以上の将来のEMIがすでに支払われている場合、この列はそれらすべてのレコードに対して「Y」に更新されます。

貸出プラットフォームのデータモデルについてどう思いますか？

借り手と投資家が独自の貸付取引を行えるようにすることは複雑だと思いますか？貸出率と保有期間について交渉できるようにするには、このデータモデルにどのような変更が必要ですか？

コメント欄でご意見をお聞かせください。