T+0 ist kein Zufall, sondern Systemarchitektur – eine eWpG-konforme Zeichnungsstrecke in der Praxis   

Während klassische Settlement-Prozesse T+2-Zyklen durch Clearingstellen schleifen, kann ein Kryptowertpapier denselben Compliance-Pfad in Sekunden durchlaufen – sofern die State Machines der Dienstleister sauber entkoppelt sind. Dieser Artikel zeigt, wie das technisch aussieht.

von Markus Kluge, tokenforge

Seit Inkrafttreten des eWpG können Emittenten Kryptowertpapiere ohne physische Urkunde begeben. Die Komplexität liegt nicht im Token-Deployment, sondern in der Koordination unabhängiger State Machines. Das Haftungsdach trägt die regulatorische Verantwortung für das Frontend und gibt den Takt vor: Ohne seine Freigabe findet weder Whitelisting noch Zeichnung statt. KYC-Anbieter, Kryptoverwahrer und Registerführer arbeiten in diesem Rahmen. Was im Frontend wie ein Checkout aussieht, ist im Backend ein Graph nebenläufiger Prozesse mit klar definierten Synchronisationspunkten.

Haftungsdach – regulatorische Klammer und Freigabe

Anlagevermittlung gegenüber Privatanlegern läuft unter einem Haftungsdach (§ 2 Abs. 10 KWG), das die regulatorische Verantwortung für das gesamte Frontend trägt. Seine State Machine umfasst Investor-Onboarding, Zeichnungsfreigabe und KYC Reliance.

Zum Onboarding gehören Stammdaten, UBO und gesetzliche Vertreter (GwG), PEP-Erklärung sowie Angemessenheits- und Geeignetheitsprüfung nach § 63 ff. WpHG inklusive Zielmarktabgleich, Produkterfahrung und Risikotragfähigkeit. Hinzu kommen Dokumentenbereitstellung und -tracking für Prospekt/VIB und Widerrufsbelehrung. Ein abgelehnter Zielmarkt blockiert nur diese State Machine, nicht andere Pfade.

Jede Zeichnung wird geprüft und per signiertem Webhook freigegeben; ungeprüfte Updates werden abgelehnt. . Erst auf „approved“ wird das Whitelisting beim Registerführer angestoßen und der Token-Transfer ausgelöst. Gleichzeitig fungiert das Haftungsdach als berechtigtes Institut nach § 17 GwG und stellt die KYC Reliance bereit: Das KYC-Ergebnis wird an Kryptoverwahrer und Registerführer weitergegeben, die dadurch auf eigene Identifizierung verzichten können. Die Plattform übernimmt das Routing zwischen den Empfängern; jede Weitergabe aktualisiert den KYC-Status in der State Machine des empfangenden Instituts.

KYC-Anbieter – Identifizierung und Wallet-Zuordnung

Der KYC/AML-Anbieter identifiziert den Investor nach GwG (Video-Ident oder gleichwertiges Verfahren) und liefert Identitätsnachweis plus Risk-Scoring. Meist erzeugt der Kryptoverwahrer die Wallet nach KYC. Emissionen können jedoch Self-Custody-Wallets zulassen; dann wird die Inhaberschaft kryptographisch verifiziert: EVM-Chains per Challenge-Response-Signatur (EIP-191 / personal_sign), Stellar per signierter XDR gegen den Public Key der Wallet. Bei Kryptoverwahrer-erzeugten Wallets entfällt dieser Schritt. KYC-Status ist eine eigenständige State Machine auf der Order.

Kryptoverwahrer – Key-Management

Ein reguliertes Institut mit Kryptoverwahrlizenz (§ 1 Abs. 1a Satz 2 Nr. 6 KWG) übernimmt das Key-Management. Eigentum am Kryptowertpapier wird ausschließlich im On-Chain-Register abgebildet; der Kryptoverwahrer verwaltet lediglich die kryptographischen Schlüssel.

Private Keys liegen in HSMs, verwaltet mittels MPC.“

Bei Transfers zwischen VASPs tauschen Kryptoverwahrer Absender- und Empfängerdaten nach IVMS101 aus (Travel Rule, FATF R16) – off-chain, nicht im Smart Contract.

