John Phenix is the Lead API architect at HSBC with many years of experience in banking APIs and architecture. Ronnie Mitra is a Strategic Advisor at a transformation consultancy called Publicist Sapient.
Ten years back, we were creating APIs hoping that someone would build the ultimate application on top of it and I could benefit. The banking world went through a compliance phase between then and now, especially in Europe. So, we saw an era of execution. Now, we’re shifting into an era of opportunity and opportunistic businesses. Ten years ago, we thought they would come if we built it. It was about developer experience and developers coming together. We were talking about shifting from SOAP to REST. Then we went through a phase of ecosystem-driven implementations. We had to follow government regulations. So, we focused on modernizing, and the work became a catalyst for some digital change. But now, we see business-driven partnerships and monetization programs.
If you’re in a bank, if you’re in a large enterprise working on APIs, this means you’re becoming more relevant. But it also means you don’t have a long-term platform vision. Your business is looking for opportunities and trying to drive revenue quarter on quarter. It’s a serious mind-shift change. We’re seeing terminology developed that describes things we have been talking about forever. But you give something a name, and it takes off. We’ve got these three levels.
- Embedded finance talks about taking parts of your bank, the user experience, and embedding it in someone else’s application.
- Banking as a service – Banking services offered as APIs to power 3rd party software.
- Coreless bank, or borderless bank – 3rd party services powering banking platforms
In the emerging world, technology needs to solve problems of scale. We, as a firm, have done some analysis and see huge opportunities, especially in the commercial banking space. You can integrate your services, build them out, and drive real revenue. But you can’t do it in a way that requires a high cost to serve, a high operating cost, and a high cost to integrate. So, the magic isn’t providing the API and slapping on a developer portal. The new technology opportunity is to drive this with some skill.
Scaling will be a challenge.
Embedding at scale – If I start embedding banking experiences in other places, how am I managing that risk to the brand and the license? How do I enable cheap and easy customization?
Integration at scale – If I have 1000 screens with hundreds of different partners, how do I service them? Identity is going to be a new problem to solve. As we move towards integrating systems, will it be enough to have a banking customer identity, or maybe it’s time to start developing things we shelved in the past?
Coreless at scale – How do you reduce switching costs? How to implement structured design and composability?
Winners in the banking API market will find ways to optimize for variation and scale. Technology and design can change the cost equation.
How design and delivery of APIs is making a difference – HSBC Commercial Bank (A case study)
Our customers range from small businesses and mid-markets to very large multinational customers and businesses. We started with internal transformation, working on internal APIs. Then we started to offer external APIs that their customers who have businesses access directly.
Over the last three or four years, we have evolved into banking as a service and embedded finance.
Embedded finance is the seamless embedding of the bank’s financial services into partner platforms. The key word is seamless. The idea is that we make the experience so good for our potential customers that they want to use HSBC services where they already are. So instead of forcing potential customers to come and find the bank, we, the bank, go to where the customers already are and make ourselves contextually helpful.
For example, we’ve announced a partnership recently with Oracle NetSuite in the US, and there we’ve done a complete embedded finance solution that’s live now, where we provide the ability for customers who use the Oracle NetSuite platform to pay their invoices directly from that platform. They never come to HSBC, even when they open their bank account; it’s all done in a seamless embedded style within that Oracle NetSuite platform.
Challenges faced
We have been struggling with two challenges over the last couple of years. The first one is how to embed complex financial products in partner platforms while keeping that seamless experience. The second one is how do you deliver business outcomes quicker for our customers?
Embedding complex financial products in partner platforms
To open a personal account, you need to fill in some basic information; it is a simple job. But if you’re a commercial customer, or a business, especially a large multinational company, there are potentially hundreds of questions we need to ask you. We need to know who your directors are, where you do business, what type of business you do, the financial products, etc. The questions we want to ask you depend on the answers to the previous questions that you gave. This makes the product complex. So, to make this feasible, there are three options –
- You embed the bank’s user interface into the partner user interface. But this is not always seamless for complex products.
- Get the partner to write the complex UI. The partner can create a compelling user experience and modify it as required. But then, the partner may not have the capacity to do this.
- Get the partner to render the user interface based on the bank’s logic. For example, Oracle and NetSuite created the user interface for onboarding customers, setting up virtual credit cards for making payments, etc. But the bank retains our expertise and provides that via an API to Oracle, NetSuite. This can be done by hypermedia style API.
How do we deliver business outcomes quicker?
For HSBC, we’ve got a couple of 100 external APIs on our developer portal. We expect people to come along and assemble some business value of those APIs. The flexibility is great. But some partners do not want to do that. They want to get the outcomes that they want as quickly as possible. We still provide individual APIs. But we want to give them API sets or packages that work well together. The partner will have to register once to use the API set and will not be required to register multiple times.
They should be provided with a simple set of instructions.
To conclude, embedded finance will lead to more hypermedia-style APIs. We will see more API sets to deliver business outcomes quicker. But, importantly, it’s going to be the API sets with the best API experience that will win.
