sql >> Database teknologi >  >> RDS >> Database

En peer-to-peer udlånsplatform datamodel

Der er mange online-portaler, som giver investorer mulighed for at låne penge direkte til individuelle låntagere – uden banker, der fungerer som mellemmænd. Hvilken datamodel kan ligge til grund for et sådant websted?

Online låneplatforme bringer låntagere og investorer sammen og giver dem mulighed for at vælge, hvem de vil låne deres penge ud til (i tilfælde af investorer), og hvem de vil låne penge fra (i tilfælde af låntagere). Nogle peer-to-peer-udlånssider giver også låntagere og investorer mulighed for at lave deres egne aftaler med hensyn til udlånsrenter (dvs. renter) og lånets løbetid.

Lad os tage et hurtigt kig på, hvordan disse portaler fungerer, og derefter gå videre til en datamodel, der kunne understøtte dem.

Hvordan fungerer peer-to-peer-udlånsplatforme?

  • Låntagere oplyser deres ønskede lånebeløb og relevante detaljer som alder, beskæftigelse, nuværende indkomst, nuværende lån, kreditscore, gennemsnitlig månedlig banksaldo, lønplan for de sidste seks måneder, eventuelle forespørgsler eller misligholdelser på deres konti inden for de sidste tolv måneder, deres årsag til låntagning, hensigt om at betale osv.
  • Investorer registrerer sig ved at udfylde relevante detaljer, herunder det samlede beløb, de ønsker at investere. Bemærk, at de skal overholde KYC (Kend din kunde) og skatteregler. KYC er en proces, der er meget udbredt af finansielle institutioner, og som indhenter kort information om en låntagers/kundes identitet.
  • Portalerne screener låntageres profiler og tildeler dem risikovurderinger (A til F; A står for bedste vurdering, og F står for værste) baseret på deres nuværende og seneste tidligere finansielle statistik og deres lånebehov.
  • Portaler kan også bestemme lånets løbetid og rentesatser; disse er primært baseret på kundernes risikovurderinger.
  • Låntageres låneanmodninger (lad os kalde dem "lånebilletter" fra nu af) vises først (vist på portalen), efter at screeningsprocessen for den pågældende kunde er fuldført.
  • Registrerede investorer kan se anførte lånebilletter og deres tilknyttede risikovurderinger, lånekrav og andre relevante detaljer. Disse hjælper dem med at træffe en beslutning om deres investeringer.
  • For at opfylde en lånebillet kan investorer bidrage med et hvilket som helst beløb, fra portalens minimum (f.eks. 50 USD) til det samlede lånebeløb.
  • Når en lånebillet er opfyldt, skal de investorer, der har bidraget til lånebilletten, frigive midler til låntageren. Normalt bruger alle finansielle transaktioner på udlånswebstedet spærrede konti.
  • Når lånebeløbet er udbetalt, tilbagebetaler låntagere beløbet i form af EMI'er (Equated Monthly Installments). EMI'er indsamles på spærrede konti og distribueres til sidst tilbage til investorerne baseret på deres andele i lånebilletten.
  • EMI-betalinger inkluderer bidrag til både lånets hovedstol og renter. I de indledende faser udgør rentebetalinger størstedelen af ​​EMI.
  • Der er to mulige lånescenarier:låntagere betaler en del af eller hele det udestående beløb på forhånd, eller EMI-betalingen er forsinket. Disse forsinkelser kan være alt fra et par dage til et par måneder. Hvis betalingerne forsinkes, pålægges låntagere yderligere renter og en bøde på misligholdte EMI'er.
  • Hvis låntagere betaler en del af et udestående lånebeløb, fordeles det blandt investorer baseret på deres andele i lånebilletten.

Datamodellen

Du kan se den komplette datamodel nedenfor. Det drejer sig hovedsageligt om to enheder:investorerne, der låner penge ud, og låntagerne, der anmoder om det.




Afsnit 1:Investor

Online peer-to-peer (P2P) udlånsplatforme giver folk mulighed for at registrere sig som investorer ved at indtaste deres grundlæggende detaljer, herunder betalingsmetoder og nominerede. Det fanger også alle transaktioner, som de foretager mod deres escrow-konto med P2P-platformen.

