IBM Digital Asset Haven bindet Banken an das Swift-Ledger an, der Betrieb im eigenen Rechenzentrum bleibt Beta

IBM hat am 24. September angekündigt, dass Digital Asset Haven Finanzinstituten den Anschluss an das blockchain-basierte Shared Ledger von Swift erleichtern soll. Das Ledger-Programm sei laut IBM in weniger als neun Monaten vom Konzept zur Aktivierung gelangt, mehr als 40 Institute hätten es mitentworfen. Parallel startet eine Beta für den Betrieb im eigenen Rechenzentrum, die Schlusszahlung bleibt bei bestehenden Schienen.

Was IBM Digital Asset Haven laut Ankündigung liefert

Die Ankündigung nennt zwei Fortschritte, und beide sind weniger weit, als die Schlagzeilen vermuten lassen. Haven soll Instituten mit Wallet-Infrastruktur und Blockchain-Anbindung den Zugang zum Swift-Ledger öffnen. Zusätzlich gibt es Haven On-Prem als Beta, mit der Institute Verwahrung und Transaktionsverwaltung in eigenen Umgebungen prüfen können. Die Beta läuft auf von den Kunden selbst betriebenem Red Hat OpenShift auf IBM Z und LinuxONE. Als Autorin der Ankündigung nennt IBM Tina Tarquinio.

Der Funktionsumfang ist konkret, aber begrenzt:

• Schlüsselverwaltung: der zentrale Baustein für den Schutz der kryptografischen Schlüssel.
• Transaktionssignatur: Signaturpfade für Transaktionen auf der Blockchain.
• Richtlinienbasierte Steuerung: Regeln für Freigaben und Kontrollen.
• Anbindung an Hyperledger Besu: eine EVM-kompatible Schicht, also kompatibel mit der Ethereum Virtual Machine, die auch im Swift-Ledger auftaucht.
• Nachrichtenadapter für ISO 20022: ausdrücklich als Beta bezeichnet. Er verbindet Zahlungsnachrichten nach diesem Standard mit Transaktionen auf der Blockchain.

Der Adapter ist geschickt formuliert. Institute sollen die Zahlungsstandards weiterverwenden, auf denen ihre bestehende Infrastruktur beruht, ohne Bankbetrieb, Compliance-Regelwerke und Abwicklungsprozesse neu aufzubauen. Das ist ein Integrationsversprechen und keine Betriebszusage. Beta bedeutet laut Ankündigung, dass der Adapter zur Evaluierung bereitsteht, nicht dass er mit einer vertraglichen Verfügbarkeitszusage im Produktivbetrieb läuft.

IBM Consulting bietet dazu Beratung, Design, Integration und Managed Services an. Das Spektrum reicht vom Business Case und der Zielarchitektur über Compliance- und Betriebsmodell bis zum Fahrplan für ein minimal funktionsfähiges Produkt. Hinzu kommen Integration ins Ökosystem, Umsetzung, Tests und laufender Betrieb. Das ist ein Dienstleistungsangebot. Aufsichtsfragen und die hauseigene Richtlinie zur Schlüsselverwahrung beantwortet es nicht.

Das Swift-Ledger koordiniert Zahlungen, die Schlusszahlung bleibt bei den bestehenden Systemen

Das Shared Ledger von Swift ist laut IBM eine Koordinationsschicht und kein Ersatz für die bisherige Abwicklung. Es soll Instituten helfen, grenzüberschreitende Zahlungen mit tokenisierten Einlagen rund um die Uhr zu koordinieren. Die endgültige Abwicklung läuft weiterhin über bestehende Finanzmarktinfrastrukturen, etwa über Systeme der Echtzeit-Bruttoabwicklung (Real-Time Gross Settlement, RTGS). Swift bleibt ein Nachrichtennetzwerk. Auch die TARGET-Systeme und nationale RTGS-Schienen ersetzt das Ledger nicht.

Die Swift-Seite zur MVP-Umsetzung des Shared Ledgers stützt diese Lesart. Die Designphase ist abgeschlossen, das minimal funktionsfähige Produkt entsteht auf offener Grundlage mit einer EVM-kompatiblen Architektur auf Basis von Hyperledger Besu. Swift betreibt das Ledger als Koordinationsschicht. Die Banken behalten die Hoheit über Schlüssel, Vermögenswerte und Finanzierung. Die Abwicklung erfolgt über RTGS, Korrespondenzbanken oder andere vereinbarte Mechanismen. Koordination auf der Blockchain ist damit noch keine Schlusszahlung in Zentralbankgeld.

