Software für Krypto-Börsen wird in der Regel als ein einziges Produkt beschafft. Geliefert und betrieben wird jedoch eine Reihe klar unterscheidbarer Module mit unterschiedlichen Fehlerbildern, unterschiedlicher regulatorischer Relevanz und unterschiedlichen Folgen für die Eigentumsverhältnisse. Wird die Plattform als unteilbarer Einkauf behandelt, bleiben genau jene Fragen unsichtbar, die später über Kosten, Kontrolle und Zulassungsreife entscheiden.
Dieser Beitrag beschreibt die Module, die eine Handelsplattform in der Praxis benötigt, die Fragen, die jedes Modul für Geschäftsführung, Technik und Compliance aufwirft, sowie die Kriterien, die eine stimmige Architektur von einer bloßen Ansammlung von Komponenten unterscheiden. Die Perspektive ist Beschaffung und Planung, nicht Implementierung: Was vorhanden sein muss, warum es relevant ist und wie Vollständigkeit vor der Anbieterauswahl beurteilt wird.
Warum Börsensoftware modulweise beurteilt wird
Eine Handelsplattform ist ein reguliertes Geschäft, das von Software getragen wird, und keine Oberfläche mit Kursen darauf. Wird eine Plattform als Ganzes bewertet, konzentrieren sich Präsentationen erfahrungsgemäß auf das Sichtbare, während die Komponenten unbeleuchtet bleiben, die über den operativen und regulatorischen Ausgang entscheiden. Eine modulweise Beurteilung kehrt diese Gewichtung um und fragt, welche Teile vorhanden sind, welche von Dritten stammen und welche der Betreiber ohne Zutun des Anbieters verändern kann.
Die Unterscheidung ist für jede Entscheidungsebene aus einem anderen Grund erheblich. Für die Geschäftsführung bestimmen Modulgrenzen, wo laufende Kosten entstehen und welche Lieferantenbeziehungen später nur teuer zu lösen sind. Für die technische Leitung bestimmen sie, was von wem und mit welchem Risiko geändert werden kann. Für die Compliance-Funktion bestimmen sie, wo Aufzeichnungen entstehen und ob Nachweise auf Anforderung vorgelegt werden können, statt nachträglich rekonstruiert zu werden.
Der Handelskern
Der Handelskern besteht aus der Matching-Engine, der Order-Management-Schicht und der Marktdatenverteilung, die beide trägt. Die Matching-Engine wendet die Prioritätsregeln des Handelsplatzes an und erzeugt den Ausführungsdatensatz, aus dem alles Nachgelagerte abgeleitet wird. Durchsatz und Verhalten unter Last setzen die Obergrenze für die Produktambitionen des Handelsplatzes, insbesondere wenn Derivate, hohe Order-Trade-Verhältnisse oder professionelle Teilnehmer vorgesehen sind.
Technische Ausgangsbasis: Eine Matching-Engine, getestet mit bis zu 700.000 Orders pro Sekunde. Benchmark-Werte beschreiben eine definierte Testkonfiguration und sind keine Leistungszusage; maßgeblich ist für jeden Handelsplatz das Orderprofil, das er tatsächlich erwartet.
Das Order-Management hält den Zustand jeder Weisung zwischen Eingang und Abwicklung, wendet die Limite des Handelsplatzes an und weist zurück, was zurückzuweisen ist. Die Marktdatenverteilung führt das entstehende Orderbuch und den Handelsstrom an Oberflächen und API-Clients. Diese drei Teile werden häufig als eines besprochen, skalieren jedoch unterschiedlich und fallen unterschiedlich aus; an ihrer Grenze werden die meisten Leistungsstreitigkeiten am Ende entschieden.
Ledger und Saldenführung
Das Ledger ist der maßgebliche Nachweis darüber, was der Handelsplatz jedem Kunden schuldet und was er hält. Es ist zu unterscheiden vom Saldo in der Oberfläche, der lediglich eine Projektion des Ledger-Zustands ist, und erneut zu unterscheiden von den On-Chain-Beständen, die gegen das Ledger abgestimmt werden müssen. Werden diese drei Ebenen vermengt, fallen Abweichungen spät auf — meist bei der Abstimmung oder in einer Prüfung, nicht im Regelbetrieb.
Eine doppelte Buchungsstruktur mit unveränderlichen Buchungssätzen ist die übliche Erwartung, weil sich damit jeder Saldo aus den Buchungen erklären lässt, die ihn erzeugt haben. Die nützliche Beschaffungsfrage lautet nicht, welche Datenbanktechnologie eingesetzt wird, sondern ob das Ledger unabhängig von der schreibenden Anwendung rekonstruiert, abgestimmt und nachgewiesen werden kann.
Wallet- und Verwahrinfrastruktur
Die Wallet-Infrastruktur umfasst die Erzeugung von Einzahlungsadressen, den Aufbau und die Übermittlung von Transaktionen, die Bestätigungsverfolgung sowie die Trennung von Hot- und Cold-Beständen. Auch die Auszahlungsfreigabe gehört hierher, und sie ist eine betriebliche Kontrolle, bevor sie eine technische Funktion ist: Wer gibt frei, unter welchen Bedingungen, und wie wird die Freigabe festgehalten? Multisig-Verfahren und hardwaregestützte Schlüsselverwahrung sind die verbreiteten Strukturen, ob intern betrieben oder über einen externen Verwahrer.
Die Entscheidung zwischen eigenem Wallet-Betrieb und Anbindung eines Verwahrers verändert Risikoprofil, Versicherungslage und regulatorisches Gespräch des Handelsplatzes und ist kaum umkehrbar, sobald Kundenwerte gehalten werden. Sie ist daher eine Architekturentscheidung vor der Auswahl und keine Konfigurationsfrage, die in die Umsetzung verschoben wird.
Fiat-Anbindung und Zahlungsverkehr
Fiat-Ein- und -Auszahlung verbinden den Handelsplatz mit Banken und Zahlungsdienstleistern; in diesem Modul verzögern sich Starttermine am häufigsten. Die Software-Anforderung ist vergleichsweise überschaubar: Anbindung der Zahlungsdienstleister, Zuordnung eingehender Zahlungen, Auszahlungsweisung und die Abstimmung zwischen Zahlungsdaten und Ledger-Buchungen. Die kommerzielle und regulatorische Anforderung ist größer, denn Bankbeziehungen werden gegen das Kontrollumfeld des Handelsplatzes gewährt, nicht gegen seine Technik.
Hält ein Handelsplatz Kundengelder, statt sie unmittelbar an einen Zahlungspartner weiterzureichen, wird das Zahlungsdienste- und E-Geld-Regelwerk für die Architektur relevant und nicht nur für den Antrag; die strukturellen Fragen sind auf der Seite zur E-Geld-Plattform-Software ausführlicher dargestellt. Grumpio verwahrt keine Kundengelder und gibt keine Zahlungsinstrumente aus. Die Plattform ist so strukturiert, dass die Pflichten des Betreibers nachgewiesen werden können.
Compliance-Module
Identitätsprüfung, AML- und Wallet-Screening, Travel-Rule-Kommunikation und Transaktionsüberwachung sind getrennte Module mit getrennten Datenflüssen — und zugleich die Module, die am häufigsten vorausgesetzt statt spezifiziert werden. Die Verifizierung entscheidet, wer aufgenommen wird. Das AML- und Sanktions-Screening entscheidet, wer zu welchen Bedingungen aufgenommen wird, und wiederholt diese Entscheidung periodisch. Die Travel-Rule-Verarbeitung regelt, was eine Übertragung zwischen Anbietern begleitet. Die Überwachung beobachtet das Verhalten nach der Aufnahme, wo der meldepflichtige Sachverhalt regelmäßig auffällt.
Die MiCA-Übergangsfrist ist beendet. Neue EU-Kryptoprojekte müssen von Beginn an für ein zugelassenes CASP-Betriebsmodell ausgelegt werden. Im Vereinigten Königreich ist die MLR-Registrierung keine FSMA-Zulassung: Die FCA hat ihre finalen Regeln für das kommende Kryptoregime am 30. Juni 2026 veröffentlicht, das Antragsfenster läuft vom 30. September 2026 bis zum 28. Februar 2027, und das Inkrafttreten wird zum 25. Oktober 2027 erwartet. Die UK Travel Rule gilt seit dem 1. September 2023. Beide Entwicklungen rücken Compliance-Module in den technischen Umfang der Plattform hinein statt daneben.
Legichain, das Screening- und Verifizierungsprodukt von Grumpio, umfasst Personen- und Unternehmens-Screening, PEP- und Sanktionsdaten, Adverse Media, Wallet-Risiko-Screening über mehrere Blockchains, Risikobewertung, PDF-Nachweisberichte und periodische Wiederholungsprüfungen — über eine API und ein Web-Panel, bei Bedarf mit dediziertem Storage. Die Identitätsfunktionen, darunter KYC-Verifizierungssoftware mit NFC-Dokumentenauslesung, Liveness und Gesichtsabgleich, laufen über denselben Kreditpool. Produktdetails und Preise sind unter legichain.com veröffentlicht.
Wir erstellen keine Rechtsgutachten und garantieren keine Zulassung. Wir setzen regulatorische und prüfungsbezogene Anforderungen in Technologie, Infrastruktur und Betrieb um.
Back Office, Rollen und Prüfspuren
Im Back Office wird der Handelsplatz tatsächlich betrieben: Kundenverwaltung, Bearbeitung von Ein- und Auszahlungen, Konfiguration von Gebühren und Limiten sowie die Untersuchung von Ausnahmen. Seine Qualität bestimmt den Personalbedarf, und der Personalbedarf bestimmt die Betriebskosten verlässlicher als Lizenzgebühren. Rollen- und Berechtigungskonzept gehören zu diesem Modul, ebenso die Prüfspur, die zeigt, welcher Bearbeiter was, wann und mit welcher Freigabe getan hat.
Prüfprotokolle werden häufig als technische Nebensache behandelt und dann in einer Prüfung kurzfristig angefordert. Ist das Protokoll als Nachweis konzipiert — vollständig, manipulationserkennend, exportierbar und auch für Nicht-Techniker lesbar —, wird die Prüfung zu einem Abruf und nicht zu einem Rekonstruktionsprojekt.
Modulkarte und Eigentumsfragen
Die folgende Karte fasst die beschriebenen Module zusammen und nennt jeweils die eine Frage, die das Modul in der Anbieterprüfung am aussagekräftigsten testet. Die Fragen zielen auf Eigentum und Nachweis statt auf Funktionen, denn Funktionslisten unterscheiden sich zwischen Anbietern selten wesentlich, die Eigentumsbedingungen fast immer.
| Modul | Wesentliches Risiko bei Fehlen oder Schwäche | Prüfende Frage |
|---|---|---|
| Matching und Order-Management | Durchsatzgrenzen und unvorhersehbares Verhalten unter Last | Wurde die Engine gegen das eigene Orderprofil gemessen? |
| Ledger | Unerklärte Salden und fehlgeschlagene Abstimmung | Lassen sich Salden unabhängig von der Anwendung rekonstruieren? |
| Wallet und Verwahrung | Verlust von Werten und unbefugte Auszahlung | Wer gibt Auszahlungen frei, und wie wird die Freigabe nachgewiesen? |
| Fiat-Anbindung | Verzögerter Start und Reibung im Bankverhältnis | Stimmen Zahlungsdaten ohne manuelle Arbeit gegen das Ledger ab? |
| KYC, AML und Travel Rule | Aufnahme unzulässiger Kunden und undokumentierte Entscheidungen | Werden Screening-Ergebnisse mit der Entscheidung als Nachweis aufbewahrt? |
| Back Office und Prüfspuren | Betriebskosten und Prüfungsfeststellungen | Lässt sich die vollständige Bearbeiterhistorie ohne Technikteam exportieren? |
| Betrieb und Resilienz | Ausfallzeiten und Resilienzfeststellungen | Wurden Wiederanlaufziele geübt statt nur dokumentiert? |
Betriebs- und Resilienzmodule
Der Betrieb ist ein eigenes Modul, denn wo die Plattform läuft, bestimmt, wer sie erreicht, wer sie ändern kann und was beim Ausfall einer Komponente geschieht. Dedizierter oder On-Premises-Betrieb, primäres und sekundäres Rechenzentrum, Release-Governance und Wiederanlaufziele sind Architekturentscheidungen mit regulatorischen Folgen, insbesondere unter den Erwartungen an operative Resilienz, die inzwischen im Vereinigten Königreich und in der Europäischen Union gelten.
DORA gilt seit dem 17. Januar 2025 und behandelt Resilienz als getestete Fähigkeit, nicht als dokumentierte Absicht. Die praktische Unterscheidung ist schlicht: Ein geübtes Wiederanlaufziel ist eine Kontrolle, ein nur in einer Richtlinie stehendes Wiederanlaufziel ist eine Feststellung, die noch erhoben wird. Die technischen Folgen werden unter regulatorische Bereitschaft weiter ausgeführt.
Fazit und nächste Schritte
Eine Börsenplattform ist vollständig, wenn jedes Modul eine definierte Grenze, eine benannte Verantwortung und eine Nachweiskette hat: Handelskern, Ledger, Wallets, Fiat-Anbindung, Compliance, Back Office und der Betrieb darum herum. Lücken in dieser Karte zeigen sich nicht in der Präsentation. Sie zeigen sich in der Abstimmung, im ersten Vorfall und in der ersten Prüfung — dann, wenn ihre Schließung am teuersten ist.
Der praktische nächste Schritt besteht darin, die Module gegen Zielmarkt, Zulassungslage und Betriebsmodell abzubilden, bevor Anbieter verglichen werden, denn der Vergleich wird erst aussagekräftig, wenn der erforderliche Umfang feststeht.
Kaufen Sie nicht nur Software. Kaufen Sie den Prozess, der sie zum Laufen bringt. Grumpio liefert Börsen-, E-Geld- und Compliance-Technologie zusammen mit der Architektur, den Nachweisen und dem Betriebsmodell, die sie tragen.