In the second part of this series on the challenges of building open, interoperable payments in Myanmar’s microfinance industry, we elaborate on the project’s first use case. Learn why we are developing a standardized loan repayment system in collaboration with the country’s financial institutions.
Wherever you are in the world, you are likely to be within walking distance of an automated teller machine (ATM). Despite cultural contrasts, language barriers, ATM manufacturers, banks, and other variables, the process of withdrawing funds will look familiar. This is the result of a standardized process: insert a card from an accepted network (Visa, Mastercard, etc.), select a language, choose to withdraw money, accept any associated fees, take your cash and card, done. Thanks to this consistent experience and the technical standards that underpin the transaction, usage and the number of available ATMs per person doubled from 2006 to 2018!
In Myanmar, ModusBox and the UNCDF are conducting a pilot project that demonstrates the potential of interoperable, real-time payments for about five million microfinance clients. This project connects various types of digital financial service providers (DFSPs), including banks, mobile money operators (MMOs), and microfinance institutions (MFIs) to a lab environment of Mojaloop – the first open source platform for interoperability in a real-time payment network. For the same reason that standardizing ATM withdrawals simplified the user experience, participating DFSPs designed a standard loan repayment use case so that their clients and loan officers would have an easier time understanding and using the product.
How was the standard use case developed?
ModusBox and UNCDF Myanmar held design sessions with 15 MFIs, banks, and MMOs through Zoom meetings and collected data and feedback using Google Forms. The process was not without its challenges. However, it was clear that an essential part of the design process was asking the right questions. For example, “Can someone pay another person’s loan?” By identifying these questions early through a process mapping exercise, participating DFSPs could hold internal discussions and return written answers to the design group.
Through this process, we designed version 1.0 of the Myanmar Microfinance Loan Repayment use case. As expected, there were differences of opinion among the participants about the design. However, we have witnessed many well-intended interoperability projects stall while attempting to reach consensus before delivering a product to customers. We have found that it is more useful to build the first version and iterate on it as the team gathers more data from customer experiences. As a result, we are already compiling proposed modifications that will be reviewed by the design group. Check out the first blog in this series to learn more about our approach to building consensus.
What’s in the loan repayment use case?
The use case specifies three transaction steps:
- Payer initiates the transaction.
- Payer receives information to validate the transaction.
- Payer approves the transaction.
In each step, the use case details the information provided by the user or system.
For example, in step one, the payer must provide an account identifier that corresponds to the loan account number recognized by the MFI. It’s important to note that a customer’s mobile phone number or other commonly used account alias was not used as the identifier in this use case. In Myanmar, many microfinance clients do not have mobile numbers, and if they do, it’s common for the number to change regularly. The account identifier is an important piece of customer data that creates uniformity across all MFI clients and is critical to creating standardization. You can read more about phone numbers as an alias in our blog post, “4 Digital Essentials for Microfinance to Survive the Economic Rainy Season.”
Additionally, in step two, the system returns information about the loan that includes the client name and loan amount due so that the payer can check that they are paying the correct amount into the correct account. However, during the design process, we found that DFSPs had varying definitions of “Loan Amount Due.” This term could hold one of three meanings: the remaining total balance, this month’s payment, or next month’s payment. Implementing and iterating on version 1.0 helped to create an understanding of the differences in what each MFI core banking system tracked.
Why is this needed?
Evidence shows that technology standards reduce cost, increase customer acceptance, and fuel product growth. In Myanmar, there are more than 150 microfinance institutions. Imagine the massive interoperability challenge that would result if each MFI designed their own loan payment experience!
The Mojaloop lab connects all classes of DFSPs to allow for interoperable payments. The loan repayment use case sits atop the payment infrastructure and specifies the transaction flow and information exchange. This greatly reduces the cost of designing bespoke use cases for each microfinance institution. In addition, Mojaloop provides centralized clearing and settlement which reduces time-to-market and cuts integration costs.
What’s next?
With version 1.0 of the loan repayment use case complete, ModusBox and UNCDF Myanmar are connecting participating DFSPs to the Mojaloop lab and testing interoperable digital payments. At the time of this writing, six financial service providers are already connected to the Mojaloop lab with another two in the process.
Using the developed standard, we are able to show the movement of funds across all financial service providers with immediate clearing and settlement. With a single connection to the Mojaloop lab, each DFSP gains interoperability with each of the other connected MFIs, mobile money operators, or banks.
Perhaps, one of the most exciting results is the acceleration of interest in this project. At the onset of our work in Myanmar, it was difficult for many participants to truly understand the potential benefits of standardizing this use case. However, now that version 1.0 has been implemented in a Mojaloop lab and the benefits can be clearly seen, our team can work towards v2.0 and gaining customer acceptance.
If you are interested in learning more about this project or establishing a Mojaloop lab in your country or for your industry, start a conversation with our team today or check out the resources on our website. These include our Mojaloop Partner Program, training courses, and the Mojaloop lab.