Die Tempo-Angaben stammen vom Anbieter und aus dem Programm selbst. Mehr als 40 Institute haben mitentworfen, vom Konzept bis zur Aktivierung vergingen weniger als neun Monate, und Pioniere sollen tokenisierte Einlagen im Pilotbetrieb nutzen. Das belegt Geschwindigkeit in Entwurf und Aktivierung. Es belegt nicht, dass die Treasury eines einzelnen Hauses morgen tokenisierte Einlagen mit eigenen Betriebsgarantien im eigenen Rechenzentrum abwickelt.

Für Praktiker in Deutschland, Österreich und der Schweiz folgt daraus eine Trennung. Shared Ledger und Haven adressieren Interoperabilität und Anbindung. Ob Schlüssel hardwaregestützt und unter Kontrolle des Kunden bleiben, beantworten sie nicht automatisch, zumal viele Compliance-Teams die Frage nach der Cloud noch nicht abgeschlossen haben. Genau dafür steht die On-Prem-Beta parallel in der Ankündigung, und genau deshalb ist sie bislang nur eine Beta.

Adapter und On-Prem-Variante sind Beta und damit Evaluierung, nicht Betrieb

Der ISO-20022-Adapter senkt die Einstiegshürde für Teams, die dieses Nachrichtenformat bereits im Betrieb haben. Laut Anbieter können Institute tokenisierte Einlagen über vertraute Formate anweisen und ihre Compliance-Prozesse behalten, ohne blockchain-spezifische Abläufe neu zu erfinden. Offen bleibt, ob Zuordnung der Felder, Behandlung von Ausnahmen, Abstimmung der Konten und Prüfpfad im eigenen Haus denselben Reifegrad erreichen wie bei klassischen grenzüberschreitenden Zahlungen. Beta-Adapter und Pilot-Ledger ergeben eine Lernkurve, aber noch kein fertiges Betriebsmodell.

Ein neuer Zahlungskanal gilt auch nicht allein deshalb als produktionsreif, weil das Nachrichtenformat geläufig ist. Das Format zu kennen ist Voraussetzung. Betriebsreife zeigt sich erst in Messwerten wie Fehlerquoten, Zeitüberschreitungen, Vier-Augen-Freigabe, Schlüsselzeremonie und Rückabwicklung.

Die On-Prem-Beta antwortet auf ein verbreitetes Anliegen regulierter Häuser. Sie wollen selbst bestimmen, wo Infrastruktur, Daten und Betrieb für digitale Vermögenswerte liegen. Haven On-Prem läuft innerhalb der Kundeninfrastruktur auf IBM Z und LinuxONE und erlaubt laut IBM die Evaluierung von Verwahrung und Transaktionsverwaltung ohne Abhängigkeit von Public-Cloud-Umgebungen. Die anfänglichen Fähigkeiten nennt die Ankündigung so:

• Bereitstellung unter Kundenkontrolle in selbst betriebenem Red Hat OpenShift.
• Hardwaregestützte Sicherheit und kundenkontrollierte Schlüsselverwaltung, abgestimmt auf die Architekturen von LinuxONE und IBM Z.
• Grundlegende Funktionen für Wallet-Verwaltung, Steuerung, Sicherheit und Transaktionsverwaltung.
• Eine einheitliche Architektur über die Bereitstellungsmodelle von Haven hinweg, um künftige Flexibilität zu prüfen.

Grundlegend bedeutet eine Basis, aber keinen gleichen Funktionsumfang wie in jeder Cloud-Variante. Beta bedeutet frühen Zugang zur Evaluierung. Wer in einer Vorstandsvorlage „On-Prem-Haven produktionsbereit“ schreibt, nur weil „ohne Public-Cloud-Zwang“ in der Überschrift stand, verwechselt Evaluierungszugang mit zugesicherter Betriebsqualität. Ebenso gilt: „Wir sind auf dem Swift-Ledger“ sagt noch nichts darüber, ob die eigene Roadmap für tokenisierte Einlagen souverän abgesichert ist. Der Anschluss an das Ledger und die On-Prem-Beta sind zwei getrennte Zeitscheiben mit eigenem Budget und eigener Abnahme.

Zur Einordnung: Die Parallelität von Ledger-Anbindung und On-Prem-Beta ist strategisch nachvollziehbar, weil cloudnahe Piloten den Anschluss beschleunigen und die lokale Variante Sorgen um Souveränität und Aufsicht adressiert. Dieselbe Gleichzeitigkeit erzeugt aber die Verwechslungsgefahr, vor der dieser Artikel warnt.

Eine illustrative Rechnung zeigt, was Pilot und Evaluierung pro Quartal kosten könnten

