Iga laenuäri algab ühtemoodi: tabelist. See töötab suurepäraselt – kuni enam ei tööta. Kuskil viiekümnenda ja viiesajanda laenu vahel tabel mõraneb. Intress arvutatakse valesti. Makse läheb vale laenu peale. Audiitor küsib dokumenti, mida sa ei suuda esitada. Asutaja saab aru, et „me peame laenude arvestust Excelis“ on vaikselt muutunud ettevõtte suurimaks riskiks.
Laenuhaldussüsteem (LMS) on see, mis selle tabeli asendab. Kuid selle ehitamine on petlikult keeruline. Pealtnäha on see lihtne aritmeetika – põhiosa, intress, maksegraafik. Tegelikult on see tarkvaras üks kõige vähem andestavaid valdkondi: raha peab klappima sendi pealt, iga olekumuutus peab olema auditeeritav ja reeglid muutuvad pidevalt, sest regulaatorid muudavad neid.
Oleme ehitanud laenuhaldusplatvorme laenuandjatele mitmel turul ja iga kord kerkivad samad arhitektuurilised küsimused. Siin on, kuidas me neile läheneme.
Alusta laenu elutsüklist, mitte andmebaasist
Kõige sagedasem viga, mida näeme, on see, et meeskond modelleerib laenu staatilise kirjena – rida summa ja intressimääraga. Laen ei ole rida. See on olekumasin, mis liigub läbi elutsükli, ja igal üleminekul on tagajärjed.
Tüüpiline elutsükkel näeb välja selline:
Taotlus. Potentsiaalne laenusaaja esitab taotluse. Midagi rahalist pole veel juhtunud, kuid sa kogud juba andmeid, millest sõltuvad KYC ja krediidiotsused.
Riskihindamine ja heakskiit. Taotlust hinnatakse ja kontrollitakse ning see kas kiidetakse tingimustega heaks või lükatakse tagasi. Siin peitub risk.
Väljamakse. Raha lahkub su kontolt ja laen muutub aktiivseks. Sellest hetkest hakkab kell tiksuma ja intress kogunema.
Teenindamine. Pikk keskmine osa. Maksed laekuvad, intress koguneb iga päev, graafikuid arvutatakse ümber, laenusaajad küsivad ümberstruktureerimist, mõni makse ebaõnnestub.
Lõpetamine. Laen makstakse tagasi, kantakse maha, refinantseeritakse või antakse üle inkassole.
Kui modelleerid laenu esimesest päevast olekumasinana, on igal ärireeglil selge koht: mis tohib selles olekus juhtuda ja mida iga üleminek saldoga teeb? Kui modelleerid seda muudetava reana, hajub see loogika üle kogu koodibaasi ja muutub võimatuks hallata. Kui alustame laenuplatvormi arendust, on olekumasin esimene asi tahvlil – ammu enne, kui keegi andmebaasi skeemi avab.
Intressiarvestus on koht, kus naiivsed süsteemid purunevad
Küsi kolmelt laenuandjalt, kuidas nad intressi arvutavad, ja saad viis vastust. Lihtintress, liitintress, väheneva jäägi meetod, fikseeritud intress, igapäevane arvestus tegelik/365 alusel, tegelik/360, 30/360 – need ei ole omavahel asendatavad ja vale valik tähendab, et iga saldo su süsteemis on veidi vale.
Kaks põhimõtet hoiavad meid hädast eemal:
Ära kunagi hoia tuletatud saldot tõe allikana. Laenu jääk peab olema arvutatav muutumatust sündmuste pearaamatust – väljamaksed, intressi kogunemised, tagasimaksed, tasud, mahakandmised. Kui hoiad „praegust saldot“ muudetava numbrina ja uuendad seda kohapeal, satud varem või hiljem võidujooksu tingimusse, topelt rakendatud maksesse või katkenud tehingusse, mis jätab numbri valeks. Kui saldo tuletatakse ainult lisatavast pearaamatust, saad alati täpselt taastada, kuidas iga number mis tahes kuupäeval tekkis. Audiitorid armastavad seda. Sina ka – kell kaks öösel intsidendi ajal.
Kasuta täpset kümnendarvutust, mitte ujukomaarve. See kõlab ilmselgelt, kuid seda rikutakse pidevalt. Ujukomaarvutus teatab rõõmsalt, et täielikult tagasi makstud laenu jääk on 0,0000000003 €. Kasuta kümnendarvu tüüpi, määra ümardamisreeglid selgelt (ja jurisdiktsiooni kaupa) ning rakenda neid järjepidevalt. Ümardamine ei ole laenunduses detail – see on regulatiivne nõue.
Pearaamat on süsteemi süda
Kui sellest artiklist võtta kaasa üks mõte, siis see: laenuhaldussüsteem on spetsialiseeritud kahekordse kirjendamise põhimõttel töötav pearaamat, mille peal on elutsükkel.
Iga rahaline sündmus – väljamakse, intressi kogunemine, tagasimakse, viivis, mahakandmine – muutub üheks või mitmeks muutumatuks pearaamatu kandeks. Saldod on sellest pearaamatust tuletatud vaated. See annab kolm omadust, ilma milleta laenuäri hakkama ei saa:
- Auditeeritavus. Saad vastata küsimusele „miks see saldo just selline on?“ iga laenu kohta mis tahes ajaloolisel kuupäeval, mängides selle kanded uuesti läbi.
- Vastavusse viimine. Su süsteemi numbreid saab võrrelda panga numbritega, sest igale rahaliikumisele vastab kanne.
- Korrektsus tõrgete korral. Kui protsess poole pealt katkeb, ei jää sulle kunagi pooleldi uuendatud saldot – kanne kas kirjutati või mitte.
Selle aluse õigesti paika panemine on igav töö, mis tasub end ära kogu toote eluea jooksul. Valesti tehes ootab ees ümberkirjutamine paari aasta pärast, tavaliselt pärast läbikukkunud auditit.
Teenindamine on 90% tööst
Asutajad kulutavad suurema osa planeerimisenergiast laenu väljastamisele – säravale taotlusvoole. Tootmises elab süsteem aga teenindamises ja see on täis erijuhte, mis esimesse spetsifikatsiooni kunagi ei jõua:
- Osalised maksed. Laenusaaja maksab osa tasumisele kuuluvast. Kuidas see jaotatakse tasude, intressi ja põhiosa vahel? Jaotusjärjekord on äriline ja regulatiivne otsus ning see peab olema selgelt kirjas.
- Ennetähtaegne tagasimakse. Kas laenusaaja peab maksma tulevast intressi? Kas on ennetähtaegse tagasimakse tasu? Väheneva jäägi ja fikseeritud intressiga laenud käituvad siin väga erinevalt.
- Ümberstruktureerimine ja maksepuhkused. Päris laenusaajatel tuleb ette raskeid aegu. Süsteem peab suutma laenu keset eluiga ümber graafikustada, ilma selle ajalugu rikkumata.
- Võlgnevus ja inkasso. Millal muutub laen tähtaja ületanuks, millal makseraskuses olevaks? Milliseid automaatseid toiminguid see käivitab ja mis peab jääma inimese otsuseks?
- Ebaõnnestunud ja tagasi pööratud maksed. Otsekorraldus põrkub tagasi pärast seda, kui oled laenu juba makstuks märkinud. Pearaamat peab selle puhtalt tagasi keerama.
Midagi siin pole eksootiline – iga laenuandja puutub kõigega kokku. Just need süsteemid, kus teenindamine jäi tagaplaanile, vahetatakse välja. Me planeerime teenindamise erijuhud analüüsifaasis, sest nende jaoks on palju odavam kohe disainida kui hiljem juurde ehitada.
Nõuetele vastavus ei ole lisamoodul
Laenundus on tarkvaras üks kõige rangemalt reguleeritud tegevusi. Sõltuvalt turust puutud kokku tarbijakrediidi reeglite, intressilagede, kohustuslike teavituste, KYC/AML kohustuste ja rangete andmete säilitamise nõuetega. Need ei ole funktsioonid, mida lõpus peale puistad – need kujundavad arhitektuuri.
Kaks järeldust väärivad eraldi esiletõstmist. Esiteks vajab iga olekumuutus auditijälge: kes tegi mida, millal ja millise laenuga. Auditilogi lisamine süsteemile, mis muudab andmeid kohapeal, on valus; sündmuspõhine pearaamat annab selle sulle tasuta. Teiseks on dokumentide säilitamisel päris tagajärjed – laenulepinguid, teavitusi ja KYC tõendeid tuleb sageli säilitada aastaid pärast laenu lõppu, samal ajal kui GDPR annab laenusaajatele andmesubjekti õigused. Selle vastuolu varakult disaini sisse ehitamine on palju odavam kui hiljem selle üle vaielda.
Ehita portfelli jaoks, mis sul tuleb, mitte selle jaoks, mis sul praegu on
Viimane arhitektuuriküsimus on skaleerumine – ja siin on lõks üleinseneerimine sama sageli kui alainseneerimine. Tuhande laenu teenindamiseks pole sul vaja hajutatud mikroteenuste võrku. Kuid pead tegema valikuid, mis ei jäta sind sajatuhande laenu juures lõksu:
- Pakktööd peavad olema idempotentsed ja taaskäivitatavad. Öine intressiarvestus suure portfelli peal katkeb varem või hiljem poole pealt. Selle uuesti käivitamine peab olema ohutu.
- Intressiarvestus peaks võimaluse korral olema sündmuspõhine. Iga laenu igaöine ümberarvutamine ei skaleeru igavesti; sündmuste graafiku järgi arvestamine skaleerub.
- Aruandluse koormus ei tohi konkureerida teenindamisega. Finantsmeeskonnad jooksutavad raskeid päringuid. Hoia need tehingute teelt eemal lugemisreplikate või eraldi aruandlusandmebaasiga.
Õige vastus on tavaliselt hästi struktureeritud modulaarne monoliit puhta pearaamatu tuumaga – midagi, mida väike meeskond suudab hallata –, kus õmblused on tõmmatud nii, et osad, mis hiljem tõesti peavad iseseisvalt skaleeruma, saab ilma ümberkirjutamiseta välja eraldada.
Kokkuvõte
Laenuhaldussüsteem ei ole intressiga CRUD-rakendus. See on pearaamatupõhine, elutsüklist lähtuv ja regulatsioonidest kujundatud finantsinfrastruktuur ning esimese kuu otsused määravad, kas see elab üle su esimese auditi ja sajatuhandenda laenu.
Hea uudis: need on teadaolevad probleemid. Elutsükkel, pearaamat, intressireeglid, teenindamise erijuhud – meeskonnad, kes on varem laenuplatvorme ehitanud, tunnevad neid hästi. Kallis tee on avastada neid ükshaaval tootmisintsidentide kaudu.
Kui ehitad või vahetad välja laenuplatvormi, on see täpselt selline süsteem, mida me ehitame. Vaata meie laenuhaldussüsteemide tööd või võta meiega ühendust, et arutada oma portfelli ja arhitektuuri.