Heb je een bankvergunning nodig om een fintech-app te lanceren?

"Heb je een bankvergunning nodig om een fintech-app te lanceren?" zijn eigenlijk drie vragen in één jas. Houd je klantgeld vast? Verplaats je het? En wiens toezichthoudende toestemming dekt die beweging: de jouwe of die van een ander? Beantwoord die, en de vergunningsvraag beantwoordt zichzelf grotendeels. De korte versie die de meeste teams verrast: de meeste fintech-apps hebben nooit een bankvergunning, omdat ze nooit het ene doen waarvoor een bankvergunning bedoeld is. Wat volgt is een kaart van het spectrum, geen juridisch advies — het doel is te weten welke vragen je moet stellen voordat iemand je een doorlooptijd of een prijs noemt.

Waar een bankvergunning echt voor dient

Een volledige bankvergunning — in EU-termen een vergunning als kredietinstelling — staat één specifieke, streng bewaakte activiteit toe: deposito's van het publiek aantrekken en dat geld weer uitlenen. Die looptijdtransformatie, lange leningen financieren met saldi die klanten op elk moment kunnen opnemen, is waarom banken zware kapitaaleisen, verplichtingen voor depositogarantie en een toezichthouder hebben die hun balans regel voor regel leest. Als jouw app geen deposito's aantrekt en daartegen uitleent, kijk je vrijwel zeker niet naar een bankvergunning. Je kijkt dan naar iets lichters, verderop in het spectrum — en dat spectrum is het hele verhaal.

Het spectrum van vergunningen, van zwaar naar licht

Financiële vergunningen kennen niveaus. Bovenaan staat de kredietinstelling — de bank — die deposito's mag aanhouden en kredieten mag verstrekken. Daaronder kan een instelling voor elektronisch geld (EMI) e-geld uitgeven: ze mag klantwaarde bewaren en op kaarten of in wallets zetten, maar de float die ze aanhoudt moet worden beschermd — apart gehouden en onaangeroerd, nooit uitgeleend. Daaronder mag een betaalinstelling (PI) betalingen uitvoeren — overboekingen initiëren, incasseren, geld overmaken, kaarttransacties acquireren — maar ze is er niet voor gebouwd om waarde langdurig te bewaren; geld gaat erdoorheen, het blijft er niet staan. En onderaan heeft een agent of distributeur helemaal geen eigen vergunning, maar opereert onder de autorisatie van een vergunninghoudende entiteit die hem heeft geregistreerd.

Het patroon: met elke trede naar beneden valt een mogelijkheid weg, en daarmee ook een deel van het kapitaal en de verplichtingen. Deposito's aanhouden is het zwaarste wat je mag doen; de agent zijn van iemand die dat mag, het lichtste. De meeste fintechapps voor consumenten — wallets, kaarten, overboekingen, betaallinks — vallen onder EMI's en betaalinstellingen, of draaien op een partner die zo'n vergunning heeft. Heel weinig partijen hoeven een bank te zijn, en dat vroeg weten voorkomt veel verspilde moeite.

Een snelle manier om jezelf te plaatsen: als je klanten een saldo in de app aanhouden — een wallet die ze opwaarderen, een kaart die ze vooraf laden — zit je in het domein van e-geld, want het bewaren van waarde is de vergunning die een EMI definieert. Als geld er alleen doorheen gaat — je initieert een overboeking, incasseert een rekening, geeft een uitbetaling direct door — past een vergunning als betaalinstelling het best, gehouden door jou of door een partner. Raak je de gelden helemaal niet aan en toon je alleen informatie over elders aangehouden rekeningen, dan bestaat daar zelfs een lichtere registratie voor. Hoe zwaarder je zit, hoe meer kapitaal en toezicht erbij horen; het ontwerpdoel is om niet zwaarder te zitten dan het product echt vereist.

De vergunning huren: partnermodellen

Je hoeft de vergunning niet zelf te bezitten om erop te bouwen. De gangbare route is huren. Bij een sponsorbank- of Banking-as-a-Service-constructie houdt een bank of EMI met vergunning de rekeningen aan, geeft de IBAN's en kaarten uit en beschermt de float; jij bouwt de app op hun API en levert de ervaring. Bij een agentmodel registreer je je als agent van een betaalinstelling — of als distributeur van een e-geldwitgever — en dekt hun vergunning jouw activiteit, waarbij de toezichthouder je via hen kent. Andere contracten, hetzelfde onderliggende feit: ergens in de stack houdt iemand de vergunning. De enige vraag is of dat jij bent of een partner.