Die folgende Kalkulation ist ausdrücklich illustrativ. Sie ist keine IBM-Preisliste, keine Swift-Gebührenordnung und keine bankinterne Kostenstudie. Angenommen wird ein internes Team aus fünf Personen: zwei Integrationsspezialisten für ISO 20022 und Nachrichtenverkehr, eine Person für Wallet- und Schlüsselgovernance, eine für Compliance und Risiko sowie eine für die Produktverantwortung im Zahlungsverkehr. Die Vollkosten betragen in Deutschland, Österreich und der Schweiz grob 120.000 Euro pro Person und Jahr, also rund 30.000 Euro pro Quartal. Für fünf Personen ergibt das 150.000 Euro pro Quartal.

Beim cloudnahen Pilot mit Ledger-Anschluss über Haven, Adapter-Beta und Beratungstagen für Integration und Zuschnitt des Produkts liegen externe Unterstützung und Plattformkosten im angenommenen Band von 40.000 bis 90.000 Euro pro Quartal, in der Mitte bei 65.000 Euro. Mit dem Team ergeben sich rund 215.000 Euro pro Quartal. Dafür erhält ein Haus eine Lernkurve, Erfahrung mit der Zuordnung von Nachrichten und Pilottransaktionen im Umfeld der Pioniere, sofern es Zugang hat. Fertige Betriebsgarantien im eigenen Rechenzentrum sind nicht enthalten.

Bei der Evaluierung der On-Prem-Beta kommen OpenShift auf IBM Z und LinuxONE, hardwaregestützte Schlüssel, Sicherheitsabnahme, Betriebsmodell und womöglich zusätzliche Kapazität im Plattformbau hinzu. Angenommen werden 80.000 bis 180.000 Euro an zusätzlichen Infrastruktur- und Abnahmekosten im ersten Quartal, stark abhängig vom Haus, plus 150.000 Euro für das Team. Die Summe liegt grob bei 230.000 bis 330.000 Euro für ein Quartal Evaluierung, ohne dass eine Produktionsfreigabe entsteht.

Ein Pilot lohnt sich, wenn er Hypothesen misst, etwa Fehlerquote bei der Zuordnung, Verzögerung durch Vier-Augen-Freigabe, Aufwand für den Abgleich mit der RTGS-Abwicklung und Dauer der Schlüsselzeremonie. Er lohnt sich nicht, wenn eine Vorstandsfolie „Token-Einlagen im vierten Quartal“ als Produktionsstart verkauft und das Team zwei Quartale ohne Betriebshandbuch verbrennt. Zwei Quartale Pilot zu je rund 215.000 Euro ergeben grob 430.000 Euro Lernbudget. Ohne Hypothesenprotokoll ist das ein teurer Newsletter, mit Protokoll ein sauber investiertes Lernen, selbst wenn die Antwort „noch nicht produktionsreif“ lautet.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2PromptTreasury desk with dual sticky notes labeled only by abstract shapes suggesting cloud pilot versus on-prem control, spreadsheet printouts blurred, soft daylight office, no logos, no brand names, no readable text, 16:9

Controlling und Technikleitung sollten drei Sätze streichen und drei Fragen stellen

Der erste zu streichende Satz lautet: „Wir sind in unter neun Monaten produktionsreif auf dem Swift-Ledger.“ Richtig ist, dass das Ledger-Programm laut Anbieter in weniger als neun Monaten vom Konzept zur Aktivierung gelangte, dass Haven beim Anschluss hilft und dass Adapter und On-Prem-Variante Beta sind. Der zweite lautet: „On-Prem ohne Cloud-Zwang, also souverän im Betrieb.“ Richtig ist, dass es sich um eine Beta zur Evaluierung mit grundlegenden Fähigkeiten handelt, unter Kundenkontrolle in selbst betriebenem OpenShift auf IBM Z und LinuxONE. Der dritte lautet: „Tokenisierte Einlagen werden rund um die Uhr auf der Blockchain abgewickelt.“ Richtig ist, dass die Koordination rund um die Uhr möglich ist, die endgültige Abwicklung aber über RTGS und bestehende Finanzmarktinfrastrukturen läuft.

Für die Treasury heißt das: Liquiditäts- und Verpflichtungssicht können sich über das Ledger synchronisieren. Die endgültige Wertübertragung in Zentralbankgeld oder über etablierte Mechanismen bleibt ein zweiter Schritt. Wer „auf der Blockchain abgewickelt“ sagt und RTGS meint, drückt sich ungenau aus. Firmenkunden, die Open Banking und Sofortzahlungen kennen, entwickeln durch neue Schienen Erwartungen. Ohne Klarheit über die Abwicklung führen diese Erwartungen zu Rückfragen und Reputationsrisiken. Als Wertung sei ein Satz erlaubt: Dass IBM die Abwicklung ausdrücklich bei RTGS belässt, spricht für den Text, denn viele Token-Erzählungen lassen genau diesen Satz weg.

