Eén core, vele apps: zo werkt een whitelabel bankplatform

Een whitelabel bankplatform is één bankcore met een verwisselbare front end. De core moet kloppen: een dubbelboekhoudkundig grootboek, klantrekeningen, KYC en onboarding, cards issuing en processing, crypto- en stablecoin-rails, en de operatorconsole die achter alles draait. De app is wat de klant ziet: naam, kleuren, vorm van de schermen, de subset aan features die aanstaat. Whitelabel betekent dat één core vele gezichten kan dragen zonder onder elk daarvan opnieuw gebouwd te worden. Eén core, vele apps.

Eenvoudig gezegd is dat een uitspraak over waar de naden zitten. Alles wat met geld te maken heeft, wordt één keer gedeeld, geaudit en gereconcilieerd; alles wat de klant raakt, wordt per tenant geconfigureerd. Het engineeringwerk is die grens eerlijk houden: de front end vrij laten verschillen terwijl de core eronder nooit forkt. Dit is een teardown van hoe die grens wordt getrokken, en waarom het met design tokens beter gaat dan met een fork.

Wat nooit varieert: de core

Begin met de helft die niet creatief mag zijn. Een overboeking wordt altijd op dezelfde manier geboekt, of de app het nu een verzending, een betaling of een uitbetaling noemt: twee boekingen in een dubbelboekhoudkundig grootboek, en er wordt nooit iets verwijderd. Het grootboek voegt alleen toe, dus een terugbetaling is een tegenboeking die naar het origineel verwijst, geen wissing. Rekeningen, saldi en autorisatieblokkades leven hier. Net als KYC en onboarding, card issuing en settlement, en de crypto- en stablecoin-rails. Erachter zit één operatorconsole waarin elke bevoegde actie een reden vereist en in een auditlog belandt.

Van elk van deze is er precies één, en dat is de bedoeling. Settlement, reconciliatie en compliance zijn lastig goed te doen en duur om fout te doen, dus je bouwt ze één keer en laat elke app het resultaat erven. Wanneer een tenant een klant onboardt, volgt het KYC-niveau dat de core bepaalt die klant de console in, ongeacht via welke app-schermen de documenten zijn vastgelegd. De core weet niet en maakt niet uit hoe de app erboven heet: hij ziet rekeningen en boekingen, geen merken.

Wat varieert: designtaal, informatiearchitectuur, featuremix

Alles boven de core mag vrij bewegen, langs drie assen. De eerste is designtaal: kleur, typografie, hoekradius, spacing, motion — de visuele grammatica van het merk. De tweede is informatiearchitectuur: wat op het homescherm staat, hoe flows heten en gerangschikt zijn, welke actie één tik verwijderd is en welke drie. De derde is featuremix: welke modules überhaupt aanstaan. Een slanke transfer-app en een rijke super-app kunnen op dezelfde core draaien en geen enkel scherm delen.

De productpagina op /products/pay beschrijft vijf uitgewerkte richtingen, en die lees je het best als voorbeelden uit oneindig veel mogelijkheden, niet als een menu van vijf. Halcyon is een strakke exchange: ingetogen, weinig schermen, de trade centraal. Lumen is een super-app waarin geld binnen het gesprek beweegt en chatbetalingen, abonnementen en earn het homescherm delen. Fern zet transfers voorop: batchuitbetalingen en regelgebaseerde FX-conversie eerst. Volt is een stablecoin-dark build met een salarisverdeler en teamkaarten. Meridian is multi-currency: een EUR-rekening naast USDC, een GBP-reissaldo en een BTC-rekening waar kaartrewards op landen. Vijf merken, vijf informatiearchitecturen, vijf featuremixen — met eronder één grootboek, één KYC, één cardprocessor.

