Learnings from ECB Exploratory Phase – Part 1

With this little blog series we want to share our insights and learnings from our Use Case Smart Derivative Contract. This use case with regard to full-automated post-trade processing for OTC Derivatives was explored successfully on Bundesbank Triggersolution within ECB Exploratory Work in September 2024. Up to now DZ BANK has been the only Institution which explored the possibility of hosting its own node on the DLT-Infrastructure provided by Bundesbank. This approach offered us a much higher degree in designing decentralized and automated transaction flows – in its core, using a Smart-Contract based Event-Driven Architecture (EDA).

A DLT Infrastructure provided by the Public Sector

In the first part of this series, we look at the architecture and the available transaction patterns on the Bundesbank Trigger Solution Infrastructure. We describe the possibilities of an own node operation and why it is beneficial in comparison to API based interaction. A direct connection to a DLT node enables a lightweight event-based design based on direct consumption of events emitted from the DLT the participants are connected to. This circumstance especially lowers the need of direct orchestrated interaction between participants and removes the need for new intermediary service providers.

Introduction: Scope of ECB Exploratory Work

Within the ECB Exploratory work ongoing in 2024, market participants have received the opportunity to explore new forms of digital wholesale central bank money (CBDC) to explore new functional process designs for settlement of Securities or Payment-Only Use Cases (e.g. Derivatives). Core challenge: Implementation of resilient functional bridges between CBDC and so-called Market DLT-platforms that ensure interoperability and seamless functional transaction patterns. Most prominently, the securities-based use cases aiming to proof decentralized Delivery-versus-Payment using algorithmic transaction patterns have gained a high focus during the phase. The Trials and Experiments that have been conducted were able to make use of three Eurosystem solutions to enable settlement of financial transactions recorded on distributed ledger technology platforms (DLT) in central bank money within the T2 real-time gross settlement system. Among these three provided solutions, Deutsche Bundesbank offers an own DLT-based Infrastructure – the so-called “Triggersolution”.

Triggersolution Infrastructure of Bundesbank

The Trigger Solution is a DLT-based solution based on Hyperleger Fabric solution that allows participants to settle eligible Delivery-versus-Payment transactions and Wholesale-based payments in Central Bank Money in RTGS by using a new DLT-based technological layer. A participant can call a smart-contracts-based software – „PaymentContract“ – provided by Bundesbank to initiate and approve a payment instruction, resulting in a payment within the RTGS component within T2. The participant is also able to connect to the event feed to catch the status of the triggered payments. The Hyperledger Fabric infrastructure in the Trigger Solution consists of deployed and configured nodes that form a functional blockchain network. The infrastructure is designed to maintain privacy and security while leveraging the benefits of a distributed ledger system. 

Transaction Schemes: Basic and Advanced Approach

According to the documentation, Bundesbank offers two distinct approaches – called „Interoperability Mechanisms“ to process a payment in RTGS via this newly provided infrastructure. Using the basic approach, a participant can create, submit, and approve a payment which gets processed between the respective accounts to be debited and credited. Using an enhanced approach, a participant is allowed to “lock” a certain amount to be transferred upon a certain condition is met. After the lock has been processed, the locked amount will be stored on an interim account of Bundesbank and won’t be accessible anymore by the initiating party. If the condition is met (e.g. a matching secret is provided) the locked amount will be transferred according to the predetermined details of the transaction. This enhanced approach enables to implement cross-chain linked Transaction Schemes – more specifically „Hash-Time-Lock Contract“ (HTLC) transaction pattern to process the transfer of an asset and its according payment across two DLT infrastructures. We will provide a closer look at this scheme in the second part of this series.

Accessing Triggersolution via Own Node or via API

