Kui inimesed küsivad, mis teeb FinTech arenduse tavalisest tarkvaraarendusest erinevaks, on meie vastus alati sama: regulatsioon.
Tavalise veebirakenduse ehitamisel mõtled kasutajatele, funktsioonidele ja jõudlusele. FinTech rakenduse ehitamisel mõtled kõigele sellele pluss KYC nõuetele, AML vastavusele, andmete asukohaseadustele, panganduse API standarditele ja finantsaruandluse kohustustele. Ning igaüks neist varieerub riigiti.
Viimaste aastate jooksul oleme ehitanud FinTech lahendusi klientidele Eestis, Indoneesias, Brasiilias ja mitmel teisel turul. Iga projekt õpetas meile midagi uut tehnoloogia ja finantsregulatsiooni ristumiskohast.
Iga riik on erinev (kuid mitte nii erinev, kui arvad)
Esimene asi, mille õppisime, on see, et kuigi regulatsioonid erinevad detailides, on aluspõhimõtted märkimisväärselt järjekindlad. Iga riik soovib:
- Teada, kes finantsteenuseid kasutab (KYC)
- Ennetada rahapesu (AML)
- Kaitsta tarbijaandmeid
- Tagada finantsstabiilsust
Erinevus on rakendamises. Indoneesia nõuab konkreetseid identiteedikontrolli meetodeid, mis on seotud nende riikliku ID süsteemiga. Brasiilias on PIX — nende kohese makse süsteem — mis loob unikaalseid integratsiooninõudeid. Euroopa turud järgivad PSD2 ja GDPR-i.
Kui ehitasime Amarbanki, neopanganduse platvormi Indoneesia turule, ei olnud kohaliku regulatiivse maastiku mõistmine valikuline — see oli iga arhitektuuriotsuse alus. Andmete säilitamine, kasutajate sisseregistreerimise voog, tehingute jälgimine — kõik see pidi vastama Bank Indonesia regulatsioonidele esimesest päevast peale.
Avastusfaas ei ole valikuline
Tavalises tarkvaraarenduses saad mõnikord hakkama kergekaalulise avastusfaasiga. Joonista mõned tarkvistandid, kirjuta mõned kasutajalood, hakka ehitama.
FinTechis on avastuse vahelejätmine kõige kallim viga, mida saad teha.
Kulutame nüüd minimaalselt kaks kuni neli nädalat avastusele iga FinTech projekti puhul, sõltumata ulatusest. See faas sisaldab:
- Regulatiivne kaardistamine: millised seadused ja regulatsioonid kehtivad sihtturul?
- Vastavusarhitektuur: kuidas kujundavad KYC, AML ja andmenõuded tehnilist arhitektuuri?
- API maastik: millised panganduse API-d, maksetöötlejad ja identiteedikontrolli teenused on kohapeal saadaval?
- Andmete asukoht: kus peavad andmed olema säilitatud ning millised on piiriülese ülekande reeglid?
See esialgne investeering säästab järjekindlalt kuid hilisemat ümbertegemist. Ühel projektil tuvastas meie avastusfaas andmete asukohanõude, mis oleks sundinud täieliku pilveinfrastruktuuri ümberdisainimisele, kui see oleks avastatud pärast arenduse algust.
Vastavuse jaoks ehitamine esimesest päevast peale
On kiusatus ehitada toode kõigepealt ning lisada vastavusfunktsioonid hiljem. Oleme näinud seda lähenemist korduvalt ebaõnnestumas — nii oma varajastes projektides kui ka toodetes, mille parandamiseks meid kaasati.
Vastavus ei ole funktsioon, mille külge poldid. See on arhitektuuriline muster, mis läbib rakenduse iga kihti:
- Kasutajate sisseregistreerimine peab sisaldama identiteedikontrolli samme, mis vastavad kohalikele KYC nõuetele
- Tehingute töötlus peab sisaldama jälgimis- ja märgistamisreegleid kahtlase tegevuse jaoks
- Andmete säilitamine peab vastama asukoha- ja säilitamisregulatsioonidele
- Auditilogimine peab jäädvustama iga finantstehingu muutumatute kirjetega
- Aruandlus peab genereerima konkreetseid aruandeid, mida kohalikud regulaatorid nõuavad
Kui ehitasime ClickCashi, laenuplatvormi Brasiilia turule, mõjutasid vastavusnõuded andmebaasi skeemi, API disaini, kasutajaliidese voogu ning kasutuselevõtu infrastruktuuri. Ühtegi neist ei oleks saanud hiljem lisada ilma märkimisväärse ümbertegemiseta.
Kultuurilised erinevused kasutajakogemuses
Lisaks regulatsioonile õppisime, et finantstoote kasutajatel on väga erinevad ootused sõltuvalt nende turust.
Mõnel turul ootavad kasutajad täielikult digitaalset sisseregistreerimise kogemust — laadi üles foto oma ID-st, tee selfie ning oled minutitega kontrollitud. Teistel ootavad kasutajad kuskil protsessis inimliku kontaktpunkti, isegi kui ülejäänu on digitaalne.
Maksete eelistused varieeruvad dramaatiliselt. Mobiiliraha on domineeriv mõnes piirkonnas. Pangaülekandeid eelistatakse teistes. Kaardimaksed, mis tunduvad Euroopas universaalsed, on Kagu-Aasia osades teisejärguline valik.
Need erinevused ei ole ainult kasutajaliidese muutused. Need mõjutavad maksete integratsiooniarhitektuuri, sisseregistreerimise voogu ning mõnikord ka põhilist äriloogikat.
Mida me soovitame FinTech asutajatele
Kui ehitad FinTech toodet, eriti sellist, mis tegutseb piiriüleselt, siin on meie praktiline nõuanne:
- Alusta regulatsioonist, mitte funktsioonidest. Su regulatiivne maastik defineerib su arhitektuuri. Kaardista see esimesena.
- Investeeri avastusse. Kaks nädalat avastust võib säästa kuus kuud ümbertegemist.
- Ehita vastavus arhitektuuri sisse. Seda ei saa hiljem valuta lisada.
- Palka kohalik ekspertiis. Ükski arendusmeeskond ei saa teada iga riigi regulatsioone. Tee koostööd kohalike õigus- ja vastavuskonsultantidega.
- Planeeri muutusteks. Finantsregulatsioonid arenevad pidevalt. Ehita oma vastavuskiht konfigureeritavaks, mitte kõvakodeerituks.
- Testi päris stsenaariumitega. Vastavustestimine nõuab realistlikke andmeid ja realistlikke tehingumustreid, mitte ainult ühiktesti.
Tasu on pingutust väärt
FinTech arendus on raskem kui tavaline tarkvaraarendus. See võtab kauem aega, nõuab rohkem esialgset investeeringut ning nõuab täpsuse taset, mis paljudele meeskondadele on ebamugav.
Kuid tooted, mis sellest protsessist tulevad, on tõeliselt väärtuslikud. Need teenindavad päris finantsvajadusi, sageli alateenindatud elanikkondadele. Ning sisenemistõkked, mis muudavad FinTechi raskeks, muudavad ka edukad FinTech tooted raskesti konkureeritavaks.
Sellepärast me jätkame nende ehitamist.
Codelive on ehitanud üle 7 FinTech lahenduse 6 riigis, alates neopanganduse platvormidest kuni laenusüsteemideni. Kui planeerid FinTech toodet, jagame hea meelega, mida oleme õppinud.