Registerführer – das hybride Register nach § 16 eWpG

Das Kryptowertpapierregister nach § 16 eWpG ist ein hybrides Konstrukt:

Der Smart Contract bildet die Rechtspositionen on-chain ab – Eigentum entsteht durch Eintragung in dieser Infrastruktur, nicht durch einen Backendeintrag.“

Personenbezogene und registerrelevante Daten verwaltet der Registerführer off-chain, da öffentliche Chains keine PII tragen dürfen.

Der Registerführer entscheidet mit dem Emittenten über Chain und Token-Standard. Produktiv kommen derzeit drei Modelle zum Einsatz: ERC-3643 / T-REX auf EVM/Polygon mit On-Chain-Compliance-Registry, IdentityRegistry und ComplianceModule; Entscheidungslogik bleibt off-chain, die Registry spiegelt den Status. ERC-7551 auf EVM und Stellar/Soroban ermöglicht komplexere Berechtigungs- und Compliance-Strukturen direkt am Token. Stellar Classic arbeitet über Trustlines, die der Registerführer zur Asset-Issuer-Adresse autorisiert; Autorisierung und Token-Transfer erfolgen dabei Off-Chain-koordiniert.

Token-Transfer und Settlement

Nach Zeichnungsfreigabe durch das Haftungsdach existieren zwei Ausführungsmodi, jeweils gültig für beide Stacks.

Im ersten Modell agiert der Registerführer als Mittler: Die Weisung des Emittenten wird signiert on-chain ausgeführt. Auf Stellar autorisiert der Registerführer die Trustline, anschließend erfolgt der Asset-Transfer via Horizon API; auf EVM triggert der Registerführer den Transfer-Call gegen die Compliance-Registry.

Im zweiten Modell erfolgt der Smart-Contract-Call direkt durch den Emittenten, sobald Wallets gewhitelistet und Compliance-Regeln hinterlegt sind. Auf Stellar übernehmen autorisierte Accounts und Trustline-Regeln dieselbe Funktion wie Compliance-Rules bei ERC-3643 oder ERC-7551. Der Registerführer wird dabei vom Ausführungsorgan zum Setup-Provider, die Chain exekutiert autonom. Im Erstmarkt bleibt die regulatorische Entscheidung off-chain – Smart Contracts sind dort Ausführungsschicht. Im Zweitmarkt, wo keine Haftungsdach-Freigabe erfolgt, übernimmt der Smart Contract die aktive Compliance-Prüfung: Whitelist und hinterlegte Regeln werden on-chain gegen jeden Transfer durchgesetzt

IT-Sicherheit und DORA

DORA dehnt IT-Sicherheitsverantwortung über die gesamte Dienstleisterkette aus: Emittent, Plattform, Registerführer, Kryptoverwahrer, Haftungsdach und KYC-Anbieter gehören zum ICT-Risk-Perimeter.

Die Authentifizierung läuft über RS256-signierte JWTs mit eindeutiger Session-Kennung für gezielten Widerruf; Auth-Klassen sind vertraglich dokumentiert und Teil der DORA-Risikoanalyse. Kryptoverwahrer, Payment-Provider und Investment-Plattformen nutzen OAuth2 Client Credentials, Registerführer-Webhooks und Chain-Inbound-Endpunkte HMAC-signierte Requests; auf Stellar zusätzlich signierte XDR-Transaktionen gegen den Public Key des Investors.

Weil Kryptoverwahrer, Registerführer und Haftungsdach als austauschbare Rollen im Domänenmodell modelliert sind, bleibt auch die DORA-geforderte Exit-Strategie umsetzbar:

Ein Providerwechsel betrifft die Adapter, nicht das Domänenmodell.“

Fazit

Eine eWpG-konforme Zeichnungsstrecke ist keine Feature-Liste, sondern eine orchestrierte Verbindung regulierter Dienstleister. Die Ingenieursarbeit liegt nicht im Token-Deployment, sondern darin, State Machines so zu verzahnen, dass rechtlich alles hält, der Investor nichts davon merkt und IT-Risiken nach DORA sauber getragen werden. Reihenfolge ist Produktdesign – Trennung der Zuständigkeiten ist Architektur. Markus Kluge, tokenforge