Overall, the ecosystem allows participants to leverage the Trigger Solution for settlement of transactions and payments, with the flexibility to choose the integration approach that best suits their needs. Deutsche Bundesbank offers two primary options: API usage and the use of a dedicated peer node operation. With API usage, participants can connect to the Trigger Solution through a ReST API provided by the Bundesbank. This allows to build and configure their applications to communicate with the Trigger Solution by using a classical Request-Response pattern. The dedicated peer node approach requires a participant to host an own Hyperledger Fabric Node connected to the node operated by Bundesbank.  An onboarding process for registering a node was provided by Bundesbank. By operation their own peer node participants can directly interact with the underlying blockchain network and especially the smart contracts – e.g. the Fabric “Chaincode” provided by Bundesbank. In comparison to the API based approach this decentralized peer-to-peer infrastructure offers the benefits of customization and increased security. Additionally, it offers the possibility to deploy custom smart contracts within the Trigger Solution and consume directly the events emitted from the network.

Benefits of Operating an Own Node

In a direct comparison operating an own node offers the design of an decentralized Event-Driven Architecture with a high level of customisation by each operating party. The drawbacks of using REST-API is that an additional layer has to be operated centrally by Bundesbank which introduces another hosted intermediary infrastructure which is placed between market participants and the DLT infrastructure in behind. In this regard, we would like to point to a little medium article regarding drawbacks of classical Request-Reponse Schemes. From our viewpoint, a decentralized infrastructure in which each party is interacting against its own node seems to be much more promising compared to a centrally hosted API might introduce system bottlenecks and masks the provided chaincode functionality by a central communication layer. The following schemes depict both communication channels in direct comparison. We will dive deeper into that later with respect to HTLC and SDC Use Cases.

Comparison of Transaction Flows for Cash-Locking

In this section we want to depict transaction flows using API versus Own Node for the advanced approach – in which cash locking is involved in direct comparison. These transaction flows aim to depict precisely the benefits of own node operation.

1. Transaction Flow with own Nodes

The following diagram depicts a possible transaction scheme to lock and unlock a cash amount on Triggersolution where paying and receiving party host their own nodes. Parties can directly interact with their node circumventing a centrally hosted API layer. Furthermore each party is free to connect on the event-queue of the network and design an automated response pattern on selected Events, e.g. the receiving party can automatically react on the PaymentLocked Event to provide the details to unlock the cash.

2. Transaction Flow based on API

The following diagram depicts a possible transaction scheme to lock and unlock a cash amount on Triggersolution where paying and receiving party interact via central API layer provided by Bundesbank. Parties need to rely on classical request-response pattern (events cannot be consumed directly) and need to have separate communication channels in place for direct communication. A higher orchestrated interaction is needed, event-driven automation designs harder to obtain.

Discussion

DLT enables Disintermediation

In a recent Article we explained the core benefits of DLT and Smart Contracts – it enables full-distributed data storage and decentralized computing (e.g. EVM). In view of financial industry these features may enable to functionalise roles of classical intermediary services by usage of smart contracts. Surprisingly this option was not explored on the Triggersolution which might be due to the fact that the focus lies on the rather closed existing Market DLT Platforms. Especially the usage of API-based communication will introduce new central layers of interaction which mask the core benefits of an own node operation as explained above. We strongly believe that even in compliance with regulatory requirements a complete smart-contract based designs can make a third party obsolete. We will make this clear in the next section with regard to concrete use cases.

Open Protocols instead of Closed Platforms

We strongly believe that the development of open, agnostic protocols, which are not tied to a particular platform or technological layer, represents the right approach for an the acceptance of new digital financial transaction designs. From the very beginning the concept of the Smart Derivative Contract was thought as a generic digital protocol. In 2021 and 2022 DZ BANK and other partners traded SDC legally binding as a new OTC-Derivative. Now, the successful implementation of the concept on Bundesbank’s Triggersolution Infrastructure is another proof to its versatile applicability irrespective on the platform or technology selected. We further believe that the usage of public sector-operated networks can help to avoid the risk of digital fragmentation. The use case of the SDC showcases the significant possibilities what open protocols offer, particularly in combination of networks provided by the public sector. This approach can foster resilience and enable the acceptance of new digital financial protocols, which in the best case will be developed an operated in a decentralized way.

In the next part we will dive deeper in the description and the implementation of SDC on Triggersolution.

Disclaimer: The opinions and statements expressed in this article are those of the author and do not necessarily represent the views of the company or organization.