The Genesis of Mojaloop

By Miller Abel, Deputy Director and Principal Technologist, Gates Foundation

Mojaloop has come a long way since a group of us at the Gates Foundation began to look at the problem of financial inclusion in the digital age. As the chief architect of the platform, some people have referred to me as “the father of Mojaloop.” But really there were a number of people involved in getting us from the financial inclusion principles embodied in the Level One Project to Mojaloop as a reference model to what it is today: a mature software platform that is constantly maintained by the Mojaloop Foundation and upgraded by a thriving community.

What follows is the history of how Mojaloop began, along with some thoughts on its value for countries that are considering it as a basis for inclusive instant payment systems (IIPS). It’s helpful to remember that the following events took place before the wide adoption of instant payment systems like PIX and UPI, and when UK’s Faster Payments was in its early days.

Before Mojaloop: Early Digital Payments in African Countries

Before I joined the Gates Foundation, work was already underway to understand how people who earn at the lower levels of economies utilize financial services.

What we observed in our research was that people with lower incomes didn’t use formal financial services at all. Many of them used cash, while others were starting to use mobile money systems. But these systems weren’t intended as an alternative to formal banking; they were invented to create an attachment to the mobile network that offered them — once your money was stored there, you would be reluctant to switch providers.

The next question for our team was, “How would we create an ability to treat mobile money systems more like a banking alternative for people with lower incomes?”

We knew that interoperability with the wider financial system would be essential. Without interoperability, you could still get currency and buy things, but you couldn’t trade with anybody on other networks. In fact, we noticed that people often carried multiple SIM cards with different balances on each, to increase their ability to pay. But splitting and managing limited assets across multiple accounts is difficult.

We saw notable features with mobile money that we thought would benefit people with lower incomes — features not offered by banks — such as the ability to instantly clear payments, just like cash. We also saw a mismatch between what banks wanted from customers and the services that people with lower incomes desired and could afford. We saw that mobile money systems, if interconnected to each other and to the wider banking system, might meet people where they are, and provide an alternative to commercial banks. This would enable anyone to pay anyone else, regardless of their level of income or the form of account they held.

No one in the commercial market provided interoperability solutions for non-bank financial institutions. That’s where we saw an opportunity to be helpful.

Defining the Criteria for Inclusivity: The Level One Project

We wrote a set of principles that described what the ideal interoperable system would look like, and what characteristics it would need to improve financial inclusion. The principles emerged from evidence of best practices uncovered through research and active investment and implementation.

Called the Level One Project, we explored how to level the playing field between people at different economic levels, and how one system could include everyone. The word “project” was intentional, because projects end, and we planned to move on to other aspects of financial inclusion once these criteria were defined.

We’re still actively using the outputs of that project, as there’s no timeframe attached to it, the most important being the Level One Project principles and the Level One Project Guide, a recipe for how to construct an interoperable payment system that is inclusive of all licensed financial institutions.

Creating a Reference Model

When we looked for a commercial solution that met the Level One Principles, or at least one that could be further tailored to these principles, we kept getting pushback from the banking sector such as, “Nobody wants this, it’s too hard to build, it’s too expensive.”

It wasn’t a real reason, of course, but it required a response. So, we developed our own reference model: Mojaloop, which provided a technical demonstration of what a good system like this would look like. A commercial effort would have to be at least as good and at least as cheap as alternatives, but the original intention wasn’t to release Mojaloop for production use. It was to be released for study as an open-source reference model, as a sort of feasibility test.

That was the genesis of the Mojaloop prototype. It got underway, with real people sitting in front of keyboards, in May of 2016.

Building the Prototype

While there were other companies that became involved as we developed a wider community, at the start I pulled in five companies to help build the initial prototype:

• Dwolla, a company that is experienced in doing bank-to-bank transfers in real time.
• Ripple, a cryptocurrency company with ideas about synchronizing ledgers across financial institutions with their Interledger Protocol, which we adopted.
• ModusBox, an API service integrator company that we used in reverse to create the Mojaloop API.
• Software Group from Bulgaria, who had experience in mobile money across Africa in wallets and financial services that targeted the impoverished.
• Crosslake Technologies, which constructed a way of working that adapted some best practices in the software development world at the time, most notably SAFe Agile.

SAFe stands for “Scaled Agile Framework for engineering.” It’s a way of having multiple teams working separately, but connecting periodically, to ensure they’re creating combined business value that’s delivered incrementally. In our case, this was every 10 to 12 weeks. In this way, we were able to make quick progress and adjust as we went.

