Blockchain wird häufig im Zusammenhang mit Tokenisierung, Kryptowährungen oder dezentralen Marktplätzen diskutiert. Doch auch innerhalb der Organisation eines Asset Managers birgt die Technologie erhebliches Potenzial. Gerade bei illiquiden Private Market Assets, bei denen Prozesse komplex, datensensitiv und abteilungsübergreifend sind, könnte eine interne Blockchain als Integrations- und Dokumentationslayer dienen. Ziel ist nicht der radikale Systemersatz, sondern eine effizientere und revisionssichere Interaktion zwischen bestehenden Systemen wie IBOR und ABOR.

Disclaimer:

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Rechts-, Steuer- oder Finanzberatung dar. Die Informationen sollten vor Entscheidungen individuell geprüft werden.

1. Einleitung & zentrale Konzepte

Blockchain-Technologie, auch Distributed Ledger Technology (DLT) genannt, wird primär für externe Anwendungsfälle diskutiert. Doch ihre Kernmerkmale – eine verteilte, chronologische, fälschungssichere und nachvollziehbare Speicherung von Transaktionen – können auch interne Prozesse bei Asset Managern revolutionieren, insbesondere im komplexen Private Markets Umfeld. Eine interne Blockchain kann als Integrations- und Dokumentationslayer dienen, um die Interaktion zwischen Systemen und Abteilungen effizienter und revisionssicherer zu gestalten.

Zentrale Begriffe:

• Blockchain (Distributed Ledger): Eine verteilte Datenbank, in der Transaktionen chronologisch, fälschungssicher und nachvollziehbar gespeichert werden. Jeder neue Block enthält einen Hash des vorhergehenden Blocks, was eine Manipulationssicherheit gewährleistet.
• Permissioned Blockchain: Eine Blockchain mit eingeschränktem Zugriff – nur autorisierte Teilnehmer (z.B. bestimmte Abteilungen eines Asset Managers, ausgewählte externe Partner) dürfen Transaktionen validieren und einsehen. Dies ist für interne Anwendungsfälle typisch.
• Smart Contract: Ein selbstausführender Programmcode, der auf einer Blockchain gespeichert ist. Er definiert Regeln und Bedingungen für bestimmte Abläufe (z.B. Freigaben, Berechnungen, Auszahlungen) und führt diese automatisch aus, sobald die vordefinierten Bedingungen erfüllt sind. Die Ausführung erfolgt transparent und manipulationssicher.
• Hash: Eine Art digitaler Fingerabdruck, der eindeutig aus einem Datensatz generiert wird und dessen Unverändertheit beweist.
• Node: Ein Rechner im Blockchain-Netzwerk, der eine Kopie des Ledgers verwaltet und Transaktionen verarbeitet.
• Wallet / Key: Digitale Identitäten bzw. kryptografische Schlüssel (Public/Private Key-Paar), über die Transaktionen signiert und Zugriffsrechte gesteuert werden.

2. Potenziale für Datenintegration und Transparenz zwischen Abteilungen

Viele Asset Manager stehen vor der Herausforderung, operative Prozesse abteilungsübergreifend zu koordinieren: Kapitalabrufe, NAV-Freigaben, Gebührenberechnungen oder Side Letter Compliance laufen oft über verschiedene Systeme, Excel-Dateien und E-Mail-Freigaben. Dies führt zu Medienbrüchen, Inkonsistenzen und mangelnder Transparenz über den Status von Prozessen. Eine interne Blockchain kann hier als „Single Source of Truth“ für Prozessereignisse und Statusmeldungen dienen: Ein gemeinsam genutztes, nicht manipulierbares Ledger, das Freigaben, Parameteränderungen und Statusmeldungen transparent dokumentiert. Die Integration von Daten und Statusmeldungen zwischen bestehenden Systemen und der Blockchain erfolgt dabei über Schnittstellen (APIs).

Vorteile:

• Gesteigerte Transparenz: Alle relevanten Prozessschritte sind für autorisierte Teilnehmer in Echtzeit auf einem einzigen Ledger sichtbar.
• Verbesserte Datenintegration: Die Blockchain kann als sichere und standardisierte Schicht dienen, über die Systeme Daten und Statusmeldungen austauschen.
• Reduzierung von Medienbrüchen: Der Austausch von Informationen kann direkt systemisch erfolgen, anstatt über manuelle Schritte (z.B. E-Mails, Excel-Uploads).

3. Anwendungsfall in der Praxis: NAV-Freigabeprozess mit Blockchain

Ein typisches Beispiel für die Anwendung einer internen Blockchain ist die NAV-Freigabe. Aktuell berechnet das IBOR-System den NAV, verschiedene Abteilungen müssen diesen prüfen und freigeben (oft manuell), bevor die Daten in den ABOR übertragen und an das Reporting weitergegeben werden. Medienbrüche, unterschiedliche Versionen und fehlende Revisionssicherheit sind dabei die Regel.

