Open APIs in Digital Finance: We Opened Up, Here’s What Happened
Open APIs have a lot of potential for payments providers looking to grow, as explained by Michel Hanouch and Xavier Faz in their recent blog posts, but many providers may be wondering whether going open is actually worth the risks. At Eko India Financial Services, we made the decision to go open in 2016. Our experience so far has convinced us that open APIs hold a lot of potential, not only for us, but likely for FSPs in many developing countries.
In the Indian context, Eko India Financial Services is a small money transfer business. We enable over 18 million customers, primarily low- and middle-income migrants, to send money home on a monthly basis. We do this through a network of more than 15,000 agents that facilitate money transfers to over 450 million banks accounts. Currently, these agents are concentrated in and around Delhi, Mumbai and five other big cities in India.
Photo credit: Simone D. McCourtie / World Bank
With an adult population in India of over 850 million people, we clearly have a lot of room for growth. We have designed our transaction processing system, SimpliBank, to handle significantly more scale than we are able to reach on our own. As a relatively small business, however, we have found it difficult to expand across all 35 states and union territories in the country. India’s 22 constitutionally recognized languages, hundreds of dialects, and many cultures are often grouped into different regions. This can make regional expansion feel more like an attempt to expand into different countries rather than different states.
We made the decision to open our APIs to third-party developers in an attempt to grow our business across these states. We were confident in our ability to deliver our core services to our core segments in our core geographies. But we were realistic about the fact that we cannot be all things to all people. So we let other providers — sometimes competitors — leverage our systems and regulatory expertise to develop their own apps that can, among other things, create a digital wallet and enable cash-in, instant P2P transfers, and merchant payments.
As things stand, third parties are able to develop their own apps and required functionality within our test environment (i.e., sandbox), without any paperwork or much interaction with our team. That way we can get out of the way and allow innovation to happen without creating bottlenecks. It is only when third parties are happy with their creations, and believe they have something worth taking to market, that we require them to get in touch and jump a few hurdles (including some paperwork, which we are still trying to minimize).
So what has happened since then? We are still early in our journey, with our APIs still running in beta, but already we have 65 active developers using our APIs. Through these partners, who bring a better understanding of the diverse needs and cultures of other regions than we could on our own, we have now managed to reach customers in every state and union territory across India. Our margin per transaction is lower; however, these transactions now contribute 50 percent of our total volumes monthly — and that number is growing. Open APIs have been good for business and enabled us to indirectly reach people that may otherwise have limited or no access to financial services.
Like any new product, which is how we treat our APIs, there are risks involved. We decided to make the entry barrier to accessing our APIs as low as realistically possible without jeopardizing our regulatory commitments, such as know-your-customer and consumer protection requirements. Beyond these, we do much of our risk management ex post by monitoring our systems and keeping a close eye on what third parties are enabling on them. We can then build flags that help us to manage and control any undesirable use of our system as close to real time as possible.
There is also the risk that third parties will target our core regions and customer segments (i.e., cannibalize our core business), resulting in a decrease in direct volumes on our platform. This is something we have grappled with internally, but ultimately we decided to let this cannibalization occur on our systems, where we can monitor it and understand it. We have not yet thoroughly mined or extracted the full value from this new source of data, but we believe the data will eventually help us to better understand (and respond to) our weaknesses and take advantage of new opportunities in the market. To date, our expansion into new segments, new value propositions and new geographies has exceeded cannibalization.
Of course, this is something we will continue to monitor closely, and we will adapt our approach should the need arise. Over time, we expect to refine the optimal balance between delivering products and services directly to customers, delivering via close partnerships, and enabling third parties to innovate over our platform through our APIs. Our API journey is just beginning, but our experience so far has convinced me that open APIs can be good for business and enable the jolt of innovation needed to reach poor people with better financial services.