Trenger du banklisens for å lansere en fintech-app?
«Trenger du banklisens for å lansere en fintech-app?» er egentlig tre spørsmål i én frakk. Holder du kundenes penger? Flytter du dem? Og hvis regulatoriske tillatelse dekker den flyttingen — din egen eller en annens? Svar på disse, så svarer lisensspørsmålet for det meste seg selv. Kortversjonen som overrasker de fleste team: de fleste fintech-apper har aldri banklisens, fordi de fleste fintech-apper aldri gjør det ene en banklisens faktisk er til for. Det som følger, er et kart over spekteret, ikke juridisk rådgivning — målet er å vite hvilke spørsmål du skal stille før noen oppgir en tidsplan eller en pris.
Hva en banklisens egentlig er til for
En full banklisens — i EU-termer en tillatelse som kredittinstitusjon — gir adgang til én bestemt, strengt overvåket aktivitet: å ta imot innskudd fra publikum og låne pengene ut igjen. Denne forfallsmismatchen, å finansiere lange lån med saldoer kundene kan ta ut når som helst, er grunnen til at banker har tunge kapitalkrav, innskuddsgarantiforpliktelser og en tilsynsmyndighet som leser balansen linje for linje. Hvis appen din ikke tar imot innskudd og låner ut mot dem, ser du nesten helt sikkert ikke på en banklisens i det hele tatt. Du ser på noe lettere, lenger ned i spekteret — og spekteret er hele historien.
Tillatelsesspekteret, fra tyngst til lettest
Finansielle tillatelser kommer i nivåer. Øverst står kredittinstitusjonen – banken – som kan ta imot innskudd og låne ut. Under den kan et e-pengeforetak (EMI) utstede e-penger: det kan oppbevare kundenes verdier og legge dem på kort eller i lommebøker, men midlene det forvalter må sikres – holdes atskilt og urørt, aldri lånes ut. Under det igjen kan et betalingsforetak (PI) utføre betalinger – initiere overføringer, kreve inn, remittere, innløse korttransaksjoner – men er ikke bygget for å oppbevare verdier over tid; pengene går gjennom, de blir ikke liggende. Nederst har en agent eller distributør ingen egen tillatelse i det hele tatt, men opererer i stedet under autorisasjonen til et lisensiert foretak som har registrert dem.
Mønsteret er at hvert trinn ned avgir en evne, og med den en del av kapitalkravet og forpliktelsene. Å ta imot innskudd er det tyngste du kan få tillatelse til; å være agent for noen som kan, er det letteste. De fleste fintech-apper for forbrukere – lommebøker, kort, overføringer, betalingslenker – hører hjemme i EMI- og betalingsforetaksnivået, eller bygger på en partner som har en av disse tillatelsene. Svært få trenger å være bank, og å vite det tidlig sparer deg for mye bortkastet innsats.
En rask måte å plassere seg selv på: Hvis kundene dine skal ha en saldo i appen – en lommebok de fyller på, et kort de forhåndslader – er du på e-pengeområdet, fordi det å oppbevare verdier er tillatelsen som definerer en EMI. Hvis pengene bare går gjennom – du initierer en overføring, krever inn en regning, sender en utbetaling rett videre – passer en tillatelse som betalingsforetak naturlig, enten du har den selv eller via en partner. Hvis du aldri berører midlene og bare presenterer informasjon om kontoer som holdes andre steder, finnes det en enda lettere registrering. Jo tyngre du plasserer deg, desto mer kapital og tilsyn følger med; målet er å ikke legge deg tyngre enn produktet faktisk krever.
Å leie tillatelsen: partnermodeller
Du trenger ikke å ha tillatelsen selv for å bygge på den. Den vanlige veien er å leie den. Med et sponsorbank- eller Banking-as-a-Service-opplegg har en lisensiert bank eller EMI kontoene, utsteder IBAN-er og kort og sikrer kundemidlene; du bygger appen mot deres API og leverer opplevelsen. Med en agentmodell registrerer du deg som agent for et betalingsforetak – eller som distributør for en e-pengeutsteder – og deres lisens dekker virksomheten din, slik at tilsynsmyndigheten kjenner deg gjennom dem. Ulike kontrakter, samme underliggende faktum: et sted i stacken sitter noen på tillatelsen. Spørsmålet er bare om det er du eller en partner.
Hvem bærer hvilket ansvar
Å leie en lisens betyr ikke at du leier bort ansvaret. Det lisensierte foretaket er det som svarer overfor tilsynsmyndigheten – for sikring av kundemidler, for overvåking mot hvitvasking, for hvordan hele programmet drives. Men disse forpliktelsene flyter nedover gjennom kontrakten. Bruker du en partners lisens, må du fortsatt kjøre KYC og onboarding, fortsatt overvåke transaksjoner for AML og fortsatt overholde grensene og rapporteringen partneren er bundet av. Ansvaret er ikke så mye outsourcet som fordelt: partneren har det overfor tilsynsmyndigheten, og har deg overfor en kontrakt som skyver mye av den daglige plikten tilbake på din side. Les den kontrakten like nøye som du ville lest lisensen du valgte å ikke skaffe.
En lisens er tillatelse til å holde eller flytte andres penger. Programvare er hvordan pengene instrueres, avstemmes og vises tilbake til kunden. Du kan kjøpe dem fra én leverandør eller fra to – men du kjøper alltid begge.
Programvaren og lisensen er separate kjøp
Dette er innsikten som stokker om på hele prosjektet. En betalingsapp ser ut som én ting for kunden, men er to ting smeltet sammen: den regulerte tillatelsen til å holde eller flytte penger, og programvaren som instruerer flyttingen, fører hovedboken, avstemmer innbetalingene og viser en saldo på en skjerm. Disse anskaffes hver for seg. Du kan ha din egen lisens og kjøpe programvaren; ha lisens og bygge programvaren selv; leie tillatelsen via en partner og kjøpe programvare oppå; eller ta begge deler fra én leverandør som har pakket dem sammen. Alle fire er normale. Det som ikke er normalt – og som i det stille koster prosjekter måneder – er å blande de to sammen: å lete etter en «banklisens» når du egentlig trengte en BaaS-partner pluss en app, eller å lete etter en app i den tro at tillatelsen følger med.
Å se dem som separate kjøp gir klarhet, fordi du kan prise og tidfeste dem uavhengig av hverandre. Programvaren kan vurderes på egne meritter – fungerer onboarding-flyten, er hovedboken korrekt, kan operatørene faktisk drifte løsningen – mens tillatelsen vurderes på jurisdiksjon, sikring av midler og vilkår. Protocore Pay (/products/pay) er et eksempel på selve programvarelaget: en whitelabel-plattform for apper og en operatørkonsoll som kjører oppå de regulerte skinnene du selv tar med. Den er ikke en lisens, og ingen programvare er det – og nettopp derfor forblir lisensen en egen linje i planen.
Spørsmål til enhver plattformleverandør
Uansett hvem som pitcher en «lanser din fintech»-plattform til deg, kutter den samme korte listen gjennom det meste av uklarheten. Inkluderer produktet deres en regulert tillatelse, eller må jeg ta med min egen? Hvis det inkluderer en, hvem sin lisens er det, i hvilke land, og er jeg direktekunde hos det foretaket eller hos dets agent? Hvem sikrer kundemidlene, og hvor oppbevares de? Hvem er oppgitt overfor tilsynsmyndigheten for hvitvasking – dere, partneren eller jeg? Hvilke forpliktelser havner hos meg gjennom kontrakten selv om lisensen ikke er min? Og hvis samarbeidet opphører, hva skjer med kundenes penger og data? Svarene sorterer raskt leverandørene i dem som selger programvare, dem som videreselger en partners tillatelse, og dem som faktisk har pakket begge deler sammen – og forteller deg hvilken av de tre du egentlig snakker med.
Det betryggende bildet: de fleste apper lanseres som programvare pluss en partners tillatelse, og går over til egen lisens først når volum, margin eller strategi gjør kapitalen og compliance-bemanningen verdt det. Å vite hvilket trinn du faktisk trenger – og at programvaren og tillatelsen kjøpes på separate linjer – er det meste av jobben. Resten er å stille spørsmålene over og lese svarene nøye. Ingenting av dette er juridisk rådgivning, og terskler og kategorinavn varierer fra jurisdiksjon til jurisdiksjon; bruk det som kartet du tar med deg i samtalen med en tilsynsmyndighet eller rådgiver, ikke som en erstatning for dem.
Har du et system som skal bygges?
Fortell oss problemet. Vi kommer tilbake med en arkitektur og en plan.