APIs as products in financial ecosystems
Vishal Sharma is Vice President of Engineering at Broadridge. He is a FinTech enthusiast and an API Learner. This article by Vishal discusses APIs as products in a financial ecosystem.
API is a means to deliver market-leading business capabilities with speed for clients and communities in a secure, stable, and scalable way.
- Provide access to enterprise services and data
- Provide additional value to customers
- Enable new digital models
In the industry, there are myths about APIs –
- Just a technology instrument or platform
- Exposure of the data model as-is
- Secondary to business
In reality, till the time we do not have API as a product mindset, we are not API compliant.
Not all APIs are equal.
Every person out there has their own perspective of an API, and they are right in their own way. If we are too close to the implementation, we cannot look at it from a distance. We need to extract ourselves and look from the outside. To get a true sense of APIs, we have to keep ourselves a foot away, if not a couple of feet away from the limitation, and see the holistic picture of how our consumers are trying to use it. And that’s where I always say not all APs are equal.
Types of APIs being delivered today
API as a service – This is how developers build software out of software. The goal is to enable integration.
API as an interaction – This is how devices talk to an application. The goal is to support a specific channel or device. A survey said 85% of Financial Services fail to recognize the true value of APIs because they stopped at API as an interaction. That’s where we see a lot of failures when it comes to monetizing your APIs. Because every time the front-end application changes, it expects you to change or add more steroids to your existing application
API as a product – This is how software is packaged, distributed, and monetized using API management solutions. The goal is to think about APIs the same way as any product we buy off the shelf. We have to take our APIs to the next level by thinking about APIs and how they’re packaged together to give a good experience to the client. It’s more consumer-centric.
Since we have different APIs, we should manage them differently as well.
API as a service and API as an interaction generally follow a normal SDLC process. You plan for it, get a requirement, design your service, and then plan for development, testing, and deploying it. If there are UI changes, you will make changes as desired. If no one is using it, it’s drying down; you will retire it.
API product management, on the contrary, goes off on a tangent than the normal SDLC process.
As we start designing the product with an outside-in view, design thinking is of utmost importance. We cannot design an API product and monetize it till the time we have thought it through as a consumer. We can build it for a specific consumer, but that would be for services, not an API product. The main protagonist of this API product lifecycle is a product manager, a part of the Product Management Group. But it’s not the whole and sole ownership of the product manager. Yes, they are accountable, but the responsibility is with the entire team. It’s the combined ownership of tech and product combined.
So, you create a product, manage it, and manage it via different tiers. You can have a premium, gold, or bronze tier based on the consumption pattern and your plans for monetization.
You then package that all together, add documentation and publish it on the shelf. You then measure its usage. You monitor feedback and accommodate relevant feedback in subsequent releases. You can enhance the product or give more offerings if you have an increasing customer base. If there are no customers, you may retire the product and not waste any time and energy on the product.
Product management for APIs
As your consumer influence decreases, your product management should increase. A private API is for internal consumption. You can work without an API management platform.
Depending on the firm size, the second set of APIs can merge internal LoB APIs or internal firm APIs. This is a construct where you start using service meshes. Your internal firms are the same ecosystem and the same IT landscape. They can talk to each other. That’s where you introduce service mesh; you should not introduce service mesh in your private APIs.
When you start losing control of your consumers, you start taking more care with your product management. You do utmost product management where you deal with external partner APIs or external public APIs.
For example, ESPN launched a public API when going digital. They got so much traffic, which their product manager did not anticipate, and they were ultimately forced to close their APIs to the public. Now they provide APIs, but just to partners.
APIs in financial services
Financial services, by their nature and design, are highly regulated. Opening financial services by itself was a challenge. It was forced on the financial services to open up their system for open banking or PSD2. Japan has the Japanese Banking Act. Singapore moved a step ahead in advance. They launched finance as a service. In North America, we started with the API standardization industry group that NACHA organizes. AISC is not a mandate; it’s a recommendation.
Most mandates are mainly towards the regulatory and data sharing side for account validation, bank account information, payee verification, or customer data control. They’re not mandating core banking or payment access. It is regulated, but it’s not mandated to open it up.
We have grown through evolution. We had Iron Age and then the information age. Now is the age of collaboration, where we collaborate and provide better services to our consumers. Financial institutions, payment providers, and retailers are the collaborating partners. It’s all built on trust.