APIs are often viewed as potential solutions for traditional financial institutions, particularly small and midsize banks, to partner with upstart financial technology companies (fintechs) to offer innovate products, especially to low-income customers. In practice, however, due to the maturity of the fintech market, fear of losing competitive advantage, and a variety of strategic errors in planning for and developing APIs, smaller banks and fintechs do not often succeed in deploying API solutions for inclusive finance.
In this report, based on nearly two dozen interviews with leaders at fintech companies, small and midsize banks, and large financial institutions, CFI examines the extent to which APIs are meeting their potential to facilitate bank and fintech partnerships that advance financial inclusion. The report breaks down what API integrations between banks and fintechs look like and how typical deployments work, and offers four recommendations for how to improve API deployments between banks and fintechs to deliver financial services to underserved communities.
A Typology of APIs
It is useful for leaders at financial institutions to understand the types of APIs common in financial services. For examples, in API aggregator and platform models shown below, a third-party provides APIs on behalf of financial institutions to institutional customers (e.g., fintechs) in its network. The aggregator or platform may also provide sales, marketing, onboarding and other services. We also explore open and private API models in the report.
API Aggregator and Platform Models
API Deployment Recommendations
This research suggests that successful API deployments in inclusive finance depend on how well API managers can execute the following recommendations:
Financial institutions that successfully offer APIs take a user-centered approach to API development and delivery. They pay careful attention to the use cases for which APIs are
being developed and specify the intended users. In other words, they articulate a clear business case for the API.
Guiding Questions:
- What are the key use cases that our clients are likely to have and how can we support them?
- What does the end-to-end customer journey (e.g., discovery, trial, onboarding and
technical integration, continued use, and support) look like? - How can we maintain, enhance and continue to add new features and functionality to the product over time?
Just as an API needs a user-centered use case to exist, so does a firm’s technology strategy. In other words, financial institutions need to have a clear business case for how investments in the “right” technology will help them serve their customers. For banks moving from mostly analog or archaic technical systems, their investment in a “digital transformation” is especially important as it will form the foundation of their offerings in
the near term.
Guiding Questions:
- Where are existing customers or internal products using existing middleware layers
and systems? - Can middleware layers be turned into APIs utilized by fintechs or other third parties?
- Are middleware layers accessed by third parties? Do they do so on a repeated basis? If so, how can we design these connection points for repeatable access?
- How will a typical fintech customer want to consume our APIs? What functionality and documentation will they expect? How will they discover and access this functionality?
- What is the most valuable minimum viable API product we can launch? How can we work with fintechs and developers to iterate and build out more use cases?
It is uncommon for financial institutions to have experience with the world of fintechs, developers, and integrators. This misalignment of skills makes executing an API difficult. Consequently, many financial institutions with an API (or ambitions for one) aspire to create a more agile, innovative culture to help execute these solutions more efficiently.
Creating this culture is not as simple as staffing the right people, although that is
important. It must be accompanied by the right management structure and lines of
responsibility. A cultural shift to a more open, adaptive approach is also needed. APIs often cut across traditional business lines and internal departments within a bank and removing overly cumbersome processes and decision-making barriers is critical.
- What skills do we have/need to build, sell and support APIs?
- Should we outsource API development and, if so, which parts?
- How do we find good tech talent and create an agile technology culture?
- Who has final responsibility for driving the success of the product? What are their
success metrics and incentives? What are the constraints on their ability to make key decisions and determine their own destiny?
Regulators are rightly concerned with systemic risks in the market and are thus cautious with innovative products, like those enabled by APIs. Many banks and fintechs start on the path to develop partnerships and launch products without sufficiently bringing the regulator on board. This often leads to sudden stoppage in product launches. Engaging with regulators early and staying on top of the evolving fintech regulatory framework in the country is a critical missing link in many of the partnerships studied for this report.
Developing a regulatory strategy and building checkpoints into the product roadmap early on is strongly recommended. A key issue is timing. Some managers wished they had done this earlier in the product development process, before investing in something that needed to be rethought later. In other cases, going to a regulator too soon was seen to cause problems, particularly if the regulator is forced to react to an undefined solution or wants excessive input into the design and launch of the product.
Guiding Questions:
- How do we typically engage with the regulators around any new product or service?
- When should we look at the regulatory implications of the API product?
- How do we ensure compliance by API customers when their systems are at arm’s length from ours?
This work was made possible with support from FMO Entrepreneurial Development Bank.
Authors
