Generally speaking, financial institutions offering APIs utilize one of three methods:
1) Open APIs
Open APIs are designed for general, repeatable use and openly accessible to third parties.
Twilio and Turn are open APIs for communication. Open APIs offer access to functional systems and, ideally can be accessed purely online, with no human interaction. To encourage uptake of open APIs, providers often offer free sandbox testing or freemium pricing allowing developers to start using the service free to get a sense of how the APIs function and whether they work with the developers’ products. Readily available documentation, standardized onboarding and KYC documentation processes, sandboxes and other aspects of the delivery in open APIs are designed for repeatability.
Open APIs are designed for general, repeatable use and openly accessible to third parties.
A financial institution planning to offer open APIs embarks on a journey that can require significant upfront investment of time and resources and may come with some risk. This is especially true when converting from complex legacy IT and core banking systems which were not initially designed to be accessed via API. Moreover, there are often significant security requirements and regulatory hurdles that must be considered.
Despite these barriers, more and more financial service providers are opening APIs. MTN Uganda invested $400,000 to open their mobile money API. Equity Bank in Kenya has invested upwards of $10 million in Finserve – a subsidiary to offer a suite of open transactional, KYC and account APIs – and NedBank in South Africa invested over $138 million to incorporate APIs as part of a massive technology overhaul across the bank. Justifying the investment, long run benefits can include higher deposits, transaction volumes and revenue, resulting from an ecosystem of partners who also benefit from lower costs of integration and better service delivery through open infrastructure.
2) Private APIs
Private APIs are created to grant access to a specific party or parties.
Private APIs are designed to enable financial institutions to allow specific internal or external, pre-authorized parties access to certain functionality, based on predetermined requirements. Often, a discreet business or use case dictates the development of a private API and, consequently, the major distinguishing feature of private APIs is a lack of repeatability.
Private APIs are created to grant access to a specific party or parties.
An example comes from Xendit, a payment processor in Indonesia, which was founded to build the “Venmo for Indonesia.” After succeeding with peer-to-peer payments, Xendit saw demand for customer-to-bank transfers. Xendit collaborated with a mid-sized bank which, as a regulated financial institution, can process payments to any other bank in Indonesia. The bank partner developed a transactional API for Xendit that enables the service to make instant transfers to any bank in Indonesia from an escrow account held by Xendit at the bank. On that foundation, Xendit built an expanded set of products, including payroll payments and invoices, has successfully onboarded a large number of customers, and built a viable business. For the partner bank, the Xendit relationship has significantly increased its total deposits.
3) API Marketplaces
API marketplaces are offered by third parties to other third parties.
API marketplaces are also operated by third parties, and offer APIs on behalf of any number financial institutions. API marketplaces aggregate documentation, KYC, and onboarding processes and try to get a critical mass of fintech innovators actively looking to develop solutions with participating financial institutions. By spreading the costs of constructing APIs among a larger number of participating FIs, marketplaces can lower the costs for participants. Examples of API marketplaces include FinConecta, a global API marketplace, and the APIX exchange launched in the ASEAN region.
API marketplaces offered by third parties to other third parties.
The resources available and business goals tend to determine the delivery model chosen by a financial institution. Internally-owned, open APIs offer financial institutions the greatest flexibility to build a suite of API-based products that can enable a successful innovation ecosystem, but they require significant investments in technology and people to sell and support. In some cases, there may not be a need, or resources available, to open APIs, and a private API will suffice to work with a partner. Private APIs still requires technical development and internal capacity to build and sell.
API marketplaces, on the other hand, reduce the need to redo internal business structures and add internal capacity. However, initial interviews for my research indicate that given the lack of ownership over success metrics, in addition to regulatory barriers, more effort may be required to make these successful. I will investigate this in more detail as my research proceeds.