When I wrote first about APIs (Apitalism:
API Monetization and Open Banking Ecosystems), I planned it as one time article on the topic but the interest it gathered encouraged me to write more. This time, I want to talk about open banking related business opportunities a little bit. Actually,
the number of resources that tell opportunities to exist are abundant but there's some scarcity about the ones, that talk about where to start and how to do in a practical way. In my opinion, everything starts with the Strategy - in other words, "what you
want to do" with the APIs.
Broadly speaking there are two main options available to you if you want to integrate APIs to your main strategic position: you can optimize your existing flows/processes or you can create new revenue streams that do not exist before.
Optimising Your Existing Processes
If you want to optimize your processes or flows, the way you would make the money would be in the form of reducing the cost to serve, shortened project timelines when you want to improve your systems and allocate fewer resources for the latency systems. Is
there any bank without these latency systems, that consume a significant number IT resources and pain in the neck whenever you want to build something on it?
In order to play with APIs for the purpose of optimizing your existing flows/processes -there is one strong pre-requisite: that is turning all your services, data and processes into services - that would be called by APIs. Easy to say, hard to do. Amazon has
been doing this strictly since 2002. If we have a closer look to Amazon's software development speed, the way setting up the partnerships, general profitability and ecosystem setup - it is obvious that they are doing much better than many other industry players.
One day soon, when Amazon starts retail banking and pushes account openings with special discounts - instead of paying interests, Amazon would pay discounts and by this way, it would not only keep the money inside their ecosystems but also steal the clients
from banks in a very artistic way.
If any bank can overcome "turning everything into services" challenge, this would be the first critical step to be ready for Apitalism Era. You also need an open-minded IT and open system architecture. If the IT culture in your organization would not buy-in
this idea and build on it - what you can do would be pretty limited. If you want to take off the ground and fly, you need an aircraft - you can not do this with a train (even if it is a bullet train - you are still on the ground!)
Finding New Revenue Resources
The more you read about APIs, you would hear more about "INBOUND" and "OUTBOUND" terms. Think about a business world, in which every company has APIs -including yours. When somebody connects your API - this is INBOUND, you are the provider of value in the form
of service, data or product. On another hand, when you connect to an external source - you get the value from someone else, this is called OUTBOUND.
You can make money by using both ways: Inbound or Outbound. But before that, it is necessary to have some API standards in place - otherwise, different systems cannot communicate with each other. So when you hear about the API standards, like the Berlin Group
or Open Banking Standards, please keep in mind that the idea behind such structures is to create a common protocol. If such a protocol does not exist, then for each & every connected entity there is a need for a custom API design & development. Imagine yourself
as a banker in Germany, where more 1.600 banks have been operating under banking license, no standard in place and you decided to connect them all. You may start and your grandkids would finish the job! Some companies called Aggregators would like to play
the role of connecting you all if you only connect to them.
Let's give an example of Inbound Opportunity. Imagine you share your client data a 3rd party company, for example, a new car-sharing company in the town - that needs a KYC for onboarding new clients. The way it would work the Car sharing company directs the
potential clients to your bank at the time of online registration, the client gives consent for sharing his/her data with the company - then they get the information they need. From Car Sharing Company either they would apply for a banking license to do this
free of charge with mandatory APIs that you have to open OR they would pay you for such service and be your partner. Guess which one would be more likely?!
Now it's the turn of Outbound opportunity. After some market investigation, you concluded that selling X product to your clients would be incredibly profitable and you immediately asked your IT to develop it. Then you learned that it would cost you millions
of euros and 2 years if you would like to do this internally. However, your smart CIO suggested that there is a company specialized in X product and it sells it in the form of API - for a fee (fixed fee, commission, use/call based or whatever). If you would
select this way, it would be ready under 9 weeks with minimum IT effort. Then it would be up to you decide "22 months earlier in the market" with 1/20 of IT cost is worth it or not.
Before I finish, I think it is critical to clarify something. APIs are not unique structures, both from design and purpose wise. PSD2 APIs are not the same with Private or Partner APIs - in terms of specifications, performance, and field numbers. APIs can also
be used internally (inside the same company), not only externally. Actually, most of APIs available in the market are Private, not Public. The main risk of relying on a Public API of any company is - it can be changed, updated or deleted on the provider decision
without saying anything to the developer community. One recent example is Facebook, check out what they have done to their APIs after Cambridge Analytica Scandal for the purpose of increasing Data Security & Privacy. Sure this was needed, but from a company
that sets up the business model on FB Apis - this is the kiss of death.
In conclusion, Apitalism represents another world - where there are some internal dynamics involved - that we better understand first, before jumping in too early decisions and actions.