Wie draagt welke aansprakelijkheid

Een vergunning huren betekent niet dat je de verantwoordelijkheid kwijt bent. De vergunninghouder is degene die verantwoording aflegt aan de toezichthouder — voor de bescherming van klantgelden, voor de monitoring op witwassen, voor het gedrag van het hele programma. Maar die verplichtingen werken contractueel door naar beneden. Rijd je mee op de vergunning van een partner, dan doe je nog steeds KYC en onboarding, bewaak je nog steeds transacties voor AML en houd je je aan de limieten en rapportages waaraan de partner gebonden is. Aansprakelijkheid wordt niet zozeer uitbesteed als wel verdeeld: de partner draagt haar richting de toezichthouder en legt jou via een contract een groot deel van de dagelijkse plicht weer op. Lees dat contract even zorgvuldig als je de vergunning zou lezen die je liever niet haalde.

Een vergunning is toestemming om het geld van anderen aan te houden of te verplaatsen. Software is hoe dat geld wordt aangestuurd, afgestemd en aan de klant teruggetoond. Je kunt ze bij één leverancier kopen of bij twee — maar je koopt altijd beide.

Software en vergunning koop je apart

Dit inzicht schudt het hele project door elkaar. Een betaalapp lijkt voor de klant één ding, maar het zijn twee dingen die aaneengesmolten zijn: de gereguleerde toestemming om geld aan te houden of te verplaatsen, en de software die de beweging aanstuurt, het grootboek bijhoudt, de bijschrijvingen afstemt en een saldo op een scherm toont. Die twee haal je apart in. Je kunt een eigen vergunning hebben en de software kopen; een vergunning hebben en de software zelf bouwen; de vergunning via een partner huren en er software bovenop kopen; of beide afnemen bij één leverancier die ze heeft gebundeld. Alle vier zijn normaal. Wat niet normaal is — en projecten stilletjes maanden kost — is de twee verwarren: op zoek gaan naar een “bankvergunning” terwijl je een BaaS-partner plus een app nodig had, of een app kiezen in de veronderstelling dat de vergunning er vast aan zit.

De twee als aparte aankopen zien geeft helderheid, omdat je ze los van elkaar kunt prijzen en plannen. De software beoordeel je op haar merites — werkt de onboardingflow, klopt het grootboek, kunnen operators het systeem echt draaien — terwijl de vergunning wordt beoordeeld op jurisdictie, safeguarding en voorwaarden. Protocore Pay (/products/pay) is een voorbeeld van de softwarelaag op zichzelf: een whitelabel appplatform met operatorconsole dat draait op welke gereguleerde rails je ook meebrengt. Het is geen vergunning, en geen enkele software is dat — precies daarom blijft de vergunning een aparte regel in het plan.

Vragen voor elke platformleverancier

Wie je ook een “start je fintech”-platform aanprijst, dezelfde korte lijst snijdt door de meeste onduidelijkheid heen. Zit er in jullie product een gereguleerde vergunning, of breng ik die zelf mee? Zo ja, van wie is die vergunning, in welke landen, en ben ik rechtstreeks klant van die entiteit of van haar agent? Wie beschermt de klantgelden, en waar staan ze? Wie staat bij de toezichthouder te boek voor antiwitwas — jullie, de partner of ik? Welke verplichtingen komen contractueel bij mij te liggen terwijl de vergunning niet van mij is? En als de samenwerking eindigt, wat gebeurt er dan met het geld en de data van mijn klanten? De antwoorden sorteren leveranciers snel in wie software verkoopt, wie de vergunning van een partner doorverkoopt en wie echt beide heeft gebundeld — en laten zien met welke van de drie je praat.

Het geruststellende aan dit alles: de meeste apps starten als software plus de vergunning van een partner, en stappen pas over op een eigen vergunning als volume, marge of strategie het kapitaal en de compliance-bezetting de moeite waard maken. Weten welke trede je echt nodig hebt — en dat software en vergunning op aparte regels worden ingekocht — is het grootste deel van de strijd. De rest is de bovenstaande vragen stellen en de antwoorden goed lezen. Niets hiervan is juridisch advies, en drempels en categorienamen verschillen per jurisdictie; zie het als de kaart die je meeneemt naar het gesprek met een toezichthouder of adviseur, niet als vervanging daarvan.