Connecting the Dots: Interoperability and Technology

06 February 2018

For many, the first thing that comes to mind when thinking about interoperability is some form of technology – a switch or an application program interface (API). Effective interoperability is more than a technological challenge, but technology is required to connect participants. Yet even effective technology is about more than moving transactions from Point A to Point B. Technology must be positioned to execute the terms of scheme rules and optimized to ensure security, encourage use, promote innovation and prepare for the inevitable time when something goes wrong.

Photo: Febri Kristiawan, 2015 CGAP Photo Contest

Connecting the participants of an interoperable scheme can be achieved in many ways. In Tanzania, mobile network operator (MNO)-led mobile money providers have chosen to connect bilaterally with their peers through APIs. Today, over 25 percent of person-to-person transactions in the market are sent between providers over these connections. In nearby Uganda, MNO participants in that market’s multilateral scheme have connected, at least initially, through a third-party aggregator.

Many schemes, from Visa’s card services to the Unified Payments Interface in India, opt for some type of central switching technology. The benefits of a switch are clear: easier scalability as the number of participants grows, improved routing efficiency and cost efficiencies at scale. But switches also require a higher upfront investment compared to other options, meaning that an economic decision must be made as to whether transaction volumes in a given market are sufficient to make the investment viable. CGAP has developed a financial model to help understand the financial trade-offs and at what transaction volumes a switch may be advantageous. (For an Excel copy of the model, email Will Cook.)

Effective technology, however, is also about a host of other technical considerations intended to help ensure a robust and resilient service. Getting these answers wrong can result in service failures, substandard customer experiences and, from the provider perspective, value left on the table. Key technical considerations for scheme participants can include a wide variety of items: 

  • Information security. At a scheme level, technology should ensure that the authenticity of a transaction is trusted. Many schemes achieve the necessary security through leased lines or virtual private networks (VPNs). However, the last mile in many of today’s services can remain vulnerable at the point-of-sale (POS) level. Some new solutions are leveraging blockchain-based solutions to ensure security on the open internet.
     
  • Customer experience. A scheme should enable the best possible experience for its participants’ customers. This means having a superior user interface as well as simplified ways to address payments, such as through phone numbers (e.g., as they are used in schemes like Pesalink in Kenya) or personalized addresses (e.g., like what is used in the Unified Payments Interface in India).
     
  • Dispute management support. Customer redress and dispute management rules are likely to be written into scheme governance, but technology must help to implement these rules. Dispute management becomes more complex when cash moves between systems. Poor design can result in a customer having the same funds available to spend in both systems. One feature that can help prevent the errors leading to customer redress is to allow customers the ability to see the recipient’s name before finalizing the transaction, as evidenced by Safaricom’s Hakikisha feature, which allows the sender to temporarily view the recipient name before the transaction becomes irrevocable.
     
  • Interchange fee calculation and experimentation. Unless technology automatically implements scheme interchange agreements, fee calculations will be managed offline and they are likely to be labor intensive. A central engine for managing calculations can help facilitate the process and better allow for changes to terms.
     
  • Reconciliations support. Solutions should minimize issues and promote automated reconciliations between systems. Revenue assurance and compliance/audit functions will always require evidence of transactions, but the right technology can make the process easier and more cost efficient.
     
  • Anti-money laundering regulatory compliance and suspicious activity monitoring. Participants in a scheme are typically required to perform regulatory compliance activities, and those requirements mean additional investment in systems. However, shared systems for fraud monitoring can provide a more efficient service with a better pool of information.
     
  • Developer support systems. Developer APIs are becoming a "must have" for any payment service. Generally, either a central service provides an API for all scheme members and manages the routing on their behalf, or API support is considered a competitive developer user experience offering, and the digital financial services provider gives access to all customers via scheme interoperability. The recently announced Bill & Melinda Gates Foundation Mojaloop code repository demonstrates how payments could be implemented to be interoperable in a mobile money scheme, giving those businesses access to the full network of customers by integrating once rather than one by one.

Finally, effective technical solutions must have equally effective business processes to support them. The most sophisticated fraud-monitoring technology in the world will not save a provider who has no one reading the report. In turn, business processes are most efficient when they use good business support technology. Even getting access to the data necessary to support analysis can often be labor intensive.  

Connecting participants is necessary, but not sufficient, for achieving interoperability. Beyond the governance and business rules needed to make schemes work, technology must do more than get passengers from one place to another. It must protect and encourage the behaviors that allow an interoperable scheme to succeed. Especially for a new interoperable service, one failed transaction or bad experience can cause a customer to not come back a second time.

Add new comment