investor tabel gemmer investorernes grundlæggende detaljer. De fleste af kolonnerne i denne tabel er selvforklarende bortset fra:

  • id – En unik identifikator givet til hver enkelt investor.
  • tax_id – Investorens statslige skatte-id (eller, i USA, deres personnummer (SSN)). Denne kolonne hjælper platformen med at forblive i overensstemmelse med skattereglerne.
  • kyc_complete – KYC-processen udføres for at fange investorernes komplette detaljer. Denne kolonne har et Y eller et N, afhængigt af om processen er fuldført for den pågældende investor.
  • escrow_account_number – Hver investor får tildelt en unik deponeringskonto. Alle finansielle transaktioner mellem investorer og låntagere foregår via denne spærrede konto.
  • fund_committed – Det beløb, som investoren har forpligtet sig til at investere (indtil videre).

Den nominee tabel indeholder oplysninger om investorernes nominerede. Alle investorer kan registrere nominerede i deres profil. Nominerede er personer, investoren kender – højst sandsynligt deres familiemedlemmer eller venner – som har ret til at modtage betalinger, hvis investoren dør. Alle kolonnerne i denne tabel er selvforklarende.

account_statement tabel gemmer detaljerne om alle transaktioner udført af investorer. En transaktion kan enten være et indskud eller en udbetaling. Når en investor sætter nogle penge ind på deres escrow-konto, er dette en "indbetalings"-transaktion. En "tilbagetrækning"-transaktion opstår, når en investor hæver nogle af eller alle pengene på deres spærrede konto. I begge tilfælde er closing_balance er opdateret i overensstemmelse hermed.

payment_method tabel indeholder oplysninger om de betalingsmetoder, der bruges til at tilføje penge til deres spærrede konto. Investorer kan tilføje flere bankkonti for at indbetale eller hæve deres penge. Kolonnerne i denne tabel er selvforklarende.

Afsnit 2:Låntager

Dette emneområde forklarer, hvordan vi fanger og vedligeholder låntageres detaljer; det oplyser os også om de processer, der er involveret i låntagerverifikation, eller forståelse af deres evne og vilje til at tilbagebetale.

Processen starter med registrering af lånere på siden. Vi vil fange oplysninger om deres uddannelse, erhverv, økonomiske status og lånebehov. Portaler fanger normalt uddannelsesdetaljer, fordi de spiller en nøglerolle i investorernes beslutningsproces, især når låntagere ikke har gunstige ansættelsesoplysninger. Finansielle detaljer inkluderer deres månedlige indkomst, eventuelle aktuelle udeståender, kontoudtog for de sidste seks måneder, eventuelle nyligt returnerede checks, og om de har nogen regelmæssig indkomst.

Når denne verifikationsproces er afsluttet, tildeles låntagere en risikovurdering. Deres lånebehov (dvs. lånebilletter) er gjort tilgængelige på portalen til offentlig visning. På ethvert givet tidspunkt kan investorer se alle åbne lånebilletter, det vil sige dem, der endnu ikke er 100 % finansieret.

borrower tabel indeholder låntagers profiloplysninger, som fanges i registreringsprocessen. Kolonnerne i denne tabel er selvforklarende, bortset fra følgende:

  • kyc_complete – Indeholder et Y eller et N, afhængigt af om KYC-processen er fuldført for denne låner.
  • highest_qualification – Den højeste uddannelseskvalifikation for denne låntager; for eksempel. bachelorgrad, kandidatgrad osv.
  • passout_year – Året, hvor låntageren gennemførte deres højeste kvalifikation.
  • university_name – Det universitet, hvor låneren modtog deres højeste kvalifikation.

employment_detail tabel gemmer ansættelsesoplysninger for låntagere. Kolonnerne i denne tabel er selvforklarende.

Når portalen har verificeret låntageres grundlæggende detaljer, opretter den lånebilletter til deres behov og registrerer deres aktiver og passiver. Aktiv- og passivoplysninger stilles til rådighed for investorer til reference. Investorer skal muligvis henvise til disse detaljer for at bestemme låntagers evne til at tilbagebetale.

