A dose of reality on the road to bank digitalisation


If you’re like me, you may be getting slightly tired of the same old stream of open banking waffle. A regurgitation of the opportunities and threats posed to retail banks in the Open Application Programming Interface (API) powered marketplace future. It has however, become a bit of a broken record, don’t you think?

These opinion pieces are never more than a high level outline of new business models for banks and third parties and are of course accompanied with a healthy dose of fear-mongering around data security and the need to monetise the customer.

But let’s get real for a moment – the push to exploit all of this and banks’ response to the rise in customer expectations will lead to unprecedented levels of pressure applied to an already creaking legacy banking infrastructure. Indeed, in this rapidly evolving digital economy, mobile data traffic is expected to increase an enormous 800% over the next 5 years (Cisco).

Against this backdrop, there is one topic that is seemingly overlooked by the online commentator community and consistently omitted from the glut of daily webinars… It is the adoption of a decentralised API-first governance and enablement strategy, where reusable APIs are defined on a global scale, yet applicable for local territory implementation at pace, powered by highly collaborative development and communication tooling. It is an enterprise IT perspective, yet still an ‘open’ concept, helping to create a truly digital bank – from front-to-back.

APIs are not a new concept and most organisations have repeatedly created many of them, including RPC, SOAP, and ReST*. What was previously lacking was a strong, yet efficient model for API Governance; one that ensures re-use and prevents duplication, one that is effective and not restrictive. For example GFT’s API First Governance framework contains no rejection but instead mandates a suggested solution should be proposed, allowing banks to successfully deliver against their transformation roadmap with globally distributed development teams developing against formally agreed API definitions. GFT’s framework combines a full set of industry best practices and solution assets developed over time following successful deployment at tier 1 banks across Europe and North America.

Once implemented, it enables redundant legacy to be carved out of the infrastructure and the rationalisation of data storage. The time to market for new products is eight times faster than before, and provides a platform solution that streamlines the integration of acquisitions. Make no mistake, the implementation of a solid API first strategy is a fundamental component to becoming a fully ‘digital bank’.

So whilst the options and absolute gains for a bank to operate in a marketplace or ecosystem environment are still being evaluated and discussed by all and sundry, GFT are focused on helping our Banking customer execute this critical pre-step; enabling them to reap upfront benefits at the same time as establishing the building blocks for fitness in the digital economy. After all, applying ‘lipstick to a pig’ will only get you so far where legacy architecture is concerned.

There you have it. Is your organisation acting upon these initiatives or choosing to bypass them? I would love to hear from you if any of this rings true for you and you organisation?


*Definitions for those who were wondering: API, SOAP, RPC, ReST

If you want to know more about how we are helping our clients in this area, please participate in our Digital Readiness Diagnostic Survey to assess your organisation’s progress in the Digital Journey and anonymously compare with other UK financial institutions.