 Now, it will be a real pleasure for us, for my colleague Bess Farshalla and myself, to provide you with some insights to the trigger solution. I will first start with a very brief explanation of what the trigger solution is, especially for those of you who are not yet familiar with it. So, as explained earlier already, the trigger solution is one of the three technical solutions which will be investigated in the context of the Euro system exploratory work, and it will be provided by Deutsche Bundesbank as solution providing central bank. With the help of the trigger solution, market participants will have the opportunity to settle DLT-based wholesale financial transactions in the existing target services, so this means without the creation of central bank money tokens. For that purpose, Bundesbank developed a DLT infrastructure, which acts basically as a technical bridge between the RTGS component of T2 and eligible market DLT platforms. Next, let me briefly explain what experience we do have so far on the trigger solution. Bundesbank has been working on that topic for quite a while already. In 2021, the initial version of the trigger solution was developed and tested together with Deutsche Börse and Germany's finance agency together with a couple of German banks. Since then, we have further worked on that topic and we further developed the trigger solution. In particular, we had to change from using MT messages to ISO 20 to 2 messages, given the change from target 2 to T2 in the March of this year. In addition, we have chosen a more flexible and more open approach with regard to the interaction with several market DLTs, which allows more flexibility and a more neutral approach. On the next slide, let me provide with some explanations on how the ecosystem looks like. On the first layer, we can see the market DLT platforms. For the purpose of the EUROSYSTEM exploratory work, these will only be platforms considered as eligible by the EUROSYSTEM or according to the EUROSYSTEM definition. On that market DLTs, eligible market participants, according to their EUROSYSTEM definitions, as well as any other entities, such as, for instance, issuers or corporates or investors could participate. The market DLT platform is basically the place where the underlying business transaction takes place, so in an example, the exchange of securities. Again, what assets will be considered eligible in the context of the exploratory work of the EUROSYSTEM will be defined by the EUROSYSTEM. Let's move to the second layer. The trigger solution, on the second layer, we have the trigger solution. Here only eligible market participants, so basically, eligible target participants and eligible market DLT operators. If they have an active role and as defined by the EUROSYSTEM, participate. Today, so both actors, eligible market participants and eligible market DLT operators have to be present or participants on both layers on the eligible market DLT platform as well as on the trigger solution to be able to create payment instructions in the trigger solution. This is illustrated for Bank A in the picture on the right-hand side. Let me emphasize that from a pure technical perspective, the trigger solution is agnostic with regard to the business or assets in the eligible market DLT platform. In between the eligible market DLT platform and the trigger solution, you can see the letters IO. IO stands for interoperability mechanism, so what does it mean? To be very clear, the interoperability mechanism is rather a conceptual approach and does not imply a technical connection between the trigger solution and the market DLT. It basically determines the interaction with a payment instruction smart contract and will be implemented on the market DLT side. So it can be designed to best fit the underlying business transaction. From the trigger perspective, we support different interoperability mechanisms. The most prominent one probably being the so-called hash time lock contract or HTLC. What matters from a trigger perspective is that the functions of our payment instruction smart contract will be called respectively. So let's move to the last and third layer. On this third layer, we have the RTGS component of T2 in exactly the same way as it is used for today's regular payments. Here the final settlement of the cash leg takes place automatically and directly on the RTGS DCAs of the respective target participants. Participants can use their existing RTGS DCAs, so there is no need for separating the liquidity on a different liquidity pot. We will now look a bit closer into how a DVP transaction could be settled using the trigger solution. In the very first step, we have for instance a buyer and a seller agreeing on an exchange of eligible assets against Euro since we settle against target in a market DLT platform. So these activities are outside the scope of the trigger solution and this is for instance also where the blocking of securities would take place. If we now move to the second step, the activities of the trigger solution start. Based on the trade in the market DLT platform, a payment instruction will be created in the trigger solution. To be very clear, this will not be done by the interoperability mechanism as such, but by the participants in the trigger solution, which can be either the payer bank, the payee bank or an authorized third party. Let's move to the third step. Once the payment instruction is created by the participants' apologies, Bundesbank will convert it into an ISO 20 or 2.2 message. These messages will be sent again by Bundesbank and via its own infrastructure via ESMIC 2-T2. Here I would like to emphasize that there are no accounts and no funds in the trigger solution. We only work with payment instructions. Accounts and funds only exist in the T2 or RTGS layer. With the next step, we move to the payment process. The trigger solution follows a two-step payment process. The first step consists of a direct debit, a regular PACS 10 message, debiting the payer bank's RTGS DCA and crediting an interim account of Bundesbank. To be very clear here again, this message will be sent by Bundesbank to T2 and not by the respective participant. In the end, an information on the successful or failed settlement will be sent from T2 to the trigger solution. On the next slide, we will come to the second part of the payment instruction. The second part consists of a credit transfer, a regular PACS 9 message and this PACS 9 message debits the Bundesbank interim account and credits the RTGS DCA of the payer bank. It basically follows immediately after the direct debit in case a basic approach is used or after a pause in order to cater, for instance, for the blocking of funds in the context of the usage of HDLC mechanisms. Again, in the end, an information on the successful or failed settlement will be sent to the trigger solution. Now we come to the last step of the process. Here, the participants in the trigger solution transfer the status of the payment instruction to the market DLT. On that basis, actually the assets can be transferred on the market DLT platform. Following that, I would like to hand over to my colleague Besfalt now who will continue with some technical details. Yeah, so let's move on to the technical details of the trigger solution itself. So one of the core elements of the trigger solution is a DLT, a blockchain infrastructure, which is called the trigger chain. And the trigger chain itself was developed using the most recent version of Hyperledger Fabric 2.5, which is a permissioned blockchain. Another point is that the whole solution, including its different components, are implemented within the internal Bundesbank environment. And through the internal communication infrastructure of the Bundesbank, our solution is able to communicate with T2. So we are not using any external cloud service provided to host our solution. So coming to the next point, what are ways users or participants can connect to the trigger solution? So we have foreseen two options. So the first option is to connect to the trigger solution via the API interface. What does that mean? Basically, we expose our REST APIs and through these APIs, participants will have the possibility to build, to configure the applications in order to be able to communicate the trigger solution. On the other side, the API can also be used for U2A communication. It means we are providing also a graphical user interface for the participants. So basically, connecting through the API interface is probably the fastest, the simplest way to connect to our solution. Option two is to connect to our solution through operating an OWN Hyperledger Fabric node. That means participants need to set up to configure their OWN Hyperledger Fabric dedicated nodes. And through that, they have full access over their nodes and also can participate on the direct interactions with the underlying blockchain network. But, or nevertheless, this requires a little bit more effort and of course Hyperledger Fabric expertise. So this was about the options to connect to the trigger solution. And I want also to add that the trigger solution itself does not have any technical requirements with regards to external DLT platforms, to external blockchains. It means for us, it's important that the participants or their applications, they can talk, they can interact with the interfaces we are providing, whether via API or by operating their OWN node. So that's about the technical basics of the trigger solution. Let's switch to the next slide in order to see the core functionalities. Yeah, so what are the main functionalities of the trigger solution? Within the blockchain, within the trigger chain, we have implemented, we have deployed the Bundesbank smart contract, which is called the payment instruction smart contract. And within that smart contract, there are some functions which can be used by the participants. So basically a participant can use the smart contract to create, to approve, to submit payment instructions in case if needed, there's also the possibility to do a modification. And as a result of creating and submitting a payment instruction, our backend application will take that, the payment instruction details and will create an ISA message and will send them to the T2 system. Another functionality is that indeed participants would be able to see all the transactions in which they are involved. This could be a payer bank, a receiver bank, a third party authorized to do that action, so they are able to see transactions in which they are involved. So basically the status of the payment instruction, for instance, if the payment was successfully or failed, will be automatically updated by the Bundesbank node based on the status of the T2 transaction. Another functionality already mentioned is that participants have the option to operate their own node or to connect via API. And there are two differences using the API connection. As mentioned, it's a simplified integration process to our solution, but on the other side, for receiving updates, the participants need to query continuously the current status information. On the other side, when operating their own Hyperledger Fabric node, there are some benefits, for instance, direct interaction with the pre-blockshare network, programmability, which means that participants can develop and deploy their smart contact based on their business processes, which could be complex transactions or the coordination of transactions across different external DLT platforms, so depending on the use case. And of course, participants, when operating their own node, they get automatically notified via the events, via the Hyperledger Fabric specific events, about the status updates of the payment instruction. So that's about the main functionalities of the trigger solution. We can switch to the next slide. So, yeah, I hope after these explanations, that you are interested or there are interesting parties willing to explore the trigger solution and also its capabilities. And in that case, we have prepared some specific documents, which are already made available in the context of the call for interest, I think two or one day ago. So first, there is a process description document providing an overview of the ecosystem and the various process steps, which are needed for the use case, DVP delivery versus payment. Then the package also includes a user requirement document with the various functional requirements. Then we have also the different onboarding steps and technical details, which are described within the onboarding guide. Another information is that we have also trigger solution specific registration form, form two, which you need to complete and to submit to your local NCB, which afterwards will forward it to the Bundesbank. And another step to be done by a local NCB is also to set up the necessary direct debitment date, which is also needed for using the trigger solution. So that's about some details for interested participants. Of course, have a read on the documentation provided and for questions, you can contact us directly through the provided email address. So that's about the theoretical presentation of the trigger solution with some technical details. And now I think we can start with the demonstration of the trigger solution. Yeah, just hold on 30 seconds. Welcome to the demonstration of the trigger solution provided by Deutsche Bundesbank. The trigger solution is one of three technical solutions offered for the Euro system exploratory phase on new technologies for wholesale central bank money settlement. Before we show you the trigger solution, we would like to provide you with some information on the process of settling a transaction where the trigger solution, so that it is easier for you to understand when we enter in the graphical user interface later on. The business case shown illustrates the settlement of a securities trade have formed on any eligible market TLT platform. The participants involved have their own RDGS dedicated cash accounts. For our demo, we have set up two new participants in the T2U test environment with their respective accounts. Let's imagine the trade is performed between Bank A and Bank B. Bob, an employee working for Bank B, buys securities from Alice, working for Bank A. Bob intends to use Bank B's RDGS DCA to pay the trade performed on the market TLT platform. In our example, Bob's DCA has the big TurboDev triple X. The liquidity will be transferred to Alice's account, which has the big TurboDev triple X. The payment process in the trigger solution follows a two-step approach. Therefore, we also set up a Bundesbank RDGS participant with its own Bundesbank RDGS DCA with the big MarkDev tree in the T2U test environment. This account serves as the Bundesbank interim account in the two-step payment process. As soon as Bob has created and approved his payment instruction, the trigger solution will send a direct debit as PACS-10 message via the standard route using SWIFT, the Bundesbank's network service provider for the target services via ESMIC to T2 so that the liquidity will be transferred from Bob's account to the Bundesbank interim account. The corresponding confirmation message is sent back by T2. This means that the trigger solution receives a positive PACS-2 message confirming the settlement of the direct debit. In addition, Bank B receives a PACS-10 message informing that the direct debit has been settled on its account to Rudev triple X. In a second step, after the trigger solution has received the positive PACS-2 message, it sends a PACS-9 message to forward the liquidity from the Bundesbank interim account to Alice's account. After this credit transfer has been settled, the trigger solution again receives a positive PACS-2 message confirming the settlement of the credit transfer and Bank A receives a PACS-9 informing that the credit transfer has been settled on its account to Rudev triple X. With this confirmation message, the trigger solution changes the status of the payment instruction to completed. This is the general process. Bob has different options to initiate this process depending on how Bank B is connected to the trigger solution. And the first option, Bank B, can be a peer user with its own node in the trigger solution. And the second option, Bank B, can use the API as a non-peer user communicating either in a U2A mode using the graphical user interface or in A2A mode. Regardless of this connectivity, but depending on the interoperability mechanism implemented on the respective eligible market DLT platform, Bob can also choose between the supported payment instruction life cycles. This means that he can use either the basic approach without HTLC functionality or the advanced approach with HTLC functionality. The difference is that the HTLC approach has additional steps to first confirm that liquidity has been blocked on the Bundesbank interim account and then to initiate the second step of the payment process after the preimage of the hash included in the payment instruction has been provided. This enables the HTLC interoperability mechanism to be implemented. With this in mind, our demonstration of the trigger solution starts with a business case using the API U2A connection and creating a payment instruction without using the HTLC functionality. First, Bob has to log in on the trigger solutions landing page. Bob can see his dashboard listing all payment instructions affecting his Zurudev XXX account along with their corresponding status. To initiate a payment instruction, Bob has to navigate to a new payment instruction. Since there is no direct technical connection between the trigger solution and the eligible market DLT platform, we use the correlation ID to establish a link between the trade and the eligible market DLT platform and the corresponding settlement on the cash lag in T2. The correlation ID is a kind of end-to-end ID carried forward throughout the process. It stems from the eligible market DLT platform and is mandatory when creating a new payment instruction in the trigger solution. It will also be part of the ISO 20.022 messages and can therefore be seen in T2 as well. For our demonstration, I take an easy correlation ID, nothing cryptic, but something rather simple so that we can follow our payment instruction easily. We already mentioned that Bob wants to transfer liquidity to Alice, so we enter Bob's RDGS, DCA Zurudev XXX as payer bank, and Alice's RDGS DCA Zurudev XXX as receiver bank. The amount should be 12,345.67 euro. That is all information that has to be entered for this use case. For a payment instruction, we need to enter the correlation ID to link the payment to the trade and who is paying how much to whom. The payment instruction is initiated by pressing the create button, and we can see the status prepared. At this point, it is possible to change certain data. For example, the amount, if anything is incorrect. If everything is correct, the payer bank, that means Bob, can approve the payment instruction using his certificate and by pressing the approve button. For clarification, in our demonstration, Bob can approve the payment instruction in two-ice mode. However, in general, the trigger solution also offers approval in four-ice mode. By the way, it does not necessarily have to be Bob, the payer bank that creates the payment instruction. The payment instruction can also be created by the receiver bank or even a third party. However, only the payer bank or someone authorized by the payer bank can approve the payment instruction. Coming back to Bob and his payment, as a next step, he has to submit the payment instruction to enable the trigger solution to start processing it. The submit function can be used immediately after the approval, but also at a later point in time should liquidity be transferred a few days later. After the payment instruction is submitted, the trigger solution validates it. To give an example, the trigger solution checks whether the payment instruction stems from an illiterable market DLT platform or whether the payer bank or an authorized third party has approved the payment instruction. The status changes nearly immediately from approved to submitted. As soon as the status is triggered, the direct debit, that means the Pax9 message, can be sent via Swift 2T2. Within a very short space of time, the status already set to completed. The trigger solution. This means that the whole payment process, including the credit transfer to Alice's account, has been finalized. The funds are booked on both Bob's and Alice's RDSTCAs in the T2U test environment. To demonstrate that this booking in the T2U test environment has actually taken place, we will now log into the T2U test environment and show the settlement of the direct debit and the credit transfer. In the T2U test environment, we see in the first line the Pax10 message, which can be identified via the field message type. Here we have the correlation ID, demo trigger solution, 10th October 2023. And here we see that Bob's account Zurudev XXX has been debited and our bonus bank interim account has been credited. We can see that the whole process has been finished here. Where we have the corresponding Pax9 message that is the credit transfer to Zurudev XXX that means Alice's account. The credit transfer has also been settled successfully which we can see by the status settled. The Pax9 message also contains our end-to-end ID that means the correlation ID which is carried forward throughout the process. The account holders are informed about the bookings on their RDSTCAs via corresponding ISO 2022 messages. A look at the timestamp shows that the whole process with all bookings takes place in a very short space of time. We can see here in the trigger solutions dashboard the payment instruction we recently created with a respective correlation ID, the creation date, the payer bank and the receiver bank, the amount and the status which is completed. Going to the details we see again the execution time, the time it was created and the time the last status change occurred. When the trigger solution receives the last Pax2 message resulting from the successful settlement of the credit transfer in T2 it updates the status to complete it to indicate a successful settlement. Thus with the trigger solution payment instructions resulting from trades on eligible market DLT platforms can be booked on participants IDGS DCAs within a very short space of time. Now we come to the second business case creating a payment instruction via the API U2A connection with using the HTLC functionality. This means we show the same steps for creating a payment instruction but include the additional information and steps needed for the HTLC mechanism. Therefore we navigate to the screen new payment instruction and start entering the data. This time we choose a different correlation ID. Demo trigger solution 13th October with HTLC. The payer is again Bob's account Zurudev XXX and the receiver Alice's account Zurudev XXX. The accounts entered cannot be fictional fixed. They have to exist in ODGS. This means that entering incorrect or nonexisting bigs will result in an error. To differentiate this payment instruction from the previous one we take another amount this time 333,044 cents. When using the HTLC mechanism additional fields have to be completed in this area. That means the hash time lock and transfer. There is an additional timeout date for the date on which the payment instruction should settle. For the timeout date we take 13th October 2023 the date the demo was recorded and for the time we enter at 12 o'clock. This timeout T2 is relevant for the cash like only. There is an additional timeout T1 that is relevant for the securities like on the eligible market DLT. It is essential that neither timeout has elapsed before the settlement of the direct debit and the credit transfer have been finalized. Timeout T2 has to be smaller than timeout T1 and within the trigger solution there are additional validation rules on these fields to ensure that there is sufficient time for settlement. We also have to enter a hash here which can be thought of as the encryption of a secret pre-image. This is supposed to be the hash that is used to block the securities on the eligible market DLT platform. Since our demo takes place without an eligible market DLT the hash and its pre-image are invented freely. Then we press create but now we get an error message. This is because the chosen correlation ID exceeds the maximum number of digits. After correcting this we can successfully create our payment instruction. Now it is again possible to update for example the amount. However, since all fields are correct we want to approve our payment instruction without any changes and submit it directly to the trigger solution. After having checked the payment instruction the trigger solution sends the direct debit as a Pax 10 message to T2 and changes the status to trigger it. After the settlement of this direct debit and confirmation by T2 the trigger solution changes the status to payment locked. This means that the liquidity has been transferred from Bob's ODIJS DCA to the Bundesbank interim account waiting for the next steps. As soon as Bob has received the pre-image of the hash from Alice which takes place outside the trigger solution he can release the payment using the transfer function. This is where this use case differs from the previous one and the previous use case all steps from the moment the payment instruction is submitted until it obtains the completed status in the trigger solution run completely automatically. However in this use case there is a pause after the funds are locked on the Bundesbank interim account. This step ensures that the liquidity cannot be released until all transaction legs are ready for final settlement and only when providing the correct pre-image of the hash the transfer of the liquidity takes place. Before releasing the payment using the transfer function we check again in T2 to make sure that the liquidity really has arrived on the Bundesbank interim account. Here in T2 we see again a Pax10 message that debits Zurudev XXX and credits MarkDevTree with €333.44 and which has been settled successfully. The funds are therefore locked. To complete the payment process Bob has to enter the pre-image of the hash provided. It is important that the pre-image of the hash and the hash itself fit together otherwise it would result in an error. For example if we delete the C here it would result in the error error while execution for this payment instruction. Adding the C again enables us to go ahead with the transfer function. After pressing the transfer button the status immediately changes to HTLC ready. This means all prerequisites have been met for the trigger solution to send the Pax9 message to T2 to enable settlement of the credit transfer. By refreshing the details of the payment instruction screen we initiate a query to the trigger solution to update the current status which then changes to completed. This means that the Pax9 message has also settled successfully and the trigger solution has received the successful status report from T2. A check in T2 reveals the successful settlement. Here we have the Pax10 message which we saw before. Moreover below we have the Pax9 message with the same correlation ID that debits our bonus bank interim account and credits Alice's rdgsdca terp dev triple x. The status is settled which confirms the settlement and shows that our business case as a whole has finished successfully. Compared to the first use case the whole process in this second use case of course takes slightly longer. This is due to the fact that the automatic process from the first use case is temporarily paused and only resumed after the pre-image of the hash is successfully entered. Thus when using the htsc functionality it is up to the participants as to how fast payment instruction is finally booked on the rdgsdcas. With this we have reached the end of the demonstration of the trigger solution. Thank you very much for your attention. In case of any questions please contact the trigger solution team of Deutsche Bundesbank via email to trigger solution at bundesbank.de So thank you very much to both Nadine and best for the introduction to the trigger solution. So we're just going to quickly have a check on potential questions. Yes indeed, Elin. I would start with the questions if I may. And I think the first question I would like to answer is that we got through the chat is is the target ancillary system interface used by bundesbank in the trigger solution when sending Pax 10 or Pax 9 to rtgsdcas. And here we can say no we do not use the ancillary system interface. We use the regular payment bank interface by bundesbank and so we also do not use ASI messages. It's just the bundesbank operating in its payment bank role. And this is how we presently implemented the trigger solution for the purpose of this exploratory phase. I hope this answers the question was pretty straight I think. Okay, so there was also second question. Let me read that. Does the payment confirmation by the purchaser has to be done manually or can the whole process be conducted E2E automated. So we have mentioned that the status of the payment instruction based on the T2 transaction is automatically provided to the trigger solution by the bundesbank node. So it's within the trigger chain. So it's up to the participants to check the status of the payment instruction and this can be done for instance by operating on our node I've already mentioned when operating an own hyperledger fabric node it's possible to get notifications through the blockchain events. So this is a process and based on a smart contract implemented by participants and their own application this whole process of being notified for an payment instruction can be automated. On the other side of course users can use also the API way to connect to the trigger solution but they need to develop an application which continuously queries the status within the trigger solution. Until the trigger solution the status is provided in an automated way by the bundesbank node for reaching out the market DLT it's up to the participant to do the needed configurations and developments. Okay. Then I would continue reading through the questions popping in and there are some questions with regard to the specifications and documentation specifically with regard to the API specifications and also the question regarding whether there is some form of sandbox and here we can say that in general the documentation is as best for it mentioned already to a large extent already published in the context of the call for interest and further information specifically with regard to the API specifications they will be provided after having submitted the first part of the registration form so then you will be granted access to a restricted area on the website of the bundesbank and there you get further technical details and there will be no sandbox or demonstration which we provide in advance apart from this video you've seen right now after having registered for the participation in the exploratory phase and considered as preliminary eligible of course then you will have the chance to directly test or interact with a trigger solution of course according to the testing and timeline as defined in the euro system okay and I think reading further there was a question on the rtgs dca basically should participants have an account with the bundesbank or can it be with a local central bank and here it's also pretty easy this the account does not have to be with a bundesbank as bundesbank here we act as solution provider the participant will have the rtgs dca with their local cb the regular relationship you have for for your usual payments business so no rtgs dca necessary at bundesbank if you are located in a different country there is also one more question so what happens when t2 is in maintenance time so the operating hours of the trigger solution will be as already mentioned at the beginning from 9 to 2 p.m. so within the t2 operating hours and everything arriving in the meantime will be buffered by the trigger solution