"For developers it is much more practical to go to one place and get access to all services from one provider"
By, Victor Zhiltsov – Senior Director, Visa Developer Platform
Summary
In my last blog post, I outlined the reasons why Open APIs are essential for innovation in the financial services industry. This post, discusses the fragmented nature of Open APIs and ways in which developers can bridge the gap between API portals.
Innovation Race is On
The innovation race is on in the financial services industry and it has manifested itself through the proliferation of Open API portals. Networks, processors and banks launch developer portals and invite all developers to explore Open APIs to build their own rendition of the next killer app. A typical digital strategy of an issuing bank involves two :
- creating a consumer-facing banking app
- offering a suite of financial services to developer’s via Open APIs
The former is done to maintain the relationship of the bank to the consumer and the latter is done to ensure the bank can keep up with Fintech innovations. Open APIs for financial services create a tremendous opportunity, but developers also realize each developer portal typically addresses a relatively narrow set of services, which by itself is not enough to create something truly innovative.
API Mash-ups
A newly launched developer portal usually exposes APIs for services which the underlying company already does well. For example, the developer portal of an issuing bank will list APIs for services like checking consumer profiles, account balances, transaction histories, etc. Whereas, a payment processing gateway may publish APIs for services related to payments, which include processing payment authorizations, captures and chargebacks. While having open access to these services is convenient, each set by itself can only serve to re-create what exists. Combining the sets (a “mashup”) opens up a whole new level of opportunities. For example, this impressive hackathon prototype, turns an Amazon Alexa into a personal investment advisor. The “Alexa” gives advice on your daily spending patterns and offers suggestions for managing your money, with the ability to transfer money from account to account.
To implement these types of services, developers must integrate with more than one developer portal and the resulting service becomes a mashup of multiple APIs. In theory, everyone who participates in a mashup benefits. This means that the mashup generates a new value, which promotes usage of all participating APIs. However, on the other hand, managing mashup business and technology integrations becomes very challenging, since each API provider brings their own technologies, business terms and service level agreements.
Advantages of the Co-development Partnership
Now that developers have access to many developer portals with Open APIs, it’s inevitable that there will be more API mashups. This trend is pushed by developers, who are looking for the next killer app and by the Open API providers looking to increase the usage of their APIs. Take note that the fragmented nature of the developer portals (most of which launched just recently) may be inadvertently slowing the progress of innovation.
From the perspective of a developer, a typical mashup means integrating with five or six different corporations, understanding commercial terms, negotiating service level agreements, maintaining many sets of API access credentials, as well as, having to deal with many technologies.
For developers, it would be much more practical to go to one place and get access to all services from one provider.
API providers see this trend and are partnering more with each other, exposing the services of others on their own portals—a process called co-development.
For example, an issuing bank might partner with a processor, to ensure their developer portal has banking and payment processing services available in one place, one set of business terms and one service level agreement. This scenario would help developers, however, there’s a natural limit to this process, because just as developers, API providers are reluctant to deal with too many integrations.
API Aggregation Opportunity
All of the above creates a gap in the financial services API universe which currently stands unfilled. The basic response in the industry has been to make access to the APIs as easy as possible. The principle is that if it takes more than a few minutes to get access to them—developers will go elsewhere. This might be true and this approach might work to attract the developers, but it leaves the operational and business integration questions still unanswered.
Who is liable if one or two services in a mashup go down and people lose money? Who will resolve customer support questions? What is the overall availability level of a mashup service (is it that of the ‘weakest link’, or is it worse, since each service can go down one after another)? Not surprisingly, the payments industry has faced a similar problem in the past. When payment networks and hosts first came online, merchants and payment terminal providers had to deal with complex one-to-one integrations, which was neither scalable nor reliable. Eventually, the gap was filled by the gateways, who took on the complexities of integrating with the networks and hosts. The gateways presented consolidated access points, simplified business terms, unified service level agreements and took on some of the liability for the outages. This ‘extra’ layer made the overall payments infrastructure much more reliable—and made it possible for millions of merchants to start accepting card payments.
A similar trend will likely unfold in the Open APIs economy. Once the use cases for mashups within the financial services industry become clearer, API aggregators will quickly fill the void of managing integrations with multiple API providers. They will create a developer environment where thousands of APIs from hundreds of API providers will be available in a unified fashion.
What’s Next?
I am watching the trend of the API aggregation closely, paying extra attention to the tools to make it happen. The API standards and unified access protocols will likely play an increasingly important role, and the API providers will have to follow the standards to stay competitive. Once standardized, the API universe will enter a new dimension, where services will be auto discoverable and machines will be able to adopt and use new APIs automatically. This will alleviate the need to write new code. There is plenty of work for all of us before that happens though, so we will continue to grow the API economy, one end point at a time.
