Can you compose your bank?
Increasingly core banking vendors are jumping onto a new bandwagon called “composable banking”. A quick Google search and the earliest reference I could find dates to August 2016 for a paper written by strategist Leon Rees heralding “the composable bank”. In this paper, he says a composable bank is “where the bank can adapt to the confluence of disruptive change taking place in our industry”.
Rees says the following shifts have created the drivers for composable banking:
- migrating the composition of commodity capability from within the bank to the wider ecosystem;
- shifting the architectural emphasis from functionality and product to a model where data, customer and orchestration has primacy;
- moving from an infrequent change model (once every six months) to a high frequency change model (several times per day);
- leaving behind fixed-cost models and moving to consumption-based pricing in contestable markets;
- adapting to a new regime where businesses are no longer regulated “on the business” but “in the business”;
- shifting from heavily governed, teams of thin-sliced specialist roles to self-governing teams of broadly scoped “T-shaped” people.
The first vendor to adopt this vision and terminology appears to be Mambu announcing its composable banking platform in 2018, and most recently Temenos joined the party announcing its composable banking solution at its 2022 user conference, Temenos Community Forum. Both of these appear to be a proprietary approach to composable banking.
Essentially composable banking is the ability to create a banking platform from multiple suppliers easily. In the past connecting software from two different suppliers involved coding the integration and sometimes required a “technology bridge/gateway” to allow one platform to talk to another. Fast forward to the modern cloud era where we should not need to understand what hardware or software a solution runs on to use it. Thus, integrating cloud solutions is more simply a mapping exercise of data/parameters to each cloud service. Often this is done with a graphical tool and hence we are “composing” the integration.
Interestingly, Banking Industry Architecture Network (BIAN) call this “coreless banking” and demonstrated its approach in 2021 using Thought Machine’s core banking system and Zafin’s pricing platform as one example (see the diagram below for the full set of third parties).
Image source: BIAN
Arguably, what BIAN has produced is much more granular and based on BIAN’s standard definitions of banking services. This would allow for “composition” of banking in a more vendor neutral way, i.e. not specific to a particular core banking solution for composing the third parties. To enable this, BIAN has developed the “message modeller” – essentially a way to map data from one platform to another based on the BIAN data standards (a demo is available on the BIAN website).
This kind of flexibility should eliminate vendor lock-in and really allow banks to swap in and out banking services much more easily. It will allow banks to choose the best-of-breed components and not be compelled to use all services from a single vendor.
As with all trends each vendor has its own take on how best to implement “composable banking”. Whether you take a vendor led proprietary approach or a more open one, what is clear is that this is a movement to reduce one of the biggest headaches for banking CTO (even in those banks that have gone through “simplification” projects to reduce the number of vendors).
In large banks there could be literally thousands of integrations with hundreds of different suppliers across the organisation. However, the real proof will be in the doing and not the saying. The marketing materials and demos are all well and exciting but as we say in the UK, “the proof in the pudding” will be live implementations of this involving more than just a small handful of services.
When looking at vendor solutions, banks will need to go beyond the marketing materials as some “composable solutions” are really pre-integrated partner solutions that have a user interface (UI) to enable (licence) the third party solutions. Banks should test the ease of swapping in/out services, and especially how easy or not it is to remap data/parameters.
This also highlights why modern core banking software has to be fully developed as a set of modern cloud native micro-services, whereas some solutions are, at best, only partially delivered as micro-services.
This week, I’m just saying that “composable banking” promises to solve a real problem and to create real flexibility, something that banks have been held back by for a long time.
Whilst it is still early days, banks should at minimum have this on their radar, if not actually trialling its possibility in test environments today. For me, it’s one of the most exciting and promising developments for core banking after the redevelopment of core into micro-services.
About the author
Dharmesh Mistry has been in banking for 30 years and has been at the forefront of banking technology and innovation. From the very first internet and mobile banking apps to artificial intelligence (AI) and virtual reality (VR).
He has been on both sides of the fence and he’s not afraid to share his opinions.
He is CEO of AskHomey, which focuses on the experience for households, and an investor and mentor in proptech and fintech.
Follow Dharmesh on Twitter @dharmeshmistry and LinkedIn.
Read all his “I’m just saying” musings here.
