 Hello, everyone. Good morning, good afternoon, or good evening, depending on where in the world you're zooming in from. Happy to have you here on our Hyperledger in-depth webinar with Kripsi and News3Tech. We're going to start in just a couple of minutes just to allow more people to join us as well. While we wait, I will encourage everybody to say hello in the chat and tell us where you're zooming in from. I'm zooming in from Boston, Massachusetts today. We're just going to give everybody just one more minute, and then we are off to go. Hi to Nigeria. Hello to Brazil and to Toronto. Hello to Spain. And hi to everybody also joining us live on YouTube and LinkedIn Live. Hi to Singapore and Sri Lanka. We have a very diverse audience. We have India, Atlanta, Sri Lanka, Nigeria. All right? So we are live, so and let us start. So again, thank you everybody for joining and welcome to this Hyperledger in-depth webinar with Kripsi and News3Tech. When we will be talking about leveraging Hyperledger fabric for banking and financial institution, for financial services. We're delighted to share this new webinar with you with Hyperledger member Kripsi and News3Tech. My name's Tomar Sedeh and I'm an ecosystem manager at the Hyperledger Foundation. Today, I will have a chance to take you through some housekeeping and introduce our panelists as well. Now, first, if you attended any of the other Hyperledger in-depth webinar, you might already know that we have some housekeeping rules. So first, I would like to emphasize that all are welcome in our Hyperledger global community. And we are striving to create a safe and welcoming environment for everybody. So please follow the Hyperledger Code of Conduct when interacting to each other on this webinar and otherwise in the community as well. All the Hyperledger Foundation webinars are held under the Linux anti-trust policy, which you can also find on our website and on our Viki as well. This session is being recorded and the recordings will be available at our webinar library along with the slides. So you can always download the slides and go back to see if there is anything that you missed or you would like to get into contact with panelists or with us at Hyperledger as well. Now, we encourage these sessions to be as active as possible and the more interactions we have, the more everybody will get out of the webinar. So feel free to raise your hand and I will unmute you and invite you to ask questions to our panelists. And again, as I mentioned, the more activity we have, the better experience for everybody. If you don't like to talk, you're more than welcome to use the chat button or the Q&A button and our panelists, we'll take the questions at the end or they will type the answer over there. And of course, you can also use the chat button to comment and thank our panelists. Now, without further ado, I would like to introduce Mohit, who is a VP of Technology and Research at Cripsy and Sintil, who is the Chief Product Architect at News3Tech. Mohit and Sintil, over to you. Thank you, Damos. Good. Yeah, hello everyone. Thank you for being part of this webinar. My name is Mohit. I take care of technology at Research at Cripsy. And today I'll be discussing and providing my views on Hyperledger Fabric and the applications we have been working on and how Hyperledger Fabric has been the perfect choice for applications on the banking and financial services and how our partners, News3Tech, we have been working together to create real use production use cases which could not have been possible without the Hyperledger Fabric and the applications we have been working on the protocol. So moving into the next, okay. So before we get into modernating it is on what is the use case and how we have been using it, I just wanted to rephrase some of the key features of Hyperledger Fabric for everyone of our understanding. We may have many of us maybe deep into Hyperledger Fabric and some maybe from the technology side, some maybe from the business side, business analyst side, some maybe recently joining. So just considering different types of audience we may be present today. I'm just getting into the basics also. So Hyperledger Fabric unlike other popular blockchains, it is a permissioned blockchain. It was always made for enterprises. There were certain design challenges even to the extent that one would do in a public ledger by modifying the source code or by modifying the way it is deployed to tune to the enterprises. Still it won't be giving the perfect output what an enterprise would be requiring. So Hyperledger Fabric from grounds up, it was thought and it was made for enterprise use case. It is completely open sourced and it is very governed by the Linux foundations umbrella. And the key features are scalability and modularity. And one would always consider when we talk about Bitcoin or Ethereum's of the world that what is the throughput and latency. So those things we need not even be worried about it. That is having very high throughput and very low latency. And identity comes in built in this protocol stack. So Fabric comes with its own Fabric CA. So every participant have their own certifying authority and they decide whom to issue certificates, whom to issue, whom to revoke the certificates. And it's very much close to how identity system works in our current organizations or current PKI infrastructure. So except PKI infrastructure is made available, but in a more immutable and a more controlled manner which is more tuned for blockchain applications. So moving to the next slide. Now, one of the primary challenge we have when we adopt blockchain in enterprise versus the open networks is privacy and then security. So securities, there are many will always think about how the private keys are okay, everything is protected using a combination of public and private key. That may not be enough in privacy. Privacy have to be addressed. Now coming into transparency, blockchain is highly transparent by nature, but in enterprise, we need to have some sort of privacy. When I say privacy, it means how to have the data public between few participants or few users and not every one of them because this data what we put in our business use case, banking use case may not be good if it is completely public with all the participants. However, the design is required that the data is immutable and it is only visible to few participants. So there are various ways in hyperledger fabric using which one could incorporate their level of privacy and their level of security. Having said that the core benefit is the customization and the options we have. So once one get deep into hyperledger fabric, they would know that how to use particular feature to tune in their requirement. So for example, we have something called channels. So there could be multiple networks within your infrastructure. One for example, a particular thing what is happening in the banking environment, loan environment, et cetera. And then you could have this networks partitioned across different participants. If that doesn't suit the case, then we have something called private data collection which is a very nice feature using which the data is private between subsets of the users. And it also helps us in making a good design choices when we have something to abide by regulations for example, GDPR. So it had been very helpful for us in terms of not only executing the security and privacy but also adhering to the regulatory frameworks. Scalability, as I said, multiple channels and then private channels. So there are ways in which hyperledger fabric can be scaled like Kubernetes clusters and how to increase the number of nodes, how to increase the number of channels, how to increase the number of instances of your chain codes. So for example, the latest feature in hyperledger fabric which is called the external chain code support it made this very easy for someone from the DevOps background or the cloud DevOps environment to visualize basically how can I increase the throughput of transaction processing? How can I execute the smart contract? So these are certain things which were very helpful. So when I say scalability, this is not limited to one of the feature I said. Obviously you have to stitch things in a different way to tune to your business requirements like how many keys you are reading and how many keys you are writing. So that's what one would do. We have been doing that for past so many years optimizing hyperledger fabric to tune the scalability requirement of the organizations. And one of the important thing I want to touch here is the pluggable consensus. Now, when I say pluggable consensus, it is not like you could change from this consensus to POS consensus to POW or there are many publicly known consensus. It is like within hyperledger fabric we have RAF. Now RAF basically or ATACD, it used to be Kafka Zookeeper and a few more will come. But the intelligent part or the intuitive part here is basically something called channel endorsement policy chain code endorsement policy. So how we can observe and understand what is actually the real world requirement in terms of how a transaction should be considered valid, right, if a particular transaction is between, let's say a couple of banks in a consortium, but this transaction is between bank A and B. How we can ensure that those banks are at least party to this transaction. So it is very easy. Once you get deep into it, how do we actually configure it and then get everyone's concern result? Okay, the transactions will not go through unless not only the majority, but the real parties who should have been involved in validation of such transactions were party to it. So this provides us another layer of, I would say, plugability, using which we are not only solving scalability, security, privacy, we are also ensuring that the right parties are also involved when a transaction got accepted and then executed, right. Maybe we can go into the next. So regulatory compliance is one of the major thing whenever we deploy a production application, there are different regional requirements, government regulations. One of the thing is GDPR. Now, if we have to have some data privacy patterns, so there are different patterns, but as I spoke, private data collection is one of the very unique features which is started by Hyperledge of February and over the last few releases, for example, from 2.0 to 2.2 to 2.4, there had been more advantages in terms of how to easily use PDC. And now in the latest 2.5 release, there had been made certain advancement in terms of instructing the node to delete all the historical data in case there is a regulatory requirement, okay, remove all the trails. Now, how do we ensure that the data at some point was set? So the hashes would be there. So all those technical things are completely taken care, plus the regulations are taken care. Now, coming to the point of consortium governance which we are seeing as a second point here. Now, in a public blockchain, typically what happens is you have so many, I would say, node and depending on your stake, one would have the ownership on the network and it generally happens to be the 51% formula, right? Like people having this stake plus majority of the nodes should agree to it. This may not be the same case can be applied into a private network or a private permission network because there are few nodes who are operated by certain governing agencies or certain enterprises who are critical to it, right? So how do we ensure that the real consortium have control over how the network is behaving, how the network is expanding? For example, we have four organizations in a consortium and now we want to have the fifth one. So by default, the majority of the four have to agree, okay, we can onboard them. And as and when the number of participants expands, the majority rules kicks in. However, in certain business requirement, there could be a lead actor, for example, the application which we are going to discuss in some time. It may be required that the lead bank or the lead platform should always be there, should always be party to something major happening in the network. For example, onboarding of a new participant or changing the version of the network. So how we could do that? So there are granular level of configurations which are possible. Obviously we have to go slightly deep into those configurations, but it is quite elastic and flexible. So we could say, okay, at least these two organizations and the majority of the organizations should agree to do certain changes like network upgrade or onboarding of a new participant. So in nutshell, it allows us to have a very good consortium governance model ensuring that the right people and the right governing organizations have the proper control. And then you have at times requirement that there could be some organizations who should have only read access. Basically they are only auditors. In every program or any project, one would require that, that I should have the visibility to what is happening, but this shouldn't allow me to basically make changes or do a transaction on the network. It's also quite possible here. We would be able to do this. And then integrating with existing systems. So there are many ways. It is one of the blockchain where you could make a call from your smart contract to external world. If those things are done properly, integration becomes quite easy compared to the other blockchains which we have been used to. Plus people could write their own connectors, SAP connectors, et cetera, look up on the transactions. Yeah, we can go into the next. Now coming into what is script code, what we have been working in Cripsy. So now we have gone through what is the advantage of Hyperledger compared to other blockchain protocols, however evolved. Now one of the major requirement for any organization, any enterprises, how quickly we can actually test our business use case and then make adaptable changes because we never know as an organization or as a use case, okay, these are the fields or this is the case which we are building. Now, if we have to have a lot of developers building from scratch and then completely changing something and then redoing everything, it takes a lot of time and somewhere we lost, we lose the track, basically the whole objective, right? Any blockchain use case, there are certain thumbs rule that there should be multiple participants or they are disparate, there should be a lack of trust why they want to come into the blockchain. Now when we configure a use case and then go about it, it's very important that we are quickly able to check, okay, by doing this, we are able to do this and then, okay, does it make sense? Does it really help? And then see how it impacted the network or let's see this change. So our ideology from beginning was how to accelerate the blockchain adoption for the enterprise and make it hydrator. So CripCore, the philosophy was no code, no code solution. So just click something and then deploy your network and then just focus on your use case and then go about it. Now the other peripherals, you're seeing Studio, Data Lake, Deployer, this basically helps in getting the meaningful data from the blockchain. Now Hyperledge of Fabric or any other blockchain, you'll always think about transactions, hashes and blocks, right? So how do we get a data which is more meaningful to my business application or my line of business data visualization tool? So all those things are made ready, made available. So my idea or a business analyst idea would be always to only focus on their use case and go about it. Then Deployer, so some banks have specific requirements where they should be deploying the Fabric network. Many organizations typically go with all the clouds, for example, Azure, AWS and Google, all there, they have their own cluster model how to minimize the effort to deploy and monitor. So the network part basically takes care of deployment. The Fabric admin on the left which you are seeing is a GUI based application. So people may not be fully Hyperledge certified if they have learned. It would be very easy for them to understand Fabric admin and use simple UI and with minimum script to basically govern the existing Hyperledge of Fabric network, one board users, deploy chain code and do various things. Now in a nutshell, this is how Cryptcore had been and we have been working in this from last, actually from 0.6% the product then went to 1.02.0. And today there are multiple production projects which are live using this. And it's been with all these projects from inception. So the beauty is we have been with those production projects and with Hyperledge, new enhancement, new product updates, it had been always there. And it have reduced all our clients time in terms of reducing the effort of making changes or adding some new features which typically would have taken a lot of months that they are able to do in few weeks in different thing. Yeah, we can go into the next. Now as I was calling the API model, we are so tuned to that once we have the application deployed, there should be some API, but when we see any blockchain, we have to create an endorsement transaction. So it's good for developers to learn but how to accelerate the journey. Okay, I have deployed a chain code which have something called purchase order. How quickly I can have an API which just take this purchase order inputs and be able to do the transaction. So philosophy has always been that. So quickly expose an API of your business thought process which you have deployed on Cryptcore and then start using it and then start visualizing it using the data lake and the data visualization. Below you are able to see the infrastructure layer and then how the smart contract API, participant manager, participant user and participant management. So user and participant management is also very important in a private permission Hyperledge fabric network because people, everyone is associated to an identity. So how do we issue identity? How do we revoke the identity? How do we create some attributes in their X509 certificates and stitch together with that chain code, access control logic. Those things are completely taken care and one of the thing was endorsement policies. Now when we do a transaction, we have to find out what is the right endorsement policy. The Cryptcore basically helps in finding the right endorsement policy. It kept a connection with all the peers who is thinking fast, who are on the proper height and try to achieve the transaction finality at the minimum time. Now with Hyperledge of February 2.5 and the PR gateway model, lot of things have already reduced, the complexity have reduced. So we are also tuning it according to the new advancement and then try to further improvise so that anyone starting their enterprise journey on Hyperledge of February, they focus more on the use case, validation of the use case rather than working on the infrastructure, deployment and then management of chain codes. Yeah. Hey, thanks. I'll let Senthil talk more about this. Well, hello again, everyone. My name is Senthil, the architect at New Street Tech. Mo walked us through some of the theoretical aspects of Hyperledge of fabric. He kind of set up the stage for me to shed some light on the use cases which we implemented both Cryptcore and Hyperledge of fabric on. These use cases were in the field of banking. I worked with a company which is a FinTech based in India. We will touch upon some of these aspects which are kind of splashed on your screen. We'll look at inter-back transactions, remittances, which is essentially moving money across borders, clearing in settlements, syndication, KYC, which is know your customer, AML, anti-money laundering regulation, which is a very big deal in banking. And that's one of the reasons that Mo kind of spoke about it, how Hyperledge of fabric has a lot of built-in bells and whistles to take care of regulation as well as to comply to regulatory bodies. India, like most of the other G20 countries, is very heavily regulated and rightfully so in the field of banking. And we'll tell you how Hyperledge of fabric makes it seamless for organizations, both FinTech, New Age FinTech, as well as traditional banks to comply to all the regulations put in by the central bodies. And in India, that central body is called, there's a bank of India. In the US, it calls the Fed. In the EU, it's the Yorickin Bank, et cetera, so on and so forth. So without further ado, for the uninitiated, this is what a bank looks like, guys. It's fairly simple on paper. It begins with a chunk of products, a basket of products, predominantly retail, consumer lending, corporate and wealth management. The four products put together essentially make the core of all banks across the world, be it JPMorgan Chase or HSBC, City or Access. And under these four umbrellas, you get into the different business functions, right? How do you originate a customer? How do you basically sell a debt portfolio which essentially is lending to customers? How do you underwrite loans? How do you report having underwritten a loan to your centralized body, which in our case is the Reserve Bank of India? And line item number three or the box number three is what I want to draw your attention to. That essentially is the core banking module. Core banking again, essentially works with a massive database which most of the legacy banks have. It's called the core banking system, CBS. It takes care of all the deposits, the lending payments and the customer information, right? Now, this is going to be the magic sauce that any system needs to plug into to run transactions. The transactions can be as simple as opening a savings or a current banking account. It's called CASA or it could be as complicated as doing forex netting or trade finance, which will involve several organizations across different continents and across several oceans, right? Now, core banking is very heavily regulated by the central bodies, basically meaning in India, any customer information which is centric like KYC, we have a social security number equivalent called the RDR. And that information needs to reside on a server which is parked within the continental borders of India. This is a regulation that all of us need to amend to. What this also requires is a lot of the last mile transaction in a blockchain, right? All you guys know that blockchain is a distributed ledger where the data is spread across different nodes for a couple of reasons. One is to avoid CFP, which is crash-fall tolerance, right? And also to kind of make sure that there's Byzantine, there's no Byzantine actor which can bring down the entire system. Now, in the banking ecosystem of India, most of these data points needs to reside on premise, which basically means this is going to be a hard server which is part behind the firewall of a PAMS data center. Most blockchain systems that we know of, especially the public blockchain systems work on a cloud-based architecture. Now, the leverage, the advantage of having a cloud-based architecture is everything is elastic. Your memory is elastic. CPU computations are elastic, right? There's zero latency. As Mohit mentioned, you can create beautiful clusters, load balancers, a lot of things which can manage traffic congestion. Now, when you move this to an on-premise solution or a node, there are certain restrictions. And one of the primary restrictions are getting approvals from the bank's CISO team to open ports, to implement technology, to create clusters, to set up databases, so on and so forth, which is not an easy task, guys. So this will require working with different departments within a bank, starting with the risk team, the treasury team, and several other teams to get approvals to set up a software. One of the biggest advantages of installing Hyperledger Fabric and Mohit kind of touched upon it in the concept of multi-channel is once I set up a node within the bank, having got all the approvals that I ever need to plug into this core banking system, I would be able to run multiple products, right? With one sheer approval, which is extremely time-consuming, very few fintechs and organizations have successfully been able to get onboarded by the banks, purely because of the demands and requirements placed on them by the Reserve Bank of India and rightfully so, right? So we will touch upon how multi-channel that Mohit spoke about kicks in and helps us out setting up multiple products within the banks. Another thing that Mohit mentioned was modular architecture of Hyperledger Fabric. Now again, this comes extremely, extremely handy in the case of banking, because the on-premise nature of one of the nodes has several restrictions. Unlike a public blockchain where the consensus is hard-coded onto the decentralized system itself, here you have the option of using a modular. So you can plug and play different consensus algorithms, right? So the Byzantine fault-tolerant is essentially, it kind of plays into the role of one size does not fit all. So I can kind of move the Byzantine fault-tolerant, I can go into something called an Istanbul Byzantine fault-tolerant, you know, PBSD and then you've got RAF, you have the original Kafka with the zookeeper, you had solo. What it does is every time I change the consensus algorithms, there is a severe impact in terms of throughput, right? When I move from a land to a van and when I move to a nested ecosystem, there is significant impact on throughput and essentially I can pick and choose which modular service to implement within my blockchain platform. Another big advantage that I have when using Hyperledger Fabric for the banking ecosystem is I do not use words like crypto or native coins. Now the word crypto kind of puts in a little bit of, it kind of makes people creepy within the banking ecosystem. And rightly so, if you ever looked at the DCXs and the fluctuations in the market, especially within the Indian regulated ecosystem, people get very nervous when you start talking crypto or native coin. Implementing Hyperledger Fabric kind of irons out that entire uneasiness because we do not work with any sort of native coins. In fact, Hyperledger Fabric until recently did not have a provision for tokens, right? We'll get to that later. Going to our use case, this was again in the banking ecosystem, looking at a concept called priority sector lending. Essentially we were taking the banks out to people who could not otherwise afford to get any kind of debt from large financial institutions. We're talking about people who are below the poverty line in India or people who are new to credit. These are called NTC customers. They're also NDBs, which has new to banking. Now the amount of capital infiltration in India is about three trillion rupees, right? Convert that to dollars if you're quick at it. The market that's estimated by several studies, Bain and Company BCG, isn't the range of 10 trillion. So we're literally scratching the surface in India. One of the biggest issues being the cost. Banks, large banks are established well among the rural areas of India. And it takes a lot of cost to spread their wings into the tier two cities, into the villages, having feet on the ground to make initial contact with customers, do a lot of the KYC documents, bring them on board, do the underwriting process, et cetera. Another big problem is the appropriate product, right? So we have people whose credit could qualify them for several products. And again, one size which all was a typical way which banks did lending in the past. We had a flat interest rate which potentially could be extremely expensive for loyal customers. There was no dynamic or intelligent system which could customize a particular product for a customer. A lot of these things have been taken care of primarily by running CripCore as an infrastructural layer communicating with the Hyperledger Fabric SDK and creating an application which is very similar to how you do a layer one and layer two abstraction, right? If you from the public, you know, public ego spaces. So we've developed an application on top of CripCore communicating with Hyperledger Fabric which allows you to customize products making it very customer-centric. So again, looking at the financial inclusion space in India and pretty much across all nations, South America, Southeast Asia and Far East. We have something called an Adard in India which is very similar to the Social Security Network. This established your KYC. We have multiple credit bureaus which vouchers for the credit scores of customers. Again, we're looking at the lending portfolio across the regulated entities in India. We have several account aggregators. Now account aggregators do everything from looking at your savings account. They scrub the banking information of customers, potential customers. They scrub social media activity. They also scrub the e-commerce websites to understand what the customer portfolio behavior has been to kind of do behavioral analysis, right? All this plays a part in creating what is called a business rule engine or a credit rule engine. And the reason I put this up here is in Hyperledger Fabric, we get to onboard several tenants onto the network who have sufficient authority to vouch for the data that they push into the network, right? Now, all of these bodies are government certified bodies within India and each one has a certificate which vouches for the authority. When we run ABI that NorthAgain spoke about, there is a lot of information that we exchange apart from the public-private key. One of the crucial information bits of information is the certificate itself, which allows us to onboard the data and hash it based on even trigger in a smart contract. I think advantages with Hyperledger Fabric is using the concept of oracles, right? We'll get to oracles and how we have incorporated oracles into a use case for farming in a later slide. The core problem again, right? In terms of cost of operations using a traditional mode of lending, the cost of operations about 14% of the entire principle that's being netted out to a customer, most banks in India would charge upwards of 26% interest rate on any loan that's awarded to a customer. 14% of which goes into cost, 12% again being the profits for the business correspondent as well as the bank. The cost of credit for a FinTech, which is an unregulated body, all for that matter, an NBFC, which is a non-banking financial cooperation, is about a 10 to 12%. Now, the impact of these large percentage numbers is mostly felt by the customer himself. A customer who's part of the priority sector lending segment, which is below the poverty line essentially, can, with the use of technology, be given a discount of 12 to 14%. And that's a huge percentage, guys. His interest repayment on a loan of $1,000 would reduce from 26% down to 14%, with the insertion of tech, with also kind of using, we'll talk about how using distributed technology and hyperlative fabric case in point allows the banks to remove a lot of the bottlenecks, which otherwise are extremely analog and extremely expensive. Again, some of the limitations with our conventional system is it's very analog in nature. Pretty much everyone has smartphones in India, in Southeast Asia and in Africa, yet a lot of the data needs to be inputted by feet on the ground. A lot of the primary contact between a potential customer and the bank is with feet on the ground. There are multiple handoffs. As you saw on the previous screen, a customer goes through a series of events, which again, concurrently have triggers in hyperlative fabric in order to qualify themselves to be credit worthy or to be kind of worthy for the bank to lend them money. Some of these steps will involve identity which is authenticated by KYC. It will involve your credit scores being validated as they will be across any banking system across the world, followed by a series of documentation. Now, again, if any one of us on the wrong side of 40, of course, have ever taken a loan, we would realize the number of documents that we have to review and put our John Hancock up, right? Essentially, we'll have to put a wet signature. A lot of these require last mile intervention in terms of feet on the ground. Now, anytime there's feet on the ground that also implicates the cost because there's payroll involved, there's processing fee involved, that entire burden of cost is eventually ultimately parked onto the customer itself. Now, what we were trying to do with technology and blockchain in particular were to remove these discrepancies between multiple tenants or actors in the network to kind of make it a trustless ecosystem, right? Now, we've heard the association of the word trustless, zero proof, zero knowledge proof being used with blockchain. And I'll try and show you how exactly they use the concept of hyperlative fabric and trustless ecosystems for both agri-financing as well as microfinance lending. Blockchain automates the center, guys, simple as that. We have several, the tagline that I've parked at the bottom of the slide is from Vitalik Buterin, famously quoted it when he kind of launched Ethereum that he wanted to replace Uber or extract Uber himself. What we've been trying to do in the banking ecosystem in the lending ecosystem in India is to try and reduce the number of middlemen involved in dispensing a loan to a farmer or to women in the priority sector or in the microfinance world, right? This is very, very far-fetched. It's very common in Africa with tons of stuff that have happened in the field of microfinance in Kenya, in Tanzania, likewise in the Philippines, in Malaysia. And we've implicated a lot of this information, especially starting with Mohammed Yunus in the Grammian Bank in Bangladesh. We've taken a lot of the good facets of microfinance and we've incorporated them in India but implemented them using blockchain. All right, here we go. So we're kind of moving it from institution-centric to customer-centric. And the way to do that is by embedding hyperlative fabric or blockchain in this case as the common medium for different tenants, right? So some of the different tenants as part of a lending ecosystem are shown on the slide. You have the bank, you have the NBFC insurance companies and so on and so forth. So all of these tenants come on board a permission ecosystem by using an MSP which is the membership service provider. Yet there is an element of market friction. There is an element of doubt amongst the different tenants. Hence the user smart contracts, hence the use of hyperlative fabric. The idea of using a smart contract is to ensure that all the tenants sign up to an absolute minima in terms of requirements on the criteria on onboarding customers, right? Now this criteria can be as basic as he or she complying to a EKYC norm being validated by a government entity. It could also mean the credit scores being validated by a certified authority. In our case, we have multiple bureaus which validate and watch for the credit worthiness of a customer. These details which are captured as events are imported into a smart contract. And again, as we talked about earlier, one of the biggest advantages with hyperlative fabric is a lot of this can be done with general purpose languages, right? We chose to go with Golang because Gol is one of the most prevalent languages in terms of SDK availability, starting with the 0.6 version and all the way up to 2.4 and 2.5 now. One of the restrictions you would see in the public ecosystem is the usage of deterministic languages, right? Ethereum, as a case in point, will only work with solidity because they ensure that it's a deterministic platform. We have the luxury of being non-deterministic. In spite of being non-deterministic, we do not have the problems of double spend, right? Because this is still a permissioned ecosystem. Each actor that comes onto the network expressively comes with the permission of the anchor and the MSP will let them know what the authority is, right? Mohit also spoke about things like system chain code. Now, the system chain code is such a beautiful concept that it will onboard a particular tenant onto the network and limit the organization's privileges. And it's such a beautiful concept because we get to use this limited privileges to increase the throughput of the entire ecosystem. And I'll tell you how we do that, right? But the idea again is to use technology, not only blockchain, I mean, we've incorporated the concepts of AI as well as ML to shift the focus from being institution-centric, where everyone's kind of parking themselves around a regulated bank to becoming a very customer-centric. One of the topics, which if I have time, I can touch upon is also on DID, which is the decentralized ID, which will allow the customer to, you know, kind of show the level or the depth of information that he or she decides to share with an entity, right? The concept of wallets, the concept of identity and access management. All these are features which are incorporated into hyperlative fabric, which we have conveniently borrowed using CripCore and incorporated into the banking ecosystem, right? Now, you know, just to touch upon very quickly in the interest of time, we've reimagined the entire customer journey using hyperlative fabric and CripCore to create multiple events. And what I've splashed on your screens are the list of events, starting with origination of the loan, EKYC, credit appraisal, so on and so forth, and that you kind of read through it as I speak. Each one of these is assigned an event registry in the ledger, right? So as far as the actors know that a particular event has been triggered or an event has been kind of completed, we will move to a next state, right? This is basically how FSM's work, it's famously known as a state machine regurgitation, SMR, and that concept has been heavily borrowed into hyperlative fabric and onto our platforms as well. It's completely rule-based, it's even-based. We use a concept called execute order and validate, which is very different from how the other blockchains work. Within permission blockchains, again, you've got different flavors, right? Just to name a few, you've got Quorum, you've got R3, you've got hyperlative fabric, which probably has the highest volumes. There are platforms which work in a concept called order execute, which again, borrows its motivation or borrows the entire architecture for public blockchain, right? If you look at Ethereum or Bitcoin, they were all created using an order-execute architecture. One of the biggest advantages on hyperlative fabric is starting with version 0.6, which Mohan mentioned, they moved to a very different way of burning events, which was execute order validate, which has a brilliant, brilliant way of increasing throughput, right? We'll talk about it a little later. Right, now in terms of smart contracts, we touched upon a lot of these bullet points in terms of pluggable consensus, et cetera. I'm not going to spend a lot of time in the interest of, we will keep moving on to the use cases. We will talk about tokenization. We'll talk a little bit about Web3, how the latest trends in terms of the hyperlative foundations, SDKs, enable us to go into domains such as tokenizations without using crypto, which is brilliant, right? It fits very well into the backing ecosystem, especially into the regulated ecosystem. All right, the use cases, guys. So we look at two different use cases per now. If time permits, we'll talk about the third one. I'd like to spend time about agricultural loans. Again, this is the loans which are dispersed to farmers at their doorstep. There have been successful programs which have been implemented in South America, both in Argentina as well as Brazil. Argentina is kind of far ahead of a lot of the nations by publishing tokens, right? They've got agro tokens. This is a very well-documented program which was implemented between Argentina and the Bank of Switzerland, essentially releasing agro tokens. There's a lot of activity of farm loans in India and we're happy to be partnering with the CripC on leading the path on how banks are lending in this eco space. We will also talk about microfinance lending, priority sector lending to women in India, a lot of whom are new to bank, new to credit, how technology, blockchain in particular, eases a lot of the cost headers that banks had to endure. And on top of that, it also kind of makes it accessible for customers in very deep interior villages to get access to finance which otherwise would not be possible, guys. If time permits, we'll look at finance against remittance. It's called FAR. It's all about how we move money across borders. We've also got a concept called remittances and lending against remittances. And of course, these are the last risk of the war. Coal ending is a concept which we will touch upon. All right, agree along guys. So the traditional process of lending to a farmer was extremely analog in nature. And it was also extremely sensitive because one, the banks did not have a footprint in most of the places, especially the Kier 2, Kier 3 cities in India, as well as the villages, which predominantly are where farmers live and most of the agriculture, most of the cultivation takes place, right? Banks park themselves in Kier 1 or Kier 2 cities for good reason because that's where the retail segment is. So the bigger problem was, how do farmers even access, get access to banks? The only way for them to get access to banks was to travel to the Kier 1 cities or to the Kier 2 cities where the banks had physical branches. And this was a cost header on the farmer himself. Once he did this arduous task of commuting, he had to go through an entire process of producing the right paperwork, right? This could amount to him producing a lot of the identity cards. It would also require for him to carry a huge bulk of paperwork, which validates that he in fact is the owner of a parcel of land, which he would then use as a collateral to raise debt, right? Once these paperwork are presented to the bank, now the banks have no motivation to go and validate everything is a paper that they receive from a farmer. What they would typically do is accumulate large number of files from a share board of founders before they would do the validation themselves. Now, the validation on the banks front requires twofold. It will require for them to take these land records to a government authority, right? In India, that's the department of revenue and land records and physically validate them by sitting on a server which is plugged into their database. This turnaround time of validating what the farmer has bought to the bank can take up to three weeks, right? Basically, that's 21 days. Now that three week can be a lifetime for a farmer who's essentially looking for a bullet loan, right? Bullet loans essentially a one-lack, two-lack loan, which and he may need that debt immediate need. Unfortunately, if he had a 21 day attack or a turnaround time, the need for requiring that debt goes away, guys. And that's unpardonable. What we did with technology and blockchain again was to reduce that total turnaround time from 20 days, three weeks, down to five minutes. And that's essentially what it took for us to dispense the loan to a farmer at his doorstep with all the checks and controls in place, right? The bank at the end of the day is very heavily regulated. There are certain checks and controls that the regulator has put on the bank to comply to before dispensing the loan. Technology, blockchain in particular, hyperledger fabric in this particular case makes it possible for us to dispense to onboard a farmer to begin with, to evaluate him, to validate him and or her and to dispense a loan within five minutes. And I'm going to skip this because this is essentially what we talked about. And this is how we did it, right? This is the base architecture. Again, if you were to go on to hyperledger fabrics website, look up any documentation, this block diagram would seem very familiar across a lot of the document that is published by hyperledger fabric. The block in the middle of the chart, so I'm just going to turn off the video for a second. The block in the middle of the chart essentially is how we spread the nodes. Each node represents the organization in the network. What we've done is zoomed into a particular organization and we've kind of shown you how we dissect the organization into multiple nodes, right? Again, mode spoke about how the architecture is very different from the others. And I spoke about the validate being the last part of it. We kind of do the evaluation part of it, ordering as well as validating. What this allows us to do is break up an organization into multiple nodes, each with its own responsibility. I'd like to point you out to two or three different actors here. We have something called as an endorsing pier with a ordering pier and a committing pier. Now these piers are all part of the same organizations, yet they have unique responsibilities. An endorsing node within an organization has the primary responsibility of taking in transactions from a client. Now the client can be an actor with a mobile phone. In our case, a client is a agricultural officer who's standing in front of a farmer taking in primary details, right? These primary details which are absolutely crucial for the bank to validate and consider whether the farmer is in fact eligible for a loan are fed to him to a mobile application which we developed in Kotlin. This data goes into the endorsing pier into a smart contract which has certain rules to evaluate the primary data. Once the data has been evaluated, the transactions have been completed, I sent them off to an auditor. Now this is where the pluggable consensus comes in. We've used the raft, which is fairly, fairly stable at this point in time. We're working with Byzantine BZT which has become a very stable consensus algorithm starting with 2.4 version of Hyperledger Fabric. What the consensus algorithm does is it orders all the transactions coming in from different endorsing piers. It also does a couple of other things. It does a very first level validation if every pier has in fact got the necessary endorsements. The endorsements are nothing but signatures which are given by different participants saying, hey, I see what you've done and I validate it because I think you've done it based on a smart contract you comply to everything that we agreed upon. Once the order has kind of created all the transactions, put them in a beautiful neat order which is basically what the hash chain is all about, we then push this back to the client himself telling him, everything that you ask for is done, we've created what you call as a read write set. Everything that you kind of pushed into the data using input variables, I have transacted. I've also created what the output is which in hyperledger terms, I call it as a write set. Once I've published this to the client, the client takes over and sends it to all the piers and the piers can communicate among themselves using a gossip protocol. Again, gossip is a beautiful, beautiful concept in hyperledger fabric which ensures that one, you can do a lot of things offline which is most unlike any distributed ecosystem. If you're talking about a public ecosystem, everybody has to be online, you cannot kind of go offline and then you'll land up having an off sync fork or a double spend. Gossip protocols essentially allow piers to talk to each other. If one of the piers were to fall off the network for any reason, right? It could be a network outage, it could be loading on the node itself. We can always come back and do a push pull mechanism to ensure that all the work states are synchronized. Now, once the client pushes the data back to all the piers, the piers validate the transactions by looking at the endorsements, they look at the metadata and once everything seems to be in order, only then do they burn it into their ledgers. Now, this is the validation part and the burning in is done by something called a committer. Now, because I'm able to park these different activities across piers within the same organization, my throughput is through the roof guys. I can achieve up to 3,500 transactions. The second, the TPS has substantially gone up now because of several improvements down by the NAC foundation, also because of several improvements in how we can deploy this on cloud, right? Mohan talked about proven edictruster, load balancers, so on and so forth. Now, I mean, that's hypervisor fabric in a nutshell, right? In terms of agri-funding, one of the unique features that we've incorporated is validate the land records of the farmer themselves, which otherwise have to be done using an analog manner. Now, one of the pain points for the bank is to ensure that the farmer has not used the same parcel of land across any other bank or if he has not pledged his land with a P2P lender or a fintech, which may not have reported it to the regulated authority. We've kind of allayed this fear for the bank by pulling the land record information using APIs from the Department of Revenue, right? It did require that these land record be digitized. India, like most nations in G20 as well as in Africa, have digitized land records, which enables us to take this data. Most of the data is in the XML format. It's in JSON key value pairs, which makes it perfect to pull it into the smart contracts. Smart contracts love key value pairs, right? They love JSON pairs. Now, once we pull the data in, we're able to evaluate it, we're also able to landmark it. When we landmark a land document, what it essentially does, it gives the gravity and it gives the basically authority to the bank to hold on to a collateralized loan and it gives a level of comfort for them to evaluate creditworthiness, also to hold on to collateral and dispense loans. Yeah. Thomas, we're good with time. How much time do we have? We actually need to wrap it up now. I'm sorry, Sintil. Got it. So again, this is probably where I'll stop if I can kind of just park myself with microfinance. I spoke about how complicated things are working with banks. Now that I've kind of integrated a lot of the poor banking APIs using a bank node which is an anchor node on my blockchain channel and Hypal as a channel, I am able to spin off several business functions using the same network. I do not have to go back to the bank for multiple approvals. I can add multiple tenants to an existing channel or create multiple channels, all these provisions being provided by Hypal at the back. And then we park it there. That's great. Thank you very much, Sintil. And yeah, sorry to cut it short, but we are at the top of the hour. But anyway, thank you so much, Mohit and Sintil. You covered really great information. It was a really interesting presentation. And thank you so much for your time. And thank you also everybody for joining us live on this webinar. Let me just share my screen here. Now, I saw that some of the answer questions unfortunately weren't answered. So feel free to post them on our Discord or also reach out to CRIPSI and New Street Tech teams as well to follow up with that. And again, thank you so much for joining us. Now, before we part, I would like to invite you to join our Discord and explore our channels relating to projects, special interest groups, working groups, and much more. It's a native community and there's a lot of real-time interaction there. Please also make sure to check our events page to see all the upcoming webinars as well as other technical workshops as well as online events. Again, thank you everybody so much for joining. And thank you to our panelists, Sintil and Mohit, for this great presentation. We hope to see you again soon. Thank you. Thank you to Mass for managing this entire show. Of course, thank you. And thank you to everybody watching. See you next time. Yeah, looking forward.