Building APIs in financial industry
The obvious, the drivers, the (business) opportunities
Chapter ONE — The Obvious
Most of the time, APIs are (still) perceived as “stuff for geeks” that are not that hard to understand by non-technical people.
“APIs? Hoo! It’s just something that allow easy interactions between different systems on the Internet.”
When it comes to define and implement an API-centric strategy, the story is much more blurred …
Of course, there are obvious elements that must be put in place to expose APIs securely: API management system, JWT, microservice architecture and
best practices required to create the right APIs.
Next to this there are the elements that need to be done to simplify adoption for the end user (aka developer):
Site Documentation: A well-documented API, which clearly explains which methods are available and how to use them
Code Samples and SDKs: In addition to the documentation itself, code samples are one of the most important items developers ask for when beginning to use an API.
Platform/Tool Integration: The third level in integration support is to go even further than SDKs and provide code-specific modules and plugins for development platforms that the target developer audience uses
(from : Winning the API economy)
In the financial sector, some neo-banks may already be considered as API natives (Monzo, fidor, …).
Major players in the payments industry have already APIs for some time (Stripe, Paypal) or more recently (Visa).
Well-established financial institutions need to go one step forward as well. Some of them are already proposing sandboxes to let developers & fintechs “playing a little bit” (bbva, citi, db, capitalOne , wellsfargo).
With PSD2 directive this should accelerate radically in europe during the next two years.
Chapter TWO— The Drivers
But APIs are not only a stuff for geeks and not only PSD2 story.
Why opening APIs? What are the drivers?
A first reason is about the evolving customer habits.
Customers want “Living Services” that can flex and adapt to make themselves more relevant, engaging and useful. Consumers no longer compare their brand experiences of two different banks; rather they make comparisons between their brand experience of their bank with a bestin-class airline, or worse, a design-driven startup such as Uber.
Those Living Services that are prepared to allow elements of what they offer to be super-distributed by other services, or which allow other services to connect into what they offer, are most likely to survive. We call this process atomization.
(from : The era of living servives)
This means collaboration and APIs !
The key challenges for big banks is moving away from a built it and they will come mindset into a collaborative models where banks connect part of their ecosystem with the preferred services that customers are already using. This will require a signifiant cultural shift.
(from : bankingtech october2016)
“Digitalist” (analysts, UX/UI experts, developers …) are usually thinking about what the screen of their app will look like according to the initial business idea and the user scenarii. The shift is about thinking first on all the usual (digital) habits of the users. Then try to integrate your new idea in this digital landscape thanks to APIs.
A second reason is about enabling the APIs economy.
The opening of APIs typically enables organizations to innovate more rapidly and provide uniform data and transaction interfaces to internal and external developers, partners and customers, for improved data access and transactions.
Such organizations can also develop software applications to access these APIs to create new functionality and value both for themselves and the wider world. The resulting economy enables many new classes of applications with
the potential to transform the way business is done.
(from : Winning the API economy)
It’s about how two companies can work together to create more value than either of them could independently.
Enabling the economy is part of the mission of banks… Enabling API economy should then be one of their priority.
Chapter THREE— The opportunities
When it comes to opportunities, especially in the financial world, the main question remains: how to make money from this?
And you can do it wrong as facebook experiment earlier this year (Facebook shutters its parse dev platform).
We’re just now waking up to the idea that you probably should never trust an API from a company that intends to make most of their money from advertising, even if they’re charging you for those APIs.
So, What are the possible business models and examples?
1. Make it free. PSD2 APIs will be free of charge which is probably one of the reason why APIs are sometimes seen as a risks within the financial echosystem.
But APIs are not only about PSD2, let’s look one step forward.
2. Developers/partners pays. You have multiple sub-categories like pay-as-you-go (pay what you consume), tiered (pay per unit, pay less per unit when you consume higher volume), freemium (only access a subset of the features or limited SLA) and transaction fee where percentage of transaction is charged to the developer/partner.
- freemium: Get investment product details, history & market data, …
- transaction fee: batch transfers, …
3. Developers/partners get paid. There are also multiple models like affiliate revenue share where developers are paid for customer referrals/acquisition, revenue share where developers are paid a share of the revenue from purchases and recurring revenue share where affiliates who refer new customers are paid a revenue share for the life of that customer. Examples:
- affiliate revenue share -> New current account is created
- revenue share -> Subscribe a loan
- recurring revenue share -> New investment account created & recurrent in/out activities (buy, sell, …)
4. The indirect revenues. One of the most important indirect revenue is the benefit of using and thinking APIs internally.
Traditional banks manage a plethora of products that often sit on different platforms that work independently, even within a single company. In short, products don’t talk to each other, resulting in a fragmented user experience. (from : bankingtech october2016)
Amazon understood it more than one decade ago
All teams will henceforth expose their data and functionality through service interfaces … teams must communicate with each other through these interfaces … All service interfaces, without exception, must be designed from the ground up to be externalizable …
Anyone who doesn’t do this will be fired !
(see full article & video here)
Chapter FOUR — The conclusion
And finally, there is no crystal ball… at that point of times, nobody really knows what the future will be made… This is also applicable for the API economy. There will be Aggregator (plaid, bankin, omnibank, teller), there will be Integrators from other industries (healthcare, travelling, cars, …).
Financial instituation need get ready for this from a technical perspective but also from a business model perspective.
The mindshift seems not rocket science but as said before — this is one of the key challenges for big banks.
And as usual, to really understand it — you need to play with it, to try it… and not especially in the financial area… understanding the power api can be applied to any other industries and on small projects.