 Hi, good morning or good afternoon everyone, depending on where you are based. My name is Vakas Mirza, I'm the CEO of Anza Innovations. We are a company based in UAE Dubai and our today's discussion topic is UAE Trade Connect, which is a national platform in UAE to facilitate trade. We'll start the presentation now formally. The UAE Trade Connect in summary is a consortium of banks, eight leading banks in UAE for now and there are another four banks that are joining this consortium. We are bringing them on board currently in the first wave, but these are the eight founding banks who have come together to launch this platform. The platform has been developed by my company, Anza Innovations and the platform is being operated by the National Pelco, Ithasalat in UAE. Now I'll tell you what this platform does and then we'll go to the technical and operational aspects of UTC, UAE Trade Connect. So the industry problem that this platform solves is that of duplicate invoice financing. For people who are not familiar with this, I'll just give you a brief overview. So this is invoice discounting or invoice financing is a global product that banks offer to SMEs all over the world to help SMEs with their cash flows. So for example, if I'm an SME in UAE and I have a receivable say of $200,000 from my customer and I've raised an invoice and submitted an invoice to my customer and my customer will pay me in say 60 or 90 days, I can take this invoice to my bank. The bank will validate the legitimacy of the trade. Maybe they'll get in touch with my customer as well. And then they will finance 67% to 80% of the invoice value to me. So that helps me in my cash flows and by the time when I receive my payments from my customer, I can pay the bank back. So like I said, this is a global product that is used by banks to help SMEs with their cash flows. Now, the problem in UAE that we've had for the past many years is that as an SME, I can go to Bank A, seek financing against an invoice or a trade. Then I can go to Bank B, then I can go to Bank C. I can seek financing against the same invoice or same trade from three, four different banks and then I can disappear from the country and never come back. Also keep in mind, please, that the population dynamics of UAE are very different from other countries. There are 80% expats that live in UAE and just 20% national population is present over here. So it's relatively easier for people to wrap up and then just leave the country. So that basically increases the problem or compounds the problem. So this is the problem that UTC solves as the first use case. UAE Trade Connector UTC is a broader platform, but this is the first problem that UTC aims to solve. Like I said, it is done by a consortium of banks. They have actually conceived this and then work on the concept and the solution while Avanza, my company and Ithasalata National Telco have developed and then Ithasalata operates this. Ithasalata obviously has a revenue model around it that for every invoice verification that happens on this platform, Ithasalata charges these banks. So there's a very solid commercial model with an ROI behind this and Ithasalata has not charged anything upfront from the bank. So in order to join this platform, banks did not necessarily have to pay anything. Obviously, we integrated into their systems. They have to dedicate their teams. So there was effort from the banks, but there was no upfront payment that was received from the bank for this platform. Now, if you look at this platform at a wider national scale, what this does is that this platform eventually becomes a catalyst for economic activity in UAE. We all understand that SMEs are the backbone of any economy and if SMEs have healthy cash flows, the trickle-down effect of this kind of an initiative is huge in terms of overall economic activity in the country. So that is why this project is very, very important for UAE, that on one hand it gives the banks a safety net where they're reasonably sure that whatever trade they're financing is a legitimate trade and that, you know, on the other hand, they can now be less conservative in extending their financing to the bank or to the SMEs. So it increases the financing to SMEs. And then the other objective is there's a huge drive of digital first in UAE across all verticals and sectors. So this is in line with that digital trade landscape or invoicing landscape that UAE as a country is pursuing. Just to give you an overview of what the journey has been like. So this platform was basically, let me just switch on my pointer. So this platform was conceived by FAB, first Fabudabi Bank, which is the biggest bank of UAE, Itasalat, the National Telco. So FAB went to Itasalat, the National Telco and said, hey, this is an industry problem in the banking sector. And we would want you being a state-owned entity and a neutral entity to champion this. And then Itasalat, you know, hired Avanzar to build the platform. So the consortium was, the concept was conceived in 2018. We started developing the platform in 2019. We did need a nod from the central bank. It was very important that central bank approves of this. And then central bank obviously had a list of questions from the operator as well, from Itasalat, you know, in terms of different risks. So central bank has been part of the steering committee, the central bank of UAE. And this played a very important role in terms of guiding the consortium and making sure that we comply with all the regulations. And then we started our pilot testing in 2020 towards the end of 2020. And this year in April, in fact, on the 19th of April, 2021, we've gone live with the first eight banks. And like I mentioned earlier, there are many more banks that are joining. We are already onboarding four other banks. So this has been a journey. This is a classic case of co-creation with industry, in this case banks, national institutions being the National Telco and the central bank development company such as ourselves, Avanza. So the scope of the first use case or whatever we've gone live with in April is to make sure that the same invoice or the same trade is not getting financed by multiple banks. And in addition to that, we also ensure that the trade doesn't have any elements of financial fraud, that it is not a case of over-envoicing or under-envoicing. The buyers and the sellers are not part of any blacklist. So this is a big blockchain play, and we'll go towards the technical side of the solution. I'm just setting up the business side of the solution right now. This is a big blockchain play, but this is a big AI play as well because people who do these kinds of frauds, they will change the invoice and the trade details when they're presenting it to Bank A or Bank B. So there's a lot of fuzzy matching that we do. There are machine learning models that constantly learn the type of frauds. And then we have personas of traders as well as products, for example, or commodities, which determine whether somebody has submitted an over-envoiced value or an overvalued product. So just to give you an example, if somebody is importing steel billets into the country, the invoices for steel billets from all importers will be part of the platform. So that is why building a persona of steel billets and its acceptable price range 30 days from now is relatively easy. So that's how we've built the personas of products, and we've also built the personas of traders, buyers, and sellers both. So in addition to having a distributed blockchain-based network, there are a lot of machine learning and AI components into the platform. That is why it has been a very interesting and exciting project for us to develop. So these are the kind of checks under financial fraud risk and duplicate invoice financing that we do. And as a result, this is first of its kind national platform being used in UAE by the banks, and it puts UAE in the center of digital trade in the entire region. So if we scratch the surface a little bit more and try to see what's happening under the hood, basically you have a blockchain-based network. I mean, you all understand that we don't have one big blockchain. Every bank has their own blockchain node, but for illustrative purposes, it makes more sense to show you the blockchain layer over here. Every bank has a blockchain node that they have set up either on-prem or they have, but now in UAE we have a lot of local clouds available, because a large-owned cloud being one, and then we have Microsoft Azure over here. So in summary, a bank has their blockchain node, and through their in-house systems, through their trade finance systems, they share or submit the details of a trade. So the invoice itself and the supporting documents are uploaded onto the platform, onto the blockchain node through APIs. We also have given a web-based interface to the banks so that they can run their OCRs and then use this web UI to basically post the invoice data onto the blockchain node, but that is not recommended, of course, because of human intervention, there could be human errors or all that. But for practical reasons, it was important that we do give them a web UI so that it can fast-track the testing of the application while the APIs are being generated internally within the banks and they have something to look at, you know, so they can feel something as well in addition to APIs. So there's a web-user interface available and there's an API interface available for the banks to upload their invoices data. This invoice data is obviously replicated across the nodes of all the other banks and Etasalat's main node. Since these are competing organizations, we ensure that the hash of the invoice values is just posted on on the other nodes, and none of the other banks are able to view this bank's details or the invoice details or the trade details. In the central Etasalat node, we have our ML and AI engines running. This is where the rule engine runs, does the matching across multiple nodes and then comes back with an outcome for this particular bank telling the banks the risks that are associated with this particular invoice. And the risks are not Boolean decisions. They're scores. So there would be a score for whether this particular invoiced system has found another similar invoice from another bank. What is the score in terms of financial crime list, you know, over invoicing or other things, whether the logo or the stamp has matched with something else. So basically it's an accumulation of a number of rules that we've configured in the system and then overall accumulated score is sort of shared with the bank. And then it's the bank's discretion whether they want to go ahead and finance the trade or invoice or whether they want to do further investigation or whether they want to just, you know, reject the invoice, the financing base. And all the other banks have this information updated with them that this is an invoice that came and it was rejected or it was accepted by a bank so that if a similar invoice comes or if the same invoice comes, the system knows that this invoice is already been financed. In terms of technology stack, we have used Hyperledger Fabric. This is Hyperledger Fabric 2.4. There's many other technology elements in there as well. There's a big component of OCR. As you all probably understand, trade documents are still paper based and the invoices and supporting documents that are submitted by the corporates to their banks are mostly paper. So that is why to convert that data into electronic data, we did need OCR. So in doing so, this has helped the banks in automating their trade finance desks a lot. So that's one component and obviously we could not have done this in a bureau model as you all probably understand. Even if a central bureau was set up and the model was for banks to dump their invoices into a central repository, this would not have been acceptable by the banks for n number of reasons. You're creating a honeypot for somebody to break into. You're creating a single point of failure. It will probably violate n number of GDPR compliance points. So that is why blockchain was an ideal vehicle for banks to have their own invoices data on their own nodes and still be able to verify whether an invoice is being financed by somebody else or not. In terms of project management and delivery, if you're doing a national scale project with around 9 or 10 entities, it is never easy. All these organizations have different cultures, different pace at which they work, different internal security compliances. So people who've done blockchain projects will probably relate with this better that the biggest problem of doing blockchain projects is not the technology itself, it's the lobbying, it's the discipline, it's to make sure that everybody is working at the same pace. So Avanza has done 20 plus production-grade blockchain implementations in our region, in the Middle East and North African region with peer-run government entities, regulators, logistics companies, port authorities. So we understand these things. We've gone through this a number of times. That is why the way these projects are managed within Avanza, we ensure that the governance model is very, very strong and we make sure that everybody moves along at the same pace. So obviously communication plays a big role. The championing entity has to play a very important role in all of this. Now once you've delivered this kind of a national platform, obviously the workplace is in stock there. You need to make sure that the housekeeping and the overall management of the technology stack is done properly. So that is why a lot of banks that are part of this platform are not even well-versed internally. They don't have skilled resources internally to support this kind of a technology stack. We work in containerized environments and microservices and then the blockchain and AI ML itself is a new technology stack. So that is why a lot of hand-holding is required for post-Goliw or post-launch governance support of this kind of a technology stack. And again, having gone through a number of implementations and a number of launches of city-wide or national blockchain projects, we understand the dynamics of post-Goliw challenges in this kind of a platform. What is also important when you're setting up this kind of a platform is to ensure that once the pilot entities, in this case fake banks, are live, the remaining entities that are not found in banks, it becomes very, very easy for them to onboard or to onboard them onto the platform. So that is again, we've come up with certification and onboarding packages, which very precisely tell a bank what it is that is required for them to join this platform, the trainings, the orientation, the API testing, test beds, everything is spelled out in a lot of detail with a lot of detail so that anybody going through this documentation easily understands what it will entail for them to join this kind of a platform. So a lot of focus and emphasis is given to new entities coming onboard this particular platform. I think that I don't need to preach the converted over here. We're all blockchain community members, but this question does get asked a lot that why did you have to build this platform on blockchain and could this have been done in a centralized environment in a bureau model? And like I mentioned earlier, banks would not have been comfortable in dumping their invoices and trade data onto a central platform with a central governance model. So that is why while there is an operator, which is the national telco, but the governance of the platform in terms of what gets shared, who shares what and the steering group is all led by banks. So this is a purely decentralized application, not just in terms of technology, but also in terms of spirit and the governance model. So it's the banks who drive the platform and even their new use cases that we're bringing on to this platform and the banks are basically telling us how to build those new cases or what new use cases need to be built. So that is why blockchain was chosen because the data is not shared between banks. It is easier to bring newer banks on board or onboarding of newer banks and then it is easier to collaborate with other networks. We all understand they've been very regional or global initiatives in the trade finance and logistics space and the plan is to join those platforms eventually. So that is why we're looking at the overall landscape of trade finance and logistics solutions and networks in the world thought that blockchain is the best vehicle once we integrate with those international or regional platforms. I'll give you a few glimpses of the platform. Like I said, basically it's back end. So API is basically exchange data between the blockchain platform and the banks systems, but we do have a user interface which banks can use which has been mostly used for testing purposes. So this is what it looks like. Basically a bank will upload their invoices onto the platform and these are the kind of scores that come out when our rule engines run. So here, for example, the system has determined that this is 100% duplicate so the system has found an exactly identical invoice in the system. Then in terms of financial risk, crime risk, the 30% score is there and UTC is recommending that this invoice should not be financed by this particular bank. Now within the financial crime risk, we have a number of other risks which accumulated score, this 30% that you see over here is shown and these are some of those risks. Like I said, we do a lot of checks on the product, on the buyer, on the seller and scores of these risks are then shared with the bank. We do a lot of object detection as well. So we look at the invoice and we do a lot of stamp matching, logo, stamp signatures to ensure that whether it's the same company or some other company so a lot of object model detection is also part of this outcome. So these are some of the system outcomes and system screens through which a bank can verify whether they should or determine whether they should invoice, finance a particular invoice or not. And then whatever decision they've taken is also entered into the system either through the UI or through the API and then it's replicated across all the nodes. Yeah, I mean I could go on there with many things as you can imagine but this is what the system looks like in the UI. There's obviously a multi-year roadmap for this platform. So we are here right now. We've done the commercial launch. We've done the duplicate finance detection and the financial crime risks. We will keep on adding to the financial crime risks. Some of the banks have very good ideas which we are currently building but the eventual objective is to go towards a complete digital trade landscape in UI on the back of this platform. The idea is that eventually all trade should be digital, paper-based trade should be eliminated and in doing so we will also want to connect with other trade networks such as WeTrade or Mark Popolo. So this is the invasion. So these are multiple milestones and they obviously have a date with them. So I think in 2021 we are supposed to do these two and then in 2022 I think they're supposed to do these two and then finally we will be open to integrate with other platforms. So this is what the roadmap looks like. So this is, I guess, from my end. If anybody has any question, please, I will go through the question and answer session and see if anybody has any question and I'll try to tell those questions. So far I don't see, yeah, so I see a question, which consensus model. So we've used RAF because we do use in Hyperledger 2.0. So that is why RAF consensus model is used with the bank nodes disposed from InVal. So thank you, InVal, for the question. We still have some eight minutes left in the session. So if anyone has any question or if anyone wants me to explain anything, very happy. Yes, so every bank has their own CA. ETHESLA did offer their own CA because being the national telco, but yes, every bank is using their own CA. So that's how the identities are managed. So this was from Jaya Simah Prasad. So thank you for the question, but every bank has their own CA. Okay, how do we onboard users and participants? This has come from Aman. So basically, the banks have the discretion to either set up their own blockchain node or ETHESLA being the national telco has a cloud environment or we have Microsoft Azure over here. So the node decision is taken by the bank where they want to host their node. And once they've done it, we go and we deploy the entire DAP of UPC on their node. And then they have very thorough documentation in terms of API interfaces and the training materials for the UI. We do a lot of hand-holding for them to join the platform. So there's a complete certification and onboarding package that we give to them. So think of it like a bank joining Visa or MasterCards. If a bank wants to join Visa or Master, Visa or Master has very, very elaborate and precise information about how this bank would get certified. So this is exactly what happens. We give a bank a certification window. Before that, we do a lot of hand-holding with them, a lot of training, orientation, and then we enable them to test. So typically, our onboarding package is, I think, a four to five week package which involves orientation, training, initial, you know, hand-holding and then testing. Okay, so there's another question. Have you integrated into banking systems or that they're submitting? No, so they have a UI. This question is from Suji. Thank you, Suji, for your question. So there are two models that are available. They have a web UI. Every bank has access to their web UI through which they can upload the invoices and data. But this is just for testing. Eventually, or actually right now, the banks use APIs to push that data. So we are integrated into the bank's trade finances. Some sort of they have a channel through which, you know, they receive invoices from their customers and SMEs. Would you like to know the difference between WeTrade and UTC? So this question is from Eugene. Eugene, thank you very much. So the difference between WeTrade and UTC is that UTC is led by banks. So WeTrade and other platforms. So pardon me if I don't know WeTrade in detail as much. But the difference between other platforms that I've seen for trade finance and UTC is that generally those platforms ask SMEs to upload an invoice onto the platform. And then they engage banks in kind of a bidding war, you know, that whoever wants to pick up the invoice and finance it and banks don't like that kind of a structure. They're not necessarily interested in bidding war, especially the bigger banks. So that is why this platform as opposed to WeTrade is led by banks and conceived by banks. So that is why banks receive, you know, invoices data from their customers and then upload onto the platform and then, you know, hedge themselves against any risks. So this is the biggest difference. Then there's a question from Diakomo. Is the ML built on-chain? How do you verify an invoice is already present into the platform? So the ML is not on-chain. And this is one of the biggest design decisions that we had to take that the academic definition of blockchain is that it has to be decentralized. But we all understand that machine learning is not efficient if you do it on-chain. So that is why we had to make a replica of the data onto the Ethisalat node. And this is where a lot of regulation was also required to back us up. So much so that banks had to get consent from their customers that we will be sharing your data with a third party called UTC or Ethisalat. In this case, and we had to get an endorsement from the central bank as well because as per the GDPR rules, a bank cannot share their customers' data. So they had to get customers' consent because we're replicating this data onto Ethisalat's node and some of the invoice data has to be decrypted because the ML would not be very efficient in terms of, you know, if the data is encrypted. So that is why ML is not on-chain. It is off-chain. We replicate the data into another database. And how do you verify an invoice is already present in the platform? So that's where our rule engines kick in. So like I said during my presentation that people who do these kind of frauds, they will change the invoice a little bit. They change the invoice value, they'll change the description of goods. So we've built a fuzzy matching model that constantly runs as a machine learning model and it determines whether it's the same invoice or not. And in doing so, like I said, we have object detection happening as well. We match logos, stamps, description of goods. So there are n number of rules that determine whether the invoice is already present in the system or not. Karthik has a question. Conventional software have an upgrade cycle once a year, but in the blockchain world things are changing by the day. How do you keep DAF and underlying tech up to date? Yeah, this is a problem that we face on every... So we've been doing blockchain projects since 2018 and 19 and some of our customers who are on Hyperledger 1.4, we're moving them and migrating them to Hyperledger 2.4 right now and you understand that the consensus mechanism has changed. And now these customers, our earlier customers from 2019, want to join networks or bring on board other participants who are on 2.4. So it is a bit of a nightmare. We're going through at least two upgrades right now. So it's challenging and some of these things are unknown. So when we are migrating from 1.4 to 2.4, things are not as seamless, but this is a constant struggle for any new technology if you're working in the nation technology space. Then we have a question from Suji. If the invoices are available in all the loads, which are with all the banks, how the GDPR on entities can be managed? So Suji, the hash of the invoices are available. This is just to ensure that even if one of the nodes is compromised, the system knows that somebody has changed something in an invoice data. So it's not open data and we all understand hash is one way. So that is why we make sure that only the hash of some of the fields of the invoice, the fields that are required for the rule engines, are replicated across all the nodes of the hash basically. Okay, Jayasema has another question. Can you speak to the privacy part a bit more please? You spoke about storing only the hash of the invoices on banks other than the banks that financed an invoice. So this is basically how we ensure. So the agreement with the central bank and all the banks is that your data, in addition to Ethasalath, which is the operator of the platform and a state-owned neutral entity, will not be disclosed to any of the other banks. So much so that if a particular bank has financed an invoice or rejected an invoice, we don't even disclose to the other banks, which bank has financed this particular invoice or trade. So all these things are basically insured through hash and through private collections and other things to ensure that the other banks do not have access to this data. I'm happy to answer any question after the session as well. AvanzaInnovations.com is our website. You can reach out to me through our website, through our info email address or I would request Hyperledger Foundation to share my contact details if anyone has any other question. I think we are out of time. Thank you very much for being patient. And I think we will close the event now. Thank you very much everybody for attending.