API Business ModelsAPI Lifecycle Management

APIs as products in financial ecosystems

451views

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.

APIs –

  1. Provide access to enterprise services and data
  2. Provide additional value to customers
  3. Enable new digital models

In the industry, there are myths about APIs –

  1. Just a technology instrument or platform
  2. Exposure of the data model as-is
  3. 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.

Vishal Sharma
• AWS, TOGAF 9 and IBM SOA Certified Architect with extensive experience in IT global delivery, strategic consulting, digital transformation, portfolio assessments, and business process optimization. • Defined and executed API first programs, that included setting up the governance and enablement model. • Empowered organization to embark on Architecture as a Code initiative. • Shaped service modeling for digitalization of a mortgage and title insurance organizations. • Worked extensively on Open Banking API (PSD – 2) and an active participant of BIAN community • Enabled enterprises to achieve Micro Services Architecture (MSA), API Management, Continuous Integration (CI). • Expert in planning and execution of IT and business transformation initiative • Specialized in enterprise merger, acquisition and consolidation of IT assets • Built cost containment framework and leveraged it across various customers to achieve 30%+ savings • Hands-on experience of various Architecture and Integration design patterns • Contributed as a key member of Architecture Review Board for several programs • Member of Global Association of Enterprise Architect (AEA)

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture