In this conversation, Steve Haley, Director of Economic Development, sat down (virtually) with Warren Carew, VP, Payment Solutions, to ask some important questions about designing real-time payment systems. The interview is part of the IIPS (Instant and Inclusive Payment Systems) certification course on Designing and Deploying Technology for IIP Systems. Warren has been a leader in the Digital Financial Services industry since 2005 when he played a major role on the team that created and launched the industry-shaping mobile money service M-PESA in 2007. Here, Warren provides his perspective on the role of governance models and the evolution of technology, how guiding principles can unify decision-making, the fundamental challenges and solutions to building payment systems, and how the industry mindset has evolved over the years.
Governance models and new technologies
At a high level, why is it important to have a good governance model in an organization, particularly around technology implementation?
The thing about technology is that it keeps changing.
More importantly, people’s technical needs keep changing. We need to ensure that we are actually creating solutions and services that have the concept of change built into them. That requires a good governance model with a feedback loop that listens to every stakeholder involved in consuming and benefiting from that service. That governance model must be flexible enough to continue evolving in order to make use of the most appropriate technical solutions available in the market.
From a technical point of view, it is not only key that the solution uses the right technology but more importantly, that we are actually meeting the market needs. How do you decide which real-time payment solution is the right one for your market?
The good news is that there’s a lot more in common with available solutions than differences between them. So we can learn from each other. In the Mojaloop community, we consider this an excellent place for collaboration. You can fold the best learnings and practices back across the real-time payments initiatives.
How guiding principles empower decision-making
Can you provide an example of when the governance team had to overcome conflicting interests to make a decision and a guiding principle made that possible, or at least easier?
To make decisions, you must have a signed set of guiding principles – a common vision of what “good” looks like. In my role, our guiding principles are the Level One Project principles, which are used as guidance for framing the solutions. For example, one of the questions we are often asked is, “How do you provide direct debits in a real-time payment system?
The answer is that we don’t.
At least not in the way that most people are used to. As a principal, we’ve established that withdrawing money from someone’s account even when they do not have enough funds and then charging them a penalty fee is not a scenario that encourages good financial inclusion. It doesn’t benefit the overall economic growth of the market. And it doesn’t benefit the person or the financial institution in the long term.
This resulted in our decision to only support push payments. In a Mojaloop-based network, you can never pull a payment.
The next question we get is, “But how do you meet the need for the market?”
A request-to-pay ability allows a lender to say, “Hey, please make this payment that is due now.” And it gives them a way to manage the financial risks involved with it. But the person is allowed to make the priority decision. That decision could mean the difference between putting food on the table for their family and children that night.
That doesn’t mean there won’t be consequences for not fulfilling your financial obligations. But it does change the way we manage it. In financial services, it’s about managing the exposure of our institutions and the risks that we allow our customers to take.
Mojaloop isn’t the only network to make this choice. M-Shwari, in partnership with Safaricom and CBA (Commercial Bank of Africa) in Kenya, is a great example and has demonstrated the real value in doing this well.
That example comes up all the time in my conversations, and the initial answer from everybody is, “Yes, of course, we want direct debit. Everybody wants direct debit.” But you have to balance that with the resulting consequences, such as low-value transactions, the cost of fraud, or the per-transaction cost of your entire system.
If you haven’t set those values in your guiding principles, you have nothing to measure the impact of a decision like allowing direct debit.
Fundamental challenges to designing and building real-time payment systems
Sometimes, after the regulations and policies have been created, another company comes in to build the regulations, and another to build the policies. Afterward, the Central Bank or the hub operator procures a technology that can meet all of those requirements.
What are some of the fundamental challenges with that approach, and what would you recommend as an alternative approach to meet that need?
Steve, you are talking about one of my lifelong challenges.
The RFP process
I’ve been involved with initiatives to provide new and innovative ways to deliver services, enhance services, and disrupt existing services throughout my career. In our industry, the RFP process has been well established to procure these services. Organizations use this process to manage risk. But the way they’re trying to manage risk simultaneously limits innovation and tends to favor known incumbent solution technologies. However, those solutions that may have a bigger impact are disregarded because they introduce some risks as a result of being relatively unknown.
Additionally, in the software technology space, we talk a lot about agile methodologies. In engineering, they generally talk about continuous improvement. And in the business processes segment, it’s about how do you continue to make things more efficient and evolve. This approach has become key to the way we run financial institutions today. The drive behind open banking initiatives around PISPs (Payment Initiated Service Providers) has meant that we have to evolve our solutions and services more quickly.
Customers are used to smartphone apps that continuously improve. In areas where there isn’t a high penetration of smartphone apps, we see feature phones that have started using USSD in ways that we’ve never expected. But because there was a need, and they could meet the need through those digital channels, things have evolved. The smartphone is only accelerating that.
Solution: an iterative approach
We’ve now been working with several organizations, both at the government levels and with organizations, where we have participated in proof of concepts and pilots rather than a big bang procurement process.
A good example is the South African Reserve Bank (SARB), which recently ran an exploratory pilot on central bank digital currencies. SARB determined that there was no solution in the space yet, and none of the solutions they evaluated had a proven technology stack. So they ran a number of pilots with partners and consortiums to discover which would work.
Everyone who was part of that process was very impressed with the approach they took and their openness. SARB said, “We don’t know which one of these is going to work. In fact, we may not choose one of the three current options because it’s an experiment.”
This agile way of doing things is an iterative method that will introduce smaller RFPs with fewer constraints. If countries and companies do this, it will prevent decisions made as part of an RFP process that has to be lived with for the next ten years. It’s about taking smaller steps, moving faster, and enabling the right iterative decision.
Most people taking this IIPS course are technologists or working in technology and are likely proponents of agile. The challenge for most organizations that have tried to be agile is a mentality that says, “Agile is that thing that the technology people do.” But the business people, product people, finance people, and operations people are not invited or required to come along on this agile journey.
That’s not the way it works. It’s not just the technology team’s responsibility to be agile. It’s everything and everyone. For building payment systems, the regulations, policies, and business rules all have to be agile. It’s not just the dev teams and CTOs from the payment switch or financial institutions. The business people, lawyers, and regulator advisors all need to adopt an agile mindset.
Evidence of change
And I think that mindset is changing in the industry – slowly.
We are working with some East African countries that have adopted this agile approach. They are saying, “Let’s get this one use case to market. First, let’s make sure we understand the scheme rules, the charging models, the scaling functions around edge cases, and the go-to-market technical operations for the solution. Then we’ll go live. After that, we will add on the next service and go through that whole process again.”
So, we’re focused on training them to keep evolving because, by the time they finish two-and-a-half use cases from now, they’re going to look at the starting one again and say, “Is that still right? Does that make sense?” It all comes back to governance and change and the things we discussed earlier.
Personally, one of those ‘aha!’ moments came when I was chatting with the managing directors at a bank. The lawyer stood up and said, “Ah, I understand this now. I can help us manage our risk by making sure I ask for an agile approach to delivery by making sure these checkpoints are in the contracts.” That was a great personal win because originally, that lawyer wanted a rock-solid, watertight contract that was going to make a promise that everything was going to be fine 24 months later. But he saw a way to incorporate that into a normal procurement process that allowed them to have that incremental reporting.
The last payment system you will ever procure
At ModusBox, one of our guiding principles is empowering local communities to adopt ownership. We’ve done this in Mojaloop by open sourcing the core technology because it allows people to own their future. It doesn’t tie them into any particular vendors. We have a dream that for those who choose to start a Mojaloop journey, it will be the last national payments solution you need to procure because it will continue to evolve to be the thing your country needs.
I think it’s important to note that Mojaloop can also be used as a framework. Just because you choose the framework architecture for a POC doesn’t mean you’re locked into that architecture forever. It can simply mean that you’re in the learning stage right now, and you may as well learn on the fly.
I like to use the example of a car engine where you get to open up the hood with Mojaloop to learn how it works. Later, you can decide if that’s the engine you want to buy or not. But, you can take a look at it while you’re learning rather than trying to learn from a black box. I hope that more people take advantage of that opportunity for their design POCs.
Keep the conversation going
If you would like to learn more about the IIPS certification program, check out our blog or visit their website. If you are designing a real-time, inclusive payment system and these challenges or ideas resonated with you, don’t hesitate to contact our team today to learn more. Warren, Steve, or another member of our payment solution team would be happy to walk you through our experiences and how we might work together.