Mit Blockchain kann der Prozess wie folgt technisch ablaufen:

• Datenpublikation (IBOR): Das IBOR-System erzeugt die finale NAV-Berechnung für einen Stichtag. Über eine API-Schnittstelle übermittelt das IBOR das Ergebnis (NAV-Wert, Hash der Berechnungsdaten, relevante Stammdaten-Verweise) an einen Middleware-Service. Dieser Service registriert die Informationen als unveränderliche Transaktion auf einem privaten, permissioned Blockchain-Ledger.
• Smart Contract-Logik: Ein vorab programmierter Smart Contract auf der Blockchain prüft, ob für die Freigabe des NAV bestimmte Bedingungen erfüllt sind, z.B. digitale Signaturen von vordefinierten Rollen (Legal, Risk, Accounting, ggf. externer Administrator). Die Signaturen erfolgen als Transaktionen direkt auf der Blockchain.
• Rollenbasierte Freigabe: Beteiligte Abteilungen greifen über ein sicheres Interface auf das Blockchain-Frontend zu, prüfen den NAV und signieren digital über private Schlüssel. Jede Signatur wird als separate Transaktion auf der Blockchain gespeichert und dem jeweiligen Freigabeschritt zugeordnet.
• Automatischer Trigger und Export: Sobald alle im Smart Contract definierten Bedingungen erfüllt sind (z.B. erforderliche Anzahl von Signaturen liegt vor), wird durch den Smart Contract automatisch ein Event ausgelöst. Dieses Event kann z.B. den automatischen Export des final freigegebenen NAVs in das ABOR-System triggern. Dies erfolgt idealerweise über eine API-Schnittstelle, die vom Middleware-Service verwaltet wird. Gleichzeitig wird ein Hash der exportierten Daten erstellt und auf dem Ledger dokumentiert.
• Dokumentation und Audit: Jeder Schritt des Prozesses – von der NAV-Erzeugung im IBOR (dokumentiert durch Hash auf der Blockchain) über die digitalen Freigaben mit Zeitstempel und verantwortlicher Rolle auf der Blockchain bis zum ABOR-Export-Hash – ist unveränderlich auf der Blockchain dokumentiert. Dies ermöglicht interne Audits und externe Revisionsprozesse ohne Medienbrüche und schafft eine nachvollziehbare Kette der Verantwortung.

Diese technisch gestützte Umsetzung reduziert manuelle Schnittstellen, verhindert Versionskonflikte und schafft eine transparente, revisionssichere Prozessdokumentation entlang der Systemgrenzen IBOR – Blockchain – ABOR.

4. Smart Contracts: Prozessautomatisierung mit selbstausführendem Code

Über die NAV-Freigabe hinaus können Smart Contracts interne Prozessschritte automatisieren und die Interaktion zwischen Systemen und Abteilungen vereinfachen:

• Performance Fee Trigger: Sobald die im Smart Contract hinterlegte Hurdle Rate oder Performance-Schwelle im IBOR erreicht ist (Information wird vom IBOR an die Blockchain übermittelt), kann der Smart Contract automatisch eine Benachrichtigung für das Accounting oder einen Prozess für die Carry-Berechnung im ABOR auslösen.
• Capital Call Workflow: Nach Genehmigung eines Kapitalabrufs durch das Investment Committee kann ein Smart Contract ein Capital Call Event auf dem Ledger erzeugen, das automatisch die nächsten Schritte im System (z.B. Generierung der Call-Briefe durch das IBOR, Aktualisierung der unfunded Commitments) triggert.
• Side Letter Event Management: Smart Contracts können Fristen aus Side Letters überwachen und bei Fälligkeit automatisch Benachrichtigungen für zuständige Abteilungen (Legal, Reporting) auslösen (z.B. Frist für MFN-Election naht, Reporting-Frist für bestimmten LP steht an).

Die Vorteile der Automatisierung durch Smart Contracts auf einer internen Blockchain sind: Reduzierung manueller Schritte, Eliminierung von Medienbrüchen, erhöhte Prozesstransparenz und eine lückenlose, manipulationssichere Dokumentation der Prozessausführung.

5. Technische und organisatorische Herausforderungen

Die Implementierung und Nutzung einer internen Blockchain ist mit verschiedenen Herausforderungen verbunden:

• Daten-Governance und Stammdaten: Klare Regeln zur Datenhoheit und zum Lebenszyklus von Daten auf der Blockchain sind notwendig. Die Verknüpfung von Blockchain-Transaktionen und Prozessereignissen mit konsistenten Stammdaten aus zentralen Registern (MDM/EDM) über Unique Identifiers ist essenziell für die Nachvollziehbarkeit über Systemgrenzen hinweg.