Bei Governance und Schlüsseln gilt dieselbe Trennung. Richtlinienbasierte Steuerung und Schlüsselverwaltung sind notwendige Bausteine, ersetzen aber keine schriftlichen Regeln zu Verwahrung, Trennung der Vermögen, Störfallbehandlung und Kommunikation mit der Aufsicht. Hardwaregestützte Schlüssel auf IBM Z und LinuxONE sind laut Anbieter ein starkes Kontrollargument. Ohne Betriebsmodell bleiben sie ein teurer Tresor ohne Schichtplan. Vier-Augen-Prinzip, Notfallzugriff, Schlüsselrotation und Prüfprotokolle bleiben Sache des Hauses, unabhängig vom Status des Adapters.

Häuser, die Krypto-Themen parallel in Broker- oder Verwahrkontexten bewegen, finden im Echttest zur Compliance nach MiCA (Markets in Crypto-Assets) eine Nachbarfrage. Es ist ein anderer Anwendungsfall als bankemittierte tokenisierte Einlagen auf einem Ledger mit festem Teilnehmerkreis, verlangt aber dieselbe Disziplin: Aussagen müssen durch Nachweise gedeckt sein. Ähnlich verhält es sich mit PSD3, digitalem Euro und Open Banking. Shared Ledger und Haven sind Infrastruktur für Institute und Netzwerke, kein Programm für eine digitale Zentralbankwährung im Massengeschäft und kein Ersatz für die Open-Banking-Roadmap. Beides gehört in getrennte Spalten und getrennte Budgets.

Hilfreich sind zudem Leitplanken, die ohne erfundene Verfügbarkeitsprozente auskommen. Blindes Vertrauen in den ersten Platz im Shared Ledger ist unangebracht,

• wenn die Roadmap produktive Token-Einlagen vorsieht, Adapter und On-Prem-Variante aber nur als Beta existieren und kein Abnahmeplan vorliegt;
• wenn „weniger als neun Monate bis zur Aktivierung“ die einzige Begründung für eine Budgetumschichtung ist, ohne Matrix für die Abwicklung und ohne Schlüsselrichtlinie;
• wenn die Teamkosten die externen Pilotkosten klar übersteigen und trotzdem keine wöchentlichen Lernziele definiert sind, denn dann wird Anwesenheit finanziert statt Fortschritt;
• wenn Zitate des Anbieters an die Stelle von Betriebsvereinbarungen und Aufsichtsdokumenten treten;
• wenn „ohne Public-Cloud-Zwang“ als „bereits souverän betrieben“ gelesen wird und der Beta-Status übersprungen wurde.

Vor dem nächsten Quartal empfiehlt sich, drei Hypothesen festzulegen, bevor Investitions- und Betriebsmittel umgeschichtet werden. Bei der Integration lautet sie etwa: Die Zuordnung der Felder nach ISO 20022 erreicht bei einer festgelegten Zahl von Testfällen eine Fehlerquote unter einem Grenzwert. Bei den Schlüsseln: Schlüsselzeremonie und Vier-Augen-Freigabe laufen in einem Zeitbudget mit dokumentiertem Prüfpfad. Bei der Abwicklung: Der Abgleich zwischen Ledger-Verpflichtung und RTGS-Endgültigkeit ist reproduzierbar, einschließlich geregelter Ausnahmebehandlung. Auf jeder Folie zu Token-Einlagen sollten drei Spalten stehen: die Angaben des Anbieters, also Anschluss, Besu, Adapter-Beta, On-Prem-Beta, weniger als neun Monate und mehr als 40 Institute. Dazu kommt, was endgültig bleibt, nämlich Abwicklung über RTGS und Finanzmarktinfrastrukturen, Swift als Nachrichtennetz und der Beta-Status. Die dritte Spalte enthält den eigenen Messplan mit Hypothesen, Euro pro Quartal und Abbruchkriterien. Wer die dritte Spalte streicht, verfälscht die Entscheidungsgrundlage.

Für Pilotteilnehmer ist der Ledger-Anschluss ein ernstzunehmender Infrastrukturschritt mit Wallet, Besu, Steuerungswerkzeugen und ISO-20022-Brücke in der Beta. Häuser ohne Pilotzugang beobachten besser, lesen die Architektur und hängen die eigene Roadmap nicht an fremde Aktivierungsmeldungen. Dieselbe Hygiene gilt bei Fragen zu Vertraulichkeit und lokaler Kontrolle im Umgang mit KI und Daten, wie sie die kritischen Vertraulichkeitslücken zeigen: Souveränität ist ein Nachweis und kein Marketingwort. Haven On-Prem kann dafür ein Baustein sein, solange das Haus ihn als Beta behandelt und Anschluss und Eigenbetrieb getrennt budgetiert und abnimmt.