Köparguide till whitelabel-plattformar för neobanker

En whitelabel-plattform för neobanker är mjukvara du sätter ditt varumärke på för att lansera en bankliknande app – konton, kort, överföringar, ibland krypto – utan att bygga kärnan från grunden. Att köpa en sådan är egentligen att köpa två saker som lätt förväxlas med en: kärnan som flyttar pengarna och applagret som dina kunder ser. Det här är en guide till hur du skiljer dem åt innan du skriver under, eftersom nästan varje svår fråga om en whitelabel-plattform visar sig handla om var dess skarvar sitter – och en leverantörs uppgift är att sudda ut den gränsen medan en köpares uppgift är att hitta den.

Det finns fem snitt värda att göra innan du binder dig: kärna mot applager, var licensen sitter, hur djupt designsystemet går, fristående mot inbäddad leverans, och valet mellan bygga och köpa som ligger under allt. Ta dem i ordning.

Första snittet: kärnan mot applagret

Den mest användbara gränsen att dra går mellan det som måste vara korrekt och det som måste vara ditt. Kärnan är dyr att göra fel: en huvudbok med dubbel bokföring, konton och saldon, KYC och onboarding, kortutgivning och kortprocessing, krypto- och stablecoin-rails samt operatörskonsolen bakom allt. Applagret är det kunden rör vid: varumärket, skärmarna, informationsarkitekturen, den delmängd funktioner som är påslagna. En plattform värd att köpa delar en kärna över alla varumärken och konfigurerar appen per tenant. Bedöm de två på olika axlar – bedöm kärnan på korrekthet, om huvudboken är äkta dubbel bokföring, om avstämningen håller och om operatörer faktiskt kan driva den; bedöm applagret på flexibilitet, hur långt ett varumärke kan avvika innan någon måste forka.

Var licensen sitter – och om den går att skilja ut

Tillståndet att hålla eller flytta pengar är reglerat och är inte samma inköp som mjukvaran. Fråga rakt ut om plattformen inkluderar ett reglerat tillstånd eller förväntar sig att du tar med ditt eget – och om den inkluderar ett, vems licens det är, i vilka länder, och om du är dess direkta kund eller dess ombud. Separation är det som räknas för en köpare: en plattform som svetsar fast sin mjukvara vid en enda licens du inte kan byta ut har i tysthet valt din jurisdiktion och din partner åt dig, medan en plattform som behandlar licensen som en rail du tar med dig låter dig välja tillstånd oberoende och byta senare. Ingetdera är fel, men du måste veta vilket du köper. Protocore Pay (/products/pay) är enbart mjukvarulagret – det körs ovanpå de reglerade rails du själv tar med, och ingen mjukvara är en licens. Begreppen du möter i det samtalet – EMI, betalningsinstitut, ombud, sponsorbank – förklaras i /glossary.

Hur djupt designsystemet går

Hela löftet med whitelabel är att appen ser ut som din, inte som en ommålad version av leverantörens demo – och löftet är bara så djupt som designsystemet under det. Ett ytligt system låter dig byta logotyp och accentfärg. Ett djupt system exponerar det faktiska vokabuläret – färg, typografi, hörnradie, avstånd, täthet, rörelse – som tokens varje skärm läser, så att ett varumärke blir en uppsättning överskrivningar i stället för en fork. Fråga hur många tokens det finns och vad de täcker, om samma tokens exporteras till webb, native och desktop så att en färg betyder en färg överallt, och om en designer kan föra en tenant långt från referensbygget utan att röra kod. Designsystemet från Protocore (/products/pds) är ett levererat svar – 144 tokens och 889 utility-klasser, dark-first, hörnradie noll som standard, exporterat för webb, .NET och native – men köparens fråga är den allmänna: är designlagret ett riktigt tokensystem, eller ett lager färg på en fast app?

Fristående app eller inbäddat lager

