Digital Rails

How Providers Can Unlock

Innovation in DFS Ecosystems
Through Open APIs

Olga Morawczynski
Lesley-Ann Vaughan
Michel Hanouch
Xavier Faz
November 2016

a
 This document explains the concept of
“Open APIs” in digital finance services
(DFS), how they enable increased innovation,
and the role they can play in expanding
DFS ecosystems.

b
 YOU
1. State of DFS today 2 ARE
HERE

2. How APIs catalyze 9

innovation

3. Transitioning toward 20
open APIs

4. Implementing 26
open APIs

1
 1. State of DFS today

This section outlines the state of the DFS

industry today, including the key reasons
for the limited range of new solutions
emerging that leverage the DFS “rails”.

YOU
ARE
HERE

2
The DFS industry continues to evolve steadily.
However, high rates of inactivity and only a
few use cases continue to dominate.

TODAY, THERE ARE . . .

271live mobile
IN
93 countries
AND
411
million registered
money services accounts

DESPITE THIS IMPRESSIVE PROGRESS

• Only 33% of these registered accounts are actively used (at least once in 90 days).

• While active customers transact around 11 times per month on average, 66% of
transactions are airtime top-ups.*

• Person-to-person transfers make up almost 72% of the total value of transactions.*

Source: GSMA, “2015 State of the Industry Report, Mobile Money”

* December 2015

3
 Industry growth is primarily characterized by more
customers rather than more transactions per customer.

These figures make clear that the DFS industry is facing a critical challenge—growth to date
has been primarily extensive (number of customers increases) rather than intensive (number
of transactions per customer goes up).

Extensive growth is problematic because markets eventually reach a saturation point. As a

result, customers don’t realize the potential benefits of financial inclusion, and the revenue
potential for providers is curtailed.

Multiple innovative solutions targeting niche segments are required to entice customers
to transact more. If things remain as they are, low-income customers will likely continue to
favor informal solutions to address the majority of their financial challenges.

INTENSIVE GROWTH
number of transactions
per customers Desired

Actual

EXTENSIVE GROWTH
number of customers

4
Digital payments providers are limited in their
ability to deliver multiple new and meaningful
solutions for several reasons:

Digital payments providers typically rely on their core platform

vendors for elements of the product development process. This
increases the cost and time to innovate, and limits their ability to
innovate in multiple directions at the same time.

Digital payments providers need to invest significant resources

in core operations (the platform, agent network, marketing, etc.)
and often have only limited resources dedicated to innovation.
These resources are focused on solutions that appeal to the
majority of customers. More targeted, niche solutions are not
the focus of internal innovation.

Mobile network operators (MNOs) and other non-bank

providers are not licensed to directly offer solutions that
incorporate credit, savings, or insurance elements. This means,
in the absence of partnerships, innovative solutions produced
by these providers have little potential to advance inclusion
beyond payments innovation.

Recent gains in digital financial inclusion have mostly been

driven by non-banks. Even when banks create or have access to
large-scale digital payments platforms, low-income customers
are often not a priority. Banks have the capacity to produce a
broader range of financial solutions beyond payments; however,
they are often risk averse and weighed down by compliance costs.
Further, in many developing countries, banks have alternative
sources of growth, either through expanding in the middle-income
segment of the market or funding the public sector through
government bonds.

5
 Smaller third parties who could contribute to the
innovation effort are effectively excluded from
the DFS ecosystem.

Third parties (e.g., FinTechs, start-ups, developers, digital banks) could bring disruptive
solutions to market through a more agile development cycle, better knowledge of niche
market segments, new technology, lower costs, and leveraging of synergies with their own
core business. However, they do not have direct access to the “digital rails” of large-scale
payments providers. For example, this includes the ability to make and receive payments,
leverage agent networks, or access customer data (with consent).

Recent CGAP research in Kenya showed that smaller third parties (e.g., developers and
start-ups) are often deprioritized from access and are most likely to have high costs, long
delays, and lack of transparency when trying to connect to digital payments providers.
Neither the process nor commercials are typically standardized.

START-UPS DEVELOPERS

DFS
SYSTEMS START-UPS
DEVELOPERS

FINTECHS

6
There are success cases involving third
parties, but these are exceptions.

