As part of the IIPS (Instant and Inclusive Payment Systems) certification course on Designing and Deploying Technology for IIP Systems, Steve Haley, Director of Economic Development, interviewed Paul Makin, Digital Finance and Identity Consultant, for his insights on mitigating risks associated with payment systems through design and oversight.
Paul is one of the creators of the M-PESA mobile money service. In 2004, as a consultant to Vodafone, he conceived of the core operating model and developed many of the concepts behind agent liquidity management. Paul works with financial regulators, mobile money operators, banks, funding agencies, and others across emerging markets. He has recently been a key contributor on the core design team for Mojaloop – the world’s first open source platform for interoperability in real-time payment systems.
How to design risk out of payment systems
Steve Haley:
What advice can you provide for inherently designing the risk out of instant payment systems?
Paul Makin:
Analyzing individual and holistic risk
You have to take a holistic view of the service, investigating all dependencies on other parties. The most complex system I’ve worked with had more than 20 organizations involved in delivering the service – even in the pilot phase. Payment system designers must understand the risk that each participant contributes to the overall risk profile of the service. It’s critical to develop a view of how one party’s risks might translate into risks to the service as a whole or to another party.
Diversity introduces risk
Payment system designers must also be aware of the different classes of participants who possess varying levels of understanding of the service as a whole and the risk they are subject to. In the financial sector, there are corporate banks, rural banks, mobile wallet providers, credit unions, microfinance institutions (MFIs), and SACCOs (Savings and Credit Co-operatives). Each has a different understanding of risk and a unique capacity for risk.
If you’re going to launch a service that integrates all of those, there must be a mechanism for managing the risk they introduce. The service itself must also limit the amount of risk exposure to a level they are comfortable with and understand. For example, you may find that some smaller MFIs or SACCOs are not familiar with instant transactions. They are familiar with transactions that could potentially take days or even weeks and scared by the idea of connecting to a service that could potentially empty their accounts in seconds if something went wrong. On the other hand, the view of risk is vastly different for a bank offering 24/7 services and instant transactions between its customers and other banks. Banks can’t afford to expose themselves to an MFI that doesn’t properly control activities related to customers’ profits.
An interconnected service is a single service that exposes all parties to all risks of each participant. That’s why it’s the responsibility of the payment system designer to provide the tools they need to manage that risk and build in controls to make sure that those risks are manageable for all parties.
Steve Haley:
You pointed out that MFIs might be afraid of connecting to a new interoperable and instant payment service that could empty their accounts in seconds; the more considerable risk is the FI that is not afraid of that happening. Since they aren’t facing that risk daily, they’re not willing to invest in it. They place their trust in one person who’s responsible for an excel document.
The challenge we face is convincing these smaller organizations to invest in risk management now. Their method may work today, but to manage the new risks that interoperable payment systems introduce, they must invest in it now.
Paul Makin:
Small FIs play a big part
Small FIs also need to understand their place in delivering the service and serving their customers properly. We’re moving to an age now where it’s not enough to simply offer your customers some basic savings and loan services. If a system is going to make a positive impact on the development of a local economy, never mind a national economy, customers must be able to reach the services that they need. For example, people need to be connected to government services to receive basic social payments from a pension and, ideally, pay their taxes.
We must ensure that small FIs understand how they play a big part by enabling their members to participate in the broader digital economy that is growing in almost every country. It’s not acceptable to leave their customers in a “quiet backwater.” They must empower them to take advantage of the available services.
However, we can’t simply expect these organizations to jump in unless we put the risk controls in place for them. The good news is that we understand the risks, how to manage them, and, more importantly, identify new risks as they come along. But that doesn’t mean that a small FI that chooses to connect will instantly understand them. We have to support them in developing their knowledge of the risk and give them the tools to manage it themselves. In the end, it is their responsibility to serve their customers better.
Why centralized risk management is critical
Paul Makin:
The small FIs that remain in a “quiet backwater” risk losing their customers to a more progressive organization. And that could be a large commercial bank. But customers need to be able to choose the service that best meets their needs. We have examples from all over the world that demonstrate how MFIs, credit unions, and SACCOs understand people’s financial needs better than bigger commercial banks. There is no reason why a customer should be required to have a special relationship with any particular bank or MFI to receive government benefits. They should be able to do it in the way that meets their needs best, not in the way that serves the government department.
Steve Haley:
I would add that a customer should choose a financial institution without any fear that selecting the smaller organization that serves their needs could be riskier. That is why it’s essential for the centralized service itself should mitigate risk.
Centralized service, centralized risk
Steve Haley:
In the context of a centralized service with centralized risk mitigation and educating multiple types of stakeholders about risk, can you talk about the importance of clearly defining the scheme’s clearing, settlement, and application layers during the design process?
Paul Makin:
Mitigating the risk is a complex process, and there are some excellent approaches to doing this. Some examples are the afi cyber security model, the FFIEC model, and the NIST model. Each one has a lot to say about mitigating the risk, but they all accept that there are layers that must be addressed in their own right.
Technology, network, and people risk
At the bottom layer, we have the technology risk. One thing that concerns me is that banks tend to look at risk only within their own boundary – things like servers, laptops, and networks. But they have a responsibility to look at the risk to their customer in the field. If they provide that customer with an app on their phone or USSD access, or another service, the customer should understand the risks that their money is subjected to by interacting with your service across those networks as well.
In the past, banks have been able to sidestep this by essentially outsourcing that risk management to the international card schemes – Visa or MasterCard, for example. However, with the move to mobile money and instant payments, that risk is back in-house and the responsibility of the FI. Unfortunately, many FIs are not ready to deal with that responsibility.
And then there are people.
People are always going to be the biggest risk to a service. We have to put technological controls around them so that we can mitigate those risks. It’s important to educate the people within an organization to understand how to manage risk properly.
One of my favorite examples of this is the experience of walking into most financial institutions in the world. You will likely go through a metal detecting gate, and there may be someone responsible for noting the serial number on your laptop or similar device. However, in my experience, no one has ever checked the serial number of my laptop upon leaving the building.
So, what was the point? I call this “security theater.” It adds nothing to the security service unless you also check that I am leaving with the same laptop. The whole purpose is to ensure that I’m not switching laptops while inside the office.
This practice is important and, when done properly due to good education, reduces the risk to a financial sector organization. Considering the risks associated with technology, processes, and people and getting all of those things right in your design makes for a managed risk in your service.
Benefits of industry standards
Steve Haley:
In the industry, we have different types of security standards out there. For example, there is ISO 20022, PCI, and ASI. How do they help, and what are the other benefits of conforming to standards?
Paul Makin:
The principal purpose of those standards is to ensure that we can interact between organizations. In principle, they provide a framework for communicating with each other. Complying with these standards makes the interconnection of all our services more straightforward. But complying is only the first step. There is a fair degree of work to be done after that to interconnect our services.
The industry standards around data security, data protection, risk, etc., are very useful because they tell you what you need to do to ensure your services are relatively secure and reliable. This goes beyond cyber security. They ensure business continuity in the event that a particular element of the service goes down and how to avoid that entirely.
These standards were developed by people and organizations who have worked in this space for more than 20 years. Additionally, multiple frameworks derived from those standards can help analyze the risk within your organization. They force you to think through all of the elements of your service, how you will control risk, and whether you have the processes and people in place to manage risk when things go wrong. Standards are critical, especially for small organizations, so they aren’t required to reinvent the wheel every time they want to start a new process.
How is Mojaloop different?
Steve Haley:
I feel like the Mojaloop community goes one step further. What is Mojaloop doing differently in terms of mitigating risk down to the smaller financial institutions?
Paul Makin:
Layered security controls
From the point of view of the service itself, there is a highly sophisticated and multi-layered set of security controls around both the hub and the transactions that go through it. This was developed using a variety of techniques across four or five different layers. This approach makes it extraordinarily difficult to fake or repeat transactions through a Mojaloop payment hub. I would argue that it’s essentially impossible to do so.
Liquidity management
Additionally, in a Mojaloop network, the risk that each party is exposed to is managed through very careful liquidity management. For example, the settlement process employs a useful technique to reduce the variability of what we call the “settlement window.” The degree of risk that an MFI or bank is liable to is the volume and value of transactions within a particular settlement window.
By making that settlement window very short, Mojaloop can carefully manage the risk and tune it to the needs of the smallest FI. They can see the transactions that are going through. They can reconcile them within a short settlement window. They can settle a relatively small amount of money for any financial institution related to that particular settlement window.
Layered transactions
During a Mojaloop deployment, risk is also managed through the layered approach to the transactions. From the start, we get that simple general core use case deployed and running so that the FI can see that a simple transaction is moving from one financial institution to another through the hub simply and reliably over and over again. Once that is in place, we can build more sophisticated use cases on top of it.
Separation between rails and services
When we built Mojaloop, we very intentionally designed a clear separation between the rails and services. Mojaloop provides the rails over which the customer service runs. It’s not the customer-facing service itself – Mojaloop serves the financial institutions.
Maintaining simple, reliable, and fast rails – for instant payments in particular – allows more complex use cases to be built on top. Having confidence that the rails are reliable allows you to experiment with new services cheaply and reliably.
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. Paul, Steve, or another member of our payment solution team would be happy to walk you through our experiences and how we might work together.
