Walking the talk with composable banking
This week, I was pleasantly surprised to read the news about Monese switching its core (ledger service) from Thought Machine (TM) to its own “coreless banking” solution under their sub-brand XYB.
Composable architecture creates real flexibility for banks looking to make changes to their cores
Before I delve into why this is big news, I feel I should give a bit of background into my experience of what software development has been like.
I remember the early days of internet banking when my team was putting banks online in a six-to-nine-month timeframe. This was with a team of less than five people. Our first client, Co-op Bank, used a third-party solution to provide 128-bit encryption because browsers only provided 32-bit at that time. Now apart from the usual firewalls, that was pretty much it for secure internet banking. Things were much simpler at the start.
As time progressed, even though 128-bit SSL was eventually provided by browsers, hackers got smarter, and we started to have to check for many other issues at both the infrastructure and application software levels.
For decades, I’ve seen that innovation starts simplistic and evolves with added layers of complexity over time, and over time common functionality is abstracted from applications into infrastructure.
The same goes for software development. Initially, we wrote large programmes that did everything needed to solve a specific need. Later, we started to design things into components so that we didn’t repeat coding (for things like data validation, for example). The code was included as a library, so if the library changed, you had to recompile your solution to use the new library.
When I moved off the mainframe into Windows development, we had dynamic link libraries (DLLs), which allowed the libraries to be linked dynamically at runtime rather than during compilation. This meant reusable code could be updated without having to recompile, albeit on the same machine.
Next came DCOM from Microsoft and Corba from Object Management Group, which both allowed the “reuse” of code at runtime but across different machines. Fast forward to now and we have something similar, albeit more open, with microservices. The key difference now being that these individual services can be managed and scaled better. The full modern architecture is defined as MACH – microservices, API-first, cloud-native and headless – and drives the outcome of business composability (which I have covered quite a bit in previous articles).
As technology leaders, we never want to duplicate our efforts and hence strive for reuse. As such, solutions are getting more complex, but much of that complexity is handled (therefore hidden) by “infrastructure” rather than built into every application.
Going back to the Monese news. Both XYB and TM are developed as modern core banking solutions based on microservices. Initially, Monese utilised TM to manage its ledgers, but it is now moving onto its own in-house development within XYB. Given the launch of XYB’s solution, this makes total sense from a control and cost perspective as well as proving the ability of their own solution.
Therefore, this does not highlight any weakness in Thought Machine. For me, what is exciting is that it highlights the benefits of a composable architecture in both solutions. My understanding is that the change will be complete in a few months with the bulk of the effort in testing rather than development. This to me exemplifies the benefits of modern architectures.
In banking, it means that the modern core solution is a wide set of microservices and no longer a monolithic code base. Modern core vendors are differentiated on breadth, depth and flexibility of their solutions. Some like TM have specialised focus on the core, while others like Mambu or XYB have broader capabilities closer to incumbent vendor feature sets.
In any platform with well-defined interfaces, changes are less risky, require less effort and are completed faster than with older (incumbent) platforms. With legacy core solutions, such “migrations” are typically measured in years, seen as high risk and are hugely expensive.
Utilising standards like BIAN makes all this much more possible as it is easier to compare similar components from different vendors, and as I’ve written before, this takes us closer to the vision of composable banking.
When you marry these composable business services with low-code/no-code configuration tools, now not only do you have flexibility, but you get the agility to make changes without the need for traditional software development lifecycles.
This week, I’m just saying that vendors and the industry generally make a lot of noise and create hype about new technologies, typically well before they have actually been delivered and proven. What I am excited about is seeing the promise of MACH and composable banking being proven by Monese and TM.
I’d also like to express my thanks to James Barker of Plumery and Stuart Mackenzie of TomorrowX for making me aware of the acronym and origins of MACH.
About the author
Dharmesh Mistry has been in banking for more than 30 years both in senior positions at Tier 1 banks and as a serial entrepreneur. He 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 founded proptech start-up AskHomey (sold to a private investor in spring 2023) and is an investor and mentor in proptech and fintech. He also co-hosts the Demystify Podcast.
Follow Dharmesh on Twitter @dharmeshmistry and LinkedIn.
Read all his “I’m just saying” musings here.