Innovative solutions requiring deeper integration with third parties

have come to life in certain markets (e.g., M-Kopa and M-Shwari),
but digital payments providers often prioritize access to larger third
parties (e.g., banks and large bill pay receivers), companies with
prospective large volumes of transactions and revenues for providers,
and third parties that have existing relationships with digital payments
providers.

BANKS
BILL PAY
DIGITAL
RECEIVERS
PAYMENT
PROVIDERS

THIRD-
PARTY
FINTECH

THIRD-
PARTY
DEVELOPER

7
 Aggregators have developed in most markets
to facilitate payments integration, but they
add costs to the business model.

Several MNOs that offer mobile money, especially in East Africa, have formed exclu-
sivity agreements with aggregators to handle integration and solutions development
efforts. These partnerships have enabled the roll out of several solutions, including bill
and bulk pay, retail payments, and payments across networks. They have connected
sometimes hundreds of third parties to the payments service. Aggregators are particu-
larly useful for third parties that limited technological capabilities.

However, aggregators have one fundamental disadvantage: they introduce addi-

tional fees that make the end-to-end transaction expensive for smaller third-party
developers.

Aggregators raise the per transaction cost paid by third parties integrating into
the payments platform because revenue needs to be split between the aggregator
and the digital payments provider. Thus, even with aggregators, many third-party
developers continue to be excluded from the DFS ecosystem.

Open APIs (application programming interfaces) could enable third parties to

leverage the digital “rails” of payment providers to unlock innovation.

Third-party entities
Payment instrument (e.g., donor, business,
provider (e.g., or government)
MNO or bank)

Aggregators can be the “glue” of the

DFS ecosystem, allowing third-parties
to integrate with payment providers to
leverage the payment “rails.”

Source: CGAP

8
2. How APIs catalyze
innovation

This section defines APIs in the context

of DFS, and elaborates on the role that
more open APIs can play in catalyzing
the expansion of the DFS ecosystem.

9
 What is an API?

An Application Programming Interface (API) “is an architecture that makes it easy for
one application to 'consume' capabilities or data from another application” (Apigee). It
is a contract that allows software programs to “talk” to one another, defining what
information should be supplied and what actions will be taken when it is executed.

APIs can fall along a spectrum from internal APIs that are reserved for use by develop-
ers working within, or on behalf of, the organization only, to partner APIs that are made
available to select partners only, to open APIs that are more broadly available.

Open APIs are not new. As early as the year 2000 leaders in this field, such as
Salesforce and eBay, were exploring more open APIs. eBay initially opened APIs to
select partners and developers to “standardize how applications integrated with eBay,
and make it easier for partners and developers to build a business around the
eBay ecosystem” (API Evangelist).

Today, businesses increasingly rely on partner and open APIs from other businesses to
design innovative products and services that might not otherwise be possible. These
businesses are often providers and consumers of APIs.

3rd Parties 3rd Parties 3rd Parties 3rd Parties

101001101 101001101
101001010 101001010
110101101 110101101
101011010 101011010

LinkedIn Facebook
4 1

Uber
Google
Maps

3rd Parties
101001101
101001010
110101101
101011010

3rd Parties

3rd Parties 3rd Parties

101001101 101001101
101001010 101001010
110101101 110101101
101011010 101011010

Source: Apigee; API Evangelist

10
Most of us use APIs every day.

Without APIs, posting to Facebook would . . . and Uber would need to develop its own
not be as seamless . . . mapping and payments capabilities.

Action

Driver queries Customer

shortest route pays for
for customer the trip

API Mapping Payments

Accessed Services integration
service

API Google Maps/ Braintree

Owner Waze

11
 In DFS, third parties that can seamlessly connect to
established payments platforms can drive multiple services
that collectively address the needs of many customers.

Within the DFS ecosystem, a range of third parties can play an active role in
identifying unmet needs of customers and creating powerful niche solutions to
meet those needs.

These solutions rely on APIs from digital payments providers. However, innovative
third-parties can also weave together a range of APIs from different players to
enhance the functionality and attractiveness of solutions—financial and beyond.

Payments providers can continue to innovate internally, developing and delivering

