 Is that right? Yes. So I'll just start recording. Let's start recording. Perfect. Let's go. Could you start recording, Julien? I did, yes. So I'll go through the antitrust policy. The Linux Foundation meetings involve participation by industry competitors. And it is the intention of the Linux Foundation to conduct all these activities in accordance with ethical, antitrust, and competition laws. It is therefore extremely important that attendees adhere to meeting agendas and be aware of and not participate in any activities that are prohibited under applicable U.S. state, federal, antitrust, and competition laws. Examples of types of actions that are prohibitive at Linux Foundation meetings and in connection with Linux Foundation activities are defined by the Linux Foundation's trust policy. If you have questions about this matter, please contact your company council. Or if you are a member of the Linux Foundation, feel free to contact the members of the growth of the firm of Casper at the Growth LLP, which provides legal counsel to the Linux Foundation. My pleasure is committed to creating a safe and welcoming community for all. More information, please visit our iPod code of conduct. Welcome, everybody. Today, we're going to have our friend Joel Shkrevitz from China System, which will tell us about, you know, digitization processing in the international trade. I would leave Brown for Joel to speak and present solutions. So Joel. Okay, can I start? Yes, you can. All right, I'll start by sharing my screen. I can start. Yes, can everyone see my screen? Yes, we can, Joel. Okay, perfect, perfect. Right. Okay, well, first of all, I would like to thank, of course, HyperLegit, the special interest group for trade finance to invite me to have this opportunity to present what China systems are doing in the area of trade digitalization, more specifically digital document technology. Quickly introduce myself. My name is Joel Shkrevitz. I'm Solutions Director for China Systems. I'm also part of the trade digitalization services team that we've recently created. And I've got some of my colleagues on the call as well, like Felipe Bruno will be joining. So if there are more detailed questions after my presentation, especially on the technical side, because I'm more business oriented, then Phil and Bruno will definitely be able to assist on those technology related questions. Okay, so the topic for today. What has China Systems done in terms of integrating with digital document technology? China Systems is part of the ITFA group. We're a member of ITFA, the International Trade and Full Fitting Association, which actually groups quite a number of banks and also fintechs who aim to innovate trade and digitize trade. And it's in the context of our ITFA membership that we've cooperated with one of the other members to come to a collaborative solution which aims to tackle the challenge of documents in trade. Trade is not just about data that makes it a challenging topic. They're part, they're very much part of the flow in trade. So if you cannot crack that nut, cannot solve that problem of the documents, we have a challenge. So when we looked at the technology, we first defined the number of criteria because we could be looking for a tactical solution for a vertical industry, vertical solution. But those typically we'll do on a project basis, but we wanted to look for something fundamental, something which could be globally deployed across industry. So that's one of the criteria we set. The key criteria that we defined for a digital trade document solution were the following. The solution had to be future proof. You can talk about standards in trade or in any business, in fact, until the cows come home. Nothing ever will get done. So we wanted to start today. So it had to be a solution that could support adoption. Early adoption can be implemented today. It is also future proof. Standards is not a destination. It's going to be an ongoing process. That's why it's called transformation. Another key criteria is that is based on the fact that if you look at just the number of networks and systems involved in trade processing, it's immense. It's a very diverse business area. Back-of-the-systems, portal systems, Swift, the new upcoming BLT-based trade platform, Retrade, Comgo, but also the quarter-side contour, Marco Polo, as new platforms, well, almost every quarter there is a new platform coming out. So this cannot, well, it could continue, but ultimately there has to be some consolidation. And the key thing is behind those systems and behind those networks is people behind it. Those people require documents. They require documents to take decisions because documents trigger cash flow, documents trigger release of goods, et cetera, et cetera. So it would be unthinkable that if you think about what DHL and FedEx or UPS, what they do today, they are currently the physical couriers in the document world. Imagine they would say, I can only send a document to a customer that I have on board and do my platform. That's not going to work. So it has to support full interoperability. There should be the limits that exist in the physical world, which there are no limits in terms of sending letters with documents, you should apply the same criteria in the digital world. Another key criteria is that if you, of course, make it open, one of the challenges, of course, is if you do not process a document inside a closed environment with control identity or where it can control security, you immediately have a challenge that you say, well, how am I going to check whether this document has not been tampered with? How can I check its originality? How can I prove who is the owner of the document? So that's why the digital document technology needs to provide a solution for that. It's something that the banks experienced, and this is a quote from an ICC report on COVID. What did banks do? What are they still doing today? They're scanning documents. They are typically using Swift File Act to send them from one bank to the other. And they're sending an authenticated Swift message to confirm that the documents are truly originals and authentic documents. So what happens then afterwards is that the bank who are the recipients, they start making phone calls to confirm whether the documents sent are actually really originals, and they even want to check, can I find the name of the person who sent it? So in today's world of technology, that looks a bit archaic. So what is required, if you want to freely transport digital documents, you should have a neutral service, digital notary service, which is able to prove data integrity, originality, and ownership. So a 24 by 7 public digital notary service is required. Typically for that purpose, a DLT based notary service is probably most suitable. Another key requirement is, again, for the first argument, I said standards is a never ending journey. So the solution, the digital container, which is actually going to store the business data and also the technical data, needs to support an open standard. I recently read an article where the CEO of Bolero was saying, because there's about nine types of bills of lading, he said, yes, if you move to one standard for bills of lading, our secret source will probably disappear, gradually disappear. But he also said, in fact, the secret source should not be in the standard. The secret source should be in the service. For the end users, it is very important that we operate on same standards, but that we compete on the digitalization services around the standard, not the standard itself. So the solution is to provide a digital container and the industry should be able to define the contents, and that should be possible on an ongoing basis. Since we are a technology vendor, a key point of course is the digital document needs to provide a configurable schema because we want to use that digital container efficiently to trigger other cross-processes. Trade data flows through at least 20, if you look at the letter of credit, there's an average of about 20 parties involved. You can imagine the flow of that data, which is often the same data. It should be possible to have API connectivity between those players and actually reuse the source data as much as possible based on an STP process. This is quite technical. I won't lose too much time on this, but you probably all know about the Trust Over IP Foundation project, which has been kicked off whereby digital identity becomes portable. That could be a real game change and even further support. This digital identity becomes portable across back office systems, across other networks, across BFT platforms. That's when digital documents will also become really portable. From a user perspective, very important and not to be underestimated, we have to make sure that if we provide a technology solution for our customers and for the customers of our customers, that it has to be fully transparent. We should camouflage the technology as much as possible. We have to focus on end user benefits. What are those end user benefits? The most obvious one in COVID times and especially in trade, very relevant. It is really silly if someone cannot collect his goods or go to the port or go to the airport because he has not received his bill of lading and is able to use that document of title to request delivery of those goods. For business continuity purposes, there should be no dependency on physical delivery and scanning of documents. Another key benefit, if the criteria that I previously defined are respected, a user should not have to join a specific platform to participate in a digital document exchange. There are simply too many participants in a documentary flow to think that you are able to create one system globally across all industries to solve this. You need to come up with an approach whereby digital documents can flow through all the existing infrastructures that we have a neutral digital and notary service. You can check with that digital originality and ownership. Very important in the design of our solutions and when we build our solution, it says it's so key we have to create a digital experience. Generating a digital document is extremely easy. That is not the objective and that's why at the top right corner, you see an iceberg. Why the iceberg? Because digital documents are just the tip of the iceberg. The real value lies in the optimization of the business processes, the use of the rich data around those digital documents to make processes more efficient, typically in a collaborative way because trade is an extremely collaborative business. One example that you will see when we do the actual demonstration is going to be a demonstration of a system. We have taken the business case of digital guarantees. I will explain to you why just before I start the demo, but we've also optimized and digitized all the related processes to the digital guarantee document, not just the document itself. It will become clear in the demonstration. Another benefit, and it doesn't look like an obvious one because bankers will immediately say, oh KYC, yes, KYC compliance still remains a challenge. However, from a technology point of view, if you're able to start exchanging digital documents in a secure way and you will see how that is being achieved, you automatically also, at least from an integration point of view, establish a relationship with a third party which does not have to be a customer of the bank. We will also illustrate that and it becomes possible for banks to start offering services to non-customer and potentially onboard them if they have their own platform they can do that, but it's a much more open world and it will become clear from the demonstration. This is what we've tried to clarify from this diagram is this is more or less what happens in trade if someone generates a document on the left side because a document starts from data, typically put in PDF, printed, etc. and it goes through an entire flow but on the receiving side, you use OCR and artificial intelligence to get that data back out of that piece of paper and start processing the content. So that's the typical flow. Now, how can you come up with, that's the reality of today and you've got all those systems behind it. So what can you do today to create the lowest friction approach possible for a digital document strategy? I've used those color codes. Let's start with the black ones. The black ones, they become redundant. Why? Because preparing a mail, putting stuff into an envelope, scanning it then to keep a copy of the signed version on the receiving side. Again, the mail room, scanning it, all of that disappears. The infrastructure, let's move to the green part. In the physical world, the couriers, the physical couriers are the channel. They are transporting, they're taking delivery of a document and they are delivering it hopefully to the right person at the door of the right company to the right person. So it's quite a tricky process if you think about it. That's the competition, a piece of paper going from one part of the world to the other. The delivery in the digital world, and that's why I say it's low friction, we should be able to use all infrastructure that exists today. So if some people want to use Swift File Act to send digital documents, why not? You can perfectly do that. If you want to send it over retrade, if you want to upload a digital document and get it across and you have interoperability potential with another blockchain, why not? It should be perfectly possible. That's why it's called low friction. You should not have to onboard everyone to the same platform. So all the existing infrastructure can be used. The two remaining colors, let's start with the blue. Blue is where we have worked with our partner and it's one solution. I'm not saying this is the only solution, but it's a DOT-based solution, a digital notary that we are integrating with. And the solution is provided by our partners in EDEO and the solution is called TraceOriginal. What do they do? It's actually quite simple and sometimes the best things in live are simple. Instead of printing to a printer, they're printing to a digital file. They of course can integrate with digital signature software, with a Signicat or anything else. It doesn't really matter, that's open. And on the receiving side, they are providing verification mechanisms. There is a public ledger which stores hashes and technical reference and that's the digital notary. It does not have to be run by EDEO. We're looking at other partners, typically chambers of commerce. Let's say if you talk about certificates of origin or in certain countries guarantees, chambers of commerce are the perfect institutions to be a digital notary to certify certificates of origin, for example. And the orange part, that's where the back office, the portal vendors, the business intelligence vendors come into transaction engines. Those who process the content, convert the content, provide the business rules around and that's typically something which China system does. But we've integrated this with our partner in EDEO and we've gone fully digital. The next slide I'm going to skip this one. If I have enough time, I will explain this at the end because this is our vision. I think of what we see how standardization in trade should be really tackled. But I'll keep that one for the end if we still have time. This is the one, I think the last one I want to show to you before I start talking about the demonstration. It looks like a complex slide. I've written an article about trying to explain it, but it's actually fairly simple. Again, at the top of this diagram, you see what happens today. Physical documents. Here you've got some of your actors. I couldn't get more on this slide because you've got Chamber of Commerce, but these are the typical actors or participants to a trade document flow. And there's many of each of those. These are the corporates, DSMEs, etc. Those physical documents today are sent by couriers across all those parties from one to another. In a typical, I'll see at least four, sometimes five or six participants. In the digital world and behind all those parties, they are running all those systems, ERP systems, trade contract platforms, trade portals, document registries, where the warehouse receipts go, where the certificates of origin go, the trade back of the systems like Chinese systems. Swift. Then you have the networks that are there. You can't change all of that. It's impossible. You have to find a solution. How can we transport a digital document across this infrastructure? That's what I'm illustrating at the bottom. Digital documents need to be portable across the platform. The key thing is that you're actually transporting the business data. So the digital container, the equivalent of a paper document needs to contain two big portions. The business data to satisfy the needs of all the systems. And then hashes and technical references, which enable a neutral DLT based notary service to actually certify and make the exchanges secure. Proof of ownership, the proof of originality, the proof of data integrity. So on the ledger, the ledger does not store one single character of business data. The content is hashed. If you have this in place, and that's what we'll show in the demonstration, you can have APIs in place. You just need to provide an API to the system. They interact with the digital notary, the public service, to verify ownership, verify originality, create proof of ownership, transfer ownership, because transfer of ownership is one of the key things, of course. How do you know who is the owner of the document? In the physical world, most of the time, know it because it's very easy to create copies. In this situation, we can have copies, but there can only be one owner. So this API service interacts with this DLT based notary service. I won't go into portable digital identity. This becomes another facilitator of this process, but I want to get to the demonstration as quickly as possible. The demo scenario that I will be showing, it's quite business oriented. So, I do not know how many business people are on the audience, but that has been the objective to show what we have done. We've taken a digital guarantee. Why did we take a digital guarantee? Because in ITFA, the focus is actually on digital negotiable instruments, bills of exchange, promissory notes, because those are very powerful instruments, also documents of title, bill of lading. The challenge with those documents is that the number of participants and the legal implications are much bigger. The advantage of a digital guarantee is, especially a direct one, you only have three involved parties. An applicant, typically an issuing bank, and a beneficiary. Where are these guarantees used? Typically, at the domestic level, it's very big business, and it's all paper based. It's typically used in countries where the government, for example, if you've got construction companies or infrastructure companies doing big infrastructure projects, the government will often ask those companies, can you provide me with a guarantee for those activities? A performance guarantee or performance bond, typically. And a bank will typically issue it. The bank will take the liability of this construction company and guarantee to the government that they are good for the value of that project. So this is what will be demonstrated. The first flow we will be focusing is on the issuance process. And in the issuance process, a guarantee is actually physically, in the physical world, it's changing owner from the bank to the beneficiary. So what we are doing is digitizing or digitalizing this transfer of ownership. And there is the digital notary will be able to verify whether this guarantee is actually real and authentic. In the second part of the demonstration, we're illustrating, we've shown we can do more than just create a digital document. We've also digitized all the subsequent processes of the digital guarantee. Because a digital guarantee can typically be a claim, but in many cases it does not happen. Those are very long life cycle instruments. What usually happens is they can sit in a filing cabinet for 20 years, and nothing happens. Only when the party does not perform typically a claim or a demand request takes place. So this is the flow that I will be illustrating in the demonstration. The key parties are I will be using an ego or partner and they will be delivering digital document technology to the Swedish government, the beneficiary and the issuing bank in our business scenario will be Exit Milk Bank. So those will be the three parties involved. This is a slide I've included this one because it gets you in the right mindset and it allows you to focus on what is the objective of the demo. Because something I've not said yet is I've talked about digital containers. But this is actually really and I've done this mainly for business people. How do you control the transfer of ownership? And it's based on PKI infrastructure. So I've used some it's quite a colorful slide but you look at I've used a vault or a safe to illustrate the concept of the notary. It's not probably the best of comparison but it's aimed to focus on the security. So when a bank creates a guarantee they encrypt this guarantee with their public key. So in terms of the ownership there is in the technical section of the digital document there is a public key. So at this point before the guarantee moves to another party only the issuing bank can use the correspondent private key to decrypt the information. So public private key infrastructure what happens then if you want to change the ownership of a digital document instead of using a courier service what you're doing is you're communicating with the beneficiary and the beneficiary has to provide its public key. Typically what we do in the process and you will see that when the beneficiary sees the guarantee to accept it when he says yes this is the guarantee and I agree to it he provides his public key and at that point the bank will encrypt the digital document with the public key of the beneficiary and that public key then gets subsequently in the technical section of the digital document gets replaced. The owner key now becomes the key of the beneficiary. From that moment on only the beneficiary has the correspondent private key to actually open the vault and prove I am the only owner even if there's someone else as a copy the private key proves that he's the owner. So that's a short explanation but you will see that in the demonstration. So now the actual demonstration something about this was a much longer demonstration it was originally about 16 minutes I've now reduced it to 11 minutes to respect the time frame that I was given. So instead of showing you the full flow we have reduced it but the system you will see the examples back of the system that you will see is the same one that we use to issue Swift guarantees is the same one that we use to issue paper guarantees and digital guarantees. From a user point of view it's fully transparent for him he does not even know what type of guarantee is issuing. I'm also skipping part of the flow where we show you how to define the guarantee templates. If there's business people in there you can always do a follow-up session for you to say how do you generate those digital guarantees. We've got of course an editor for technical people this is all given but I'm skipping that step as well. So we've also skipped the portal interaction because a guarantee starts from an applicant typically a corporate or an SME. I've skipped this part so the entire drafting process. I'm sure the people from Bolero will know this the drafting process between the applicant and the bank. I'm skipping that part as well because it makes the demo too long and a bit too heavy on the business side. So I'm starting from the moment that the back office receives the guarantee application and they will issue the guarantee. So all the data is already there. So I'm going to start the presentation now. Any questions on what I've said so far? No questions? Then I'll kick off the demonstration. Everyone can still hear me because sometimes if things are too quiet Yeah we can. Alright so we're starting the demonstration part now so you will be seeing Eximble's enterprise or back office and our integration with the digital document technology from Enegeal. So we start the process by selecting the guarantee reference and then in 147 I'm going to issue it like I said all the data is there I'm just quickly going to run through it the details of the guarantee all the wording which is the template permissions information just going to change it quickly this is to automate the batch process for the commissions and this is for the PDF diehards this is not the digital document yet some users especially business users they want to see a PDF file so if you want to see a PDF file we can give them a PDF file but it is not the original document this is just a template a simple mapping exercise into PDF I'm going to release this guarantee now and that's the first time the first time we use our APIs with the trace original technology I'm going to sort by new look for transaction reference 1047 I'm going to pick it up and supervise release this transaction I can start reviewing all the data but I'm not going to waste my time on that business data we can do a deep dive session if you're really interested in this but I'm going to confirm this what happens now is the moment I confirm this transaction I'm going to swift creating a record on the full node of trace original and we also at the same time send an email notification it could be through other channels what we've done is the lowest friction possible an email to the beneficiary the Swedish government so the Swedish government gets immediately a notification of this issue guarantee in their favor it's just a notification check where this is real because the notary can already do its work what we've created here is this is our doc viewer it's our digital document viewer we've created sort of a user interface on top of this to view the data in a structured format these are the parties the applicant, the beneficiary the guarantor which is a bank and then more structured information in the agreement terms this is all data we can use for STP purposes also the corporate, the beneficiary or the Swedish government can use this and here you can see already something we've done we've made it truly digital we've put secure tokens in place to also trigger additional business processes in a digital way on this guarantee which is normally a piece of paper where you send paper if you want to do something with it so this is the wording as you can see a banker can easily read this now to transfer the document as I explained before with the PKI infrastructure the beneficiary if they accept this guarantee they have to provide their public key so this is a secure token so this is a secure page there is a direct interface into the back office of exit bills our back office will receive this message and we will have a CP process in place where we automatically transfer the ownership and replace the owner key on the notary service so immediately this is in a couple of seconds two seconds or less the beneficiary is immediately notified that the guarantee has been issued so no user intervention on this it's all through APIs this is the same data the agreement terms are there and at this point the beneficiary said I want to see this guarantee or I want to integrate it you can have integration here APIs with your own internally or piece system or whatever or you can simply download and store it into a DMS system as you can see here such written request for a claim a normal claim in a guarantee is done by a piece of paper someone goes into Word creates a claim URL which will create a digital claim I'm now going to download this guarantee and you're just going to see this in Notepad yeah this is what it looks like in Notepad the digital guarantee there is a structured adjacent schema inside the techies understand that much better than I do but this is typically where you can use your STP engine and then there's a human readable part of in the guarantee which is down below you can print this we can create a PDF for it whatever you want to do with it but normally you would store this inside typically the DMS or an enterprise management system the next part I'm going to do now is typically well usually nothing happens with this guarantee it's simply filed for many many years but I'm now going to execute a claim now the bank if a bank receives a claim of course the bank has to make sure the claim can prove that he's authorized that he's actually the holder so I'm now going to show you we've not integrated this with an API yet but this is the this is the DLT ledger this is the trace original ledger and here you have all the functions that allow you to actually interact with the ledger so what I'm going to do is I'm going to create a proof of ownership in the next version you have an API so I've now uploaded the guarantee and the system says yes it is an exact copy of the current digital original why does it say copy? because everyone can have there's multiple people that have a copy the only original will be based on the private key so that's why it says it's a copy of the digital original so it does a content hash check it does not check the owner key yet the owner key in the next step the verify ownership so here the owner has to enter his private key and that's the key to the kingdom if you can prove that you are the holder of the private key I will give you access to the claims page so we will be uploading this proof of ownership to the digital claims page again in the next version this will be all API driven no user intervention on this so I'm showing you now manual what happens so I've now downloaded the proof of ownership and if you remember in the next part of my demo I was going to do the digital claim but only the party that is the owner of the guarantee should be authorized to do this claim so I'm going back to my claims page and it says drop your proof of ownership file here so I'm going to go back to my downloaded proof of ownership if I upload this at this point the owner key the digital notary which is in the background you're not seeing it it's a DLT application it will check it will verify the ownership it will give you access to secure again digital token a secure page here where we can actually provide data on the guarantee as you can see the references at the top 1047 I'm going to speed up the data entry a little bit because this is Swift compliant in fact already with the 2021 standards we can also do checks against the maximum amount for the claim because we know what guarantee it is about so I'm quickly going to enter all the other data and submit this claim so this is again a page it's not a portal this is just a secure token URL which will push this data straight into the exam bills back office and we can generate a notification to the back office user this is my account now you know who my bank is so I'm going to submit this claim it was registered successfully at this point I'm going back into our back office system what our back office has done in real time as this you're supposed to do the digital world we're immediately confirmed to the Swedish government we've received your demand request all the data you saw entered on that page is now automatically put into an email so at least the Swedish government knows yes the bank is working on this they're doing something I will now go into the last step of the process going back into the back office and I'll show you what has happened with this guarantee because I did not use the system that much there's been a lot of things happened behind the scenes in STP mode so if I take my guarantee 1047 there's about 5 steps on the guarantee which are the 5 same steps in the manual world the swift world as the digital world it's an application it's a process an issuance transfer of ownership and a claim they're all there but what is remarkable 3 out of 5 steps are robotic actions we use an STP process which interacts with the ledger automatically and generates deals events on the system the last step in the process is processing the claim to show you that the date is actually there the process demand request step and here the back office user will be able to pick up the data submitted by the Swedish government so everything that was captured on that secure page because the Swedish government is not a customer of my bank is automatically captured here there's an API in place to capture all that information if I go to the demand details pay or extend the demand type all the data that was entered the user can simply review it and he can go to his decision process where he can say I'm going to honor this claim I'm refusing the claim or I'll enter into negotiations with applicant and beneficiary on the claim so this is this is the process it's like I said I've gone I apologize because I think I've gone quite fast it's probably quite difficult to follow but that's sort of what the business process is like I said we can organize deep dive sessions but I've tried to respect the half hour that I have been given and this is sort of the end of my demonstration if I can give maybe one minute I'll probably explain this slide and then we start with questions I'd like to share still this is and I'll stop talking here this is sort of our view and it's actually a message to the DSI the Digital Standards Initiative there's a lot of activity going on in trade messaging standards but there is one big risk that everyone is talking about being customer centric now if we are truly customer centric then we're talking about in trade it's the SMEs it's the corporates because every trade transaction does not start with a bank it does not start with an insurer it does not start with with a piece of technology it starts with a trade agreement between two parties and I know Bolero I think Ross will know this because they a long time back came up with a trade agreement on the surf it starts all with a purchase order or a sales order between two parties the two key documents in trade which everything else comes out of those two documents it's a purchase order and an invoice whatever trade business whether it's open account whether it sells seized, whether it's collections whether it's supply chain finance they have something in common purchase order an invoice and a settlement so if you really want to talk about trade messaging standards we should not say oh we're going to develop a solution we're moving from swift letters of credit and we can do letters of credit much smarter then you then you're driven if that is your approach you're actually saying oh or like we can actually provide a better solution for an existing product you get again into your product silo approach or you say oh that we're going to replace that part of the market I'm not saying that is not an approach that will not work but if you really are customer centric you tackle it from the source because in my opinion all trade finance all supply chain finance all settlement services financing service reconciliation insurance risk distribution transport logistics certifications it's all services that are offered on top of this core trade dataset it's remarkable that in the world of e-invoicing some people may know this terminology a PO flip a purchase order flip what is a purchase order flip it's using the purchase order source data to generate an electronic invoice why can't we use PO flip to issue an LC because an LC is actually nothing more than a purchase order a set of purchase order enriched with some instructions it's a smart contract around purchase order data yeah same thing for invoices the same thing a shipment instruction is again something which can start from a flip an invoice flip or a purchase order flip so it's based on the concept that if digitization really looks at the core we should the industry should define core trade document data what is the common denominator for this source data and start from there and based on that you can actually take a look at the customer-centric approach take a look at accounts payable and accounts receivable bank payment commitment bank payment undertaking DOPC the bill of exchange it flows out of this so that's sort of a division we believe and like I said I can keep talking about this one for a long time but I'll stop here for now to give still time for questions thank you that was a very interesting presentation very insightful deep in detail it's about international trade there is actually another document which is pretty fundamental in international trade transactions which is the BL bill of trading it's a real headache when you literally have to deal with transactions it has so many aspects legal aspects so many comparative aspects deal with LCs deal with open account yeah that's correct but if you really focus on those legal aspects and we are partners of Bolero as well legal aspects are often a consequence of the interpretation of data on a specific platform because the moment you start defining a let's say a central repository whether it's a DOT based or a non DOT based the moment you start defining a semantic model you have to sort of say what does this data really mean in the business world what will happen is if the nine types of bill of trading if they manage to define a common denominator yeah across those nine types the secret source and the rule books will eventually in my opinion disappear why because you do not if there is a common understanding of what data is from a legal point of view then you do not need the rule book specific approach based on one ecosystem that's at least my opinion you point out real problem just defining what we talking about right now in international trade are we talking again with documents or data instead good point no well I'll explain that I had a slide of that as well but I'll try to explain everyone will agree today your physical documents let me take this slide again this one this is what you have today if I purely make abstraction of what could be the best solution in the world then I would create a DOT based solution and make all those parties actors or participant I will all onboard them and create one digital trade data record I would immediately go from document to data the reality is that is that like I said you know if you create a vertical solution in a specific industry maybe that approach will work but everyone will know I've been in trade now for 32 years I've seen many come and many go and some have survived but still the critical mass has not been achieved why not? because this is a far too competitive space there is room for everyone but we have to recognize that the value is not on creating actually be the owner of that digital document because if you think that you can move straight from a physical document to creating a data record and making that with the same characteristics of the physical one then everyone needs a rule book and I believe that is the wrong approach there is a better way where you say let's accept the competitive aspects because there are thousands millions of people behind all those systems how can you adopt an infrastructure will you mimic the physical flow of a document where a document can digitally flow but you can start using digital identity across that is an ongoing project but you can use a digital notary which could be used by any of those systems to prove originality integrity authenticity and ownership this is where DOT should be used DOT should I perfectly agree I wasn't clear enough to have a sort of double channel that's what I was meaning to create physicality and digital world you know work in parallel that's my understanding you cannot escape from a purely purely physical world such as straighties nowadays nowadays it's still based heavily on base documents so you cannot escape from that picture from a day to another and step into a fully digital world you have to create a sort of double world the hybrid world correct but like I said from our application for us it's no extra work the digital notary actually creates low friction why because there's no business data the moment you offer a public service then you get into permissions you get into all sorts of complexity and that's why are all the blockchain platforms why are they so difficult for them to create critical mass because trade is so much intertwined with that physical document but you can create a digital one here I have digital delivery I go from physical to digital delivery so there's a file there's a file being transported digitally through existing infrastructure APIs Swift Connectivity, host to host connectivity but this is the neutral DLT based service that everyone can use everyone is verifying the truth this is where the truth lies but it's a technical verification process the business data still flows here yeah and that's the nice thing about it all the efficiencies, the intelligence we can reuse it we only control the hashes the technical aspects of the document in DLT this could be retrade this could be Congo we don't care that's why this is the world of today and that's going to be the world we live in for many years but this is why we believe this is the lowest friction approach create a DLT based digital delivery Perfect Is there anybody else who would like to make questions to Joel I hope I've not lost too many people Joel Ross from Bolero sure you know the end game is not necessarily what we see in front of us we have good technology and key players but have you put this in front of say some of the more the ones that become the barriers at the end like regulatory entities, governments customs, those type of players we'll have our first thank you very good question Ross because that's indeed we are like I said we can theoretically fantasize about what technology can do but that's we're not really interested in that yet Chinese systems we're not, we are the first vendor to actually put this into reality but our approach is like this we prove what the technology can do we have the vision now we have to prove it and you're right the barriers are there so we're having our first because this is all quite recent this has been done quite recently we will have our first test with the digital guarantee in a specific jurisdiction and with guarantees you have actually because the guarantee is the legal document and we'll be testing it in a specific country and with a number of banks involved and a chamber of commerce and it's a country typically where the governments and the chamber and the bank are all quite I would say they have quite a close relationship so we're trying to create the lowest barriers possible because indeed the moment you start going into legal aspects let's be honest everyone has a business behind this Polaro has a business you have your know-how you have your IP so you automatically get first of all defensive reactions so you can choose how do I protect my model but there is one thing which is undoubtedly going to happen and it's going to be with hurdles open standards if you look at what's happening in the industry you can try to protect your business as long as you can and it's normal we also have a retention strategy we have more than 120 customers so we have to make sure that we can keep building those customers business however the world is moving in this direction open standards and yes the law is still a challenge however even the law like I said if the standard is going to get resolved you know there's a lot of things happening there as well so we're going to test this now with a digital guarantee in a specific part of the world with a chamber of commerce involved because they could be the digital notary the key thing is that the digital notary they have to realize and those should typically be neutral institutions the ICC for example should also be interested in this because if they truly believe in a standard and they they want to avoid being considered to be a club because that's a risk that you start seeing oh these guys are doing digitization there is a risk that you get a specific flavor of a certain standard and that would in my opinion be wrong to do standards you need a digital container an open standard it should be technology independent although I'm the first one to agree the distributed ledger technology is the most suitable technology for trade because you have so many participants but you need to get this is where you need to do the convincing that at government level ICC level chambers of commerce start realizing this so the first one to agree yes it is a challenge why because of competition protection mechanism retention strategy etc that's the reality we just started you will see probably Ross what's going to happen in the market but I also know that you're part of what is it called the DCSA you're part of the digital container shipping you're part of this exercise and they you're one of the partners they're talking to together with S-Docs to actually move from nine bills of lading to one will it happen the market will show but I'm a true believer that the competition should be of the service if we really care about these people and these people are really the owners of the trade business if you really care about these people we should go for open standards and compete on the service not on the standard that is I'm very convinced about that stop talking thanks any other questions hours up anyway I think the time is up our hour is finished it is so I think we we will again in two weeks for the next session it was a very interesting one and I would like to thank personally Joel for his contribution thank you thank you for the invitation on the 7th of July and thanks for attending today alright take care everybody keep safe thank you everyone and if you have questions you can always follow up through Andrea or to me directly thank you very much