Skip to content
RiverCore
IBM setzt darauf, dass Banken tokenisierten Einlagen nicht der Cloud vertrauen
tokenized depositsIBM Zdigital asset custodyIBM on-prem tokenized deposit bankingSwift shared ledger tokenized assets

IBM setzt darauf, dass Banken tokenisierten Einlagen nicht der Cloud vertrauen

24 Sep 20267 Min. LesezeitMarina Koval

Jeder Platform-Lead bei einer regulierten Bank, der einen Fahrplan für tokenisierte Einlagen bis 2026 vor sich hat, muss vor dem Q4-Abschluss noch ein Vendorgespräch führen. IBM hat dem Markt gerade mitgeteilt, dass der institutionelle Digital-Asset-Stack nicht auf einem Hyperscaler leben muss – und das Timing fiel auf einen Swift-Pilot, an dem bereits Citi, HSBC, UBS, BNY und Wells Fargo beteiligt sind. Das ist kein Produktlaunch, das ist ein Positionierungszug gegen jeden krypto-nativen Custody-Anbieter, der in den letzten drei Jahren eine Cloud-first-Architektur an Tier-1-Banken verkauft hat.

Was passiert ist

IBM kündigte zwei Neuerungen an seiner Digital Asset Haven Plattform für regulierte Finanzinstitute an – und die Marktreaktion war verhalten: Die Aktie rutschte im vorbörslichen Handel am Donnerstag um 0,4 % ab, während das Retail-Sentiment auf Stocktwits von bullish auf neutral abkühlte, wie TradingView berichtete. Die Kursreaktion verkennt das strategische Gewicht des Gelieferten.

Das erste Update verbindet Digital Asset Haven Clients mit Swifts blockchain-basiertem Shared Ledger – jenem Ledger, den Swift auf der Sibos 2025 vorgestellt hat und der auf einem Prototyp von Consensys basiert. Swift verbindet mehr als 12.500 Finanzinstitute in mehr als 200 Märkten. Das Ledger wurde gemeinsam mit mehr als 40 Banken entwickelt und in neun Monaten vom ersten Konzept bis zur Live-Nutzung gebracht – ein Liefertempo, das jeder als ungewöhnlich aggressiv einschätzen wird, der innerhalb eines regulierten Konsortiums geliefert hat. Siebzehn Early-Adopter-Institute, darunter Citi, HSBC, UBS, BNY und Wells Fargo, pilotieren derzeit tokenisierte Einlagentransaktionen auf diesem Ledger.

IBMs Einstieg in diesen Pilot ist ein neues Produkt namens ISO 20022 Messaging Adapter, mit dem Banken Ledger-Transaktionen über die Standard-Zahlungs-Messaging-Formate instruieren können, die sie bereits über ihre bestehenden Rails betreiben. In IBMs Darstellung gibt die Anbindung an Swift Banken die Möglichkeit, über standardisiertes ISO 20022 Payment Messaging teilzunehmen, ohne ihre Integrationsschicht neu aufzubauen.

Das zweite Update ist dasjenige, das die Vendor-Rechnung verändert. Digital Asset Haven kann jetzt vollständig auf der eigenen IBM Z- oder LinuxONE-Hardware eines Kunden betrieben werden – ohne Verbindung zur Public Cloud. Software und kryptografisches Key Management verbleiben in der Umgebung der Bank, unterstützt durch Crypto Express Hardware Security Modules und formale Key-Ceremony-Prozesse, die darauf ausgelegt sind, Dokumentation für Aufsichtsbehörden zu erzeugen. IBM zitiert J.P. Morgan Payments Research, wonach 93 % der Finanzinstitute ihre Zahlungsinfrastruktur modernisieren, um den Nachfragehintergrund zu verdeutlichen.

Technische Struktur

Zwei Design-Entscheidungen sind hier relevant, und sie zeigen in dieselbe Richtung: Die Krypto-Oberfläche innerhalb der bestehenden Control Plane der Bank belassen.

Beginnen wir mit der Swift-Integration. Ein blockchain-basiertes Shared Ledger hinter einem ISO 20022 Messaging Adapter ist architektonisch bewusst unspektakulär. Banken haben bereits Core-Banking-Systeme, Sanktionsscreening, Fraud-Engines und Reconciliation-Pipelines, die an ISO 20022-Flows angebunden sind. Wenn tokenisierte Einlagen als weiterer Nachrichtentyp über dasselbe Adapter-Muster ankommen, wird die operationelle Risikobewertung zu einem inkrementellen Delta statt zu einem Greenfield-Build. Das ist der Unterschied zwischen einer sechsmonatigen und einer zweijährigen Integration. Consensys hat den Prototyp gebaut, daher borgt sich das zugrundeliegende Ledger mit hoher Wahrscheinlichkeit stark von ethereum-geprägten Account- und State-Modellen, auch wenn Swift die Details des Produktions-Stacks eng hält. Wer Enterprise-Ledger-Tooling baut, sollte den aktuellen Stand der Ethereum-Spezifikationen lesen, um zu verstehen, welche Muster institutionelle Rückendeckung erhalten.

