Database
 sql >> база данни >  >> RDS >> Database

Модел на данни на платформата за равностойно кредитиране

Има много онлайн портали, които позволяват на инвеститорите да отпускат пари директно на отделни кредитополучатели – без банки да действат като посредници. Какъв модел на данни може да стои в основата на такъв сайт?

Платформите за онлайн кредитиране обединяват кредитополучателите и инвеститорите и им позволяват да избират на кого искат да заемат парите си (в случай на инвеститори) и от кого искат да заемат пари (в случай на кредитополучатели). Някои сайтове за равнопоставени кредити също позволяват на кредитополучателите и инвеститорите да сключват свои собствени сделки по отношение на лихвените проценти (т.е. лихвени проценти) и срока на заема.

Нека да разгледаме набързо как работят тези портали и след това да преминем към модел на данни, който може да ги поддържа.

Как работят Peer-to-Peer платформите за кредитиране?

  • Кредитополучателите предоставят желаната от тях сума на заема и съответните подробности като възраст, заетост, текущ доход, текущи заеми, кредитен рейтинг, средно месечно банково салдо, график на заплатите за последните шест месеца, всякакви запитвания или неизпълнения по техните сметки през последните дванадесет месеца, причината за заемането им, намерението за плащане и др.
  • Инвеститорите се регистрират, като попълват съответните данни, включително общата сума, която искат да инвестират. Имайте предвид, че те трябва да спазват KYC (Познай своя клиент) и данъчните разпоредби. KYC е процес, широко използван от финансовите институции, който получава кратка информация за самоличността на кредитополучателя/клиента.
  • Порталите преглеждат профилите на кредитополучателите и им присвояват рискови рейтинги (A до F; A означава най-добър рейтинг, а F означава най-лош) въз основа на техните текущи и неотдавнашни минали финансови статистически данни и техните изисквания за вземане на заеми.
  • Порталите могат също да определят сроковете на заема и лихвените проценти; те се основават предимно на оценките на риска на клиентите.
  • Заявките за заем на кредитополучателите (отсега нататък да ги наричаме „билети за заем“) се изброяват (показват се на портала) само след като процесът на проверка за този клиент приключи.
  • Регистрираните инвеститори могат да видят изброените кредитни билети и свързаните с тях рискови рейтинги, изисквания за вземане на заеми и други подходящи подробности. Това им помага да вземат решение относно своите инвестиции.
  • За да изпълнят билет за заем, инвеститорите могат да внесат всякаква сума, от минимума на портала (да речем $50) до общата сума на заема.
  • След като талонът за заем бъде изпълнен, инвеститорите, които са допринесли за кредитния билет, трябва да отпуснат средства на кредитополучателя. Обикновено всички финансови транзакции на сайта за заеми използват ескроу сметки.
  • След като сумата на заема бъде изплатена, кредитополучателите изплащат сумата под формата на EMI (равни месечни вноски). EMI се събират в ескроу сметки и в крайна сметка се разпределят обратно на инвеститорите въз основа на техните дялове в билета за заем.
  • Плащанията по EMI включват вноски както към главницата на заема, така и към лихвата. В началните етапи лихвените плащания представляват основната част от ЕПИ.
  • Има два възможни сценария на заема:кредитополучателите плащат част или цялата неизплатена сума предварително или плащането по EMI се забавя. Тези закъснения могат да бъдат от няколко дни до няколко месеца. Ако плащанията са забавени, кредитополучателите подлежат на допълнителна лихва и неустойка за неизпълнени EMI.
  • Ако кредитополучателите плащат част от непогасената сума на заема, тя се разпределя между инвеститорите въз основа на техните дялове в кредитния билет.

Моделът на данните

Можете да видите пълния модел на данни по-долу. Той се върти главно около два субекта:инвеститорите, които дават пари на заем, и кредитополучателите, които ги искат.




Раздел 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:Кредитополучател

Тази предметна област обяснява как улавяме и поддържаме данните на кредитополучателите; също така ни просветлява за процесите, свързани с проверката на кредитополучателя или разбирането на тяхната способност и желание да изплащат.

Процесът започва с регистриране на кредитополучатели в сайта. Ще събираме информация за тяхното образование, професия, финансово състояние и изисквания за вземане на заеми. Порталите обикновено улавят образователни подробности, тъй като те играят ключова роля в процеса на вземане на решения от инвеститорите, особено когато кредитополучателите нямат благоприятни данни за заетостта. Финансовите подробности включват техните месечни доходи, всички текущи неизплатени задължения, банкови извлечения за последните шест месеца, всички наскоро отхвърлени чекове и дали имат редовен доход.

След като този процес на проверка приключи, на кредитополучателите се присвоява рейтинг на риска. Техните изисквания за вземане на заеми (т.е. билети за заем) са достъпни на портала за обществено виждане. Във всеки един момент от време инвеститорите могат да видят всички отворени билети за заем, т.е. тези, които все още не са 100% финансирани.