Using an Agile methodology was important because we didn’t quite know what form the system was going to take and we didn’t have time to write a 400-page requirements document and go to RFP. We intended to learn by iterating.

The First Mojaloop Community Meetings

The Community Meetings began in June 2016 with the five companies along with some invited guests.

The first two or three program increments occurred as part of the prototype work. There was no break between program increments: it wasn’t like we suddenly stopped and said, “Now what?” — we just continued to expand.

We opened to a wider community and had our first formal convening in Seattle, which brough together 25 or 30 people.

Compare that with the March 2024 Mojaloop convening in Nairobi with 268 people attending. That was the largest we’ve ever had at that time, and the most engaged, with representation from over 30 nation states, which is remarkable.

Debut at Sibos

The first program increment of Mojaloop was completed in June 2016 — but the most interesting inflection point for the prototype was when it was released in October 2017 at the Sibos conference in Toronto.

Sibos is the largest banking conference in the world, hosted by SWIFT, the wholesale payments network for global banking. There are more than 10,000 banking and banking-related stakeholders who attend the event. Kosta Peric, Deputy Director of the Inclusive Financial Services (IFS) team at the Gate Foundation, spent many years at SWIFT and had a long-term connection to Sibos. So, it was a natural place for us to announce this project.

Mojaloop was received very well. In fact, the director of a national payment system was in attendance and expressed interest in using Mojaloop as the basis for building the country’s instant payment system.

Birth of the Mojaloop Foundation

Mojaloop’s original statement of work stipulated that if the platform was successful and we built a community, then we would off-board the source code to a separate, independent foundation for further development. By mid- to late-2019, we had established a core community of stakeholders eager to advance Mojaloop as a production-quality software platform.

On May 6, 2020, at the peak of COVID, the Mojaloop Foundation was incorporated. I had spent the previous 90 days wearing a hole in my carpet, pacing back and forth on the phone, working with Paula Hunter, our collective attorneys, and partners on the logistics of establishing the organization, as well as working with Kosta and our Gates Foundation colleagues to engage co-sponsors for the Mojaloop Foundation, such as Google, the Rockefeller Foundation, and Ripple.

Greater Participation and Expansion

Since its incorporation, Mojaloop has expanded in a number of important ways. Primarily, countries and hub operators who are interested in adopting Mojaloop now attend the Community meetings and participate directly — it isn’t just the core software developers.

We also now have a much broader community of systems integrators, which are companies that take the software, tailor it for adopters and provide support and maintenance.

Significantly, those system integrators are not being drawn from European companies; they are companies in the African and Asian markets where Mojaloop-based systems operate. This shows that open-source systems like Mojaloop can be used by world class, locally-based developers without having to fly people in from Europe or pay exorbitant markups relative to market salaries. Of course, another benefit is national ownership, which is something that a foreign commercial solution could never provide.

Adoption Increases

Mojaloop is now being adopted in several ways. Most importantly, it’s being adopted by nation states to create nation- and regional-scale payment systems with the full force of regulation and mandate behind them. It’s also being utilized by collaborating groups of commercial actors, such as microfinance institutions, small banks and community banks that want to create their own network and own the software.

Reasons for Optimism

One of Mojaloop’s great strengths lies in its reinforcement of the Level One Project principles and a recognition that the principles can be used to build commercially viable systems. It’s important that interoperable payments systems that address the needs of people with low incomes be viable and sustainable — these systems should not depend solely on subsidies. Sustainability can be achieved as a “not for loss utility” — not losing money, and requiring subsidy, but also not seeking to maximize profit directly from payments. The fact that all Mojaloop transactions include an agreement of terms phase is the primary means of keeping costs down on high-volume low-value transactions: At the start of each payment transaction, the financial institutions exchange non-financial messages which affirm the full transaction details. The transaction details are reviewed by the user making the payment, digitally signed and non-repudiable. This idea is gaining traction with the recent ISO20022 updates.

Another reason why I think Mojaloop has a bright future is that several countries have already started using it as the basis for their national payment systems. While each country may have different priorities, the commonality is a focus on the sovereignty of national payments as a core function of what that country does for itself, rather than importing a solution.

With Mojaloop, countries can accelerate building their payment system themselves and can independently manage and maintain it to best serve the evolving needs of their people. And as Mojaloop is open-source software, each of the adopting countries benefits from improvements made by the others. This offers the most opportunity for economic development and social inclusion which are essential for long-term sustainability and growth.