Der oprettes en lånebillet for hvert lånebehov. Disse oplysninger gemmes i loan_ticket bord. Kolonnerne er:

  • id – Et unikt nummer givet til hver lånebillet.
  • borrower_id – En refereret kolonne fra lånertabellen.
  • loan_amount – Det ønskede lånebeløb.
  • loan_tenure_in_months – Antallet af måneder, hvor lånet vil blive tilbagebetalt.
  • interest_rate – Renten for det lån.
  • risk_rating – Hver låntager tildeles en risikovurdering. Det afhænger af deres aktiver, passiver og andre økonomiske detaljer.
  • reason_for_loan – Hvorfor låntager har brug for dette lån. Årsagen til et lån er en nøglefaktor for nogle investorer. For eksempel foretrækker nogle investorer at investere af uddannelsesmæssige årsager eller gældskonsolidering, men de kan holde sig væk fra lån, der finansierer en ferie.
  • ability_to_repay – Portalen fanger punktopstillinger, der henviser til låntagers evne til at tilbagebetale et lån. Disse punktpunkter overvejes af investorer under deres beslutningsproces.
  • risk_factors – Denne kolonne gemmer oplysninger, der er fanget af portalen med henvisning til de risici, der er forbundet med at investere i dette lån.

Risikovurderinger beregnes gennem en algoritme, der er baseret på de oplysninger, som låntageren har indsendt. En platformsmedarbejder gennemgår hver låntagers profil, validerer deres finansielle detaljer (inklusive deres kreditscore) og kan manipulere risikovurdering, lånebeløb (f.eks. ved at sænke beløbet, hvis det er nødvendigt) og låneperioden under behandlingen af ​​låneansøgningen.

borrower_liability tabel indeholder detaljer om låntageres udestående lån. Kolonnerne i denne tabel er:

  • id – Tabellens primære nøgle.
  • loan_ticket_id – Henviser til loan_ticket tabel.
  • liability_cost –Lånets udestående beløb.
  • liability_type – Ansvarets art, f.eks. boliglån, billån, privatlån osv.
  • liability_start_date – Datoen for optagelsen af ​​lånet.
  • liability_end_date – Datoen for, hvornår lånet bliver fuldt ud indfriet.

borrower_asset tabel gemmer oplysninger om låntageres aktiver og investeringer. Disse aktiver kan være faste indskud, fast ejendom og investeringer (egenkapital/gæld), som låntagere ejer helt eller delvist. Det er faktisk ikke sikkerhed for lånet, men det kan likvideres, hvis det er nødvendigt. Derudover gør det at angive aktivoplysninger en låntagers profil stærkere. Kolonnerne i denne tabel er:

  • id – Tabellens primære nøgle.
  • loan_ticket_id – Henviser til lånebillettabellen.
  • asset_type – Aktivets type, f.eks. fast ejendom, fast indskud, investeringsforeninger, aktier mv.
  • asset_value – Aktivets aktuelle markedsværdi.
  • ownership_percentage – Låntagers procentdel af ejerskab. Nogle aktiver er købt i partnerskab med en anden person.
  • possession_since – Den dato, hvor låntageren erhvervede dette aktiv.

Afsnit 3:Indfrielse og tilbagebetaling af lån

Dette emneområde indeholder detaljerne om låneforslag, opfyldelse og tilbagebetaling.

investor_proposal tabel gemmer data forbundet med investorernes forslag om lånebilletter. Efter at lånebilletter er lagt ud på portalen, kan investorer indsende deres forslag på dem. De fleste af kolonnerne i denne tabel er selvforklarende, bortset fra:

  • proposal_amount – Det beløb, som investor ønsker at låne ud. Investorer kan foreslå beløb op til 100 % af lånebilletten.
  • proposal_date – Datoen for indsendelse af forslaget.
  • cancel_date – Investorer kan annullere forslag, der ikke er konverteret til udbetalingsanmodninger. Denne kolonne indeholder datoen (hvis nogen), hvor forslaget blev annulleret.
  • last_update_date – Investorer kan også ændre størrelsen af ​​et forslag, men kun før det konverteres til en udbetalingsanmodning. Denne kolonne indeholder datoen for den seneste forslagsopdatering.

Lad os nu gå videre til loan_ticket_fulfilment bord. Når en lånebillet er fuldstændig finansieret, oprettes der anmodninger om opfyldelse for at opfylde lånebilletten. Disse opfyldelsesanmodninger er også kendt som udbetalingsanmodninger, det vil sige, at investorerne skal frigive midlerne til låntagers konto. (Bemærk:Denne tabel indeholder også oplysninger om EMI og før-lukning, som vi vil diskutere separat.) Kolonnerne i denne tabel er:

  • id – Et unikt nummer tildelt hver anmodning om opfyldelse. Hvis der er 10 investorer, der bidrager til en lånebillet, vil der være 10 poster i denne tabel, der henviser til den pågældende lånebillet.
  • investor_proposal_id – ID'et for hver investor, der har bidraget til lånebilletten; dette refererer også til det beløb, som investor skal frigive.
  • release_date_from_investor – Datoen, hvor investoren frigav midler til spærringskontoen.
  • udbetalingsdato_til_låner – Den dato, hvor beløbet er krediteret på låntagers konto. Normalt sker begge disse transaktioner på samme dag eller med et mellemrum på en hverdag.
  • last_update_date – Denne kolonne opdateres, når en post opdateres.

