Fältanteckningar

Behöver du bankinstitutstillstånd för att lansera en fintech-app?

”Behöver du banktillstånd för att lansera en fintech-app?” är egentligen tre frågor i en och samma rock. Håller du kundernas pengar? Flyttar du dem? Och vems regulatoriska tillstånd täcker den förflyttningen — ditt eget eller någon annans? Svara på de frågorna så svarar licensfrågan till stor del på sig själv. Den korta versionen, som överraskar de flesta team: majoriteten av fintech-appar har aldrig ett banktillstånd, eftersom majoriteten av fintech-appar aldrig gör det enda som ett banktillstånd faktiskt är till för. Det som följer är en karta över spektrumet, inte juridisk rådgivning — målet är att veta vilka frågor du ska ställa innan någon ger dig en tidplan eller ett pris.

Vad ett banktillstånd egentligen är till för

Ett fullständigt banktillstånd — i EU-termer ett auktorisationstillstånd som kreditinstitut — tillåter en specifik, hårt bevakad verksamhet: att ta emot insättningar från allmänheten och låna ut pengarna igen. Den löptidsobalansen, att finansiera långa lån med saldon som kunderna kan ta ut när som helst, är skälet till att banker bär tunga kapitalkrav, insättningsgarantiåtaganden och en tillsynsmyndighet som läser balansräkningen rad för rad. Om din app inte tar emot insättningar och lånar ut mot dem är det nästan säkert inte ett banktillstånd du tittar på. Du tittar på något lättare, längre ner i spektrumet — och spektrumet är hela historien.

Tillståndsspektrumet, från tyngst till lättast

Finansiella tillstånd är indelade i nivåer. Överst står kreditinstitutet – banken – som kan ta emot insättningar och låna ut. Under det kommer e-pengainstitutet (EMI), som får ge ut e-pengar: det kan lagra kundens värde och lägga det på kort eller i plånböcker, men de medel det håller måste skyddas – hållas avskilda och orörda, aldrig utlånade. Därunder finns betalningsinstitutet (PI), som får utföra betalningar – initiera överföringar, inkassera, förmedla pengar, förvärva korttransaktioner – men som inte är byggt för att lagra värde över tid; pengarna passerar, de blir inte liggande. Och längst ner har ombudet eller distributören inget eget tillstånd alls, utan verkar under ett licensierat företags tillstånd, det företag som har registrerat det.

Mönstret är att varje steg nedåt tar bort en förmåga och med den en del av kapitalkravet och ansvaret. Att ta emot insättningar är det tyngsta man kan få tillstånd till; att vara ombud för någon som får det är det lättaste. De flesta fintechappar för konsumenter – plånböcker, kort, överföringar, betallänkar – hör hemma i spannet mellan e-pengainstitut och betalningsinstitut, eller bygger ovanpå en partner som har något av de tillstånden. Mycket få behöver vara bank, och att veta det tidigt sparar en hel del felriktad möda.

Ett snabbt sätt att placera sig: om kunderna ska ha ett saldo i appen – en plånbok de fyller på, ett kort de laddar i förväg – befinner du dig på e-pengaområdet, eftersom lagring av värde är det som definierar ett EMI. Om pengarna bara passerar – du initierar en överföring, driver in en faktura, för en utbetalning direkt vidare – passar ett tillstånd som betalningsinstitut naturligt, innehaft av dig eller av en partner. Rör du aldrig medlen utan bara visar information om konton som finns någon annanstans har även det en egen, lättare registrering. Ju tyngre du placerar dig, desto mer kapital och tillsyn följer med; målet är att placera sig inte tyngre än produkten faktiskt kräver.

Hyra tillståndet: partnermodeller

Du behöver inte ha tillståndet själv för att bygga på det. Det vanliga är att hyra det. I en sponsorbank- eller Banking-as-a-Service-lösning har en licensierad bank eller ett EMI kontona, utfärdar IBAN och kort och skyddar kundmedlen; du bygger appen mot deras API och levererar upplevelsen. I en agentmodell registrerar du dig som ombud för ett betalningsinstitut – eller som distributör för en utgivare av e-pengar – och deras licens täcker din verksamhet, med tillsynsmyndigheten medveten om dig genom dem. Olika avtal, samma grundfakta: någonstans i kedjan innehar någon tillståndet. Frågan är bara om den någon är du eller en partner.

