A six-month-long interoperability project in Myanmar’s microfinance industry has shown there is much to be learned for banks and regulators. Here, we focus on five lessons that central banks, commercial banks, and mobile money operators can discover from this project for building a national payment infrastructure.
Traditionally, central banks have built payment systems that suit the needs of big banks that have agreed to products and rules that work for them. However, as our Myanmar project with the UNCDF has demonstrated, the needs and interests of varying classes of digital financial service providers (DFSPs) are incredibly diverse. DFSPs can be large banks, small banks, digital banks, deposit-taking microfinance institutions (MFIs), agricultural MFIs, telco-led mobile money operators (MMOs), bank-led MMOs, niche MMOs, etc. As such, a national payment system designed for only one member of this group will fail to include others effectively.
It is the scheme owner’s responsibility to deliver a successful system, not only a successful technology. We started our project with the hypothesis that a payment system will be more successful if the participating DFSPs (banks, mobile money, and MFIs) are the ones that drive transactions. The key to this is that they not only understand the system but also feel ownership over it.
The project’s primary goal is to further digital financial inclusion for about five million MFI clients in Myanmar. However, from this work, there is much to be learned for banks and regulators. Here, we focus on five lessons that central banks, commercial banks, and MMOs can take away from this project for building a national payment infrastructure. These are real lessons learned by real participants.
Picture the destination and show a clear roadmap.
Before achieving ownership, there must be an understanding of where the project is going and how the team will get there. There will be many obstacles, disputes, and details along the journey on any project of this caliber. This necessitated a significant amount of education about real-time payment networks, and how and why they differ from standard payment systems. We accomplished this early in the project through hours of training and utilizing tools such as a “Destination Postcard.”1
We outlined the roadmap with participants through a series of meetings limited to DFSP leadership. However, the team quickly learned that each DFSP was dependent upon key (sometimes external) stakeholder participation. Additionally, our initial roadmap was focused on product and technology, but we soon found it necessary also to include information for business and operations.
It wasn’t long before our team recognized the need for a simplified, visual communication style. This led to the development of 3-4 intelligible yet effective slides. Most countries develop 100-page payment strategies (spoiler alert… no one reads them). We believe this is a critical step and validates the use of communication professionals to develop these components. (My PowerPoint skills are good but didn’t quite cut it!)
If you would like to read more about how we gained participant consensus on this project, read Part 1 of this series.
Provide concrete results.
Building the rules, regulations, and infrastructure is a lengthy, massive undertaking (actually, it’s a process that should never end, but that’s for another blog post). The number of variables and decisions is daunting and endless. No PowerPoint plan ever survives the details that inevitably come up, such as differences in account number formats, account types, time out rules, etc. In many countries, we often hear, “I know the central bank is doing something but their projects never actually happen.” The demo-first process outlined in Part 2 provided concrete results to the participant DFSPs, increasing their commitment to the project. This improved our team’s ability to differentiate between the industry leaders – those who believe in open interoperability – and those who drag their feet while building closed systems. Reward the early adopters on the project by allowing them to provide additional input into the scheme’s governance.
Regular and transparent communications – not just for CEOs!
In agile development, we call them “team cadence meetings” – a regular schedule of brief, open meetings. These maintain momentum and build relationships among diverse stakeholders – crucial for negotiations around rules later in the project. We held Leaders Updates every two weeks, even when there wasn’t much to report. Meeting recordings were made available for those who were absent or joined later. We recommend these meetings to be held once per month initially and once per quarter thereafter for a national project.
This method proved to be beneficial for maintaining leadership commitment and buy-in on the project. However, we found these meetings occasionally resulted in other key stakeholders feeling uncertain or left behind. As a result, we now coordinate separate meetings that include subgroups with specialized purposes. Similarly, the Central Bank of Myanmar convened working groups for its planned QR system. These included both technical and business working groups to ensure all participants had visibility to project status and the roadmap. Our team validated the importance of this approach but it could be taken a step further with the addition of groups that include operations and product stakeholders.
Capacity building – also, not just for CEOs!
Informed participation requires a deep bench in each organization. Like the boot camps hosted by the Bill and Melinda Gates Foundation during the Level One Project, workshops in the past have focused on DFSP leadership. Often, CEOs lack the technical knowledge to decide on integration patterns, settlement, disputes, and pricing. Thus, it’s important to recognize that key individuals may belong to external organizations such as vendors, consultants, subsidiaries, or holding companies. We have worked with some world-class leadership on this project. However, the work never really started until other team members had become involved.
Identify technology gaps and who can fix them.
Admittedly, we focused on technology requirements in the first phase. Not because the project is technology-led, but because we knew that DFSP technology capabilities would likely slow progress. While some DFSPs were able to integrate quickly, it became clear that others would require a technological overhaul before participating in the national system. We recommend that central banks run widely available proof-of-concepts and deploy products like our Mojaloop Lab. This enables DFSPs to identify technology gaps – especially in security, speed, and redundancy – at least six months before integrating. It is common for DFSPs to possess siloed technology teams, including infrastructure, back-end, front-end, and core systems with different reporting lines. We managed this early in the project by combining them into a single project team in addition to the technology-specific working groups mentioned above.
The bottom line
Throughout these lessons, the theme has been communicating effectively. For scheme owners or hub operators, it is not the participants’ responsibility to understand your vision. It is your responsibility to lead them and build trustful relationships through productive communication.
If you would like to learn more about our work with Mojaloop or how we are driving open, interoperable, real-time payments, we would love to start a conversation with you today. Additionally, our website has several excellent resources for you to get started, including the Mojaloop Partner Program, training courses, and the Mojaloop lab.
- I highly recommend Switch: How to Change Things When Change is Hard by Dan and Chip Heath. More on that in another post!