solutions directly to customers, including by consuming APIs of others. At the same
time, they “productize” their APIs, competing on the type of assets they make
available to third parties (new APIs) and how easily accessible those assets are
(how open). Innovation is driven internally, through strategic partners and through
third parties leveraging open APIs.

12
DFS APIs fall into three main categories:
Consent, payment,and data.

Consent APIs are the foundational layer of

APIs that enable third parties to call both data
or payment APIs for consenting account holders.
These APIs authenticate the account holder
and consent (authorize) the third party to gain
access to certain assets for that account holder.
It is through consent APIs that customers give
third parties permission to access their data or
to move their money. Consent APIs enable
customers to include parameters on permission
(to do/access what, for how long, how many
times, etc.).

Payment APIs facilitate the transfer of digital

value from one place to another. These APIs
enable a variety of use cases from bill payments
to bulk payments, merchant payments, and
online payments. These are the most frequently
released APIs within DFS.

Data access APIs enable third parties to access

data on customers, agents, and even merchants
to build out their solutions. Types of data released
by digital payments providers can include
customer transactions, liquidity levels of agents,
and geolocational data for account holders.
Some data APIs will be aggregated data;
some will be anonymized data.

13
 Third parties can create some powerful solutions
when consuming these APIs.

Imagine a solution that could . . .

Help customers to save by auto-deducting a small

amount from their wallets and transferring that
value to a separate savings wallet or bank account.
Customers could have a visual representation of
how much they saved to date (e.g., half of a cow,
one-tenth of a house). Solution powered by: data,
payment, and consent APIs.

Help retail agents manage their cash float, by

leveraging an Uber-like cash-in and cash-out
facilitation platform. Customers could make
surplus money “work” by responding to agent
cash deficits for a fee. Solution powered by: data,
payment, and consent APIs, as well as location APIs.

Let merchant aggregators enable their merchants

to offer their customers loans for in-store purchases.
Solution powered by: data, payment, and consent
APIs (complemented by non-DFS APIs, for exam-
ple, to enable repayment reminders).

14
These powerful solutions can extend
well beyond finance.
FINANCE
Real-time credit score (incorporates data from all my financial services)

EDUCATION
School savings scheme and loan top-up (credit); monitor performance and attendance

BASIC SERVICES
Manage monthly water usage and payment; prepurchase solar credits and manage
daily/weekly plans

BUSINESS AND TRADE

Manage stock or other inputs; manage goal-savings plan for personal and
business—help buy a house, bike, or cow

SOCIAL COMMITMENTS
Asking for and making social contributions; lending to and borrowing from
social network

15
 Multiple types of developers are well-positioned to
consume DFS APIs and offer innovative solutions
for the poor.

Type of Developer Example

Aggregators, master/super agents, Kopo Kopo, wanting to make a

payment gateways (supportive better merchant experience to recruit
ecosystem players) more merchants

Banks and other financial institutions KCB and CBA offer loans and savings
accounts leveraging Safaricom data
and payment capabilities

Businesses and start-ups with M-KOPA selling pay-as-you-go solar

complementary technical electricity
capabilities

Independent developers, M-LEDGER spotting a missing user-

FinTech disruptors, app experience opportunity and creating
developers an android app that was later
acquired by Safaricom

International businesses Uber wanting to enable a frictionless

experience for mobile money
account holders, as it has for card
customers

In-house innovation Customer care wanting to help

customers with the SIM swap process
(by informing the customer of
progress through SMS updates)

16
All APIs are not equal: Businesses exposing APIs
can choose which APIs to expose, to whom, and
under what terms.

One of the challenges to open APIs is that providers are often concerned about
risks open APIs may expose them to and do not know how to mitigate these risks.

An API provisioning platform helps a business to selectively launch APIs—some

APIs could be reserved for strategic partners only, while others could be opened
more widely. All are provided through the same mechanism.

Better understanding their API options and the functionality that leading API
platforms offer can help businesses mitigate risks and capture the benefits of
becoming more open.

CLOSED OPEN

Source: APIgee

17
 The strategy toward API openness can evolve over time.

APIs can start focused on internal clients and become open over time.
Conversely, APIs can be closed after initially being open.

CLOSED OPEN

