Blockchain und Mainframe wurden lange Zeit beinahe wie Gegensätze behandelt. Auf der einen Seite stand die Vorstellung einer neuen, dezentralen Finanzwelt, in der Distributed Ledger klassische zentrale Systeme überflüssig machen könnten. Auf der anderen Seite standen die großen Kernbanksysteme auf dem Mainframe, die seit Jahrzehnten Konten führen, Zahlungen verarbeiten und dafür sorgen, dass geschäftskritische Finanzprozesse zuverlässig funktionieren.
Diese Gegenüberstellung war schon immer etwas zu einfach. Interessant wird sie aber spätestens jetzt, weil digitale Assets und tokenisierte Einlagen langsam die Experimentierphase verlassen und näher an reale Bankprozesse heranrücken.
IBM hat am 24. September angekündigt, IBM Digital Asset Haven mit dem blockchainbasierten Shared Ledger von Swift zu verbinden. Gleichzeitig soll Digital Asset Haven in einer On-Premises-Variante vollständig im eigenen Rechenzentrum auf IBM Z beziehungsweise LinuxONE betrieben werden können. Damit treffen zwei Welten aufeinander, die in der öffentlichen Diskussion häufig getrennt betrachtet wurden: neue Formen digitaler Finanztransaktionen und klassische Enterprise-Infrastruktur.
Gerade deshalb ist diese Entwicklung interessanter als die alte Frage, ob Blockchain den Mainframe irgendwann ersetzen könnte. Sobald aus einer technologischen Idee ein echter Bankprozess wird, verändern sich nämlich die Anforderungen. Dann reicht es nicht mehr, dass eine Transaktion technisch auf einem Ledger ausgeführt werden kann. Sie muss zuverlässig verarbeitet werden, regulatorischen Vorgaben entsprechen, revisionssicher nachvollziehbar bleiben und sich in bestehende Zahlungsverkehrs-, Compliance- und Kernbankensysteme integrieren lassen.
Und plötzlich wirken viele Anforderungen erstaunlich vertraut.
IBM Digital Asset Haven bündelt unter anderem Wallet- und Transaktionsmanagement für digitale Assets. Die Plattform soll künftig auch On-Premises auf IBM Z und LinuxONE betrieben werden können. (Quelle: IBM)
Tokenisierte Einlagen sind keine Kryptowährung mit Banklogo
Zunächst lohnt sich eine begriffliche Einordnung. Tokenisierte Einlagen werden gelegentlich zusammen mit Stablecoins, Kryptowährungen und anderen Digital Assets genannt, wirtschaftlich handelt es sich jedoch um etwas anderes.
Die Bank for International Settlements (BIS) beschreibt tokenisierte Einlagen als Forderungen gegenüber einer Geschäftsbank, die auf einer programmierbaren beziehungsweise tokenisierten Infrastruktur repräsentiert werden. Sie bleiben damit grundsätzlich Bankeinlagen und damit Verbindlichkeiten der jeweiligen Bank.
Ein Kunde besitzt also nicht plötzlich Kryptowährung, nur weil eine Bank seine Einlage technisch auf einem Distributed Ledger repräsentiert. Hinter dem Token steht weiterhin die Forderung gegenüber der Bank.
Genau diese Verbindung zwischen neuer technischer Infrastruktur und bekannten bankwirtschaftlichen Strukturen macht tokenisierte Deposits interessant. Sie könnten bestimmte Vorteile programmierbarer Ledger nutzen, ohne zwangsläufig ein neues monetäres Paralleluniversum zu schaffen.
Noch befinden wir uns dabei nicht im Alltag des Retail Banking. Tokenisierte Einlagen werden derzeit vor allem für Wholesale-Szenarien untersucht. Trotzdem verändert sich die Diskussion bereits sichtbar, weil sich Banken zunehmend mit der Frage beschäftigen, wie solche Modelle in bestehende Finanzmarktinfrastrukturen integriert werden können.
Swift bringt Blockchain näher an den realen Zahlungsverkehr
Besonders interessant ist deshalb die Entwicklung bei Swift. Das Zahlungsnetzwerk hat gemeinsam mit mehr als 40 Finanzinstituten an einem blockchainbasierten Ledger gearbeitet. Im Juli 2026 meldete Swift, dass 17 Banken aus sechs Kontinenten den Einsatz für tokenisierte grenzüberschreitende Zahlungen vorbereiten. Ziel sind unter anderem eine durchgängige Verfügbarkeit von Zahlungen und ein effizienterer Umgang mit Liquidität.
Das ist noch kein flächendeckender Produktionsbetrieb, aber eben auch kein klassisches Blockchain-Laborexperiment mehr.
Parallel dazu zeigen Projekte wie Project Agorá, an dem Zentralbanken, Geschäftsbanken und weitere Finanzinstitutionen beteiligt sind, wie tokenisierte Geschäftsbankeinlagen und tokenisierte Zentralbankreserven in neuen Abwicklungsmodellen zusammenspielen könnten. Eine Zusammenfassung zu Project Agorá findet sich bei der Europäischen Zentralbank.
Damit verschiebt sich die Fragestellung. Es geht zunehmend weniger darum, Blockchain als Selbstzweck einzusetzen, sondern darum, ob programmierbare Ledger konkrete Probleme im internationalen Zahlungsverkehr lösen können, etwa bei Geschwindigkeit, Liquidität und der Koordination verschiedener Beteiligter.
An genau dieser Stelle wird die Mainframe-Perspektive interessant.
Sobald Blockchain produktiv wird, kommen die bekannten Anforderungen zurück
Ein Proof of Concept mit einigen Testtransaktionen lässt sich relativ überschaubar betreiben. In einer Bank sieht die Situation anders aus, sobald eine Technologie Teil des produktiven Zahlungsverkehrs wird.
Dann muss geklärt werden, wer Transaktionen freigeben darf, wie Identitäten verwaltet werden, wo kryptografische Schlüssel liegen und wie Vier-Augen-Prinzipien technisch umgesetzt werden. Ebenso wichtig werden Auditierbarkeit, Hochverfügbarkeit, Disaster Recovery, Monitoring und Integration in vorhandene Bankprozesse.
Damit nähert sich eine Digital-Asset-Plattform sehr schnell genau den Anforderungen an, mit denen Banken ihre klassischen Kernsysteme seit Jahrzehnten betreiben.
IBM Digital Asset Haven soll deshalb nicht einfach nur eine Blockchain-Schnittstelle liefern, sondern Funktionen für Wallets, Transaktionsmanagement, Governance, Berechtigungen und Schlüsselmanagement miteinander verbinden.
Interessant ist also weniger, dass irgendwo Blockchain eingesetzt wird. Spannend ist, dass Blockchain zunehmend in eine Enterprise-Betriebsarchitektur eingebettet wird.
ISO 20022 könnte wichtiger werden als die Blockchain selbst
Ein Detail der aktuellen IBM-Ankündigung halte ich für besonders relevant. Digital Asset Haven soll über einen ISO-20022-Messaging-Adapter mit dem Swift-Ledger kommunizieren können. Banken könnten damit tokenisierte Deposit-Transaktionen über Nachrichten anweisen, deren Grundprinzip sie aus dem bestehenden Zahlungsverkehr bereits kennen.
Das klingt deutlich weniger spektakulär als Blockchain, könnte für die tatsächliche Einführung aber wesentlich wichtiger sein.
Eine der größten Herausforderungen neuer Technologien besteht schließlich selten darin, dass sie prinzipiell funktionieren. Schwieriger ist meistens ihre Einbindung in bestehende Systeme, Prozesse und Kontrollmechanismen.
Wenn sich vorhandene ISO-20022-Prozesse weiterverwenden lassen, sinkt diese Integrationshürde. Tokenisierung wird dadurch weniger zu einer komplett neuen Welt und stärker zu einer zusätzlichen Verarbeitungsform innerhalb einer vorhandenen Zahlungsverkehrsarchitektur.
Gerade für Mainframe-Anwendungen ist das interessant. Ein bestehendes Kernbankensystem muss nicht selbst zur Blockchain-Anwendung werden, nur weil eine Bank tokenisierte Einlagen anbieten möchte. Es braucht vielmehr eine klar definierte und kontrollierte Schnittstelle in die neue Welt.
Das entspricht einem Modernisierungsansatz, den wir auch aus anderen Bereichen kennen: Nicht jede bestehende Anwendung muss vollständig ersetzt oder neu geschrieben werden, nur weil eine neue Fähigkeit hinzukommt.
Der Mainframe muss nicht selbst zur Blockchain werden
Auch technisch lohnt sich eine klare Trennung. Wenn Digital Assets auf IBM Z oder LinuxONE betrieben werden, bedeutet das nicht, dass z/OS plötzlich zum Blockchain-Betriebssystem wird oder bestehende COBOL-Anwendungen künftig direkt Smart Contracts ausführen müssen.
Die angekündigte On-Premises-Version von Digital Asset Haven soll auf IBM Z und LinuxONE in einer kundenseitig kontrollierten Red-Hat-OpenShift-Umgebung betrieben werden. Die Digital-Asset-Funktionen bleiben damit architektonisch eigenständig, befinden sich aber sehr nahe an den bestehenden Kernsystemen.
Genau diese Trennung kann sinnvoll sein. Ein Core-Banking-System kann weiterhin die Geschäftslogik übernehmen, für die es gebaut wurde, während eine neue Digital-Asset-Schicht Wallets, Blockchain-Konnektivität, Governance und On-Chain-Transaktionen bereitstellt.
Entscheidend wird dann die Integration zwischen beiden Welten.
Bei digitalen Assets wird Schlüsselmanagement zum Geschäftsprozess
Eine Besonderheit digitaler Assets macht den Infrastrukturansatz zusätzlich interessant. Kryptografische Schlüssel sind hier nicht nur technische Hilfsmittel. Wer einen privaten Schlüssel kontrolliert, kann unter Umständen unmittelbar über einen digitalen Vermögenswert verfügen.
Damit wird Key Management vom reinen Security-Thema zu einem Bestandteil des Geschäftsprozesses.
IBM setzt deshalb unter anderem auf Hardware Security Modules, Multi-Party Computation und Offline Signing. Crypto-Express-Adapter von IBM Z und LinuxONE können als HSMs betrieben werden, wobei sichere Schlüssel innerhalb der Hardware verarbeitet werden und ihr Klartextwert dem Betriebssystem nicht zugänglich sein muss. IBM beschreibt diese Möglichkeiten in seiner Dokumentation zu Hardware Security Modules.
Für regulierte Finanzinstitute ist das relevant, weil nicht nur die technische Sicherheit eines Schlüssels zählt. Ebenso wichtig sind Prozesse für Erzeugung, Freigabe, Rotation, Nutzung und gegebenenfalls Wiederherstellung.
Spätestens hier zeigt sich, warum die Gegenüberstellung „Blockchain oder Mainframe“ wenig hilfreich ist. Bei produktiven Digital Assets geht es nicht nur um das Ledger, sondern um die gesamte Infrastruktur darum herum.
On-Premises bringt Kontrolle, aber auch Verantwortung
Die neue On-Premises-Variante von Digital Asset Haven dürfte vor allem für Institute interessant sein, die Infrastruktur und Schlüsselmanagement im eigenen Rechenzentrum behalten möchten.
Das kann aus regulatorischen, betrieblichen oder strategischen Gründen sinnvoll sein. Es bedeutet allerdings nicht, dass die Plattform dadurch automatisch einfacher oder sicherer wird.
Mehr Kontrolle bringt immer auch mehr Verantwortung mit sich. Patchmanagement, Monitoring, Kapazitätsplanung, Hochverfügbarkeit, Recovery und Security Operations müssen dann selbst beherrscht oder durch entsprechende Partner abgedeckt werden.
Gerade bei neuen Technologien ist dieser Punkt wichtig. Digitale Souveränität entsteht nicht allein dadurch, dass ein Server im eigenen Rechenzentrum steht. Sie setzt voraus, dass Know-how und Betriebsprozesse vorhanden sind, um die Plattform tatsächlich kontrollieren zu können.
Damit schließt sich der Kreis zu vielen anderen Mainframe-Themen. Die Technik ist häufig nur ein Teil des Problems. Mindestens ebenso wichtig ist das Verständnis der Abhängigkeiten, die durch neue Architekturen entstehen.
Neue Assets treffen auf bestehende Geschäftslogik
Für mich wird das Thema besonders interessant, wenn tokenisierte Einlagen mit vorhandenen Kernbankensystemen verbunden werden.
Eine Bank beginnt mit Digital Assets schließlich nicht bei null. Kunden, Konten, Limits, Compliance-Regeln, Buchungslogik und Berechtigungskonzepte existieren bereits. Eine neue tokenisierte Transaktion muss in diese Welt eingebunden werden.
Ein erheblicher Teil der wirklich wertvollen Geschäftslogik bleibt deshalb in den vorhandenen Anwendungen bestehen. Eine Blockchain kann einen neuen technischen Transaktionsweg bereitstellen, ersetzt aber nicht automatisch die fachlichen Regeln, nach denen eine Bank arbeitet.
Gerade deshalb halte ich die übliche Gegenüberstellung von „alt“ und „neu“ für wenig hilfreich. Die interessantere Architektur dürfte häufig darin bestehen, vorhandene und neue Systeme mit klar definierten Verantwortlichkeiten miteinander zu verbinden.
Dabei stellen sich sehr klassische Fragen: Welches System hält den führenden fachlichen Zustand? Wo findet die Autorisierung statt? Wer kontrolliert die Schlüssel? Wie werden Transaktionen zwischen beiden Welten abgeglichen? Welche Systeme müssen gemeinsam verfügbar sein und wie sieht die Wiederherstellung nach einem Ausfall aus?
Diese Fragen wirken nicht besonders futuristisch. Sie entscheiden aber darüber, ob aus einem interessanten Demonstrator ein belastbarer Bankprozess wird.
Vielleicht bekommt IBM Z damit eine zusätzliche Rolle
IBM Z wird im Bankenumfeld traditionell mit Kernbankensystemen, Zahlungsverkehr, Kartenverarbeitung und hohen Transaktionsvolumina verbunden. Mit Digital Assets könnte sich diese Rolle erweitern.
Der Mainframe beziehungsweise LinuxONE muss dabei nicht das eigentliche Distributed Ledger bereitstellen. Die Plattform kann vielmehr zum sicheren Betriebsfundament werden, auf dem kritische Digital-Asset-Funktionen laufen und mit klassischen Bankprozessen verbunden werden.
Das ist ein interessanter Perspektivwechsel. Der Mainframe wird dadurch nicht relevant, weil er alte Technologien schützt, sondern weil bestimmte Eigenschaften auch für neue Technologien wertvoll bleiben.
Hohe Verfügbarkeit verliert schließlich nicht an Bedeutung, nur weil eine Transaktion tokenisiert wird. Kryptografischer Schutz wird nicht weniger wichtig, weil ein Ledger verteilt arbeitet, und Auditierbarkeit verschwindet ebenfalls nicht, wenn Smart Contracts zum Einsatz kommen.
Je näher Digital Assets an reale Finanzinfrastruktur rücken, desto wichtiger werden genau diese Anforderungen.
Aus „Blockchain gegen Bank“ wird Integration
Die frühe Blockchain-Diskussion war stark von Gegensätzen geprägt. Dezentralisierung stand gegen zentrale Systeme, Kryptowährungen gegen Banken und Blockchain gegen etablierte Finanzinfrastruktur.
Inzwischen zeichnet sich ein pragmatischeres Bild ab. Swift integriert Blockchain-Technologie in seine bestehende internationale Zahlungsverkehrsinfrastruktur, IBM verbindet diese Welt mit ISO 20022, HSMs und klassischen Enterprise-Betriebsmodellen, während Zentralbanken und Geschäftsbanken gemeinsam untersuchen, wie tokenisierte Geschäftsbankeinlagen und Zentralbankgeld in neuen Abwicklungsmodellen zusammenwirken können.
Das klingt weniger revolutionär als manche Vision von vor zehn Jahren, dürfte dafür aber deutlich näher an der Realität liegen.
Technologischer Fortschritt besteht eben nicht immer darin, bestehende Infrastruktur vollständig zu beseitigen. Häufig entsteht der eigentliche Nutzen dann, wenn neue Technologien dort eingebunden werden, wo sie ein konkretes Problem besser lösen.
Für die Mainframe-Modernisierung steckt darin eine wichtige Lektion
Digital Asset Haven ist deshalb nicht nur ein Blockchain- oder Banking-Thema. Es zeigt auch etwas über Mainframe-Modernisierung.
Modernisierung bedeutet nicht zwangsläufig, eine bestehende Plattform durch eine andere zu ersetzen. Sie kann genauso darin bestehen, neue Funktionen so mit vorhandenen Systemen zu verbinden, dass beide Seiten ihre jeweiligen Stärken behalten.
Ein COBOL-basiertes Kernbanksystem muss nicht selbst tokenisiert werden, nur weil eine Bank tokenisierte Einlagen anbieten möchte. Der bestehende Zahlungsverkehr muss ebenfalls nicht komplett neu entwickelt werden, nur weil zusätzlich ein Blockchain-Ledger verwendet wird.
Entscheidend ist vielmehr, die Grenzen und Verantwortlichkeiten zwischen den Systemen sauber zu gestalten.
Noch befinden sich viele dieser Konzepte in einer frühen Phase. IBM spricht ausdrücklich von Beta-Angeboten, Swift arbeitet zunächst mit 17 Early-Adopter-Banken, und auch die BIS weist darauf hin, dass tokenisierte Deposits bislang vor allem in Wholesale-Szenarien untersucht werden.
Trotzdem ist die Richtung bemerkenswert.
Aus Blockchain als vermeintlichem Gegenentwurf zur klassischen Bankinfrastruktur wird zunehmend Blockchain innerhalb regulierter Finanzinfrastruktur.
Und genau dort könnte IBM Z eine Rolle spielen, die auf den ersten Blick überraschend wirkt, bei genauerem Hinsehen aber ziemlich logisch ist. Sobald digitale Assets zu echten Bankprozessen werden, zählen nicht nur Innovation und Geschwindigkeit, sondern wieder jene Eigenschaften, die Finanzinfrastruktur schon immer brauchte: Verfügbarkeit, Sicherheit, Kontrolle, Integration und Vertrauen.
Mit diesen Anforderungen kennt sich der Mainframe seit vielen Jahren ziemlich gut aus.
Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet
