In API world - are you going to be an aggregator or a contributor of data? Might this affect your client relationship?

Retail Financial Services

John Hall

Bank and Brand Distribution of Retail Financial ServicesRetail Financial Services

If you aren’t on the front foot, might you be losing control of your customer base?


There will be people who will make a business out of showing your clients’ affairs. We have all heard of open banking and APIs – that’s Application Programming Interface in case you have forgotten.

If you aren’t on the front foot, might you be losing control of your customer base?

APIs have been around for a long time, but it is only of late that they are starting to permeate and gain real traction in the finance space. Many would argue that this is largely driven by Open Banking and the mandate the CMA9 have had to open up their transactional APIs.

At Bud, an open banking platform distributing a financial marketplace via banks, we have looked to other industries and examples of success to help us build our platform


I used Citymapper to find my route here today. Citymapper is a great example of a hugely successful and user-friendly tool used by millions, across dozens of cities around the world. It’s successful because it gives users what they need in a seamless and user friendly manner. They do this, by leveraging popular tools from great companies (Google Maps, Uber, TFL etc) all via APIs.

In this instance, they are all built on top of the Google Maps API (some would argue that Uber wouldn’t be where it is today without the availability of the Google maps API) - remember Apple Maps?

So in this example, who are the aggregators and who are the contributors of data?

Well they are both aggregators and contributors.

The platform I’m using is CityMapper - and they have aggregated data via the APIs of Google Maps, TfL, Uber and more. All of those companies obviously see the value in their API (their services) being consumed on another platform to help users achieve something (in this case get from A to B).

But TfL, Uber and Google Maps also have their own direct platforms too where a user can engage directly. The point is their API capabilities allow them to deliver their tool/services in various instances which derives value for them.

None of the providers have lost control of the relationship - in fact it has helped power their relationships even further as it continues to drive awareness to them (not that they need it) and deepens relationships.

“focus on your USPs and API everything else”

Citymapper is another example of a mantra I love, “focus on your USPs and API everything else” - the API integrations allow a seamless and integrated experience for the user and the benefits to the company centre around the data they receive.

Bundling of products with APIs is actually the common practice these days.

The richness of data which Citymapper collected and analysed (driven from these connected APIs) helped drive their Citymapper bus initiative (now SmartRide). They studied the existing public transit routes and realised they didn’t always serve people best, nor did they evolve quick enough to accommodate changes in the city. So they launched a bus route using this data.

It is this data that creates real value. By analysing it and spotting opportunities to build or offer something new. In this case, new routes...

At Bud, we believe finance can do the same and have proved it with some of our bank pilots. We launched a basic marketplace of third party products within a First Direct app (something which was very alien 2 years ago) and saw users happily apply and take out credit cards with the likes of Amex.  First Direct, introducing their customers to a competitive product, strange right? This was done via affiliate links because there wasn’t an abundance of APIs, but as the technology (APIs) develop we can do this more intelligently.

By treating your APIs as a product in an ecosystem, you make them available for future growth. As mentioned earlier, bundling of products with APIs is actually the common practice these days (across many industries)

Client relationships no longer need to be solely direct - it can be via a trusted intermediary.

Platformification is the new method appearing more widespread now (think Spotify, Netflix etc) and this is even happening more now where traditional competitive organisations collaborate to offer a better user experience, by putting the customer’s needs first. Look at SkyQ & Netflix -

It’s what we did with the likes of Amex and First Direct and OB will drive this even more - where you can log into one banking app and view all your cards (across different providers) - First Direct invited non FD customers into their app.

Treating your APIs as a product

If you think about the fact that the API is your product, you realise quickly that it’s not only an IT topic that is in front of you. It’s way more!

There are multiple aspects like marketing and sales but also product management and strategy. To run your API Product you have to ask a couple of questions and formulate a proper digital strategy.

  • How do you package the service you plan to deliver?
  • How do you advertise and market your service?
  • How do you grant access to your APIs?
    • Do you invite people or do you want to let people sign up themselves?
  • What are the technical requirements?
    • Do you need an API Management platform?

Developer portals to allow developers to access and or build on top of your API creates new opportunities you may never have thought of before. Amex soft launched theirs a couple of weeks ago. I worked at Amex prior to Bud and they were working on it then too (so it’s taken the best part of 3 years+ to build and launch), so I’m not saying it’s easy.


If you don’t have an API there is real risk of playing catch up, or worse…

But to play in this space and offer real value to your existing customers whilst also attracting new ones, if you don’t have an API (or an API roadmap at least), there is real risk of playing catch up, or worse……