Ein Core, viele Apps: So funktioniert eine Whitelabel-Banking-Plattform

Eine Whitelabel-Banking-Plattform ist ein Banking-Core mit austauschbarem Frontend. Der Core ist der Teil, der korrekt sein muss: ein doppeltes Hauptbuch (Double-Entry-Ledger), Kundenkonten, KYC und Onboarding, Kartenausgabe und -verarbeitung, Krypto- und Stablecoin-Schienen sowie die Operator-Konsole, die hinter alldem läuft. Die App ist der Teil, den der Kunde sieht – ihr Name, ihre Farben, die Form ihrer Screens, die Auswahl der aktivierten Funktionen. Whitelabel heißt: Ein Core kann viele Gesichter tragen, ohne für jedes neu gebaut zu werden. Ein Core, viele Apps.

Klar gesagt, ist das eine Aussage darüber, wo die Nahtstellen liegen. Alles, was mit Geld zu tun hat, wird einmal geteilt, geprüft und abgestimmt; alles, was den Kunden betrifft, wird pro Mandant konfiguriert. Die eigentliche Ingenieursarbeit besteht darin, diese Linie sauber zu halten – das Frontend darf sich frei unterscheiden, während der Core, auf dem es steht, sich nie verzweigt. Dies ist eine Analyse, wie die Linie gezogen wird und warum Design-Tokens dafür besser taugen als ein Fork.

Was nie variiert: der Core

Beginnen wir mit der Hälfte, die nicht kreativ sein darf. Eine Überweisung wird immer gleich gebucht, egal ob die App sie „Senden“, „Zahlung“ oder „Auszahlung“ nennt: zwei Buchungen in einem Double-Entry-Ledger, und nichts wird je gelöscht – das Ledger kennt nur Ergänzungen, eine Erstattung ist also eine Gegenbuchung mit Verweis auf das Original, keine Löschung. Konten, Salden und Autorisierungsreservierungen liegen hier. Ebenso KYC und Onboarding, Kartenausgabe und -abwicklung sowie die Krypto- und Stablecoin-Schienen. Dahinter steht eine einzige Operator-Konsole, in der jede privilegierte Aktion eine Begründung erfordert und in einem Audit-Log landet.

Von jedem davon gibt es genau eines, und genau das ist der Punkt. Abwicklung, Abstimmung und Compliance sind schwer richtig zu machen und teuer, wenn sie falsch sind – also baut man sie einmal und lässt jede App das Ergebnis erben. Wenn ein Mandant einen Kunden onboardet, folgt die vom Core festgelegte KYC-Stufe diesem Kunden in die Konsole, unabhängig davon, über welche App-Screens die Dokumente erfasst wurden. Dem Core ist egal, wie die App darüber heißt – er sieht Konten und Buchungen, keine Marken.

Was variiert: Designsprache, Informationsarchitektur, Funktionsmix

Alles oberhalb des Cores ist frei beweglich, und zwar entlang dreier Achsen. Die erste ist die Designsprache: Farbe, Typografie, Eckenradius, Abstände, Bewegung – die visuelle Grammatik der Marke. Die zweite ist die Informationsarchitektur: was auf dem Startbildschirm liegt, wie Abläufe benannt und angeordnet sind, welche Aktion einen Tap entfernt ist und welche drei. Die dritte ist der Funktionsmix: welche Module überhaupt aktiviert sind. Eine schlanke Überweisungs-App und eine dichte Super-App können auf demselben Core laufen und keinen einzigen Screen teilen.

Die Produktseite unter /products/pay zeigt fünf ausgearbeitete Richtungen, die sich am besten als Beispiele für unendlich viele lesen lassen, nicht als Auswahlmenü mit fünf Einträgen. Halcyon ist eine aufgeräumte Exchange – zurückhaltend, wenige Oberflächen, der Handel im Mittelpunkt. Lumen ist eine Super-App, in der Geld innerhalb der Unterhaltung fließt und Chat-Zahlungen, Abos und Earn sich den Startbildschirm teilen. Fern setzt auf Überweisungen – Sammelauszahlungen und regelbasierte FX-Umrechnung zuerst. Volt ist ein Stablecoin-Build im Dark-Look mit Gehaltsaufteilung und Team-Karten. Meridian ist mehrwährungsfähig: ein EUR-Konto neben USDC, ein GBP-Reisesaldo und ein BTC-Konto, auf dem Karten-Rewards landen. Fünf Marken, fünf Informationsarchitekturen, fünf Funktionsmixe – ein Ledger, ein KYC, ein Kartenprozessor darunter.

Das heißt nicht, dass das Produkt aus fünf Apps besteht. Die fünf sind Richtungen, die dieselbe Pipeline einschlagen kann; entscheidend ist nicht die Zahl fünf, sondern wie viele Mandanten Sie onboarden. Jede ist der Beweis, dass sich das Frontend bis hin zur Form des Startbildschirms unterscheiden kann, ohne dass der Core darunter etwas davon bemerkt.

