Mobile Money Interoperability is Easy! Connect two systems and go! Right?

There has been an ongoing debate since at least the past 4 years about “interoperability” across mobile money services. At the mobile 360 event in Cape Town in early November 2014, the GSMA team stated that there are now mobile money providers in four countries (Tanzania, Sri Lanka, Pakistan and Indonesia) experimenting by implementing interoperability and that mobile network operators in at least five additional countries have started to look at the issue.

But what exactly does “interoperability” mean?

At a high level, in my mind, “Interoperability” can be defined by looking at different types of scenarios of which three are documented below.

Account-to-account interoperability: In almost all deployments currently, customers of mobile money provider “A” can send funds to customers of mobile money system “B” – but mobile money system “A” will require that the recipient signs-up for the system "A" before the funds can be used. In other words, it is not possible for customers of system "A" to send to users of system "B" so that users of system "B" can use the funds in their system "B" wallets. Reasoning: This approach is used as a customer acquisition and retention tool.

When mobile operators enabled their subscribers to send SMS text messages to subscribers of other networks, usage on all networks increased. Similarly, it is expected that by enabling customers of one mobile money system to transfer funds to customers of another mobile money system, the overall number of users and transactions will increase across the ecosystem in the country. A great report discussing A2A interoperability by GSMA can be downloaded here.

Agent interoperability: In most deployments, regardless of regulations restricting exclusivity of agents, mobile money systems require agents to exclusively serve customers of that specific system. Reasoning: The cost of agent acquisition, training and retention is very high. Mobile money systems need to ensure that agents have enough cash and e-money (liquidity) to serve customers when required.The reality on the ground is that agents sign up with as many mobile money systems as they can simply due to the fact that transaction volumes of each system are initially low. Or there is simply a scarcity of qualified agents in that area.

It would be best to enable customers of any system to use agents that belong to any system. Reasoning: 1) Increased customer service; 2) access to qualified agents by all service providers across the country; and 3) bring more transactions to the agent making the economics at the agent level exciting.

This post discusses the account to account interoperability. A subsequent post will discuss agent interoperability (shared agents) and its potential to move digital financial services to full-throttle in many countries.

Now lets look at the technical considerations to implement interoperability.

Interface standards: There are well-established standards for interfacing very different computer systems. The Internet is a case in point: it has a broad range of disparate computer systems that can be accessed from various types of technologies and services consumed meaningfully by the interested party.

Technical hand-over management: This involves moving information from one mobile money system to another. This has to be carefully coordinated through carefully designed business rules. Put simply, it is about ensuring the receiving system responds with a “yes” and I have received correctly.

It would be ideal if all hand-over was always done in “real-time” i.e. as soon as the sender confirms the instruction. In reality, there may be a delay on either system involved in the transaction. Consequently, error handling has to be carefully coordinated and information passed to the sender about success or failure to send the funds across to the recipient’s system.

Disaster recovery (DR) and business continuity planning (BCP): DR and BCP are important to ensure that the mobile money system does not lose any customer funds or transaction instructions. DR and BCP need careful coordination and testing within the mobile money service provider. With interoperability, two different businesses and data systems and their interface mechanisms need to be coordinated carefully.

The typical metrics for BCP are Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). The RTO and RPO are time intervals, typically expressed in number of seconds, specified by the business continuity team to be the longest time the business can allow for without incurring significant risks or significant loss.

RPO is the maximum tolerable period in which data might be lost from the mobile money service due to a major incident. In an ideal world, RPO will be 0 seconds – in other words, no data is lost at all between the backup system and main system. This is not possible to implement due to the fact that copying data to another server in a physically separate location requires time, even if it is a few seconds.

RTO is the duration of time and a service level within which the mobile money service must be restored after a disaster (or disruption) in order to avoid unacceptable consequences. In an ideal world, RTO would be 0 seconds – in other words, no time is lost to swap-over to the backup system. This is not possible in real life because time is required for a system to switch from primary to the backup environment.