• Rollen- und Zugriffsmanagement: Ein detailliertes, rollenbasiertes Zugriffskonzept muss klar definiert und technisch umgesetzt werden, um zu steuern, wer auf der Blockchain welche Aktionen durchführen darf.

• Datenschutz: Sensible Inhalte dürfen nicht unverschlüsselt auf der Blockchain gespeichert werden. Verschlüsselungsmethoden und Mechanismen zur selektiven Sichtbarkeit müssen implementiert werden.

• Auditierbarkeit: Das interne Audit und externe Prüfer müssen den Ledger als nachvollziehbare und gültige Dokumentationsgrundlage akzeptieren und über die notwendigen Werkzeuge zur Prüfung verfügen.

• Schulung und Know-how-Aufbau: Beteiligte Abteilungen müssen für den Umgang mit blockchainbasierten Prozessen und die Funktionsweise der Technologie sensibilisiert und geschult werden.

Die Fähigkeit von bestehenden Systemen, über moderne APIs mit einer separaten Blockchain-Infrastruktur zu interagieren, ist dabei ein wichtiger Faktor für die **Zukunftssicherheit**. Systeme mit offenen und granularen Schnittstellen ermöglichen die Integration mit neuen Technologien und Plattformen, einschliesslich Blockchain, und bieten so mehr Agilität.

6. Pilotansätze und Sandbox-Anwendungen im internen Umfeld

Die Einführung von Blockchain-Technologie sollte nicht mit einem Big Bang erfolgen. Realistisch sind Pilotprojekte mit engem Scope, die den potenziellen Nutzen evaluieren und den Aufbau von Know-how ermöglichen:

• NAV-Freigabeprozess: Automatisierung und Dokumentation des Freigabeprozesses für NAVs.

• Performance Fee Dokumentation: Nachvollziehbare Dokumentation der Trigger und Auslöser für Performance Fee Berechnungen.

• Side Letter Event Management: Automatisierte Überwachung und Benachrichtigung bei Fälligkeit von Fristen oder Bedingungen aus Side Letters.

Solche Sandbox-Szenarien ermöglichen ein risikobegrenztes Testen und den Aufbau von Know-how, bevor breitere Rollouts erfolgen. Die Auswahl des ersten Anwendungsfalls sollte sich an einem Prozess orientieren, der aktuell von Medienbrüchen und manuellem Abstimmungsaufwand geprägt ist.

7. Fazit

Blockchain ist kein Allheilmittel, aber ein vielversprechender Baustein für mehr Transparenz, Integration und Automatisierung innerhalb des Asset Managers – vor allem dank ihrer spezifischen Eigenschaften. Im Vergleich zu herkömmlichen Workflow-Management-Systemen bietet Blockchain insbesondere Vorteile wie die Unveränderlichkeit gespeicherter Informationen, eine automatische und lückenlose Revisionsspur sowie die dezentrale Verifikation durch mehrere Parteien. Diese Merkmale schaffen Vertrauen in die Datenintegrität und ermöglichen eine prozesssichere Koordination zwischen Systemen wie IBOR und ABOR – ohne aufwändige manuelle Nachvollziehbarkeit oder medienbruchbehaftete Kontrollen.

Gerade in der Verwaltung illiquider Assets, wo Prozesse komplex und systemübergreifend sind, konsistente Stammdaten essenziell sind und die Zuverlässigkeit von Berechnungen (z.B. im IBOR) auf korrekten Daten basiert, kann ein interner Blockchain-Layer zwischen IBOR, ABOR und Fachabteilungen echten Mehrwert schaffen. Wichtig ist dabei ein pragmatischer, nutzerzentrierter Ansatz: Prozesse identifizieren, Pilot bauen, Nutzen evaluieren. Die Technologie ist bereit – die Organisation muss folgen. Investitionen in Systeme mit robusten und offenen APIs sind dabei ein wichtiger Schritt, um die zukünftige Integration mit Blockchain und anderen Technologien zu ermöglichen und die Agilität des Asset Managers zu erhöhen.

7.1 Recherchequellen & Literatur

• Fachartikel und Whitepaper zu Blockchain und DLT im Finanzwesen und Asset Management

• Publikationen von Technologieunternehmen und Beratungsfirmen zu Blockchain-Anwendungsfällen

• Akademische Forschung zu DLT in der Finanzindustrie

• Leitfäden von Regulierungsbehörden und Branchenverbänden zu DLT

• Fachartikel zu Systemarchitekturen, APIs und Stammdatenmanagement in Finanzinstituten