Den Core dürfen Sie nicht neu erfinden; die App dürfen Sie nicht einschränken. Eine Whitelabel-Plattform ist die Disziplin, beide Sätze gleichzeitig wahr zu halten.

Warum Token-Theming besser ist als das Forken der Codebasis

Es gibt zwei Wege, ein Produkt wie viele aussehen zu lassen. Der naheliegende ist der Fork: die Codebasis pro Kunde kopieren, umgestalten, ausliefern. Das funktioniert für genau ein Release. Danach muss jeder Bugfix und jede regulatorische Änderung N-mal auf N auseinanderdriftenden Kopien eingespielt werden, die Kopien geraten aus dem Takt, und die Sicherheitsoberfläche, die Sie überblicken müssen, vervielfacht sich mit der Zahl der Kunden. Forking macht aus einem System, das Sie verstehen, viele, die Sie nicht verstehen.

Token-Theming kehrt das um. Es gibt eine Codebasis. Eine Marke ist ein Satz von Werten – Tokens für Farbe, Schrift, Radius und Abstände, eine Komponentenkonfiguration, ein Feature-Flag-Set –, die zur Build-Zeit zu einer gebrandeten App aufgelöst werden. Ändern Sie ein Token, bewegt sich jeder Screen, der es liest, gemeinsam mit, denn nichts hat einen Wert hartkodiert, der aus einem Token stammen sollte. Ein Fix im Überweisungsablauf geht an alle Mandanten gleichzeitig raus, weil es nur einen Überweisungsablauf zu korrigieren gibt. Die Marken unterscheiden sich in ihrer Konfiguration, nicht in ihrem Quellcode.

Wo das Design System ansetzt

Die Tokens sind keine lose Idee, sondern ein ausgeliefertes Artefakt. Das Protocore Design System – /products/pds – umfasst 144 Design-Tokens und 889 Utility-Klassen: das Vokabular, in dem jede App gethemt wird. Es ist Dark-first, token-getrieben und standardmäßig mit Radius null, und derselbe Token-Satz wird für Web, .NET und Native ausgegeben – eine einmal definierte Farbe ist also in einem React-Screen, einer Desktop-Konsole und einem nativen Mobile-Build dieselbe Farbe. Die Marke eines Mandanten wird als Overrides gegenüber diesem Vokabular ausgedrückt. Deshalb ist ein Re-Skin einer App eine Konfigurationsänderung und kein Rewrite.

Das macht das Frontend auch wirklich frei und nicht nur frei innerhalb einer Vorlage. Weil die Designsprache in Tokens und Utility-Klassen statt in einmaligen Stylesheets lebt, kann ein Designer einen Mandanten weit vom Referenz-Build wegführen – mit eigener Palette, Typografie, Dichte und eigenem Rhythmus –, ohne den Core anzufassen oder die App zu forken. Die Farbe reicht tief, bleibt aber nur Farbe; die Installation darunter wird geteilt.

Die App ist eine Konfiguration, kein Build

Der Funktionsmix folgt derselben Regel. Jedes Modul – Chat-Zahlungen, Earn, Krypto, Karten, Abos, Team-Karten, Empfehlungen – ist ein Schalter pro Mandant, und ein Flag kann zunächst für einen Teil der Nutzer ausgerollt werden, bevor es breit live geht. Betreiber legen sie in einem Konfigurations-Panel um, nicht per Deployment. Der Unterschied zwischen einer schlanken Überweisungs-App und einer vollwertigen Super-App sind also nicht zwei Projekte, sondern zwei Konfigurationen eines Projekts. Die Referenz-App, von der jeder Mandant ausgeht, ist ein neutraler Build im Protocore-Branding mit dem gesamten Angebot – jedes Whitelabel ist dieser Build mit überschriebenen Tokens und ein- oder ausgeschalteten Modulen.

Die ehrliche Grenze

Ein Core, viele Apps lohnt den Aufwand nur, wenn Sie tatsächlich viele Apps haben – oder eine App, die Sie im Lauf der Zeit umgestalten, neu anordnen und neu zuschneiden wollen, ohne jedes Mal die Bank neu zu bauen. Wenn Sie eine einzige feste App ausliefern, die nie eine zweite Marke tragen wird, brauchen Sie keine Whitelabel-Plattform, sondern eine App. Ihren Wert beweist sie in dem Fall, für den sie gebaut wurde: eine Plattform, die Mandant für Mandant gebrandete Banking-Produkte aufsetzt, jedes erkennbar eigenständig, keines ein Fork. Die vollständige Analyse – die fünf Richtungen, die Referenz-App und die Operator-Konsole dahinter – finden Sie unter /products/pay, das darunterliegende Design System unter /products/pds.