The cult of APIs originated at least as early as the 1st dynasty, around 2800 BC. Like other bull deities, APIs was probably at first a fertility god concerned with the propagation of grain and herds. Today and as predicted on the Moroku blog 2 years ago, there is a new cult of APIs. With APIs having joined the vernacular, the banking world has been sent scurrying off on a journey of APIification (as distinct from APPification). Perhaps more curious still is the resulting debate over whether a waterfall and agile approach to getting the API’s built is correct. Accordingly there has been no shortage of those declaring their oracle style wisdom or priest like authority over the subject.
The Moroku leadership has been digitising banking since 1997 and has come across our fair share of digital banking deployments globally. We regard APIs like any other language; To get started you don’t need the full vocabulary, just enough to order dinner and see the local attractions. As you get accustomed to the culture and the landscape you build skills and experience until you are required and become able to negotiate complex commercial agreements.
Many people disagree with us, prompting the note here. Many prefer instead to define the full vocabulary, grammar, slang and context and then embark on a program to instil and install that complete dictionary and set of rules. It’s a natural thing to do it seems. Why be incomplete? If you’re going to do something why not plan for every eventuality? Our view is that such an approach is complex, expensive and fraught with danger as with all waterfall approaches; the greatest danger of which is never doing anything. At the heart of the problem is the assumption that we could indeed imagine every eventuality within the safe confines of the bank or vendor, The other risk at play here is that every eventuality is worth supporting.
Moroku has recently released ChoreTracker, an app for banks to engage parents and children around banking. To integrate ChoreTracker we need to know if modern APIs exist at our partner bank, and if so, what the syntax/protocol is for them in relation to:
- Retrieving account details. e.g. get the list of my accounts (including type and account meta-data)
- Making intra-account payments. e.g. move $X from one of my accounts to another of my accounts
- Querying account balance; e.g. Get the balance of my account numbered XYZ
As you can see, the devil is always in the detail. In our instance we are able to deploy an innovative useful mobile app with a precise and small set of API verbs. Our experience tells us that using this level of precision leads to requirements that are lean and executable.
Standards based implementations of large, heavy, overly complex dictionaries are risky and require way more verbiage than your average FinTech requires to get to market. We suspect that many FinTechs have a similar view and that the three API calls above may satisfy a broad selection of FinTechs with whom banks, insurance companies and wealth providers may wish to engage.
In the meantime a number of vendors continue to tout, as they have done for decades, for the more “robust” approach. Examples include BIAN, Open Bank and MIRA-B. While these projects may look attractive if you’re a bank struggling to work out how to surface APIs to a FinTech community in a secure, manageable way, the reality is that you can spend millions of dollars and hundreds of man years of time to get precisely nothing (in terms of new, customer services).
Once you have these “complete” APIs, you still have no apps that run on them. Until then you have to undertake the risk of asking the FinTech community to stop innovating and delivering for a couple of years while you stand up the APIs that they “need” to make this stuff work.
Once the monster, waterfall defined API is agreed we’re also not that further along. These standards projects are always horrible to deploy. They’re largely designed by committee, with members having competing interests and whom largely joined to find out what everyone else is doing. They routinely have so many implementation options that there’s no “standard” that you can write to anyway, with engineers spending so much time trying to handle every conceivable edge case (multi part account numbers, should we support sub-accounts, if so how many layers?) that they end up having to spend many years building wrappers around them just so that they can integrate with any bank that has implemented them. How successful has IBM’s Information Framework been at simplifying banks’ internal app development processes? Their membership of BIAN is unlikely to drive any major change whilst continuing to prove their passion for heavy vs lean. Contrast this with one of the most digital and open of banks, BBVA. They have exposed a number of APIs to developer through hackathons etc. without the overhead of an ‘open industry standard’.
The starting point for the API as indeed the strategy must be to put the customer at the centre. From there we can determine the products and services that they need, from whence the data you need to expose can be determine. Then (and ONLY then) we get to work out the best mechanism for doing this. This will inevitably involve a number of experiments and failing fast. You cannot, by definition, fail fast if you take a couple of years to stand up infrastructure. Having picked an experiment it may be possible to run it without exposing an API, or by standing up a very simple API. There are plenty of standards that can be deployed to secure an API (OAuth) plenty of products that can be used to meter or profile traffic (Level7) and so on.
For our money, which as a small company is delightfully limited, we would rather spend time talking to our banking partners about the innovative services we can offer customers rather than the digital pie-in-the-sky we might be able to have once we have completed the herculean effort of defining the world, whilst hoping it hasn’t changed so much that we are required to restart the effort or that we are still alive once we have completed it.
What we see however is a heavy waterfall predilection to the definition of APIs despite a routine fervour for being lean and agile. If the waterfall API high priests pervade, attempting to build out their new dynasties, they will draw omens from their behaviour, their oracle gaining too wide a reputation. However when the APIs bull finally dies and it will, it will be buried with great pomp at Sakkarah, in underground galleries dedicated to the worship of the Greco-Egyptian god SearAPIs allowing the new world to move on. Sadly this perahps is what it will take