Banks the world over are looking at how they can be more productive and deliver competitively better value to customers. To do this, most are looking to identify specialist systems and tools to bring into their existing eco-system. It sounds so simple – they just need to ensure the selected solutions have an API and the job is done. If only this were true.
It seems everyone wants an API without really understanding what it means. While once a highly specialist undertaking, the term API has become over-used and under-valued. Just because an application has an API, does not mean it is necessarily going to play nicely with a bank’s ecosystem.
It is like rugby and football on the pitch
One of the best analogies to describe this is to think about rugby and football – both team sports, played with a ball, on a pitch, with a goal at each end. But for a rugby team and football team to play with each other on the same pitch, multiple things would need to be agreed and then aligned in real time. The number of players and their positions? The shape of the ball and the goals? How is a goal scored? And countless other rules would need to be interpreted and adjusted for a meaningful exchange to take place.
The job of an API is to translate that real-time data exchange between the bank and the selected specialist tool or system. The issue is, no two banks want to interpret the game in the same way. Every bank has different needs and requirements to go into an API to engage with their existing environment.
As many who have started the journey will attest, the fact a tool has an API doesn’t mean it will necessarily play nicely in your infrastructure. There is often considerable development effort required at both ends, and some very real considerations around security and shared data that need to be addressed in making sure the API is robust and compliant.
Getting APIs to talk to each other
If you then want the various specialist tools to work together in an ‘ecosystem’ even greater complexity is created. Think of the ‘bank’ as the hub of a wheel with each application as a spoke. For the various applications to ‘talk’ to each other they need to translate through the central hub or have multiple APIs to engage around the wheel. As you can imagine this is even more complex and technical and where the enthusiasm to bring a range of new tools into the environment often wains. It just all gets too hard.
It is why banks have been talking integrated platform plays for nearly a decade, but few have made any real progress. The recent push to remote banking has accelerated the desire to create a cloud connected point of difference. Corporates are already using many of these tools and pushing banks to adopt them by identifying where additional value can be built into their engagement.
Getting on the same platform as your customer, quite literally, is seen as highly desirable. If a bank could provide that, while simultaneously improving its productivity and client outcomes, you would have to think it was a win-win for everyone. So how do we get there without needing a fully integrated API environment?
There is another way
Consider why a bank wants to do this in the first place. There is real value in using highly specialist tools to deliver exponential value, without having to create original IP or manage and maintain the solution over time. The value lies in what the tools ‘do’ as opposed to the need to operate in real-time.
In many cases an API is not necessary as there are easier ways to transfer data to deliver the same result. While these options may seem relatively old school there is a reality check in the desire for real-time data transfer and the cost of lost opportunity this causes.
In many cases synching data at hourly or daily intervals would be far more achievable and practically acceptable by all parties involved. It means banks can get started on delivering the value while working on building the APIs in the background – if they are needed at all.
The football and rugby teams play on the same pitch with minimal rule changes needed because they are playing at different times. They can have multiple games in progress with everyone playing happily – just not all together at once.
So, in seeking a competitive advantage the first question should not be ‘does it have an API’? But ‘does it do what we want it to’? The next question being how to make this work in the specific environment as fast and securely as possible – without breaking the bank.