INTERNAL
Benefit: Agility
Selected organizational assets are open to use by developers working within,
or on behalf of, the organization. This can improve time-to-market for certain
internal innovations.

PARTNER
Benefit: Collaboration
Selected organizational assets are open to use by a chosen set of partners only.
As new APIs are designed, the digital payments provider can decide the right
developer segment that should be eligible for access. For example, any APIs
that require a user PIN as a parameter would have to go through an extensive
verification processes.

OPEN
Benefit: Innovation
Selected organizational assets are open to use by outside developers who register
for access. To reach the long tail of developers, these open APIs need to offer self-
service access. It is critical to proactively “watch and learn” from the API traffic, to
understand usage, manage risk, and design appropriate controls, as well as to
support decisions on API roadmaps.

Source: APIgee

18
 APIs don’t have to remain in any particular category:
Netflix managed to generate impressive revenue by
focusing on its internal and partner APIs after
reviewing its API traffic.

Netflix started with an open API strategy, but a few years after launch, it found
that the majority of its traffic was coming from a small set of partners and from
internal API usage. So the company decided to prioritize energy appropriately
and stopped allowing mass access to its platform.

INTERNAL PARTNER OPEN

Netflix is available on over 1,000 different device types today because its well-
developed internal API offers a standardized interface that allows engineering
teams at Netflix to work on onboarding new devices in parallel. Its internal
API receives over 5 billion calls a day, 97.7% of total traffic.

19
 3. Transitioning toward
Open APIs

This section explores some of the reasons why

a digital payments provider would transition
toward openness, notes some of their concerns
with opening up, and considers some of the
workarounds third parties pursue in the
absence of openness.

20
Businesses might open APIs for a number of reasons.

Broadly speaking, any digital payments provider that is launching an API program
will be aiming to achieve one or more of the following business goals:

REVENUES
Grow revenue through customer acquisition, more
$$$$$ revenue per customer, and monetization of assets
previously unavailable to third parties

REACH
Connect with more customers directly and indirectly

ENGAGEMENT
Create a more engaged developer community
APIs to help build the DFS ecosystem, improve
customer satisfaction, and reduce churn

INNOVATION
Accelerate delivery of new innovations, products,
and services

INTEGRATION
Increase speed and lower cost of integration
with partners; expand the number of integrations

Source: http://www.apiacademy.co/

21
 In DFS, open APIs can drive the ecosystem expansion—
more solutions, more usage, more revenue.

APIs turn digital payments providers into APIs can lead to important revenue
“rails” for a broad range of applications. streams plus strategic positioning at
the center of the ecosystem for digital
• Payments providers’ resources are no
payments providers.
longer a binding constraint to innovation.
Third parties invest in parallel, leveraging • A range of third-party solutions, address-
their different assets and skills to develop ing an array of consumer pain points,
solutions that complement those of can increase the number of customers
payments providers. and the number of transactions per
customer. The combination can quickly
• APIs facilitate both internal and external
build transactional volume.
solutions development. Payments
providers continue to innovate in parallel, • A new type of customer is added—third
and remain in control of which assets are parties that consume DFS APIs. This
made available and to whom. generates direct and indirect revenue
opportunities.
• The rate of development can be higher.
Numerous innovations can be developed Systems integration time is cut
in parallel. Innovations can create new significantly with well-designed APIs.
customer-facing solutions, better custom-
• This increases the possible number of
er experience for existing solutions, and
partner integrations that providers can
enhanced reach via ecosystem players,
complete annually, leading to significant
for example, through improved agent/
cost efficiencies per integration and
merchant experiences.
increased payment and data revenues.

22
 The Walgreens experience demonstrates how opening
strategic APIs can boost revenues from existing
products and services.

Walgreens made the strategic decision to open its photo printing and pharmacy solu-
tions to the outside world via APIs. A large number of developers responded and
created immensely popular applications such as Printicular, which allows users to print
photos directly from Facebook, Instagram, or Dropbox. Walgreens managed to enroll
200 partners and attract 65 million unique users per month via its APIs.

INTERNAL PARTNER OPEN

Walgreens was able to enhance overall customer engagement with its retail
stores: Those customers who interacted with Walgreens both via web/mobile
devices and in-store were generating six times more revenue than those
who just shopped at the stores.

