Blockchain in Banken: sinnvolle Use Cases

Für Banken ist Blockchain selten ein isoliertes Innovationsthema. Relevant wird DLT dort, wo Nachweise, Identität, Abwicklung, regulatorische Anforderungen und organisationsübergreifende Prozesse sauber zusammenkommen müssen.

Nicht jeder Bankprozess braucht Blockchain

Banken verfügen bereits über starke Kernsysteme, klare Kontrollprozesse und etablierte regulatorische Anforderungen. Deshalb ist Blockchain nicht automatisch die bessere Lösung. Sinnvoll wird sie vor allem dort, wo mehrere Parteien Datenstände, Nachweise oder Berechtigungen synchronisieren müssen und klassische Abstimmungsprozesse teuer oder langsam sind.

Die erste Frage lautet also nicht: „Welche Chain?“ Sondern: „Welcher Prozess leidet unter Abstimmung, Nachweisbarkeit oder fehlender Interoperabilität?“

Digitale Nachweise und Kundenprozesse

Ein naheliegendes Feld sind digitale Nachweise: Unternehmensdaten, Berechtigungen, Signatur- oder Vertretungsbefugnisse, Compliance-Informationen oder Dokumente, die wiederholt geprüft werden. Verifiable Credentials können helfen, solche Nachweise strukturierter und prüfbarer zu machen.

Besonders spannend wird es, wenn Nachweise nicht nur innerhalb einer Bank, sondern zwischen Banken, Kunden, Dienstleistern oder Behörden verwendet werden.

Abwicklung, Tokenisierung und Settlement

Weitere Use Cases liegen in Abwicklung, Tokenisierung und Settlement-nahen Prozessen. Hier ist die fachliche und regulatorische Einordnung besonders wichtig. Ein PoC sollte sehr klar beschreiben, welche Asset-Logik, Rollen, Risiken und Integrationspunkte geprüft werden.

Für viele Banken ist ein kleiner, fachlich sauberer Scope wertvoller als eine breite technische Demo. Das gilt insbesondere dann, wenn Compliance, Risikomanagement und IT früh eingebunden werden müssen.

Auditierbarkeit und interne Kontrollsysteme

Unveränderbare oder nachvollziehbare Protokollierung kann in bestimmten Prozessen hilfreich sein. Trotzdem muss genau geprüft werden, welche Daten gespeichert werden, wer Zugriff hat und welche Alternativen bestehen. Nicht alles, was auditierbar sein soll, gehört auf eine Blockchain.

Oft ist ein hybrider Ansatz sinnvoll: sensible Daten bleiben in bestehenden Systemen, während Nachweise, Hashes oder Statusinformationen so gestaltet werden, dass spätere Prüfungen einfacher werden.

Empfohlenes Vorgehen für Banken

Für Banken empfiehlt sich ein strukturiertes Vorgehen: Use Case priorisieren, Business-Nutzen beschreiben, regulatorische Annahmen dokumentieren, Rollenmodell klären und erst danach einen PoC definieren. Die Blockchain-Beratung sollte hier Fachbereich, IT, Compliance und Projektsteuerung zusammenbringen.

So entsteht keine Innovationsdemo, sondern eine belastbare Entscheidungsgrundlage.

Compliance als Designfaktor, nicht als Nachprüfung

In Banken darf Compliance nicht erst am Ende eines Blockchain-Projekts geprüft werden. Regulatorische Anforderungen, Datenschutz, Informationssicherheit, Outsourcing-Fragen, Aufbewahrung, Nachvollziehbarkeit und Verantwortlichkeiten beeinflussen bereits den Zuschnitt des Use Cases. Wer diese Punkte erst nach einer Demo diskutiert, riskiert, dass der Prototyp fachlich interessant, aber nicht anschlussfähig ist.

Deshalb sollte ein Bank-PoC von Beginn an mit Annahmen arbeiten: Welche Daten werden verarbeitet? Welche Rollen sind reguliert? Welche Systeme bleiben führend? Welche Nachweise dürfen außerhalb bestehender Kernsysteme entstehen? Welche Prüfung muss intern dokumentiert werden? Diese Annahmen machen den PoC nicht schwerfälliger, sondern entscheidungsfähiger.

Use Cases entstehen oft im Partnernetzwerk

Der größte Nutzen entsteht selten in einem vollständig bankinternen Prozess. Spannender sind Prozesse mit Kunden, anderen Finanzinstituten, Dienstleistern, Prüfern, Behörden oder Infrastrukturpartnern. Genau dort entstehen Abstimmungsaufwand, Medienbrüche und wiederholte Prüfungen. Blockchain und digitale Nachweise können helfen, wenn mehrere Parteien denselben Nachweis verwenden oder prüfen müssen.

Ein Beispiel ist die strukturierte Prüfung von Unternehmensnachweisen. Wenn eine Information mehrfach in ähnlicher Form angefragt, eingereicht und geprüft wird, kann ein digitaler Nachweisprozess langfristig effizienter sein. Der schwierige Teil liegt aber nicht nur in der Technik, sondern in gemeinsamen Datenmodellen, Akzeptanzregeln und Governance.

Was ein guter Banken-PoC beantworten sollte

• Welche konkrete Reibung im Bankprozess wird reduziert?
• Welche Parteien müssen Nachweise ausstellen, halten oder prüfen?
• Welche regulatorischen Annahmen sind kritisch?
• Welche Daten bleiben im Kernsystem und welche werden als Nachweis geteilt?
• Wie wird ein Fehler, Widerruf oder Rollenwechsel abgebildet?
• Welche Entscheidung kann die Bank nach dem PoC fundierter treffen?

Wenn ein PoC diese Fragen beantwortet, ist er auch dann wertvoll, wenn die Entscheidung am Ende gegen eine Blockchain-Lösung ausfällt. Denn die Bank hat dann Prozess, Risiko und Alternativen besser verstanden.

Datenqualität bleibt die Grundlage

Blockchain kann Datenstände nachvollziehbar machen, aber sie macht schlechte Daten nicht automatisch richtig. Für Banken ist daher entscheidend, welche Quelle fachlich führend ist, wie Daten validiert werden und wer für Korrekturen verantwortlich ist. Besonders bei Kundendaten, Unternehmensnachweisen und Compliance-Informationen ist diese Frage zentral.

Ein Bank-Use-Case sollte deshalb immer beschreiben, wie Daten entstehen, geprüft, aktualisiert und bei Fehlern korrigiert werden. Ohne diese Grundlage entsteht nur eine technisch robuste Ablage für fachlich unsichere Informationen.

Welche Use Cases zuerst prüfen?

Als Einstieg eignen sich Use Cases, die einen klaren Prozessschmerz haben, aber nicht sofort das gesamte Kernbankensystem berühren. Digitale Nachweise, Berechtigungen, Dokumentenprüfungen oder begrenzte Partnerprozesse sind oft besser geeignet als sehr breite Transformationsprogramme. Sie sind verständlich, prüfbar und erlauben eine realistische Risikoeinschätzung.

Weniger geeignet für den Anfang sind Themen, bei denen regulatorische, technische und organisatorische Unsicherheiten gleichzeitig maximal hoch sind. Dort sollte zuerst ein fachlicher Vorcheck stattfinden, bevor Budget in technische Umsetzung fließt.