It is important to adopt a pragmatic approach to RPO/RTO metrics: there is always a point at which the cost of deploying a very low RPO/RTO is outweighed by a) the probability of the disaster actually occurring and b) the cost of deploying a low RPO/RTO service.

Consider the example where mobile money provider “A” has an RPO of 5 seconds and an RTO of 240 seconds; and mobile money provider “B” has an RPO of 10 seconds and an RTO of 600 seconds.

Scenario 1: a customer of “A” issues an instruction to transfer funds to “B” at 09:00:00. Due to a system disruption, “B” fails at 08:30:00. Now “B” is not available. So “A” can handle the error and reply to the customer rapidly and confirm to “try again later”. The customer funds are safe on “A”.

Scenario 2: a customer of “A” issues an instruction to transfer funds to “B” at 09:00:00. “B” is available and instruction is passed from “A” to “B” at 09:00:02. Due to a system disruption, “A” fails at 09:00:03. Backup system of “A” comes online at 09:00:10. The instruction from the customer has been lost (since the RPO is 5 seconds) so the customer funds will show as BEFORE the transaction took place. The upshot being both “A” and “B” have the funds of the customer and settlement and clearing between the two systems will fail.

These scenarios illustrate the fact that for interoperability, multiple systems have to be coordinated in-case of failure.

Using a 3rd party switch: It would be ideal to integrate into a 3rd party switch like a national ACH to reduce the number of bilateral integrations across the countries. In some instances card schemes like Visa and Mastercard have talked about becoming the “interoperability standard”. This is intuitively a good idea – a global payment scheme brings high standards of service and availability to enable smooth operations and issue resolution. Whilst using a 3rd party switch may simplify operations (single point of contact and SLAs implemented), it creates another interested party for a revenue share. Like the card schemes, many existing ACHs and switches may already have fixed commercial terms that they may be unwilling to negotiate on thereby pricing interoperability too high for market realities.

Now that we have the technical considerations (many more need to be thought through and decided upon apart from those mentioned in this post) understood, agreed upon and implemented, we can switch on interoperability! Right...? erm, no... this was 20% of the problem. The main issues are around commercial considerations - things that take much longer than the technology piece.

Commercial considerations: As with most businesses, interoperability is not as much about technology as it is about commercial agreements that are in place and respected. Specifically, it is about ensuring the customer has a single point of contact (ideally the call center or the agent) that can resolve any problems with sending funds from “A” to “B”. The questions typically to be asked are:

• Whom does the customer call in case of a problem?
• How will the call centres of “A” and “B” ensure they know enough to support a customer in case of problems?
• Will the customer support staff of “A” have access to systems of “B” to help resolve errors directly or do they need to manually call “B” to resolve queries?
• How do you agree sharing the fees charged to the customer for transferring funds from “A” to “B”?
• Will there be an additional fee charged for “off system” transfers (defeating the purpose of interoperability)?
• How can “B” be sure about “A” (or vice-versa) following KYC rules correctly and that the funds are truly from a valid customer on “A”.
• How will fraud be handled – internal, agent, customer?
• How are rejections of funds by the recipient (customer of “B”) handled?
• What happens in the situation where clearing or settlement fails?
• Who is liable for the shortfall in case of a system failure? How does this get proven and redressed?
• How long will it take for funds to be made available to the customers in case of genuine problems?

As would be expected, commercial issues take the longest to negotiate and implement.

The three key take away from this blog post are:

1. Think through each user journey and have clear operational processes and systems to support errors that may occur.
2. Integration is not just about interfacing two systems together – it is about ensuring smooth handovers, disaster recovery management and fraud management. In other words – it is mainly about risk management and mitigation.
3. Be open and flexible and entrepreneurial to build a service and adapt it as the user base matures – there are risks involved that no one would have yet thought about. This is easier said than done in the field of interoperability given the various interests each party has but the importance of learning-as-you-go cannot be overstated in this context.

Welcome comments to discuss this further. We are all still learning!

Prateek

Prateek Shrivastava is founder of Accendo Associates, a mobile money and branchless banking services consultancy. He is also the co-founder of BeyondBranches International through which he is supporting the roll-out of a shared agent network in Africa.