Post-PSD2 banks are considering premium B2B APIs that are monetized. In this series of blogs, we discuss several ideas for such B2B APIs. As you can no longer expect your customers to come to your bank, you have to bring your bank to the customer. We believe APIs offer a good way to do just that.
It is commonly accepted that few customers will keep coming to branch offices to get advice and purchase financial products. It will even become much harder to lure customers to your banks' website as they grow accustomed to seamless experiences offered elsewhere on the web.
With APIs banks can become part of a seamless flow where customers buy the product they really want, such as an expensive piece of equipment, while in the same flow financing options are offered. In that sense APIs take over the traditional function of branch offices and corporate websites. (In all honesty, there will always be a small percentage of cases out there that are too complex to be dealt with by APIs and off-the-shelf logic, but these cases can be treated in the traditional ways.)
A wide-spread fear is that by offering them through APIs, financial services will quickly degrade to commodities and banks to bland, unrecognizable entities behind them.
In this series of posts, we demonstrate that this need not be the case. If APIs are combined with a solid, fast digital onboarding mechanism, they will help you gain new customers. These clients are fully aware of the fact that next to acquiring the product they were looking for, they also digitally signed a contract with your bank.
Picture a British corporation that sells typical British products online. Of course they also like to sell their goods to people in Continental Europe. The continental clients could use a credit card to make the purchase, but given the prices of the products at sale a significant amount will be spent on fees.
Figure 1 : A web shop selling products priced in GBP, through a premium API offered by a bank the payment can also be made in Euros
XiBank offers an API to such organizations. The API takes an amount in GBP, creates an FX-spot transaction in the bowels of XiBank, and returns a proposal consisting of the amount in Euros, a fee and perhaps a collateral.
The API is triggered by a press on the Pay in Euros button, and when that happens a -XiBank controlled- screen appears. The terms of the Foreign Exchange transaction are clearly stated in that screen, and when the buyer accepts them, they click Fix & Buy. Subsequently the payment can be made, perhaps using PSD2 endpoints as depicted above or a payment method such as iDEAL.
When XiBank hears that the payment succeeded they can already pre-warn the British shop to start crating the spitfire, as a guaranteed payment is underway.
Ximedes has worked on many software development projects in the past two decades. We have learned that failure or success is almost always determined by the team.
API development is just like any other software development project. To make it a success technically, budgetary and in the market you need a great team to build, run and sell it.
A team needs a strong Product Owner, with a real mandate to make on the spot decisions, but the team also needs Security, Risk and Compliancy Officers who want the new product to succeed, not by sacrificing security or compliance, nor by introducing risk, but by building these things in the application from in a pragmatic, inventive way, right from the start.
The team also needs UX designers, who must relentlessly strive to keep the application as simple as humanly possible, while taking into account the non-functionals introduced in the previous paragraph.
Of course, the team also needs developers. Often developers - who possess a mindset keyed to fully comprehend problems - can build bridges between the other team members.
With a team composed of the right people in the right roles, almost any innovative product can be build. One of Ximedes' specialties is to build such a solution quickly, often in no more than 8 weeks, launch it and continuously improve it from there.
With APIs banks are creating brand-new products, and almost each API targets a different market. For instance, the FX API introduced in this blog will have to be sold to foreign customers, in Norway, Danmark, the UK or China. For internationally operating banks this may be easy, more domestically oriented banks may have have to focus their sales efforts on PSPs or similar parties, introducing the FX API as a 'payment method'.
We believe the sales team, like the developers, UX designers, compliancy and risk officers need to be part of the team. Only there can they make sure that the product is developed in such a way that it becomes marketable and successful. The sales team of these new, specialized products, should not be a traditional, seperate, department that sells a little bit of everything.