Feltnotater

Kjøperguide til whitelabel-neobankplattformer

En whitelabel-neobankplattform er programvare du setter ditt eget merke på for å lansere en bankliknende app — kontoer, kort, overføringer, noen ganger krypto — uten å bygge kjernen fra bunnen. Å kjøpe en slik plattform er egentlig å kjøpe to ting som lett forveksles med én: kjernen som flytter penger, og applaget kundene dine ser. Dette er en guide til å skille dem før du signerer, for nesten alle vanskelige spørsmål om en whitelabel-plattform handler til slutt om hvor skjøtene ligger — og leverandørens jobb er å viske ut den linjen, mens kjøperens jobb er å finne den.

Det er fem snitt som er verdt å gjøre før du forplikter deg: kjerne versus applag, hvor lisensen ligger, hvor dypt designsystemet går, frittstående versus innebygd levering, og valget mellom bygg og kjøp under det hele. Ta dem i rekkefølge.

Første snitt: kjernen versus applaget

Den mest nyttige linjen å trekke går mellom delen som må være korrekt og delen som må være din. Kjernen er dyr å gjøre feil: en hovedbok med dobbelt bokholderi, kontoer og saldoer, KYC og onboarding, kortutstedelse og -prosessering, krypto- og stablecoin-rails og operatørkonsollen bak alt sammen. Applaget er det kunden berører: merkevaren, skjermbildene, informasjonsarkitekturen, utvalget av funksjoner som er slått på. En plattform som er verdt å kjøpe, deler én kjerne på tvers av alle merkevarer og konfigurerer appen per tenant. Vurder de to etter ulike akser — bedøm kjernen på korrekthet: om hovedboken er ekte dobbelt bokholderi, om avstemmingen holder, om operatørene faktisk kan drifte den; bedøm applaget på fleksibilitet: hvor langt en merkevare kan avvike før noen må forke.

Hvor lisensen ligger — og om den kan skilles ut

Tillatelsen til å holde eller flytte penger er regulert, og den er ikke samme kjøp som programvaren. Spør rett ut om plattformen inkluderer en regulert tillatelse eller forventer at du tar med din egen — og hvis den inkluderer en, hvem sin lisens det er, i hvilke land, og om du er direkte kunde eller agent. Separasjon er det som teller for en kjøper: en plattform som sveiser programvaren fast til én lisens du ikke kan bytte, har i det stille valgt jurisdiksjon og partner for deg, mens en plattform som behandler lisensen som en rail du tar med, lar deg velge tillatelsen uavhengig og bytte den senere. Ingen av delene er galt, men du må vite hva du kjøper. Protocore Pay (/products/pay) er programvarelaget alene — det kjører oppå de regulerte railene du tar med, og ingen programvare er en lisens. Begrepene du møter i den samtalen — EMI, betalingsforetak, agent, sponsorbank — er forklart i /glossary.

Hvor dypt designsystemet går

Hele løftet med whitelabel er at appen ser ut som din, ikke som en ny drakt på leverandørens demo — og løftet er bare så dypt som designsystemet under det. Et grunt system lar deg bytte logo og aksentfarge. Et dypt system eksponerer det faktiske vokabularet — farge, typografi, hjørneradius, avstand, tetthet, bevegelse — som tokens hver skjerm leser, slik at en merkevare er et sett overstyringer og ikke en fork. Spør hvor mange tokens det finnes og hva de dekker, om de samme tokenene emitteres til web, native og desktop slik at en farge betyr én farge overalt, og om en designer kan flytte en tenant langt fra referansebygget uten å røre kode. Designsystemet til Protocore (/products/pds) er ett levert svar — 144 tokens og 889 utility-klasser, dark-first, radius null som standard, emittert for web, .NET og native — men kjøperens spørsmål er det generelle: er designlaget et ekte tokensystem, eller et malingslag over en fast app?

Frittstående app eller innebygd lag