loan_ticket_fulfillment tabel indeholder også oplysninger om hver investors andel i præ-EMI og EMI-udbetalinger. Når låntagere kun har adgang til en del af deres lånebeløb, skal de kun betale renter af det udbetalte beløb (indtil det fulde lånebeløb er tilgængeligt). Disse renter kaldes præ-EMI-renter (PEMI) og betales månedligt, indtil den endelige udbetaling er foretaget, hvorefter EMI'erne begynder.

  • pre_emi_due_date – Den dato, hvor præ-emien forfalder. Normalt er det den sidste dag i måneden, hvor lånet blev opfyldt.
  • pre_emi_amount – Den beregnede mængde præ-emi.
  • emi_amount – Det beløb, låntageren betaler som månedligt afdrag.
  • emi_start_date – Datoen, hvor EMI starter. Normalt er det den første dag i den næste måned (f.eks. er et lån opfyldt den 13. januar og EMI starter den 1. februar).
  • emi_end_date – Den dato, hvor låntageren er planlagt til at betale den sidste EMI. Dette er en beregnet kolonne, der opdateres på det tidspunkt, hvor lånet er opfyldt. Hvis et låns løbetid er 12 måneder, og EMI's startdato er den 1. februar 2019, vil den sidste EMI blive betalt den 1. januar 2020.
  • number_of_total_emi – Antallet af EMI'er, der skal betales i dette lån.

Låntagere kan lukke (afbetale) deres lån tidligt ved at betale den udestående hovedstol som helhed. I bankmæssige termer er dette kendt som "før-lukningen" af et lån. En låntager kan på forhånd lukke lånet for en eller flere långivere ad gangen ved at betale denne långivers andel af den udestående hovedstol. Jeg har tilføjet to kolonner til tabellen for at håndtere denne sag:

  • pre_closure_flag – Denne kolonne angiver, om lånet er præ-lukket. Som standard forbliver denne kolonne tom.
  • pre_closure_date – Datoen, hvor lånet er præ-lukket. For et løbende lån forbliver denne kolonne tom.

loan_repayment_schedule tabel indeholder detaljer om tilbagebetaling af lån. Så snart et lån er udbetalt, indsættes poster i denne tabel for hver EMI-betalingsplan. Hvis der for eksempel er 10 investorer, der har investeret i én lånebillet, vil der være 10 poster i loan_ticket_fulfillment bord. Hvis løbetiden for det pågældende lån er 12 måneder, er loan_repayment_schedule tabel vil indeholde 120 poster (10 poster x 12 måneder).

Inden vi fortsætter, så tag et kig på et eksempel på en tilbagebetalingsplan:

Flere kolonner i loan_repayment_schedule tabel er beløbskolonner, oprettet for at gemme det skyldige beløb og de beløb, der betales til forskellige EMI-komponenter. Nogle af de andre kolonner er:

  • id – Et unikt nummer tildelt hver betaling.
  • loan_ticket_fulfillment_id – Denne kolonne indeholder detaljer relateret til investor, lånebillet og låner.
  • is_emi_payment_defaulted – Hvis EMI ikke er betalt inden forfaldsdatoen, opdateres denne kolonne med 'Y'. Som standard forbliver denne kolonne tom.
  • is_emi_payment_advanced – Hvis en eller flere fremtidige EMI'er allerede er blevet betalt, opdateres denne kolonne til "Y" i forhold til alle disse poster.

Hvad synes du om udlånsplatformens datamodel?

Synes du, at det er komplekst at tillade låntagere og investorer at lave deres egne låneaftaler? Hvilke ændringer har denne datamodel brug for, hvis vi skulle give dem mulighed for at forhandle om udlånsrenter og løbetid?

Fortæl os venligst dine synspunkter i kommentarfeltet.


  1. Valg af rækker ordnet efter en kolonne og adskilt i en anden

  2. Python-modulet cx_Oracle-modulet kunne ikke findes

  3. Bestil først efter specifik feltværdi

  4. Returner kolonneprivilegier fra en sammenkædet server i SQL Server (T-SQL-eksempler)