Source: Harvard Business Review and APIgee

23
 However, some digital payments providers have
expressed concerns in progressing toward openness.

Cannibalization of revenue: Some provid- Consumer protection/fraud risk: Providers

ers are concerned that opening up their are concerned about the risk of more open
platforms could lead to cannibalization of API structures, specifically as they relate to
their products (existing and those in the accessing and sharing confidential custom-
pipeline). er information. They also want to better
assess and determine how to mitigate the
Digital payments providers need
risk of fraud, specifically by those accessing
to holistically evaluate the potential
the payments platform in new ways.
impact of enabling external
innovation. In certain cases, some This is where well-managed
cannibalization can be offset by customer consent APIs become
substantial increments in the number critical—putting customers in
of customers and transactions per control of their money and their data.
customer, or through other levers.
Internal conflicts: Champions within digital
Reputational risk: Digital payments provid- payments providers trying to pitch open
ers are still uncertain whether developers API structures to decision makers face a
have the capacity to deliver products that fundamental challenge—the requirement
will scale and not operate to the detriment for immediate and high returns for any new
of the payments provider’s brand and business case makes investment required
consumer trust. for open APIs a hard sell. Because of the
lack of clarity on the business case, few
Payments providers will need
providers have a clear strategy for open
to manage the way third parties
APIs at a group level or dedicated local
present their solutions and use
leadership to implement the strategy.
the payments provider’s brand.
Successful DFS open API demon-
stration cases should gradually
address this reluctance.

24
Remaining closed is an option, but increasingly, third
parties are able to find suboptimal workarounds to
access valuable assets; the proliferation of smartphones
will make this easier.

Examples of workarounds, also known as “Generation 1” APIs:

• Shared pay bill accounts, with funds ownership managed by aggregators.

• Automated login and activities to work around onerous processes.

Smart phones’ operating system flexibility can work against digital

payments provider intentions:

• Robots can be designed to automate arduous tasks.

• SMSs can be “scraped” to reconstruct a data feed.

The workarounds simply mean there is a problem that is not currently being
solved well.

Innovation happens outside the digital payments provider domain to solve

that need.

THE CONSEQUENCES OF WORKAROUNDS

TECHNICAL PROBLEMS
• Robots plus scale equal a very poorly performing system for the rest of
the network.

DATA LOSS
• Loss of data to aggregators could harm future innovations for the digital
payments provider.
• Potential AML/CFT issues arise from account-sharing models.

OVER-THE-TOP (OTT) PLAYERS GAIN MARKET SHARE

• Innovation can occur “around” digital payments providers.
• OTT players like Branch (branch.co) and Tala (tala.co) in Kenya can leverage
smartphone capabilities to deliver OTT solutions.

25
 4. Implementing
Open APIs

This last section highlights some of the core

elements of an open API effort that digital
payments providers would need to consider
when transitioning toward openness.

YOU
ARE
HERE

26
Payments providers transitioning toward openness
will need a mindset shift from developing end solutions
only for users, to also treating third-parties as customers,
who in turn deliver innovative end solutions.

Many businesses might start experimenting by opening a core set of assets to

developers via APIs, either in response to latent demand for these assets or to
gauge whether there is enough interest in consuming them.

Eventually, APIs will need to be not just exposed ad hoc but strategically
“productized,” monetized, and operationalized.

“APIs cannot just be turned on. You need a clear strategy

for their growth. You need to test them, and you need to
carefully feed them and try different approaches to make
them bloom and flourish.”

—John Musser, API expert

27
 The East Africa experience highlights some of the
challenges third parties experience when trying to
access and consume APIs.

Developers are offered a very limited set of payment APIs.

There is a latent demand for “beyond payment” APIs to
? ? ? facilitate a broader array of solutions. For example, some devel-
opers express the need for authentication APIs to
? ? ? facilitate in-app payments, while others want to consume
data APIs and leverage consumer, agent, and geolocation
data for purposes of innovation.

The commercial model for accessing core APIs is not transpar-

ent to third parties. In some cases, this results in price discrimi-
nation based on opaque criteria, such as who a third-party
developer knows within the payments provider.