borrower таблицата съдържа данни за профила на кредитополучателите, които се записват в процеса на регистрация. Колоните в тази таблица са обясними сами по себе си, с изключение на следното:

  • kyc_complete – Съдържа Y или N, в зависимост от това дали процесът на KYC е завършен за този кредитополучател.
  • 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 – ИД на всеки инвеститор, допринесъл за кредитния билет; това също се отнася до сумата, която инвеститорът трябва да освободи.
  • release_date_from_investor – Датата, на която инвеститорът е освободил средства по ескроу сметката.
  • disburse_date_to_borrower – Датата, на която сумата е кредитирана в сметката на кредитополучателя. Обикновено и двете транзакции се извършват в един и същи ден или с интервал от един работен ден.
  • last_update_date – Тази колона се актуализира при актуализиране на запис.

loan_ticket_fulfillment таблицата също така съдържа информация за дела на всеки инвеститор в изплащанията преди EMI и EMI. Когато кредитополучателите са получили достъп само до част от сумата на заема си, от тях се изисква да плащат лихва само върху изплатената сума (докато пълната сума на заема бъде налична). Тази лихва се нарича лихва преди EMI (PEMI) и се плаща ежемесечно, докато бъде извършено окончателното изплащане, след което EMI започват.

  • pre_emi_due_date – Датата, на която предстои пре-емисията. Обикновено това е последният ден от месеца, когато този заем е изплатен.
  • pre_emi_amount – Изчисленото количество предеми.
  • emi_amount – Сумата, която кредитополучателят плаща като месечна вноска.
  • emi_start_date – Датата, на която започва EMI. Обикновено това е първият ден на следващия месец (например заемът е изпълнен на 13 януари, а EMI започва на 1 февруари).
  • emi_end_date – Датата, на която кредитополучателят трябва да плати последния EMI. Това е изчислена колона, която се актуализира в момента на изпълнение на заема. Ако срокът на заема е 12 месеца и началната дата на EMI е 1 февруари 2019 г., тогава последният EMI ще бъде изплатен на 1 януари 2020 г.
  • number_of_total_emi – Броят на EMI, които трябва да бъдат платени в този заем.

Кредитополучателите могат да затворят (изплатят) своите заеми предсрочно, като изплатят неизплатената главница като цяло. В банково отношение това е известно като „предварително затваряне“ на заем. Кредитополучателят може предварително да затвори заема за един или повече кредитори наведнъж, като плати дела на този кредитор от непогасената главница. Добавих две колони към таблицата, за да се справя с този случай:

  • pre_closure_flag – Тази колона показва дали заемът е предварително закрит. По подразбиране тази колона остава празна.
  • pre_closure_date – Датата, на която кредитът е предварително закрит. За текущ заем тази колона остава празна.

loan_repayment_schedule таблицата съдържа подробности за погасяването на заема. Веднага след като заемът бъде изплатен, записи се вмъкват в тази таблица за всеки график за плащане на EMI. Ако например има 10 инвеститори, които са инвестирали в един билет за заем, ще има 10 записа в loan_ticket_fulfillment маса. Ако срокът за ползване на този заем е 12 месеца, loan_repayment_schedule таблицата ще съдържа 120 записа (10 записа х 12 месеца).

Преди да продължим, разгледайте примерен график за погасяване:

Няколко колони в loan_repayment_schedule таблицата са колони за суми, създадени за съхраняване на дължимата сума и сумите, платени към различни компоненти на EMI. Някои от другите колони са:

  • id – Уникален номер, присвоен на всяко плащане.
  • loan_ticket_fulfillment_id – Тази колона съдържа подробности, свързани с инвеститора, заемния билет и кредитополучателя.
  • is_emi_payment_defaulted – Ако EMI не бъде платена до датата на падежа, тази колона се актуализира с „Y“. По подразбиране тази колона остава празна.
  • is_emi_payment_advanced – Ако една или повече бъдещи EMI вече са платени, тази колона се актуализира на „Y“ спрямо всички тези записи.

Какво мислите за модела на данни на платформата за кредитиране?

Смятате ли, че позволяването на кредитополучателите и инвеститорите да сключват свои собствени сделки за заем е сложно? От какви промени се нуждае този модел на данни, ако им позволим да договарят лихвените проценти и срока на собственост?

Моля, уведомете ни вашите мнения в секцията за коментари.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Използване на JShell в Java 9 в NetBeans 9.0, част 2

  2. Промените в записваем дял може да се провалят неочаквано

  3. Лоши навици:Преброяване на редовете по трудния начин

  4. Анонимизирайте детайлите на плана си по естествен начин в Plan Explorer

  5. Как се стартират паралелни планове – част 1