 Beautiful. Welcome everybody to the 30th of November, 2023. We're going to be talking about leveraging ISO, how ever we pronounce it, ISO, 20,022. Mario's going to help us with that. How do we pronounce it? Leveraging ISO, 20,022 in supply chain and trade finance. Here with a lock chain. Mario Reichel has a PhD from Potsdam University. He also is a lead payments industry representative at PPI based out of Hamburg in Germany. And I asked around, hey, who knows ISO, 20,022 really well. Mario's name came up pretty good and fast. So that's great. Mario also presented almost three years ago to the trade finance group. So welcome back Mario to here. One of the things that's really interesting for all of us here on this session is that Mario is the leader of the non-finance implementation committee for this ISO standards. And he has lots of banking experience. That's that also really helps here since that's the real life that we're talking about here. So agenda here before I turn it over to Mario. We're part of the Linux foundation here at Hyperledger supply chain and trade finance. SIG all are welcome. So we're glad you're all here while they're listening live and watching live or you're watching us and listening on YouTube. Also, from an antitrist perspective, this is all an open group here. So please don't say anything that's confidential or you don't want anything out there since this is an open group. This is our last session for 2023. So Mario we're saving the best for last year. There are a couple of events here. There's a Hyperledger Memored Summit if you happen to be around Tokyo in December 4th. And then we will kick things back off on January 11th in the new year here where we'll plan out what we're going to do in 2024. We'll say it was a lot of fun this year working on the ebook and bringing that to fruition. And now we're looking to create something similar that is value to the community in 2024. So, I mean, you don't have to wait till January 11th. If you want to send emails post something in the wiki post something on the hype on the LinkedIn group that you're interested or you think that we can provide added value out there. And certainly if you join us on January 11th and we can have further discussions and figure out what we're going to do in 2024 to have some fun. So, let's see here. So presentation. So Mario, I'm going to stop sharing and turn this over to you. Okay. Now, now I can start. And if I'm not mistaken. Now you're seeing the presentation right. We are seeing a presentation. And Mario, would you like questions along the way or would you like to go through your presentation and questions at the end. Questions on the way. Just jump in and ask. If it is maybe on a later slide, I can, I can drop that. But anyway, don't. Don't make a hard scramble. If you have a burning question, just just. Okay, that sounds great. Thank you, Mario. It's all yours. Yeah, 20 minutes and then we can discuss afterwards anyway. So, thank you for the invitation. Thank you, Tom, for the right fine intro. And you jumped about something that ISO 20 or 22 is a standard, but some people say it's not a standard is because people pronounce it differently 222. 222 or something else. It's, yeah. That's at least, at least the start. Actually, I was going on at Mario to be at the end here. Well, how we want to describe it. I'm joking. I'm joking. Yeah, I'm very often saying 20 22 because if you say 222, it sounds like 222. So, how, how, how do you get that? Yeah. And a five digit numbers selling by every digit, it's, it's quite long. So 222, it's kind of a mixture of that. Anyway, it is a standard. This is for sure. And I would like to show you what is about the harmonizing that standard, why that comes from. And at the end, and at the end, I have a real life example of a blockchain platform. But that's, that's at the end, the very, very last slide. And I didn't dare to put agenda slides in between. So I'm just moving on. Right. Yeah, Tom introduced me. So I would like to introduce you to my company because they pay the bill. So it might be worth it to tell you that PPI is a software and solution company based in Hamburg. I work in Frankfurt office. We have other offices in Paris, Zurich and Milan. So we are European focused and European, European based. We do offer products for payments from end to end in the classical way and we offer a consultancy for everything that's around payments. That's enough for the for the intro. Let's dive into the standard 20 22 definition and so what is it and especially what what it's not the ISO standard 20 22 funny number is not a standard of a message set or messages. It's rather a recipe. It's, it specifies rules and the methodology for how to develop messages. Of course, it is mostly known as an XML standard because that was the very first one. In the second version of that ISO standard. It also has an ASN one as another available syntax right now. The committees are working on the JSON implementation of that standard in so that we can go for that for the API world. It is supported by swift. It's not a swift standard. So it's the for for the global swift migration as we will see that later on. It is very important for swift and swift is important for the standard because they are the so called registered authority. They provide the website 20 ISO 20 or 22.org where you can find by now more than 740 different messages from different areas and more than 20 organizations are involved alongside with swift. Fun fact ripple is also involved in that in those committees. Okay. If we talk about payments. I often come across the so called for corner model that you have on the on the right on the right hand. Side here. We have the debtor the creditor debtor bank and creditor bank. The fifth corner of that work on a model is since since SEPA 20 years by now. The so called CSM the clearing and settlement mechanism defining the way how the money would move from debtors bank to creditors bank. Then XML by ISO 20 or 22 messages is very often called by the abbreviation the first block that is the business domain. If you want to define it more closely than you have that pain or one or pain one abbreviation that is the payment initiation credit transfer. Actually, that was the very first I saw 20 or 22 message defined in 2004 as for organizations came together and defined the core payment kernel because it was derived from the initiative of corporates banks and vendors in the early 2000. They wanted to go for a bank agnostic channel agnostic and product agnostic way to initiate the payment from a corporate to a bank. And that was the very beginning and payment initiation. Therefore, the pain one is the very first message. The third part is the so called variant. You would rather not see any other variant than the very number one. It's a difficult question and that's that's too much to say about the most important credit transfer message in XML by SEPA 22 is the version nine. Because that is from the so called ISO 20 or 22 release 2019. That is a very important one because the whole world, almost the whole world goes into into this release. The iso messages as they are called. I'm not just for that rectangle of the four corner model. So for the payment initiation, we also have interbank messages that are those packs payment clearing and settlement messages. That is the information taken from the payment initiation and put into the interbank message by the same methodology that ISO 20 22 defines. So there we have the packs messages to transport the information from left to right and the reporting message then is an so called C. A. M. T. cash management message and the statement message is to come come 53. In that example, there are many, many more business domains. For example, a C. M. T. That's not a typo. It's a different business domain account management. That's about that. That are messages. For example, in the customer to bank space to open a new account in an existing relationship to change business rights, access rights for certain users to close an access right for a certain user and so on. That's a whole series of messages. But we also have trade messages, collateral messages as you have seen that here. There are message definitions in the card areas, as I said, 740. Just crawl through the website. ISO 20 22.org. You will see many, many of those messages in different business domains and purposes and many different versions as ISO is a standard. They have a yearly release every year. If the message changes, there's an open change request process. And then a committee that accepts those change requests if applicable and then you get a new version of a certain of a certain message. What else to say on the ISO website? You find that booklet ISO 20 22 for dummies. It's now already the fifth edition of that. It's helpful and easy to read as all those for dummy booklets quite fine. How's a message look like that XML? Of course, you know that XML has those tags. And for example, an address information comes with a name tag and the postal address and the beauty of ISO 20 22. One part is that it is a very structured message syntax. So we have a street, the building name, postcode and much more. You have about 20, 25 different tags that defines in a very structured way the address as well as account numbers, routing numbers, codes and so on. In that 2019 release, we have dedicated tags for the so called UETR. That's very important on the Swift network for tracking tracing of messages. You have dedicated reference numbers. The end to end reference is in reference that goes in the whole for corner model. It has to be transported from the debtor to the to the creditor as it is called end to end reference. It's for business reasons where the UETR is also called end to end reference, but that's more a technical address. You have transaction and instructional address references. One is a point to point reference from one bank to the next. And the other is instructing in the, in the very beginning. Yeah. That's very good. This is Tom. Can I ask a question here? Yes. Of course, anytime. Thank you. So I see this XML here and maybe you'll talk about this in the future. If so, then just say, you know, what hang loose. Are there tools to build this XML already out there? Is this built into accounts payable accounts receivable software? You know, who does this work in order to build up these payments kind of stuff? Or do you got to start from scratch and build your own customer XML kind of stuff? In the early 2000s, XML was chosen as an representation because it was fancy and modern at that time. And there had been public and open knowledge tools out there for XML. It's nothing special for the financial industry. It's almost everywhere. As you might know that XML and our websites HTTP. HTTP is pretty, pretty similar. All this and there are open tools out there. But of course, if you have an ERP or Treasury Management System, then the vendor will take care of producing the file that has to go from a from a debtor to debtor agent and the payment platforms out there. Different vendors as PPI is one of them as well. Take care that the pain is processed into a tax debt or stuff. No, that's good for now. Thank you. Yeah. So Mario, just one real quick question and I'm making an assumption that these are encrypted messages as they go across. Yes, of course. Yeah. So, you know what cryptography you're using? Is it giving the, who has the, I guess, who has the private key using encryption? Is it the initiator? That's a very good thing about that XML by ISO 2022 because it's defined without defining the channel and the transport. You can transport that kind of XML via the easiest way would attach it to an email without any encryption. You can send it via FTP and Q. You can send it via the Swift network. You can send it via common or proprietary communication tools like like eBIGs. It's very popular out here in Europe. AS what's called AS2 in the Americas. Anyway, so the format is the format and as we see on the next page, there are many, many communities that so far already or have planned in the near future to jump on that standard in order to use it. As I mentioned, or did I, did I? Anyway, 2004 was invented. That was the time where Europe went to something called SIPA, the Single Europe Payment Area, where the different local domestic payment formats had to vanish and to be put together to a single Europe payment area. So we dropped those fixed lengths format that we had in Germany and in France and other countries. Austria was already on a standard called Edifact. Others had more Swift MT-like standard and with that XML by ISO 2022 coming across around the corner, the European Payment Council, the scheme owner of all those SIPA schemes jumped onto that and was more or less the very first clearing and settlement mechanism to use ISO 2022. And after that, many others domestic regions jumped onto that and in 2018, the global Swift community decided we want to migrate from the old proprietary so-called MT standard to that now global standard ISO 2022 and the decision was at that time that we go to the ISO release 2019. It started this year, March 20 in the year 2023 and it's not a big bang migration. It's a so-called coexistence phase, so the global community of Swift correspondent banking, some already migrated, some of those 11,000 banks and others will follow. The latest numbers is about 18% of the message volume is ISO, two more years to come. So you have the usage of those message standard in different communities already, but if you want to send, for example, from Switzerland to India, a message you have to go more or less via Swift and this you can do by now in the standard ISO 2022. You can imagine if many communities jump onto a standard, they derive variants and different flavors and therefore we got an initiative by the so-called CPMI, that it's the committee on payment market infrastructure and industry body that is on a G20 level, on a global level of those G20 countries. They have seen the movement of many countries moving to ISO 2022 and now Swift is moving to that standard as well as we are now are using different dialects of ISO 2022. They came along and said, let's harmonize the different dialects and the usage of the huge standard and different initiatives along the chain of the payment have to come together. In the customer-to-bank space, we have that initiative CTIMP, it's called Common Global Implementation Market Practice Group, that also is a free initiative of banks, corporates and vendors for harmonized usage of ISO 2022 XML messages in the customer-to-bank space. If you talk about different clearing and settlement systems, especially high-value payments, so-called RGGS systems, then you have the harmonization initiative, it's called HVPS+, and if you talk about clearing systems that are even faster on the way, real-time payments or instant payment systems, you have the initiative harmonization initiative Instant Payment+, IP+. In now Swift, with their variant of ISO 2022 usage, that's called cross-border payment and reporting, and they put the plus at the end of their harmonization initiative as well. So you have different initiatives along the way, the statement at the end becomes 53, that dimension already is again by the standard of CTIMP, where it happens that I'm a co-convener of that initiative, a non-financial co-convener of that. So in here, we come and say, let's harmonize usage. What is the rich and structured beauty of ISO 2022? Some richer data elements that you might not have in other formats is, for example, let me pick the ultimate debtor and ultimate creditor data elements. The end-to-end reference we talked about already, ultimate debtor and creditor, what is that? That's, for example, in a corporate environment, if you have a buyer that has to pay something to the seller, but the buyer is the subsidiary of the buyer's parent company, you have usually or very often a situation that you have a payment factory, a shared service center or something like this in that big company structure, so they have to pay, but the seller needs to know who is really paying. Then you can put the details of the buyer in the so-called ultimate debtor data elements, and the payer itself as a debtor is with its details as an account owner for transfer currency reasons that needs to be put into the payment chain, so that we have a full transparency who is paying by whom orders and so on, so you have the ultimate debtor. Of course, you can have the same structure on the creditor side, then you would talk about the ultimate creditor situation. We have, as richer data elements also and structured omittance information, you might know that other payment formats have, if you take, yeah, different formats. The standard Svip MT 103 has 140 characters, that is the basic information structure in ISO 2022 as well, but that's the so-called unstructured omittance information. We also have a structured omittance information where you have about 150 different tags, data elements that you can put into the message, and you can pay up to, I don't know, 90 invoices with credit notes and so on, and you have as the creditor receiving that information, you don't have to guess what invoice was paid, it's all in the structured omittance information and dedicated here. And much more, we can dive into that deeper. So with all those harmonization initiatives and communities, different dialects in the usage, that CPMI initiative did the consultative report last year, and out of that report, many stakeholders in the global payment community did the consult to the, how many was it, 18 suggestions, what to harmonize in the ISO structure, they now published the report of all the consultation, and they came up with those 12 basic requirements put in here to save some space to move together the identity, identify all entities and persons involved in the structured way so that actually are two. 12 peer and some, some details, for example, is the core message set. Another beautiful aspect about ISO 2022, it's taking care not only for the happy flow of messages, it also takes care of unhappy flows. For example, there's a dedicated recall message to come 56. There are reminders, returns, parts for, and so on, investigation request requests, we get in the next release of the CBPA plus account, 110, 111, all in a structured way, no free text with code words and so on, and we get that structured. One requirement just to name another one is to identify all financial institutions involved in the payment chain in a standardized way, international standard, so that either a business identifier code, the so-called Swift code, or the legal entity identifier, another international code where you can easily identify that is exactly the one that is talking about. That all is required by all those RTGS systems, the each high value payment systems, till November 20, 27, it's not that long anymore, and some of those responded to that report that they welcome the report and say it's a challenge, but I have not seen any respond to the report where an RTGS system says we will not. UK, for example, mentioned that they will comply with those requirements till the end of 2025 already. Even the SIPS system, the Chinese proprietary system in China, but using ISO 2022 messages mentioned that they will follow the requirements, and that is very necessary, because if you see the interlinking of global trade and global payments that comes along, this is important. Talking about the global trade. I'm going to make one comment there, so could you go back one chart, please. So this report, when I saw a little blurb on it a couple of months ago, was actually the genesis for this session here, because I saw it and I said, this is something that is valuable for us from the blockchain community, basically now things are laid out for how money can flow in a standard way and one of the biggest challenges associated with blockchain notation is all the difficulties associated with both transport as well as the semantics of how whatever sort of data set that you're working with here. And, you know, not surprising that it's taking years to get here. I know I think a few years ago we had the folks with fishing and it took them three, four years to get their standard set it for some of the semantics and so this is really good so if you're building a blockchain based system out there. You know, this is the way to go as my takeaway Mario, if you can confirm that, and if you're going to be using a blockchain based system and you need to integrate in now you know how to integrate in also is kind of my takeaway from this if that makes sense. Any other comments to that. I will jump on to that comment in the next slide. You mentioned that the standard is used to to move money. I would rather put it a little bit around the standard is used to move information around. If you see that correspondent banking chain in an so called direct and cover payment method, the cover message, the payment actual payment is transported by a tax line message from course one correspondent bank to the other. The real money is moved in the country of the currency via RTS system and so on. The information is sent in a direct and cover mode use directly to the creditor bank. That information. The money is moved from account to account in the old fashions way as you can think of correspondent banking is called correspondent banking because it was invented by the by the merchants in the mid evil time where they wrote a letter a correspondent to their to their office in the other city. Please pay from my account to the beneficiary. And those low row nostril accounts vostro low nostril, whatever you name it is still the same method to move value to move the money. The information is now on the edge that is done by a standard way by different dialects of course but still the same language. On an on a global level in a way where the methodology defines the data dictionary and and party is a party and account is a count everybody understands in that language. The same with those notions. By the way banks that move from empty to XML message ISO 2022 they have to learn a totally different language, but the money is still moved from account to account. Blockchain might be lead to a totally different paradigm and even our friends from Swift look into this. Blockchain technology CVDC central bank digital currencies. They even talk about are that might be different central bank digital currencies in different areas and they offer that they could become a CVDC connector. And so stay in business so to speak. Moving the information hosting the standard the data dictionary and so on and and connect via their transaction manager in the in the center and. Yes. Be able to to move. The value in a different way then then from account to account. And that that BIS that presented the report CPMI is shown they are also in the business of crypto currencies. So they just published October 23. It's not that old. It's very fresh. Consideration for the use of stable coins. I'm sorry. Stable coin arrangements in cross border payments. It's not that big often often report but discusses the the important parts if you are not in a blockchain environment where you talk about an central bank digital currencies. But if you talk about stable coin environments. So somehow that all comes together. And at the very end. I promised you a real life example of a blockchain environment and I'm totally fan of that theme is. Project. It's called even though it is not global. It is just Euro and the first proof of concept for that was just between two chemical. Chemical. Companies a one on one side and yes on the other side. It's kind of a role model. For that kind of stuff because. It is not just about moving the value and. Secured by by all the beauty things of. Blockchain technology. It is. In the heart. It is an order confirmation. Matching system these those two companies have inside the blockchain. A number of data points defined. Together agreed upon. Where the order is placed on the on the blockchain and the the. The buyer is informing the seller. Do you accept that order and then they do the normal business stuff. As as you would do in a business environment. And then at a certain point you get the confirmation to that into the blockchain as well. The beauty is that both companies have at a certain point at their notes. The the truth. So there is no reconciliation needed and then defined by via smart contracts. You get an automatic payment done and you need to. To provide. Yeah appropriate liquidity to your wallet. Both companies have a wallet. So far it is connected to the same bank in this case it is commerce bank. Here in Germany where they provided the money license to get that done in the commerce bank. It's also some notes in the network for regular reporting so that there is no money laundry. And they can do their anti-terrorist finance checks and so on. But the whole system then works without any payment initiation message. Clearing and settlement is done all in the system. You don't need an structured remittance information with batching 90 or more invoices because it's all done single by single. The the treasurer or the cash management colleagues so to speak quote unquote just have to take care that there is enough liquidity in the wallet. They don't have to care about the single payment because it's done automatically by system I said already. And in the system you have all the data you need. And of course you need those data into in your ERP systems and that's done via via API and those APIs talk about the business content. And they could be done easily in the context of ISO 2022. So that's Mario Mario just to confirm this against Tom on that chart. The key here there's when the payments are done or the information is moved back and forth as you specified there. Commerce Bank in this case did not get involved other than make sure that both Yvonnek and BASF both had money in their wallet in effect right in their account. That's that's really what their involvement doesn't is. Yeah they provide what's the role of Commerce Bank of course with that regulatory stuff on one side. On the other side they are the they are the borderline between real life Piat money that gyro money on the standard gyro account that the companies have that they put the money into the wallets. But Commerce Bank doesn't have to take care that in the wallet is enough money. That's the the duty of the cash manager of Yvonnek respectively BASF. Okay. Yeah. Cash manager is essentially the consensus for the blockchain. The transaction is valid. The consensus mechanism is actually built into the smart contract that the order and the confirmation match into 100 percent. If not it pops up for an what's called not not an investigation. It pops on either side actually on both sides pops it up a message saying here's an order that doesn't match the confirmation. In this data point in there is is not is not that. So I was told. Such an not matching was in the in the past for example. One company ordered a certain chemical in in kilogram and the confirmation wasn't on or vice versa something like this. So you have the same number but totally different amount that is behind the number so it doesn't match and that's that's easy and it does not. Does not lead to an to a standard business would lead to the invoice. Then is about that different amount even though it's the same number but that would lead to an investigation into a delay the payment and so on and so on. And now you got that in the first place and the the data points order confirmation delivery and all this is in the platform and the nobody has to decide whether the payment is due or not. The system does you don't have any payment run anymore to send the payment initiation via to the bank. It's all in the system. The data points defined by you could easily define that by by by the means of the data dictionary that comes out of ISO 2022. We already have one more chart or should we open it up for questions here. I'm I'm done with the charge chart. I was eager to have only a few to have more time for discussions. Okay, we'll open for questions here so if you'd like you can either put it in the chat. If you're live here, which all of us are right now who are listening to this, or feel free to unmute yourself and ask a question associated with what Mario has shared and what your understanding is. In the interim either Andrea while we're waiting for questions here Andrea or I hunt either one of you has any thoughts that you want to take Mario's thoughts and expand upon them. I was thinking about something long time ago actually you see that. Trade finance actually it's not about payment only. We're talking about messaging and I was wondering to ask Mario the impact was 2022 on the traditional trade finance messaging system. How this is set to revolutionize the traditional messaging, for instance, not only in open accounts, for instance, in the commensurate credit is there any use over in that space. You see that they do invest a lot logistic and supply chain side. In two different cities in only one. The bodies in ISO 2022 are separated into different business areas. So there's a payment sec, a standard elevation group is a SEG sec and many others for cards and so on. It was the last couple of years. It was very silent about trained finance change request and definition. So the trade finance sec actually was put down 10 years ago or something. But because of requests from the from the community, from the from the ISO community from the users, the trade finance sec was reopened. So they start discussing change requests on the trade finance messages. The old fashioned the legacy format MT is also moving. We just had in the SWIFT network a major release coming in two years about the MT 798 MT 60 and serious messages. Even more release and change requests are coming and on the other end ICC and SWIFT just published. There are new APIs about guarantees. Of course, that's only one part of trade finance letter of credits are more complicated. But with those few examples, you can see that there is movement in the area. Sorry, Tom. No, go ahead. I know I just first of all thank you to Mario for his kind presentation. It is quite invaluable quite having so many information. But I think of the blockchain life is really easy. When we think of the legacy systems, it's hard to implement anything. It's quite hard to do something. You have to do many things indeed. But when I think of the financial institutions, they will have to accept the role of the blockchain in the soon future indeed. That is the one of the points which we should emphasize always. When we think of the legacy payments, for example, structured remittance information, which is the 9000 character is available. But it's quite hard to implement it, which requires the bilateral agreement between the parties. That's why lots of things have to be done. But all we need to rise the awareness of the global community and we need to share the more and more use cases. Depending on the harmonized data, depending on the standard size of data, that will help us to understand the global community. What will benefit from these points? The journey has just started. The legacy system has already had their own standardization rules in their hand, which they will use. I'm sure they will make some kind of benefit, but which will definitely take so many time. But on the other hand, when we think of the chain solutions, life is quite easy to implement. No more need to go into more details of why such solutions are not to be easily implemented by the financial institution. It's a big question, Marx, in all minds, I guess. That's the reason what I would like to say, ERP systems are quite important when I think of the legacy system. ERP is the starting point, ERP is the end point. If we forget these points with an on-chain solution or without on-chain solution, we have nothing in our hand. That's the reason all the treasury solutions. Whether they will give any trade finance functionalities or not, but they have some kind of the treasury management functionalities. That's the reason I would personally put my personal focus on more ERP developers. They will be a game changer in the future if they really understand the power of the structure that's moving their platform to the banks and to the creditor agent, to the creditor, and even the ultimate creditor. That's the reason I guess ERP systems is going to be a great role in the future and I personally put my attention on how I will be supporting them in the future. Thank you very much, auntie. We need more use cases to see and we need to make more collaboration to develop to increase the awareness of the ISO 2022. That's the journey has just started, long way to go. I'm not sure whether I can see or not, but it's just started, but there is no way to run away from standardization. That's the only way we have to obey its rules. That's my idea, auntie. Thank you so much. I would like to share with the same online webinar with Mario that Mario is always focusing on the same idea. What is that? Info with movement of the money. That is the crucial point. That is the crucial point. And I wish all the blockchain solutions, whatever they are, put their attention on that point. Money movement from account to account, wallet to wallet, without any info, is nonsense. That's the reason, that's the reason any layer one solution should put their attention to be aligned with these prerequisites to increase their awareness of their crypto currencies. Thank you. Thanks so much, Mario. Thanks, Ayan. I got that too loud and clear. It's information moving, not money. We should always keep it in your mind. Thanks, Mario. I have put it in my mind always. So along the lines here, Mario, there's two questions here. We're going to go over a couple of minutes if people can go over a couple of minutes here. There's a question here. There's two questions. One is along the lines of what we just talked about here from Ricardo. Transfers are either done from one account to another, or even through the blockchain, but how about the supporting documents, contracts, invoices, IDs be exchanged securely? After all, the MLRO won't approve unless he has everything associated with the transfer, right? I don't know what an MLRO is. Me neither. Ricardo, if you could, maybe... Money laundering risk officer, things like that. Yeah, yeah. That's why in that theme is project, Kummersbank has a note for them as well to access the data to do their anti-terrorist financing duties. Anti-money laundry and that kind of stuff. So if you move money as a certified payment service provider, then you have to obey all those rules, AML, ATF and so on. And that's coming along. And if you have just the money movement without any information, then you run into the risk that this money movement is blocked. It is derived from the FATF, the Financial Action Task Force, about the anti-money laundry that if you send money from debtors' names, for example, one of our customers, such a movement has to be blocked. You need the transparency and you need to transport that via appropriate information in the data dictionary of ISO 2022, or the formats that are used, XML, by ISO 2022, give a structured way of checking that. Just the recent example, the sanctions had just been moved from sanctions by country into sanctions by regions. Where does it come from? From the Ukraine war, where the West Ukraine is freeing to do trade with, but the Donbas reason, where the Russians are invaded, there you are not allowed to do trades. And therefore, the minimal requirement for structured information of addresses is that you have not just the country code in the structured way, but also the town, so that you can check whether the town is in a region for sanctions or not. And you don't want to pick this in a free floating 140-character address out of that, because if you have a payment to a Cuba Libre bar at a certain street in California, then if it is a free text address, this would lead to a hit, of course, because Cuba is sanctioned. But if you have all those information, as I had that on the slide, if you have that in the name only, and the country code is California US, then it's fine and can process as STP manner without any frictions. And that's what we want. One of those goals of the CPMI harmonization is that we have 75% of all the payments on a global level done within an hour. So it's not just for some area, instant real-time, in Europe we have that definition instead of 10 seconds, you have that on a global level. Swift, by their GPI and UETR, they have statistics that 50% of all payments are final and paid to the creditor in one hour. 95% are done final in one day, but it's a bit way to go until we get that one hour for 75% of all payments. Okay, good. So Mario, quick 30-second reply here, there's a thought here about plans for ISO 20-022 aligning with other standards work here. Specifically, there's one around a telecommunication standard in the chat here, which I can send you later, but just give your quick thoughts on that here. So the question is how ISO standard works together with other standards? Yes. In terms of data dictionary or so, yeah, you can map everything to everything, but there is a risk of translation. If you come along with telecommunication in terms of transport, security, and so on, you can transport any message with the ISO message, it's channel-agnostic. Good. Okay. And Mario, do we have your email? Are you open to follow up questions from people? Okay, good. And what's asking about presentation? We'll create the PDF and we'll put it onto the agenda here also. So thanks for that. So for those who have stuck around, beautiful. Thank you very much. For those who ask questions, thank you for that. Mario, we'll get your email. If you want to mention it right now, you can either put it on the chat while I'm talking. That might be the easiest way to do it here. And thank you, everybody, for joining either live today or on the YouTube recording here. Mario, thanks for giving us a wonderful idea of what's going on with ISO 2022 here and how we can use it within the blockchain world and finishing off 2023 with the bang thing. So thanks, everybody. Enjoy the rest of your day. Enjoy the rest of your year. And we'll see you on the other side of January 1st. Bye for now. Okay, you're talking. Thank you. Bye. Thank you. Bye-bye. Thank you, Mario. Thank you, Tom. Bye-bye. Thank you very much.