Banken und Finanzinstitute haben Schwierigkeiten, Blockchain- und DLT-Anwendungen in die profitable Produktion zu bringen. In einem Markt, in dem Proof-of-Concept (POC) für viele Unternehmen tatsächlich das Geschäftsmodell ist, müssen wir ehrlich über den Zustand unserer Branche sein.
Es gibt eine Vielzahl von Gründen für das Scheitern von Blockchain-Projekten innerhalb von Finanzinstituten. Einige davon laufen auf Naivität bei der Live-Bereitstellung hinaus, einschließlich mangelndem Verständnis für sichere Bereitstellungsverfahren für Banken. Es besteht eine klare Diskrepanz zwischen dem hohen Maß an IT-Sicherheit, das Banken erwarten, und dem innovationsorientierten Ansatz einiger Blockchain-Frameworks, bei denen die Einsatzfähigkeit und Interoperabilität mit bestehenden Systemen nicht berücksichtigt werden.
Um Code in den sicheren Bereich einer Bank zu bringen, ist ein sorgfältiger Bereitstellungsansatz erforderlich. Erwarten Sie nicht, dass Ihr Code einfach Komponenten aus dem Internet abrufen kann. Ohne jede Zeile gelangt nichts in die Systeme einer Bank
Der Code wird überprüft, geprüft und genehmigt.
Darüber hinaus sind häufig niedrige Geschwindigkeit, eingeschränkte Skalierbarkeit und eine fehlende Strategie zur Integration in bestehende Systeme schuld. Um vom POC zu einem Live-System zu gelangen, müssen Banken ein hohes Volumen und eine enorme Größenordnung einplanen. Sie müssen innerhalb der Reihe von Systemen funktionieren, die Banken derzeit einsetzen. Dazu gehören Links zu SWIFT, Hardware-Sicherheitsmodule, Unternehmensidentitätssysteme und vieles mehr.
Weitere Gründe, warum Finanzinstitute Schwierigkeiten haben, DLT-Projekte in die profitable Produktion zu bringen, sind die Verwendung exotischer und nicht unterstützter Programmiersprachen, die Fixierung auf eine bestimmte Technologie anstelle eines Geschäftsziels und die mangelnde Analyse der Vorteile für den Endkunden.
Die 10 Gründe, warum Blockchains nicht funktionieren, werden im Folgenden ausführlicher beschrieben und umfassen:
- Mangelndes Verständnis für sichere Bereitstellungsverfahren
- Geringe Geschwindigkeit und Skalierbarkeit des gewählten Ledgers
- Schwierigkeiten bei der Integration in bestehende Systeme
- Exotische oder nicht unterstützte Programmiersprachen
- Fixierung auf einen bestimmten technologischen Ansatz über Geschäftsziele
- Kundenbedürfnisse werden nicht analysiert
- Ein Missverständnis regulatorischer Zwänge
- Keine klare strategische Vision über den PoC hinaus
- Unrealistische Annahmen zur Dezentralisierung
- Angenommen, es handelt sich um ein Kryptoelement innerhalb einer Marktinfrastruktur
Um die Hindernisse für den erfolgreichen Einsatz von Blockchain-Projekten zu überwinden, ist eine Kombination aus fundiertem Fachwissen im Bereich der Finanzmarktinfrastruktur, einer nachgewiesenen Erfolgsbilanz und einem Verständnis für die Arbeit in regulierten Hochleistungsorganisationen sowie einem Verständnis für die Komplexität und Sicherheit erforderlich Auswirkungen einer Bereitstellung in großem Maßstab.
Die 10 Herausforderungen können durch die Bereitstellung eines robusten und autorisierten Toolsets für Finanzinstitute behoben werden, um Anwendungen zu erstellen, die zwischen vorhandenen Infrastrukturen und einer Reihe von Unternehmens-Ledger-Technologien, darunter Corda, Besu, Fabric, DAML und SETLs eigenem Hochleistungs-Ledger, zusammenarbeiten. Darüber hinaus muss das bereitgestellte Toolset in der Lage sein, große Mengen an Transaktionen und Vorgängen mit den extrem hohen Geschwindigkeiten abzuwickeln, die der Markt mittlerweile erwartet.
Die 10 wichtigsten Gründe, warum Blockchain- und DLT-Projekte nicht in Produktion gehen
Mangelndes Verständnis für sichere Bereitstellungsverfahren
Der Prozess der Bereitstellung in einer sicheren Bankumgebung ist kompliziert. Innerhalb der sicheren Umgebung einer Bank wird der Zugriff auf das Internet streng kontrolliert und jeglicher Computercode, der in einer Anwendung enthalten ist, kann nicht einfach von externen Quellen heruntergeladen oder eingeschleust werden. Jedes gemeinsame Modul, das Teil einer Anwendung ist, muss in der Regel aus den internen Repositories der Bank eingebunden werden. Möglicherweise muss ein Antrag geändert werden, um diese genehmigten Module nutzen zu können. Im Bereitstellungsprozess werden strenge Rollen angewendet, um eine klare Trennung der Verantwortlichkeiten zwischen den Entwicklern, den Dev-Ops-Teams und den eventuellen Betreibern der Software sicherzustellen. Viele DLTs sind nicht für den Einsatz auf diese Weise strukturiert.
Geringe Geschwindigkeit und Skalierbarkeit eines ausgewählten Ledgers
Das institutionelle Volumen kann Tausende von Transaktionen pro Sekunde erreichen. Darüber hinaus kann es für jede Transaktion eine Vielzahl von Ereignissen geben, die ausgelöst und bedient werden müssen. In vielen Rechtsordnungen ist es beispielsweise bei der Übertragung eines Wertpapiers von einem Kunden zu einem anderen erforderlich, dass sowohl der Sender als auch der Empfänger des Wertpapiers die Transaktion bestätigen, bevor sie ausgeführt wird. Transaktionen finden in verschiedenen Zuständen statt und bei jeder Zustandsänderung müssen Meldungen generiert werden. DLT-Technologien, die nicht mit der erforderlichen Geschwindigkeit verarbeiten können, können Stunden brauchen, um Rückstände zu beseitigen, was zu Verzögerungen und Ausfällen in anderen Prozessen führt.
Die Schwierigkeit der Integration in bestehende Systeme
Bei den meisten DLTs handelt es sich um eigenständige Systeme, und es wird nur sehr wenig darüber nachgedacht, wie sie sich in die komplexe Systempalette integrieren, die Finanzinstitute einsetzen. Interoperabilität muss mit der Interoperabilität mit anderen Nicht-DLT-Systemen beginnen. Ein erheblicher Teil der Anweisungen von Kontrahenten erfolgt in Form von Standardfinanznachrichten wie FIX- oder SWIFT-Nachrichten. Diese Nachrichten können auf einer Reihe von Transportschichten wie KAFKA, MQ oder sogar FTP übertragen werden. Nachdem ein Kontostand auf dem DLT aktualisiert wurde, muss eine andere Sammlung von Systemen, wie z. B. ERPs, benachrichtigt werden. DLTs, die der Integration keine Beachtung schenken, bieten in diesen Bereichen suboptimale Lösungen.
Exotische oder nicht unterstützte Programmiersprachen
Vorgeschlagene Artikel
iFX EXPO International 2021 - Highlights der Zypern-ShowZum Artikel >>
Bevor benutzerdefinierter Code in einem Finanzinstitut live bereitgestellt wird, muss er einer Sicherheitsüberprüfung unterzogen werden. Es gibt branchenübliche Tools, die automatisierte Prüfungen auf alles durchführen, von schlechten Programmiertechniken bis hin zu bekannten Hacks und Schwachstellen. Diese Tools basieren auf jahrzehntelanger Programmiererfahrung mit etablierten Sprachen wie JAVA, JS und C++. Es bedarf einer erheblichen Beteiligung der Community, um den Wissensbestand aufzubauen, damit diese Überprüfungen effizient automatisiert werden können. Den in einigen DLTs integrierten domänenspezifischen Sprachen fehlt hierfür die kritische Masse. Das bedeutet, dass die Experten schwieriger zu rekrutieren sind, automatisierte Code-Sicherheitsüberprüfungen spärlich sind und die Kosten für die Wartung des Systems viel höher sind.
Fixierung auf einen bestimmten Technologieansatz über Geschäftszielen
Viele DLT-Experten und Innovatoren haben Zeit und Mühe in eine bestimmte Technologie investiert. Für sie ist es selbstverständlich, dass sie diese Investition validieren und diese Technologie in einer Live-Umgebung nutzen möchten. Dies kann dazu führen, dass das Design im Vergleich zu den Geschäftszielen nicht optimal ist. Beispielsweise ist eine DLT-Technologie, die hauptsächlich auf bilaterale Interaktionen ausgelegt ist, wahrscheinlich nicht die beste Wahl für eine tokenbasierte Plattform. Es mag möglich sein, einen quadratischen Stift in ein rundes Loch in einem POC zu hämmern, aber es ist unwahrscheinlich, dass es den Test der Live-Implementierung besteht.
Kundenbedürfnisse werden nicht analysiert
Kunden von Finanzinstituten wollen Ergebnisse. Eine gute Lösung mit DLT bringt messbare Vorteile für das Finanzinstitut und seine Kunden. Der Entwurf einer Lösung beginnt mit den Anforderungen und führt zur besten Technologie, um diese Anforderungen zu erfüllen. Es kommt selten vor, dass der Kunde ein DLT oder eine Blockchain benötigt. Der Bedarf besteht wahrscheinlich in niedrigeren Kosten, schnellerer Abwicklung, mehr Automatisierung oder mehr Funktionalität. Eine gute Lösung legt den DLT möglicherweise nicht einmal in seinem Kern offen. Lösungen, die den Benutzern zusätzliche Belastungen auferlegen, wie beispielsweise die Notwendigkeit, dass jeder Teilnehmer einen Knoten betreiben muss, werden bei der Einführung auf Hindernisse stoßen.
Ein Missverständnis regulatorischer Zwänge
Blockchains und DLTs fallen nicht außerhalb der regulatorischen Verpflichtungen von Finanzinstituten. Zu diesen Verpflichtungen gehören Maßnahmen zum Schutz der Privatsphäre des Kunden, Maßnahmen zum Schutz von Vermögenswerten und Maßnahmen zur Gewährleistung der Integrität des Marktes als Ganzes. DLT- und Blockchain-Systeme, die Daten austauschen, selbst auf pseudoanonymer Basis, werden diese Anforderungen nicht erfüllen. Einige DLTs legen beispielsweise die gesamte Transaktionskette eines Tokens offen, um die Einzigartigkeit des Tokens zu überprüfen. Es ist unwahrscheinlich, dass dies ein konformer Ansatz ist.
Keine klare strategische Vision über den POC hinaus
Die Übertragung eines bestehenden Systems auf ein DLT ist an sich keine strategische Vision. Blockchain und DLT gehören zu einer Familie von Technologien, die unsere persönlichen und geschäftlichen Interaktionen verändern. Wenn man im Großen und Ganzen versteht, wie sich diese Veränderungen in einem bestimmten Wirtschaftssektor entwickeln, kann man wahrscheinlich auf mögliche zukünftige Zustände schließen. Nur mit einer gründlichen Analyse der relativen Stärken und Schwächen kann ein Unternehmen eine Technologiestrategie entwickeln, die eine Komponente von DLT oder Blockchain als Teil der Gesamtstrategie umfassen kann.
Unrealistische Annahmen zur Dezentralisierung
Finanzmärkte sind hochentwickelte Vertrauensmechanismen. Aus jahrhundertelanger Erfahrung sind zahlreiche Modelle für Transaktionen und Investitionen entstanden, die ein unterschiedliches Maß an Vertrauen beinhalten. Dritte, Treuhandgesellschaften, organisierte Märkte und Regulierungsbehörden sind allesamt gültige und nützliche Elemente der Treuhandmärkte. Vermittler übernehmen wichtige Aufgaben als Berater, Aggregatoren, Netzwerkanbieter und Liquiditätsorganisatoren. Eine Fixierung auf den Ausschluss aller Vermittler aus einer Transaktion ist aus regulatorischer Sicht oft unpraktisch, für den Endnutzer unhandlich und kann mit technischem Kunstgriff verbunden sein, der Zentralisierungspunkte wie Mining-Pools, Notare oder Netzwerkbetreiber verbirgt.
Angenommen, es handelt sich um ein Kryptoelement innerhalb einer Marktinfrastruktur
Einige der am meisten gehypten Blockchain-Technologien erfordern die Verwendung eines proprietären Tokens, um Transaktionen einzureichen oder Smart Contracts abzuwickeln. Ein typischer Ansatz bestand darin, dass diese Token vorab an das Unternehmen oder die Gründer ausgegeben wurden und ein Teil über einen ICO verkauft wurde. Das implizite Versprechen an Token-Inhaber während der ICO ist, dass eines Tages die Mainstream-Finanzwelt das System übernehmen wird und es eine große Nachfrage nach ihrem Token geben wird. In Wirklichkeit ist die Einbeziehung von a Krypto-Token macht die Einführung der Technologie schwieriger, da es Unsicherheit über die Kosten für den Benutzer mit sich bringt, die Geschäftsmodelle der Banken der Spekulation aussetzt, ein operatives Risiko für das Schlüsselmanagement schafft und die Bank anonymen Handelsaktivitäten aussetzt.
Anthony Culligan, Chefingenieur bei SETL
Quelle: https://www.financemagnates.com/fintech/why-isnt-blockchain-working/
- "
- Zugang
- Konto
- Adoption
- Berater
- Alle
- Analyse
- Anwendung
- Anwendungen
- um
- Artikel
- Details
- Auto
- Automatisiert
- Automation
- Bank
- Banken
- Barrieren
- BESTE
- Blockchain
- blockchain Projekte
- Körper
- bauen
- Geschäft
- Geschäftsmodell
- Übernehmen
- Überprüfung
- Schecks
- Chef
- Code
- Programmierung
- gemeinsam
- community
- Unternehmen
- Komponente
- Verträge
- Seil
- Kosten
- Krypto
- Kunden
- Zypern
- technische Daten
- Verzögerungen
- Demand
- Design
- Detail
- Entwickler
- DLT
- Ingenieur
- Unternehmen
- Arbeitsumfeld
- Veranstaltungen
- ERFAHRUNGEN
- Experten
- Stoff
- Gesicht
- Familie
- Finanzen
- Revolution
- Finanzinstitutionen
- Fixieren
- unten stehende Formular
- Gründer
- Zukunft
- gut
- Hacks
- Hardware
- GUTE
- Ultraschall
- HTTPS
- riesig
- ICO
- Identitätsschutz
- Einschließlich
- Aufnahme
- Energiegewinnung
- Infrastruktur
- Innovatoren
- Institution
- Institutionen
- Integral
- Integration
- International
- Internet
- Flexible Kommunikation
- Investitionen
- Investition
- IT
- es Sicherheit
- Javac
- Wesentliche
- Wissen
- Sprachen
- führen
- Ledger
- Limitiert
- Line
- Liquidity
- Mainstream
- Management
- Markt
- Märkte
- Mitglieder
- Bergbau
- Bergbau-Pools
- Modell
- Netzwerk
- die
- Einkauf & Prozesse
- Organisationen
- Andere
- AUFMERKSAMKEIT
- Plattform
- PoC
- Perspektive
- Pools
- Arm
- Gegenwart
- Datenschutz
- Produktion
- Programmierung
- Projekte
- Risiken zu minimieren
- Angebot
- Realität
- Gründe
- Regulators
- Regulierungsbehörden
- Voraussetzungen:
- Risiko
- Führen Sie
- Skalierbarkeit
- Skalieren
- Sicherheitdienst
- SETL
- Siedlung
- Teilen
- smart
- Smart Contracts
- So
- Software
- verkauft
- Lösungen
- Geschwindigkeit
- quadratisch
- Anfang
- Bundesstaat
- Staaten
- Strategisch
- Strategie
- erfolgreich
- SWIFT
- System
- Systeme und Techniken
- Technische
- Techniken
- Technologies
- Technologie
- Technologiestrategie
- Test
- dritte seite
- Zeit
- Zeichen
- Tokens
- verfolgen sind
- Trading
- Transaktion
- Transaktionen
- Transformieren
- Transportwesen
- Vertrauen
- Nutzer
- geschätzt
- Anzeigen
- Seh-
- Volumen
- Sicherheitslücken
- .
- Arbeiten