Vem bär vilket ansvar

Att hyra en licens innebär inte att man hyr bort ansvaret. Det licensierade bolaget svarar inför tillsynsmyndigheten – för skydd av kundmedel, för penningtvättsövervakning, för hur hela programmet bedrivs. Men de skyldigheterna rinner nedåt genom avtal. Åker du med på en partners licens kör du fortfarande KYC och onboarding, bevakar fortfarande transaktioner för AML och håller dig till de gränser och den rapportering som partnern är bunden av. Ansvaret läggs inte så mycket ut som fördelas: partnern svarar för det inför tillsynsmyndigheten och håller dig ansvarig genom ett avtal som skjuter över mycket av det dagliga arbetet på din sida. Läs det avtalet lika noga som du skulle läsa den licens du valde att inte skaffa.

En licens är tillståndet att hålla eller flytta andras pengar. Mjukvara är hur pengarna instrueras, stäms av och visas för kunden. Du kan köpa dem från en leverantör eller från två – men du köper alltid båda.
— Protocore · Betalningsteknik

Mjukvaran och licensen är två separata inköp

Det är insikten som ordnar om hela projektet. En betalapp ser ut som en enda sak för kunden, men är i själva verket två sammanfogade: det reglerade tillståndet att hålla eller flytta pengar, och mjukvaran som instruerar flytten, för huvudboken, stämmer av krediteringarna och visar ett saldo på en skärm. De två anskaffas var för sig. Du kan ha en egen licens och köpa mjukvaran; ha en licens och bygga mjukvaran internt; hyra tillståndet via en partner och köpa mjukvara ovanpå; eller få båda från en enda leverantör som har paketerat dem. Alla fyra är normala. Det som inte är normalt – och som i tysthet kostar projekt månader – är att blanda ihop de två: att leta efter en ”banklicens” när det man behövde var en BaaS-partner plus en app, eller att köpa en app i tron att tillståndet följer med.

Att se dem som separata inköp skapar klarhet eftersom du då kan prissätta och tidsplanera dem var för sig. Mjukvaran kan bedömas på sina meriter – fungerar onboardingflödet, stämmer huvudboken, kan operatörerna faktiskt driva systemet – medan tillståndet bedöms utifrån jurisdiktion, skydd av kundmedel och villkor. Protocore Pay (/products/pay) är ett exempel på själva mjukvarulagret: en whitelabel-appplattform och operatörskonsol som körs ovanpå den reglerade infrastruktur du själv tar med. Den är ingen licens, och ingen mjukvara är det – just därför förblir licensen en separat rad i planen.

Frågor att ställa till alla plattformsleverantörer

Vem som än pitchar en plattform för att ”lansera din fintech” räcker samma korta lista långt för att reda ut det mesta som är oklart. Ingår ett reglerat tillstånd i er produkt, eller tar jag med mitt eget? Om det ingår, vems licens är det, i vilka länder, och är jag direktkund hos det företaget eller hos dess ombud? Vem skyddar kundmedlen, och var förvaras de? Vem är angiven mot tillsynsmyndigheten för penningtvätt – ni, partnern eller jag? Vilka skyldigheter faller på mig genom avtal trots att licensen inte är min? Och om samarbetet upphör, vad händer med mina kunders pengar och data? Svaren sorterar snabbt leverantörer i dem som säljer mjukvara, dem som säljer vidare en partners tillstånd och dem som verkligen har paketerat båda – och visar vilken av de tre du faktiskt pratar med.

Det lugnande i det hela: de flesta appar lanseras som mjukvara plus en partners tillstånd, och går över till en egen licens först när volym, marginal eller strategi gör kapitalet och compliance-bemanningen värda det. Att veta vilken nivå du verkligen behöver – och att mjukvaran och tillståndet köps på separata rader – är det mesta av jobbet. Resten är att ställa frågorna ovan och läsa svaren noga. Inget av detta är juridisk rådgivning, och gränsvärden och kategorinamn varierar mellan jurisdiktioner; se det som kartan du tar med dig till samtalet med en tillsynsmyndighet eller en rådgivare, inte som en ersättning för någon av dem.

Har du ett system att bygga?

Berätta vad problemet är. Vi återkommer med en arkitektur och en plan.