Krypto-Börsen-Software wird in zwei kommerziellen Modellen angeboten, die häufig als Varianten desselben Kaufs dargestellt werden. Im White-Label-Modell wird eine Plattform lizenziert, die der Anbieter weiterhin betreibt, hostet und weiterentwickelt; konfiguriert wird eine klar abgegrenzte Oberfläche. Im Source-Code-Modell wird die Codebasis selbst übergeben, womit sowohl die Möglichkeit als auch die Pflicht zur Änderung übernommen wird. Der Unterschied ist nicht in erster Linie technischer Natur und wird in einer Demonstration selten sichtbar.
Entschieden wird damit vielmehr, wer die Handelsplattform ändern darf, an welcher Stelle laufende Kosten entstehen und wie schnell reagiert werden kann, wenn eine Aufsichtsbehörde, ein Vorfall oder eine geschäftliche Gelegenheit ein anderes Verhalten der Plattform erfordert. Zwei Angebote können zum Verkaufszeitpunkt nahezu identische Funktionen zeigen und achtzehn Monate später deutlich auseinanderlaufen, wenn die Börse etwas benötigt, das die Roadmap des Anbieters nicht enthält.
Dieser Beitrag beschreibt, was die beiden Modelle jeweils liefern, welche Fragen sie voneinander trennen und unter welchen Bedingungen welches Modell vertretbar ist. Die Perspektive ist Beschaffung und Planung: Bewertungskriterien, Risiken und betriebliche Folgen statt Umsetzungsdetails.
Was die beiden Modelle liefern
Eine White-Label-Vereinbarung liefert eine Lizenz zur Nutzung einer Plattform unter eigener Marke. Der Code verbleibt beim Anbieter, in der Regel ebenso das Hosting, und Aktualisierungen werden zentral an alle Lizenznehmer ausgeliefert. Konfiguriert wird innerhalb von Parametern, die der Anbieter vorab festgelegt hat: Gebührenmodelle, gelistete Instrumente, Limits, Darstellung der Oberfläche und die Auswahl integrierter Drittdienste. Der Zeitraum bis zum Start ist kürzer, weil die Plattform bereits existiert und bereits getroffene Entscheidungen übernommen werden.
Eine Source-Code-Vereinbarung liefert die Codebasis zu verhandelten Lizenzbedingungen sowie die Möglichkeit, sie in einer selbst gewählten Umgebung zu betreiben. Grundsätzlich kann jeder Teil der Plattform geändert werden, womit zugleich die Verantwortung für die Folgen dieser Änderungen übernommen wird. Der Zeitraum bis zum Start ist länger, und das Modell setzt eine Entwicklungsfunktion voraus, die den Code lesen, pflegen und ausliefern kann, statt ihn lediglich entgegenzunehmen.
Zwischenformen existieren und sind oft die praktische Antwort. Ein Source-Code-Escrow gibt den Code erst bei definierten Auslöseereignissen frei. Ein Dedicated Deployment stellt eine vom Anbieter gepflegte Plattform auf einer Infrastruktur bereit, die der Betreiber kontrolliert, ohne dass der Code übertragen wird. Ein Teilzugriff gewährt Änderungsrechte an ausgewählten Modulen, während der Handelskern beim Anbieter verbleibt. Diese Zwischenformen sollten ausdrücklich bewertet und nicht als Kompromiss behandelt werden, der erst bei stockenden Verhandlungen entsteht.
Die Eigentumsfrage
Eigentum wird diskutiert, als wäre es ein einziges Merkmal; tatsächlich zerfällt es in mehrere Fragen mit unterschiedlichen Antworten. Wem gehört die Codebasis. Wem gehören die Kundendaten und die daraus abgeleiteten Aufzeichnungen. Wer kontrolliert die Umgebung, in der die Plattform läuft. Wer hält die Wallet-Schlüssel und gibt Auszahlungen frei. Wer kann eine vollständige Historie der Betreiberaktionen vorlegen, wenn sie angefordert wird. Eine Börse kann ihre Daten besitzen, ohne den Code zu besitzen, und ihre Schlüssel halten, ohne das Deployment zu kontrollieren.
Die Frage, an der sich jede Vereinbarung messen lässt, lautet: Was geschieht, wenn die Beziehung endet. Unter einer White-Label-Lizenz überdauert die Plattform die Lizenz in der Regel nicht; Migration bedeutet dann, die Börse im laufenden Handel neu aufzubauen. Unter einer Source-Code-Lizenz überdauert der Code, doch sein Wert hängt davon ab, ob die Pflege intern geleistet werden kann und ob die Lizenzbedingungen die tatsächlich benötigten Änderungen zulassen. Keines der Modelle beseitigt Abhängigkeit; sie verschieben sie.
Hinweis: Die Entscheidung ist nur in eine Richtung umkehrbar. Der Wechsel von einer White-Label-Plattform zu einer eigenen Codebasis ist ein Migrationsprogramm mit eigenem Risiko-, Kosten- und Meldeprofil. Der Wechsel von einer eigenen Codebasis zu einer White-Label-Plattform ist vergleichsweise unkompliziert. Diese Asymmetrie gehört in die Ausgangsentscheidung und nicht in die erste Überprüfung.
Wo die Kosten entstehen
Ein Vergleich der beiden Modelle über den Anschaffungspreis führt in die Irre, weil die Kosten an unterschiedlichen Stellen des Plattform-Lebenszyklus anfallen. White-Label-Lizenzierung konzentriert die Kosten auf laufende Gebühren, die fix, volumenabhängig oder umsatzabhängig sein können, sowie auf einzeln bepreiste Änderungsanforderungen, die jeweils mit einer geteilten Roadmap konkurrieren. Source-Code-Lizenzierung konzentriert die Kosten auf den Anfang und auf die Entwicklungs- und Infrastrukturfunktion, die anschließend erforderlich ist, um die Plattform aktuell zu halten.
Die sinnvolle Frage ist daher nicht, welches Modell günstiger ist, sondern ob die eigene Kostenbasis beeinflusst werden kann. An das Handelsvolumen gekoppelte Gebühren steigen mit dem Erfolg und lassen sich schwer nachverhandeln, sobald die Börse von der Plattform abhängt. Entwicklungskosten sind steuerbar, aber real, und wer eine Codebasis erwirbt, ohne sie personell zu besetzen, hat eine Verpflichtung gekauft und keinen Vermögenswert. Die Kostentreiber werden unter Fintech-Architektur-Beratung vertieft.
Regulatorische und prüfungsbezogene Auswirkungen
Das Lizenzmodell wirkt über die kommerziellen Bedingungen hinaus, denn eine regulierte Handelsplattform muss nachweisen können, wie ihre Systeme arbeiten und wer sie geändert hat. Liegen Code und Umgebung beim Anbieter, wird dieser zum kritischen Drittanbieter, dessen Kontrollen Teil des eigenen Kontrollumfelds werden. DORA gilt seit dem 17. Januar 2025 und behandelt Drittanbieter-Abhängigkeit als Gegenstand von Bewertung, Tests und Ausstiegsplanung und nicht als Frage vertraglicher Zusicherungen allein.
Die Zulassungsfristen machen das Thema unmittelbar statt theoretisch. Die MiCA-Übergangsfrist ist beendet. Neue EU-Kryptoprojekte müssen von Beginn an für ein zugelassenes CASP-Betriebsmodell konzipiert werden. Im Vereinigten Königreich hat die FCA am 30. Juni 2026 die endgültigen Regeln veröffentlicht; das Antragsfenster läuft vom 30. September 2026 bis zum 28. Februar 2027, und das Inkrafttreten des Regimes wird für den 25. Oktober 2027 erwartet. Wer heute eine Plattform auswählt, wählt zugleich die Nachweisgrundlage, die in diesem Verfahren vorgelegt wird.
Die praktischen Prüfsteine sind in beiden Modellen dieselben. Ob Änderungskontrolle mit benannten Freigebenden und datierten Releases belegt werden kann. Ob Prüfaufzeichnungen ohne Mitwirkung des Anbieters exportiert werden können. Ob Wiederanlaufziele geübt und nicht nur dokumentiert wurden. Ob eine aufsichtliche Frage beantwortet werden kann, ohne zuvor ein Support-Ticket zu eröffnen. Diese Fragen trennen eine regulatorisch ausgerichtete Architektur von einer Plattform, die lediglich funktioniert. Weitere technische Aspekte finden sich unter regulatorische Bereitschaft.
Abgrenzung: Wir erstellen keine Rechtsgutachten und garantieren keine Zulassung. Wir setzen regulatorische und prüfungsbezogene Anforderungen in Technologie, Infrastruktur und Betrieb um.
Die beiden Modelle im Vergleich
| Dimension | White-Label | Source-Code |
|---|---|---|
| Zeit bis zum Start | Kürzer; die Plattform existiert, Entscheidungen werden übernommen | Länger; Entscheidungen werden getroffen statt übernommen |
| Änderungskontrolle | Anforderungen konkurrieren mit einer geteilten Roadmap | Bestimmt durch die eigene Release-Steuerung |
| Kostenprofil | Laufende Gebühren, bepreiste Änderungsanforderungen | Anfangslizenz, Entwicklungs- und Infrastrukturfunktion |
| Drittanbieter-Exposition | Der Anbieter wird Teil des Kontrollumfelds | Für die Plattform reduziert, für Integrationen bestehend |
| Prüfnachweise | Abhängig von Anbieterwerkzeugen und Mitwirkung | Selbst erzeugt, abhängig von der eigenen Kapazität |
| Ausstiegsposition | Migration baut die Börse im laufenden Handel neu auf | Der Code bleibt; sein Wert hängt von der Pflegefähigkeit ab |
Wann welches Modell passt
Eine White-Label-Plattform ist dort vertretbar, wo das geplante Produkt innerhalb eines etablierten Rahmens bleibt, wo eine Marktposition geprüft wird, bevor Kapital gebunden wird, und wo keine Entwicklungsfunktion besteht und auch keine aufgebaut werden soll. Vertretbar ist sie ebenso, wenn die Roadmap des Anbieters nachweislich zur eigenen Richtung passt — wobei diese Übereinstimmung an dem zu messen ist, was der Anbieter geliefert hat, und nicht an dem, was er ankündigt.
Eine Source-Code-Vereinbarung ist dort vertretbar, wo sich das Produkt in einer Weise unterscheidet, die eine Konfigurationsoberfläche nicht abbilden kann, wo die eigene Lizenzposition nachweisbare Kontrolle über Änderungen und Aufzeichnungen verlangt und wo der Betriebshorizont lang genug ist, damit laufende Gebühren die Eigentumskosten übersteigen. Vorausgesetzt werden ein Entwicklungsteam, ein Release-Prozess und eine Sicherheitsfunktion; das Modell scheitert leise, wenn diese angenommen statt besetzt werden. Die Plattformfähigkeiten hinter beiden Modellen werden unter Krypto-Börsen-Software beschrieben.
Zusammenfassung und nächste Schritte
White-Label und Source-Code sind keine Stufen desselben Produkts. Sie sind unterschiedliche Verteilungen von Kontrolle, Kosten und Pflichten, und die richtige Wahl folgt aus Lizenzposition, Produktanspruch und Entwicklungskapazität — nicht aus dem Preis auf der ersten Seite eines Angebots. Wer nicht benennen kann, welches der beiden Modelle benötigt wird und warum, ist für einen Anbietervergleich noch nicht bereit.
Der praktische nächste Schritt besteht darin, festzuhalten, was ohne Erlaubnis geändert werden muss, was ohne fremde Hilfe nachgewiesen werden muss und wovon man sich abhängig machen kann. Diese drei Antworten grenzen die Modellwahl ein, bevor die erste kommerzielle Verhandlung beginnt.
Das Lizenzmodell ist eine Betriebsentscheidung, kein Beschaffungsdetail. Grumpio liefert Börsentechnologie in beiden Modellen — zusammen mit der Architektur, den Nachweisen und dem Betriebsmodell, die diese Wahl tragfähig machen.