Nun zur On-Prem-Seite. Der Betrieb von Digital Asset Haven auf IBM Z oder LinuxONE mit Crypto Express HSMs und ohne Public-Cloud-Abhängigkeit bewirkt drei Dinge gleichzeitig. Er hält den kryptografischen Root of Trust physisch im Rechenzentrum der Bank – genau das, was ein General Counsel sehen möchte, wenn der Regulator fragt, wer einen Zugriff auf Schlüssel erzwingen kann. Er entfernt den Hyperscaler aus dem Audit-Boundary, was eine ganze Klasse von Third-Party-Risk-Fragebögen aus dem Due-Diligence-Zyklus streicht. Und er ermöglicht es der Bank, formale Key-Ceremony-Prozesse durchzuführen – dieselbe Art choreografierter Multi-Party-Rituale, die für Certificate Authorities und Payment-Card-Master-Keys verwendet werden –, mit Dokumentation, die für Aufseher aufbereitet ist.

Die Folge ist, dass die Krypto-Custody-Frage aufhört, eine neuartige Kategorie zu sein, und stattdessen wie eine Erweiterung bestehender HSM-Governance aussieht. Für eine Bank, die bereits Mainframe-Workloads betreibt, ist das ein vertrautes Betriebsmodell. Für einen krypto-nativen Custody-Anbieter, der eine SaaS Control Plane bewirbt, ist es eine erheblich schwieriger zu verkaufende Geschichte gegenüber einem CISO, der keine neue Angriffsfläche außerhalb des Perimeters haben möchte.

Wer Federn lässt

Die offensichtlichen Verlierer sind die Cloud-first institutionellen Custody-Anbieter. Fireblocks, BitGo, Anchorage und jedes Startup, das „enterprise-grade" Custody auf AWS oder GCP bewirbt, müssen jetzt eine Frage beantworten, die sie vor sechs Monaten noch nicht beantworten mussten: Warum sollten Key Material und tokenisierte Einlagen-Ledger überhaupt einen Hyperscaler berühren, wenn IBM dieselbe Funktionalität im eigenen Rechenzentrum der Bank liefert – inklusive einer regulatorisch validen Key Ceremony? Das ist ein hartes Gegenargument, wenn der Käufer eine Tier-1-Bank mit bestehenden IBM Z-Verträgen ist.

Die Hyperscaler selbst erhalten einen subtileren Treffer. AWS, Azure und Google Cloud haben Confidential Computing und Nitro-ähnliche Enclaves als Antwort auf Bank-Krypto-Workloads positioniert. IBMs Schritt rahmt diesen Pitch als unzureichend für den wertvollsten Use Case ein: tokenisierte Einlagen, die über Swift bewegt werden. Erwarten Sie innerhalb von zwei Quartalen eine schnelle Gegenbewegung von mindestens einem Hyperscaler – wahrscheinlich verpackt als dedizierte Financial-Services-Region mit vertraglichen Key-Sovereignty-Garantien.

Der CFO eines jeden Series-B-Custody- oder Tokenisierungs-Startups, das an Banken verkauft, sollte diese Woche seinen Vertriebsleiter fragen, ob die Pipeline davon ausgeht, dass Cloud-Deployment selbstverständlich ist – denn diese Annahme ist gerade schwächer geworden. Wenn die Hälfte der Deals in der Pipeline On-Prem- oder Hybrid-Delivery erfordert, um abgeschlossen zu werden, ist der Engineering-Headcount-Plan für 2026 falsch und die Burn-Rate-Rechnung muss neu aufgestellt werden.

Public-Chain-Infrastruktur-Teams spüren das auch indirekt. Swifts Ledger, das mit 40+ Banken entwickelt und jetzt von 17 pilotiert wird – darunter die größten Namen im Korrespondenzbankgeschäft –, ist ein konkurrierendes Settlement-Fabric für tokenisiertes Cash. Es muss nicht bei Dezentralisierung gewinnen, es muss bei regulatorischer Klarheit und Kompatibilität mit bestehenden Rails gewinnen. Auf diesen Achsen startet es vorne.

Playbook für Krypto und DeFi

Für Teams, die im institutionellen Krypto-Umfeld tätig sind, haben die nächsten 90 Tage eine klare Form.

Wenn Sie Custody- oder Tokenisierungssoftware an Banken verkaufen, liefern Sie dieses Quartal eine On-Prem- oder Bring-your-own-HSM-Deployment-Option. Nicht eine Roadmap-Folie, sondern eine echte Referenzarchitektur mit einem Key-Ceremony-Runbook. Die Käufererwartung hat sich gerade verschoben. Wenn Ihr Produkt nicht ohne Ihren Cloud-Tenant im Trust-Boundary läuft, konkurrieren Sie beim Preis gegen eine Geschichte, mit der Sie nicht mithalten können.

