Paberil on Open Banking standardiseerimise võidukäik. PSD2 kohustas Euroopa panku avama konto- ja makseandmed reguleeritud API-de kaudu, hulk agregaatoreid pakkis need API-d ühte SDK-sse ja äkki sai iga fintech mõne koodireaga lugeda kliendi tehinguid või algatada makse. Nii see lubadus kõlab. Siis ühendad oma esimese päris panga ja lõhe spetsifikatsiooni ja tootmisreaalsuse vahel avaneb su jalge all.
Oleme integreerinud Open Bankingut laenu-, kliendiks registreerimise ja maksevoogudesse mitmel ELi turul ning samad probleemid korduvad sõltumata sellest, milline agregaator vahel on. Ükski neist pole eksootiline. Kõiki saab vältida, kui tead, et need tulevad. Siin on nimekiri, mida oleksime soovinud saada esimesel päeval.
„Standardsed“ API-d ei ole standardsed
PSD2 määrab, mida pangad peavad avama, mitte kuidas. Tulemuseks on terve murrete pere – Berlin Groupi NextGenPSD2 standard, Ühendkuningriigi Open Banking Implementation Entity spetsifikatsioon, STET Prantsusmaal ja pikk saba panku, kes on teinud oma tõlgenduse. Isegi ühe standardi piires ei ole pangad detailides ühel meelel: kuidas tehinguid lehekülgedeks jagatakse, kas ootel tehingud on näha, mida tähendab „kirjenduskuupäev“, kui kaugele ajalugu ulatub ja millised väljad on päriselt täidetud ning millised on olemas, aga tühjad.
Agregaatorid katavad suurema osa sellest kinni ja see on tõeliselt väärtuslik – kuid abstraktsioon lekib. Saldotüübid erinevad. Mõni pank tagastab interimAvailable, mõni expected, mõni closingBooked ja nende samaväärsena käsitlemine rikub vaikselt iga maksevõime- või krediidiotsuse, mille selle peale ehitad. Õppetund, mille saime kalli hinnaga: ära usalda normaliseeritud välja enne, kui oled näinud selle konkreetse panga töötlemata vastust. Logi muutmata vastus, vaata registreerimise ajal läbi päris kontode näidised panga kaupa ja kirjuta vastavusse viimise loogika selle järgi, mida pank päriselt saadab, mitte selle järgi, mida SDK dokumentatsioon lubab.
Nõusolek on tiksuv kell, mitte linnuke
PSD2 kõige rohkem alahinnatud osa on nõusoleku elutsükkel. Regulatsiooni järgi kliendi nõusolek kontoandmete jagamiseks aegub – ajalooliselt iga 90 päeva järel ja isegi pärast seda, kui SCA uuesti autentimise erandid seda leevendasid, on nõusolekul endiselt kindel aegumistähtaeg ning klient või pank võib selle igal hetkel tagasi võtta.
Meeskonnad modelleerivad nõusolekut tõeväärtusena: kasutaja ühendas oma panga, seega on meil ligipääs. Siis 90 päeva hiljem hakkab iga andmepäring ebaõnnestuma, töölauad jäävad tühjaks ja ajastatud maksevõime kordusülevaatus tagastab vaikselt mitte midagi. Kui su toode sõltub pidevast ligipääsust – ja iga laenuhaldusplatvorm, mis jälgib laenusaaja rahavoogu, sõltub –, pead käsitlema nõusolekut täisväärtusliku, aeguva ressursina:
- Salvesta täpne aegumisaeg, mis iga nõusolekuga tagastatakse, mitte eeldatud 90 päeva.
- Küsi uut nõusolekut ennetavalt enne aegumist, rakenduses, sel ajal kui klient on aktiivne – mitte katkise funktsiooniga tagantjärele.
- Käsitle tagasivõtmist sujuvalt. Ligipääs võib kaduda keset sessiooni. Iga kooditee, mis pangaandmeid loeb, vajab haru „nõusolek ei kehti enam“, mis langeb puhtalt tagasi, mitte ei viska viga.
Ehita nõusoleku olekumasin enne funktsiooni, mis seda kasutab. Hiljem juurde ehitamine tähendab kõigi integratsioonipunktide korraga üle vaatamist.
Tugev kliendi autentimine katkestab su voo
SCA ehk tugev kliendi autentimine on PSD2 turvalisuse selgroog ja see tähendab, et pank – mitte sina – otsustab, millal klient peab teise faktoriga uuesti autentima. See ümbersuunamine panga rakendusse või 3-D Secure lehele ei ole erijuht, millest saab mööda disainida; see on põhitee. Su integratsioon peab üle elama selle, et kasutaja lahkub su voost, autendib end oma pangarakenduses ja tuleb tagasi – võib-olla teisel seadmel, võib-olla pärast aegumist, võib-olla olles poole pealt loobunud.
Siin aitavad kaks mustrit. Esiteks tee iga pikaajaline toiming jätkatavaks: salvesta piisavalt olekut, et tagasi tulev kasutaja jõuaks täpselt sinna, kus ta pooleli jäi, mitte ei peaks otsast alustama. Teiseks mõõda väljalangemist. SCA ümbersuunamised on koht, kus konversioon sureb, ja ainus viis lekkivat lehtrit parandada on mõõta iga sammu – algatus, ümbersuunamine, panga autentimine, tagasipöördumine, lõpetamine – ja näha täpselt, kus kasutajad välja kukuvad. Meie kogemuses peitub enamik vigu tagasipöördumise (callback) käsitlemises: mittevastavad ümbersuunamise URI-d, kaotatud sessiooni kontekst ning võidujooks tagasipöördumise ja sama olekut kontrolliva päringutöö vahel.
Makse algatamine ei tähenda „makse tehtud“
Kontoteabe teenus (AIS) on ainult lugemiseks ja suhteliselt andestav. Makse algatamise teenus (PIS) liigutab raha ning raha liikumine on asünkroonne, ebaõnnestumisaldis ja õiguslike tagajärgedega. Levinud ja ohtlik eeldus on, et 200 OK makse algatamisel tähendab, et makse toimus. Ei tähenda. See tähendab, et pank võttis korralduse vastu. Makse võidakse endiselt tagasi lükata, edasi lükata, pettusekontrolliks kinni hoida või see laekub tunde hiljem.
Kui märgid tellimuse makstuks, vabastad kauba või maksad laenu välja algatamise vastuse põhjal, kannad varem või hiljem kahju. Õige mudel on sama, mis hoiab pearaamatud ausana kõikjal fintechis: käsitle makset olekumasinana, mille autoriteetset olekut küsid ise või saad veebikonksu (webhook) kaudu, ja ära lase ühelgi ärilisel toimingul sõltuda optimistlikust vaheolekust. Võrdle algatatud makseid pidevalt tegeliku laekumisega ja anna häiret kõige kohta, mis on vaheolekus kinni kauem, kui peaks. Maksete vastavusse viimine on igav töö ja see on täpselt see selgroog, mis eristab auditi üle elavat fintechi sellest, mis seda ei tee.
Agregaator on sõltuvus, mitte garantii
Agregaatori kasutamine (TrueLayer, Tink, Salt Edge, Nordigen/GoCardless ja teised) on peaaegu alati õige otsus – otseühenduste ehitamine sadade pankadega on mitmeaastane kohustus, mida ei tasu kergekäeliselt võtta. Kuid agregaator on kolmanda osapoole sõltuvus su rahavoo kriitilisel teel ja sa pead selle reaalsusega arvestama:
- Katvus on ebaühtlane. Pank, mida su suurim klient kasutab, võib olla just see, mille tugi on ebastabiilne või kus PIS puudub. Kontrolli katvust oma tegeliku kasutajaskonna jaoks enne otsustamist, mitte turunduse katvuskaardi järgi.
- Päringupiirangud ja seisakud päritakse. Kui agregaatoril või selle taga oleval pangal on intsident, on intsident ka su tootel. Disaini sujuvaks talitluse halvenemiseks: puhverda, mida tohib seaduslikult puhverdada, pane järjekorda, mis võib oodata, ja näita ausat olekut, mitte lõputut laadimisikooni.
- Abstraktsiooni lekkimine lõikab mõlemat pidi. Uued pangad, muudetud väljad ja aegunud otspunktid saabuvad agregaatori ajakava järgi. Versioneeri oma integratsioon ja jälgi vaikseid skeemimuutusi.
Üldiselt soovitame klientidel hoida agregaatorit sisemise kaitsekihi (anti-corruption layer) taga – õhukese teenuse taga, mis tõlgib agregaatori mudeli sinu domeenimudeliks. Kui ühel päeval vahetad teenusepakkujat, lisad varunduseks teise või lähed võtmepangaga otse, on just see kiht vahe piiratud muudatuse ja ümberkirjutamise vahel.
Andmete minimeerimine on disainipiirang, mitte õiguslik joonealune märkus
PSD2 elab GDPR-i kõrval ja pangatehingute andmed on nii tundlikud, kui isikuandmed üldse olla saavad. On ahvatlev tõmmata kogu tehinguajalugu, hoida seda igavesti ja kaevandada hiljem. See instinkt on nõuetele vastavuse risk. Regulaatorid ootavad andmete minimeerimist: kogu ainult seda, mida väljaöeldud eesmärk nõuab, hoia seda ainult nii kaua, kui vaja, ja suuda seda soovi korral selgitada ning kustutada.
Ehita see sisse skeemi tasemel. Märgista andmed eesmärgi ja säilitusajaga, eralda töötlemata pangavoog tuletatud signaalidest, mida su toode päriselt kasutab, ja tee kustutamisest tavapärane toiming, mitte tulekahju kustutamine. Laenuettevõte, mis suudab regulaatorile näidata täpselt, milliseid pangaandmeid ta hoiab, miks ja kui kaua, on hoopis teises olukorras kui see, kes peab tähtaja surve all vastust otsima.
Ehita kõigepealt tõrkejuhtude jaoks
Kõiki neid lõkse ühendab sama joon: Open Banking töötab demos laitmatult ja kukub tootmises läbi sajal väikesel moel. Nõusolek aegub. SCA katkestab. Maksed laekuvad hilja. Pangad muudavad välju ette teatamata. Agregaatoritel on seisakud. Ükski neist pole erand – need on süsteemi tavalised töötingimused.
Usaldusväärseid Open Bankingu integratsioone ehitavad meeskonnad, kes käsitlevad tõrkejuhte peamise disainipinnana, mitte järelmõttena. Modelleeri nõusolekud ja maksed selgete olekumasinatena. Salvesta piisavalt, et kõike saaks jätkata. Vii andmeid pidevalt vastavusse autoriteetse allikaga. Hoia kolmandad osapooled kaitsekihi taga. Minimeeri ja märgista andmed, mida hoiad.
See on igav inseneritöö, mis teeb fintechi usaldusväärseks – ja just sellist tööd me teemegi. Kui ehitad Open Bankingu peale ja soovid partnerit, kes on nende seintega juba kokku põrganud, vaata, kuidas me töötame.