Leveransen finns i två former. En fristående app är en komplett bankapp du märker upp och lanserar under eget namn – dina kunder laddar ner din bank. Ett inbäddat lager är en uppsättning komponenter och flöden du lägger in i en produkt du redan har – betalningar och saldon som lever i din befintliga app. Valet handlar inte om kvalitet utan om var pengaupplevelsen hör hemma. Är bankverksamhet din produkt vill du ha det fristående bygget. Är bankverksamhet en funktion i en större produkt – en marknadsplats som betalar ut till sina säljare, en plattform som ger sina användare en plånbok – vill du ha den inbäddade vägen, så att pengarna finns där dina kunder redan är. En plattform värd att köpa klarar båda från en kärna, eftersom kärnan inte bryr sig om dess frontend är en fristående app eller en panel i någon annans.

Bygga eller köpa, ärligt uttryckt

Att bygga kärnan själv ger kontroll och kostar år. En korrekt huvudbok, kortprocessing, KYC, avstämning och en operatörskonsol är var och en ett projekt, och alla är basförutsättningar du måste klara innan du lanserat en enda funktion som en kund märker. Att köpa kärnan köper tillbaka de åren och kostar viss suveränitet – du ärver någon annans modell av ett konto, en gräns, en avveckling. Det ärliga sättet att avgöra är att fråga vilka delar som är din produkt och vilka som är rörmokeri. Rörmokeriet – avveckling, avstämning, compliance-verktyg – är ungefär detsamma för alla och sällan där du vinner; köp det. Delarna som kunderna faktiskt väljer dig för – flödena, varumärket, det enda du gör bättre än etablerade aktörer – är där dina egna utvecklare ska lägga sina liv. Att köpa en plattform är ett vad på att kärnan är rörmokeri och att din särart ligger ovanför.

Du köper aldrig en neobank. Du köper en kärna du hoppas är rörmokeri och ett applager du tänker göra till ditt eget – och hela utvärderingen går ut på att avgöra om leverantören drog den gränsen där du själv hade dragit den.

Fem riktningar, inte fem produkter

Be en leverantör om exempel och du får ofta se en handfull färdiga appar. Läs dem rätt: de är riktningar samma kärna kan ta, inte en meny där du väljer en sak. Ett plattformsreferensbygge kan driva en ren börs (Halcyon – återhållen, handeln i fokus), en chattcentrerad superapp (Lumen – pengar som rör sig inne i konversationen), en överföringsledd app (Fern – batchutbetalningar och regelstyrd växling först), ett stablecoin-mörkt bygge (Volt – en lönefördelare och teamkort) och ett flervalutakonto (Meridian – ett EUR-saldo bredvid USDC och ett BTC-konto där kortbonusar landar). Fem varumärken, fem informationsarkitekturer, fem funktionsmixar – en huvudbok, en KYC, en kortprocessor under varje av dem. Siffran som spelar roll är inte fem; det är hur många tenants kärnan kan bära. En leverantör som säger att produkten är fem appar har missförstått sin egen produkt; en leverantör som visar fem för att bevisa att den sjätte är trivial förstår den.

Frågorna som skiljer leverantörerna åt

En kort lista tar död på de flesta säljpresentationer. Är kärnan ett gemensamt system eller en fork per kund – och när en bugg åtgärdas, når rättningen alla tenants samtidigt? Exponerar designlagret riktiga tokens, eller bara en logotypplats? Ingår ett reglerat tillstånd i plattformen, eller måste jag ta med ett eget – och kan jag byta ut det senare? Kan samma kärna leverera både en fristående app och ett inbäddat lager? Vilka delar betraktar ni som rörledningar, och vilka förväntar ni er att jag bygger själv? Svaren placerar leverantören på den karta som den här guiden har ritat upp: gemensam kärna eller forkfarm, tokensystem eller ytlackering, mjukvara plus mitt eget tillstånd eller ett hopsvetsat paket, en leveransform eller två. Den fullständiga genomgången av en sådan kärna – de fem riktningarna, referensappen och operatörskonsolen bakom dem – finns på /products/pay, designsystemet under ytan finns på /products/pds, och begreppen finns i /glossary.