Wenn Sie ein DeFi-Protokoll betreiben, das auf institutionelle Liquidität abzielt, gehen Sie davon aus, dass tokenisierte Einlagen zuerst auf permissioned Rails abgerechnet und erst dann in Public Chains überbrückt werden. Gestalten Sie Ihre Integrationsoberfläche so, dass eine bankseitige tokenisierte Einlage über eine Wrapped-Darstellung in Ihr Protokoll eintreten kann, ohne dass die Bank eine Public-Chain-Wallet berühren muss. Das ISO 20022-Nachrichten-Muster ist das Signal: Institutionen wollen instruieren, nicht signieren.

Wenn Sie zu regulatorischer Positionierung beraten, überprüfen Sie das SEC-Regelwerk anhand eines Szenarios, in dem tokenisierte Einlagen-Settlement innerhalb von 18 Monaten zur Standard-Bankinfrastruktur wird. Die Definitionen für Custody, Transfer Agent und Broker-Dealer werden alle in einer Welt einem Stresstest unterzogen, in der das Ledger innerhalb der Bank liegt und Swift das Messaging routed.

Wenn Sie einstellen, wird der Markt für Engineers, die sowohl HSM Key Ceremonies als auch EVM-nahe Ledger-Semantik verstehen, sehr bald sehr eng werden. Dieses Skill-Set findet sich vielleicht bei einigen hundert Menschen weltweit. Sichern Sie sich die, die Sie haben, mit Retention-Paketen, bevor die Banken anfangen, Schecks auszustellen.

Der GC eines jeden Custody- oder Tokenisierungs-Anbieters sollte seinen Platform-Leiter diese Woche fragen, ob die aktuelle Architektur ein Kunden-RFP überstehen kann, das kein vendor-kontrolliertes Cloud im Key-Management-Pfad erfordert. Wenn die Antwort nein ist, ist das ein Gespräch auf Vorstandsebene, kein Engineering-Ticket.

Wichtigste Erkenntnisse

  • IBM hat sowohl einen Swift-Ledger-Connector via ISO 20022 Messaging Adapter als auch eine vollständig On-Prem-Bereitstellung von Digital Asset Haven auf IBM Z oder LinuxONE geliefert – gezielt auf den 17-Banken-Swift-Pilot mit Citi, HSBC, UBS, BNY und Wells Fargo ausgerichtet.
  • Die On-Prem-Option mit Crypto Express HSMs und formalen Key Ceremonies rahmt Bank-Krypto-Custody als Erweiterung bestehender Mainframe-Governance ein – nicht als neuartigen Cloud-Workload.
  • Cloud-first institutionelle Custody-Anbieter müssen jetzt begründen, warum Key Material überhaupt einen Hyperscaler berührt – ein erheblich schwierigeres Verkaufsgespräch als noch letztes Quartal.
  • Dass Swift in neun Monaten mit 40+ Co-Designerbanken vom Konzept zur Live-Nutzung übergegangen ist, signalisiert, dass permissioned tokenisierte Einlagen-Rails bei regulatorischen und Integrations-Achsen vor der institutionellen Adoption öffentlicher Chains liegen.
  • Teams, die institutionelle Krypto-Infrastruktur evaluieren, sollten jetzt fragen, ob ihr Anbieter dieses Quartal – nicht nächstes Jahr – eine On-Prem-Referenzarchitektur mit einem regulatorisch validen Key-Ceremony-Runbook liefern kann.

Häufig gestellte Fragen

F: Was ist Swifts blockchain-basiertes Shared Ledger und wer pilotiert es?

Swift hat auf der Sibos 2025 ein blockchain-basiertes Shared Ledger vorgestellt, das auf einem Prototyp von Consensys basiert und gemeinsam mit mehr als 40 Banken entwickelt wurde. Siebzehn Early-Adopter-Institute, darunter Citi, HSBC, UBS, BNY und Wells Fargo, pilotieren derzeit tokenisierte Einlagentransaktionen darauf.

F: Warum ist IBMs On-Premises-Bereitstellung von Digital Asset Haven für Banken relevant?

Die On-Prem-Option läuft vollständig auf der eigenen IBM Z- oder LinuxONE-Hardware eines Kunden ohne Public-Cloud-Verbindung und hält Software und kryptografisches Key Management innerhalb der Bank. Sie wird durch Crypto Express HSMs und formale Key-Ceremony-Prozesse unterstützt, die darauf ausgelegt sind, Dokumentation für Aufsichtsbehörden zu erzeugen, was die aufsichtliche Prüfung erheblich vereinfacht.

F: Wie fügt sich der ISO 20022 Messaging Adapter in die Swift-Integration ein?

Der Adapter ermöglicht es Banken, Transaktionen auf Swifts Shared Ledger über Standard-ISO-20022-Zahlungs-Messaging-Formate zu instruieren, die sie bereits betreiben. Das bedeutet, dass die Teilnahme an tokenisierten Einlagen-Flows auf der bestehenden Zahlungsinfrastruktur aufsetzen kann, anstatt eine Greenfield-Integrationsschicht zu erfordern.

MK
Marina Koval
RiverCore Analyst · Dublin, Ireland
TEILEN
// ÄHNLICHE ARTIKEL
StartseiteLösungenProjekteÜber unsKontakt
News06
Dublin, Irland · EUGMT+1
LinkedIn
🇩🇪DE