Dat betekent niet dat het product uit vijf apps bestaat. De vijf zijn richtingen die dezelfde pipeline kan nemen; het getal dat telt is niet vijf, maar het aantal tenants dat je onboardt. Elk is het bewijs dat de front end kan verschillen tot aan de vorm van het homescherm, terwijl de core eronder er niets van merkt.

De core mag je niet opnieuw uitvinden; de app mag je niet beperken. Een whitelabelplatform is de discipline om beide zinnen tegelijk waar te houden.

Waarom token-theming het wint van het forken van de codebase

Er zijn twee manieren om één product op vele te laten lijken. De voor de hand liggende is forken: de codebase per klant kopiëren, restylen, uitrollen. Dat werkt precies één release. Daarna moet elke bugfix en elke regelwijziging N keer worden doorgevoerd in N uit elkaar groeiende kopieën, lopen de kopieën uit de pas en vermenigvuldigt het beveiligingsoppervlak zich met het aantal klanten. Forken verandert één systeem dat je begrijpt in vele die je niet begrijpt.

Token-theming draait dat om. Er is één codebase. Een merk is een set waarden — tokens voor kleur, type, radius en spacing, een componentconfiguratie, een set feature flags — die bij de build wordt omgezet in een app met eigen merk. Wijzig een token en elk scherm dat het gebruikt, beweegt mee, omdat niets een waarde hardcodeert die uit een token hoort te komen. Een fix in de transferflow gaat in één keer naar elke tenant, omdat er maar één transferflow is om te fixen. De merken verschillen in configuratie, niet in broncode.

Waar het design system past

De tokens zijn geen los idee; ze zijn een opgeleverd artefact. Het Protocore Design System — /products/pds — telt 144 design tokens en 889 utility classes: het vocabulaire waarin elke app wordt gethemed. Het is dark-first, token-driven en standaard radius nul, en dezelfde tokenset wordt uitgegeven voor web, .NET en native, zodat een kleur die je één keer definieert in een React-scherm, een desktopconsole en een native mobiele build dezelfde kleur is. Het merk van een tenant wordt uitgedrukt als overrides op dat vocabulaire, daarom is een app van een nieuwe skin voorzien een configuratiewijziging en geen rewrite.

Dat maakt de front end ook echt vrij, in plaats van vrij binnen een template. Doordat de designtaal in tokens en utility classes leeft in plaats van in losse stylesheets, kan een designer een tenant ver van de referentiebuild afbrengen — eigen palet, type, dichtheid en ritme — zonder de core aan te raken of de app te forken. De verf gaat diep, maar blijft verf; het leidingwerk eronder is gedeeld.

De app is een configuratie, geen build

Voor de featuremix geldt dezelfde regel. Elke module — chatbetalingen, earn, crypto, kaarten, abonnementen, teamkaarten, referrals — is een schakelaar per tenant, en een flag kan eerst naar een deel van de gebruikers uitrollen voordat hij breed live gaat. Operators zetten ze om vanuit een configuratiepaneel, niet via een deploy. Het verschil tussen een kale transfer-app en een volledige super-app zijn dus geen twee projecten, maar twee configuraties van één project. De referentie-app waarmee elke tenant begint, is een neutrale build met Protocore-branding en het volledige menu; elke whitelabel is die build met overschreven tokens en modules die aan of uit staan.

De eerlijke grens

Eén core, vele apps is de machinerie alleen waard als je echt vele apps hebt, of één app die je in de loop der tijd wilt restylen, herordenen en herafbakenen zonder telkens de bank opnieuw te bouwen. Lever je één vaste app die nooit een tweede merk draagt, dan heb je geen whitelabelplatform nodig; dan heb je een app nodig. Het verdient zichzelf terug in het geval waarvoor het is gebouwd: een platform dat tenant na tenant bankproducten met eigen merk neerzet, elk zichtbaar zijn eigen product, geen enkele een fork. De volledige teardown — de vijf richtingen, de referentie-app en de operatorconsole erachter — staat op /products/pay, en het design system eronder op /products/pds.