</>(){}; There is a lack of easy-to-read and easy-to-navigate API

=var documentation, helper libraries, and online communities for
developers to support each other in the integration process.

Providers typically do not offer a sandbox test environment

to allow developers to experiment with the API before
launching the solution. This limits the ability of providers to
test and effectively tweak solutions before launch and increases
error rates of those solutions.

101100101 APIs often leverage legacy technologies for API definition

and security protocols. While relatively common within the
010110001 financial services industry, these technologies are considered
100010101 “heavy” and “outdated” when compared to simplified modern

110101101 protocols. Developers often find workarounds to this pain point

that may potentially lead to other problems.

28
To address these and other challenges, the following
core elements must be developed as part of an effort
to launch open APIs.

A clear strategy for open API implementation that has buy-in from
A B senior management and is aligned to the business strategy. It
should make clear the business rationale for opening priority APIs.

A business structure that supports implementation, provides

ongoing support to external developers, and manages the API,
including critical roles such as API product management and a
community engagement manager to ensure that developers can
easily link into and derive value from the platform. The business
structure also needs to address the legal and commercial require-
ments of more open APIs.

A sandbox test environment where developers can test

APIs and observe the results quickly before they hit a live
environment.

A well-designed developers portal that provides a one-stop shop

for API onboarding, documentation, exploration, collaboration,
</>(){}; discussion, support, and more. A good portal is important to attract
=var
and retain a critical mass of developers. The portal should detail
available APIs and clearly explain to outsiders what to expect so
that they can develop and deliver solutions easily. Ideally, the
developers portal should enable developer self-service.

An online collaborative space to inspire developers, communi-

cate roadmap thinking, and receive feedback. Initially, this
needs to be “manned”; however, the vision would be that
the community can support each other’s queries over time.

continued

29
 To address these and other challenges . . .
(continued)

A self-service mindset, including developer onboarding,

and transparent and standardized commercials and contracts.
This should include clear service-level agreements around
response and resolution times.

A developer community engagement strategy that includes

social ways to educate and incentivize active developer
consumption of APIs. Hackathons are one option to engage
developers and get them more familiar with available APIs.
Developer challenges can be explored to incentivize more
polished solutions. Developers may also benefit from mentorship
or marketing support. Digital payments providers should also
listen to, and incorporate, developer input and feedback.

An ability to learn from best practice and leverage existing

initiatives. Most notably, GSMA is developing harmonized
API definitions for commodity payment APIs, such as bulk
payments, bill payments, and bank-wallet transfers, among
others. Digital payments providers should look to leverage
these where appropriate. Further, payments providers should
leverage best practice from other sectors for authentication and
authorization security, with the “long tail” and cost in mind.

A roadmap that looks beyond commodity APIs and pushes

the API boundaries. Third-party innovation will benefit from
access to a broader set of DFS assets and capabilities, moving
beyond basic payments, and including data and location, for
example. The roadmap should ideally draw from developer
input.

Source: GSMA Mobile Money APIs available at https://mmapi.gsma.com/

30
Final thoughts

The transition toward open APIs has potential to lower costs, increase efficiency, and
most importantly from an ecosystem perspective, expand the breadth of innovative
solutions to which DFS customers have access. CGAP posits that this transition
toward openness, and the ability of third parties to leverage digital payments
providers’ (and other) assets, is a critical step in growing the DFS ecosystem, and
with it key metrics, such as number of active customers, number of transactions per
customer, and overall industry revenue.

Two things are needed for this shift to be realized:

1. Exposure of a greater range of APIs. APIs should facilitate more than just
payment solutions; allowing third parties to effectively access a range of business
assets to create solutions—financial and other—that add real value to the lives of
customers.

2. More openness. This includes the creation of infrastructure and a self-service

environment that allow a broader range of third parties to consume valuable
business assets safely and effectively.

The key to this is a mindset shift, with the digital payments providers moving from
end-to-end customer ownership to owner/provider of modern “rails” to facilitate
industry innovation in a way where governance is maintained and risk management
and consumers are protected.

31
Consultative Group to Assist the Poor
1818 H Street, N.W., MSN IS7-700
Washington, DC 20433 USA
Phone: +1 202 473 9594
www.cgap.org