 Well, welcome everyone, those here and those that are remote. We're going to talk today about financial inclusion and helping the 1.7 billion people, first by taking off my mask so you can hear me better, the 1.7 billion people that lack access to formal financial services and some of the challenges that they struggle with daily, walking 20 kilometers to find a cash agent or to find a bank. Only to find the bank doesn't want them in the branch in the first place. So digital financial inclusion has been the work that the Gates Foundation has undertaken. And five years ago we began the process of creating an open source platform to connect payment systems together. Payment systems typically are what we call closed loop. That is both the payer and the receiver have to be on the same system in order to receive money. But what we want is something where a poor person who banks in a very specialized kind of institution has the ability to receive money from anyone or pay anyone. But that only works if we can connect all the systems together. That's been problematic, it's been expensive, it's been complicated, and frankly, even if persuaded, governments don't know where to begin. So we decided to build open source software to do that. So last year, as the pandemic unrolled, we launched the Mojloop Foundation, which is a formal corporation, a charitable company, to take over the assets that had been developed by the Bill and Melinda Gates Foundation. It was a project that I convened about in 2016. And in 2017 we announced it at SIBOs, the SWIFT conference, and then last year created the Mojloop Foundation and transferred all of the open source assets to that company. And these are the list of sponsors that have joined us to sponsor the work going forward. It is a membership company, it's open to sponsorship from anyone, but the software itself is free and available to anyone. It can be taken, used for any purpose, commercial or otherwise. Of course, we would hope that it would be used in service of the mission, which is to help people get connected to financial services. But let me talk a little bit first about what is the problem specifically in some more detail, and then what was our solution and how did we give rise to that. And to do that, I'm gonna play this video because it does a very good job of keeping me on time, in volume. They buy food, share money with friends and family. Let me do that again. Imagine your life without banking. How would you pay your bills or store your money for safekeeping? For two billion people around the world, these challenges are very real. They buy food, share money with friends and family, and make dozens of other transactions every day but they do it all in cash. As a result, they miss out on the security and other benefits of bank accounts and payment cards while financial providers miss out on millions of daily transactions. When cash becomes digital, these all changes. People can spend and save money more easily and securely and financial providers can access billions of new customers. Digital financial services are starting to spread around the world but not nearly as fast as they could. One big reason is that providers have to build everything on their own. That means they have to charge high transaction fees that are hard for poor customers to afford or they don't build anything for new markets at all. It also means that most services end up being a closed loop where customers can only transact with other customers using the same service. Grace, for example, can use her mobile money account to pay her energy bill and buy groceries but to receive her paycheck, pay her daughter's school fees and send money to her parents back home she still has to use cash because her employer uses one bank, the school uses another one and her parents use a mobile money service that is different from the one Grace uses. If companies had a common platform to work from they wouldn't have to worry about high costs and closed loops. Moja Loop is a way to build that common platform. Moja Loop is open source code for making digital payments secure and interoperable across an entire country or region. Named after the Swahili word for one it can help loop digital financial providers and customers together in one inclusive system. So when Grace receives her paycheck and sends money to her parents and her daughter's school she can do it all digitally with a single account because behind the scenes technology powered by Moja Loop is tying everyone's different services together. There are three main components to the code an interoperability layer which facilitates payments between different kinds of services including bank accounts, mobile money wallets and merchant accounts. A directory service layer which routes each payment to the correct provider in the ecosystem and a transaction settlement layer which makes sure that all the money that changes hands between customers throughout the day is recorded in each provider's master ledger as well. Developers can use parts of the software to build or adapt financial products and services or they can take the whole thing and build an internet of payments routing transactions from anyone to anyone instantly and securely. Moja Loop is open source so that anyone can use it and make it better. It's software for banks, fintech firms, systems architects, mobile operators and tech companies. In a world where financial services have always left some people out of the loop Moja Loop is a tool to bring us all together because an economy that includes everyone benefits everyone. So that gives you a picture of what the problem was and I'm gonna talk a little bit about what our solution to this is. So the open source software for instance instant payments clearing and what we mean by clearing is when a person making a payment and somebody who's receiving the payment they're exchanging IOUs in essence when they use one of these payment systems and if they're on the same system it's pretty easy for them to simply put the money down on the ledger immediately. But if they're on separate systems somebody's money has to move from one system to the other system and for that to work there has to be some record keeping in between. Moja Loop is set up for that purpose but it's done unlike a traditional bank where this might take two days for the money to actually move. In this case, if Alice pays Bob on the system using Moja Loop as the clearing system in the center the money moves instantly. It's immediately credited to Bob's account and it's final on receipt that means it can't be taken back later. There's no charge backs or anything of the sort. If there was a dispute that might arise later they can deal with that in the business context that they have or personally. But the payment system itself won't do those things automatically. The reason we remove some of those things from the system is they're expensive. Dispute resolution and reconciliation are the two most expensive things that we have to go through in the system fraud being one of the others. And we wanted to make sure that we addressed the costs in the system and the complexity. So if we get down to basics what are the semantics of moving money from one account to another on different institutions? Can we standardize that? And then with that standard can we minimize it essentially removing policy from it? So we say it's always the same. And we've done that in a way that allows us to create the Moja Loop hub in the hub system with a four piece API. There's three phases to moving the money. We call these the discovery phase, the agreement phase and the transfer phase. The discovery phase is very simple. Alice wants to pay Bob. Bob gives Alice his phone number and says please send me a thousand tons of knee and shillings and Alice says no problem, I'll set that up. She then through her financial service provider which we've labeled FSP here in the diagram through the app that her provider has given her or through a simple mobile phone. She will propose that transaction. Her service provider will go to the hub and look up who it is that Bob banks with. Now the account lookup service does not return an account number. In fact it doesn't return any financial details of Bob whatsoever. What it does do is it tells you who's associated with that alias. Could be a phone number, a national ID. It could be a specialized payment alias that we use for the purposes of addressing payments. But it's not an account number. In that way, Bob never discloses his account information to any way unlike what would happen with a credit card transaction. So once we know the pay E FSP on this side that is where the money is going. Bob service provider receives this account lookup query and responds with that's Bob and we will in fact accept money on Bob's behalf and make sure that that payment is fulfilled. That's step A. In step B the service provider for alias submits a query request. Basically it's a quotation request that says Alice would like to pay Bob a thousand shillings. Can you take care of that? It flows through the hub system really without inspection for the purposes of a simple connection. To Bob's service provider, they look at that and say is Bob capable of receiving a thousand shillings today given his limits that might be on system whether it's accounts suspended and other things. And they will respond most of the time they're going to respond with sure no problem we'll take that. But what they're gonna do is take all the transaction details as proposed by Alice's service provider and they're gonna assign them with a secret key that they never exposed to anyone. They're gonna take that signature and they're gonna hash it. The shot to 56 hash which we call the payment condition. They're gonna return the original transaction details and the payment condition to the hub but they're gonna throw away the signature. That's gonna flow back to the payer service provider who will present the details to Alice. This might include say 10 shillings and fees that are required to make this payment. There might be a foreign exchange conversion that has to be explained. If Alice looks at that and says I'm not doing this today she can safely ignore that message completely. It's not a financial message and there's no obligation to that no expectation that it will complete. If she wants to proceed she'll either thumb print or pin her approval of this. Her service provider then presents what we call the through the transfer interface the prepared payment. And the prepared payment includes all the transaction details and this we'll call it the digital deposit slip which was the payment condition. So the payment condition and the transaction details are submitted to the hub. The hub keeps the payment condition and forwards on all of the information including the payment condition to the service provider. When the service provider receives that on the transfer leg they will recalculate, re-sign the transaction details using their secret key, rehash that and see if the two hashes match. If they do they know well I signed this up earlier and we're fine we can take this thing forward. If they don't match they can reject it and say I didn't sign that that's not mine. In the event that they do like it and they're willing to do this they will take money from their working capital and credit Bob immediately and irrevocably. They will then return the digital signature to the hub as proof of fulfillment. The hub can match that by generating the hash from that and comparing the hash to the one it was received from the payer and say oh those match. So it now has permission from the sender and the receiver to clear the transaction. It can then commit it for settlement and it will respond by returning the fulfillment instruction that is the signature to the paying service provider. The paying service provider can again recalculate the hash, compare the hash with the one it originally submitted and verify that in fact it's the same in which case it will take the money that it reserved analysis account against this payment and place it in its own working capital knowing that it will pay out in settlement and knowing of course that the payee service provider is going to receive money in settlement and that completes and concludes the transaction. The system as it's currently operating today can has been tested up to 5,000 TPS that's complete flow through the C interface here end to end. On modest hardware running on AWS and Azure it's been deployed now in several countries and it's there are more coming more on the way most in East Africa some in Asia and we're hopeful that we can continue to evolve this software there are other elements of this that we hope we can gain others attention for. Importantly we've created a new extension we call the third party payment initiation interface. This is borrowed from open banking in Europe it's a way in which a third party who is neither the payer or the payee service provider but in a third party like Google Pay is an example of this. Google uses this kind of interface on in India for Google Pay in India. We've taken from that and made a generic interface that is now connecting to Mojaloop and what this permits is fintechs are now first class citizens of the payment system they don't have to be a bank and they don't have to be a regulated entity in the sense that they're in the financial flow because they're not. They use instead the transaction interfaces that 3PPI provides directly to Mojaloop with the customers off to Veritoken permission to act on the customer's behalf through their smartphone interface and with a single point of connection they don't have to make deals with 15 or 20 banks in order to connect into the market they do one with the scheme provider if that's the national government or a commercial provider it's still one connection and of course it's second factor so you can include either biometry or a PIN in order to ensure that that wallet system is there. That's based on a FIDO standard that's now just emerging. We built Mojaloop using modern methods and techniques we started originally with the notion this would be cloud hostable even though we know it's challenging in some sovereign markets to go in and say it's okay you can forget about your data center push everything into the cloud it's difficult for a sovereign government to make that commitment when that cloud is being run by a US national company so it works also on premises and we have evidence of both one case a commercial company is using this across Africa and nine markets they're hosted on Azure we do all of our build, our CI, our CD that's all done on AWS. Microsoft is helping us now think about what would it mean to create generic deployment templates on Azure for Mojaloop and we have one national implementation going on now where it's being done on premises and they're using open nucleus so they essentially can treat this like a cloud it's just their cloud. So what we need is we need help honestly we're always in a case of we could use more hands-on keyboards and we could use more brains in the box we're looking to build out now several things but the business operations framework is one of the key pieces this is where an operator will actually interact directly with the hub system so you can imagine three shifts 24-7, 365 you gotta keep the system running somebody's gotta be in there at midnight with a big red button to stop trading or to be able to adjust the system move to cause settlement to occur to do research into spurious conditions so that business operations framework is heavily technical but of course driven by business rules we wanna create the template and the framework for that that can then be easily used by others we need DFS experts for sure but we also need product experts to help us think about a business operations roadmap that isn't just pie in the sky that we really have something we can reduce all of our systems that we've created so far with this, the subsystems are developed using the safe agile method so each one of the teams operates in an agile way on a two-week sprint cycle with Scrum and that rolls up into a 10 to 12 week program increment so this is the way that we can hold the product people at bay, give ourselves some time and patience to do some work, leave us alone but at the same time honor the urgency of actually getting stuff done so that gives us essentially three release cycles per year of developing real value to people that need it and not saying, yeah, wait till next year we'll get to it and then suddenly it didn't happen we're also driven by what does the community need and what is the community able to produce we need both of those things to come together so this is an example that pretty much everybody full stack, UX, what have you we are using the jam stack approach to the business operations framework so there's no web server on the hub nothing that you could hack to go give yourself some money if you got in somehow on the system the idea is to use a local enterprise grade CDN to deliver a statically compiled page essentially pulled directly and frequently from the source repository and then delivered directly to the operating consoles on a local DMZ, behind the local DMZ so this gives us an ability then to quickly turn and to react to change as needed but it's not something where nobody knows what's going on because the web server is trying to figure it out but that it has full horizontal access to everything within the system that would be a horrible outcome and it would be hacked quickly, I'm sure so we want to stay to where there's a nice front end it's an API front end, it's in the building only you hit it from the operation consoles and we have implementing or we are implementing an RBAC design for that role-based access control using all of the components that we use are open source in this case I believe it's Ori that we're relying on for that the reference architecture is the next piece of evolution that we're undertaking and this is where we've got now in say say in deployment the version one of the system it operates quite well and we've tested what would we need to do in order to make to really blow the doors off this thing and have it run fast and be able to to really settle in well for the future a domain-driven design has completed and we now have a conceptual working map of what we need to do in order to move to this next system level but we need people to help us translate that into working code and of course to test our ideas and make sure we got this right and there's plenty of time to change course we're based on Node.js with TypeScript Kafka, Docker, Kubernetes that's basically the core of the system but there are 1100 I think dependencies pulled in by various components we're trying to minimize the number of versions of those that we pull in but that's always a challenge too a lot of this is maintained in an automated CI CD fashion I'm gonna drop quickly through this and just say there are lots of other areas that we can actually go through and I'd love to have conversations with people about how to evolve this how you can help us with your skill set and by all means please join us there's room for everyone we'd love to have you I hope that there's time here I can take maybe a question or two and then we'll have to roll off to the next session if there's anything would you suggest that we provide and just give us the same question can you understand the question? Of course, yeah, he's saying when we talk about a provider is it a bank and the answer is yes, it can be a bank it can be something called a mobile money organization or a mobile money network operator which is generally a telco that then offers prepaid account services to its customers it's very prevalent in Africa and also in Asia and also like you don't concentrate on B to B B to B through the hub, yes, absolutely yes, there are 13 different use cases that we think are the sort of canonical use cases it's peer, I'm not gonna get them all right but it's peer to peer it's a mobile wallet to bank bank to wallet it's in the case that we have a wallet which is not a bank the use of an ATM to pull cash out where it's not your ATM it's somebody else's ATM point of sale merchant request to pay is another one so you think about this when you give your card to a merchant and they run your transaction you're giving them all your account details so they can run that but we don't wanna work that way so merchant request to pay is a real time invoice sent to your phone it says if you pay us 15 shillings right now if you agree then you can have this bag of vegetables and so it's a way of them controlling the transaction but not your money or your account data it's still a credit push system I push money to them but against a specific transaction and so there's another set of use cases as well so B2B in that case but also the longer term I wanna pay my utility bill right so to pay my utility bill I know when it's coming they'll send it to me and I can pay it whenever I get around to it hopefully not late but I have that ability let me just leave I'm gonna say this that there's there's a link here and you can find me and everyone else we have about 1,100 people now contributing to the system about 1,100 and most of that is gonna be conversation on our threads and it's been hugely valuable to get people to just give us their ideas and to help us think things through we have probably on core about 200, 250 people that come to the convenings and really help us out with working on code but there's always room for more please reach out to me at the link there or through this QR code and if I could take if I could beg another minute or two I wanna just run a little bit of a loop here that'll give you a sense of what's happening when we deploy this thing sorry thank you