Levering kommer i to former. En frittstående app er en hel bankapp du merker og sender ut under eget navn — kundene dine laster ned banken din. Et innebygd lag er et sett komponenter og flyter du slipper inn i et produkt du allerede har — betalinger og saldoer som lever i den eksisterende appen din. Valget handler ikke om kvalitet, men om hvor pengeopplevelsen hører hjemme. Hvis bank er produktet ditt, vil du ha den frittstående løsningen. Hvis bank er en funksjon i et større produkt — en markedsplass som betaler selgerne sine, en plattform som gir brukerne en lommebok — vil du ha den innebygde veien, slik at pengene bor der kundene dine allerede er. En plattform som er verdt å kjøpe, kan gjøre begge deler fra én kjerne, fordi kjernen ikke bryr seg om frontenden er en frittstående app eller et panel inne i en annens.

Bygg eller kjøp, ærlig sagt

Å bygge kjernen selv gir kontroll og koster år. En korrekt hovedbok, kortprosessering, KYC, avstemming og en operatørkonsoll er hver for seg et prosjekt, og alle er minstekrav du må klare før du har levert én eneste funksjon kundene merker. Å kjøpe kjernen kjøper de årene tilbake og koster deg noe suverenitet — du arver en annens modell av en konto, en grense, et oppgjør. Den ærlige måten å avgjøre på er å spørre hvilke deler som er produktet ditt og hvilke som er rørleggerarbeid. Rørleggerarbeidet — oppgjør, avstemming, compliance-verktøy — er stort sett likt for alle og sjelden der du vinner; kjøp det. Delene kundene faktisk velger deg for — flytene, merkevaren, den ene tingen du gjør bedre enn de etablerte — er der dine egne utviklere bør bruke livet. Å kjøpe en plattform er et veddemål på at kjernen er rørleggerarbeid og at det som skiller deg ut, ligger over den.

Du kjøper aldri en neobank. Du kjøper en kjerne du håper er rørleggerarbeid og et applag du har tenkt å gjøre til ditt eget — og hele evalueringen går ut på å avgjøre om leverandøren trakk den linjen der du selv ville trukket den.
— Protocore · Plattformutvikling

Fem retninger, ikke fem produkter

Be en leverandør om eksempler, så får du ofte se en håndfull ferdige apper. Les dem riktig: de er retninger den samme kjernen kan ta, ikke en meny du velger ett punkt fra. Én plattforms referansekjerne kan ligge bak en ren børs (Halcyon — avdempet, handelen i front), en chat-først superapp (Lumen — penger som flyttes midt i samtalen), en overføringsdrevet app (Fern — masseutbetalinger og regelstyrt konvertering først), et mørkt stablecoin-bygg (Volt — en lønnssorterer og teamkort) og en flervalutakonto (Meridian — en EUR-saldo ved siden av USDC, og en BTC-konto der kortbonuser lander). Fem merkevarer, fem informasjonsarkitekturer, fem funksjonsmikser — én hovedbok, én KYC, én kortprosessor under hver av dem. Tallet som betyr noe, er ikke fem; det er så mange tenants kjernen kan bære. En leverandør som sier at produktet er fem apper, har misforstått sitt eget produkt; en leverandør som viser deg fem for å bevise at den sjette er triviell, forstår det.

Spørsmålene som skiller leverandørene

En kort liste kutter gjennom de fleste salgspresentasjoner. Er kjernen ett felles system, eller en fork per kunde – og når en feil rettes, når rettelsen alle tenants samtidig? Eksponerer designlaget ekte tokens, eller bare en logoplass? Inkluderer plattformen en regulert tillatelse, eller må jeg ta med min egen – og kan jeg bytte den ut senere? Kan den samme kjernen levere både en frittstående app og et innebygd lag? Hvilke deler regner dere som infrastruktur, og hvilke forventer dere at jeg bygger selv? Svarene plasserer en leverandør på kartet denne guiden har tegnet: felles kjerne eller fork-farm, tokensystem eller maling, programvare pluss min egen lisens eller en sammensveiset pakke, én leveranseform eller to. Den fullstendige gjennomgangen av én slik kjerne – de fem retningene, referanseappen og operatørkonsollen bak dem – finner du på /products/pay, designsystemet under ligger på /products/pds, og begrepene står i /glossary.

Har du et system som skal bygges?

Fortell oss problemet. Vi kommer tilbake med en arkitektur og en plan.