One core to rule them all – part two
In my last column piece, I discussed the high-level business requirements or capabilities that the ultimate core banking solution should support.
The business of banking is changing, and much of that is only possible with new technology
This week, I’ll take a look at the technical requirements.
As I said previously, there is no point in specifying something as a requirement if it cannot be fulfilled. This is most easily seen with technical requirements. The cost and capability of technology has dramatically changed since the very first core banking solutions were created in the 1960s. In that timeframe, banking too has dramatically changed. Some of my requirements are not new, but mostly I’m looking to cover what’s not possible with legacy technology.
My high-level technical requirements can be summarised as follows:
Composable
As I have written a lot about this before, it is clear that I’m a fan of composable solutions. Standards like BIAN that define the components of a complete banking solution are key to enabling composability.
Composability enables the ‘eat as much as you like’ (EAMAYL) requirement I discussed in my last article. However, it also fulfils the requirement of not having to rely on a single vendor for everything in your solution. Composability requires the core banking solution to be componentised.
These days, solutions like microservices enable components to not only be developed and executed separately, but also deployed individually. This simply was not possible before. Composability fosters greater innovation and progress for banking software as new players increase competition to serve banks better.
Flexible
When I first started in banking software, the mantra for development was “build to spec”. Why build in flexibility to support something we don’t have requirements for? It’s one of the reasons banks have multiple cores. In our ultimate super-core, we must have flexibility everywhere, not just the flexibility to support product innovation or to replace suppliers.
Scalable
In the past, if you wanted to grow, you would need to buy a bigger mainframe because it wasn’t possible to scale using the software. These days, it’s now possible to do this AND control resources (memory, threads and so on) at a more granular level. This is not only more efficient, but it also allows you to scale further – at some point even hardware will have limits.
This makes software development much more complex, as componentising the previous monolith is not simple. These components have to be able to run independently – something you need not worry about in a monolithic solution.
Again, without getting too deep, there are many other technical challenges when it comes to leveraging software scalability. However, it’s important to realise that the first generation of “cloud banking software” typically was just enabling the monolithic software to run in a cloud environment and not gaining the full advantage of designing specifically for a cloud environment.
Deploy anywhere
This may be controversial, but I’m going to put it out there anyway. It is not a given that banks should move everything to the cloud. With Software-as-a-Service (SaaS), banks can consume all these different software services that are running on different cloud providers. This makes things like business resilience harder for banks as they are still accountable for what these solutions do even though they are not under the banks’ control (more on this in future posts).
Indeed, the challenges are significant enough that I hear some banks are considering moving solutions back on premise. So, our solution should be designed to be deployable natively on the cloud as well as on premise.
Secure
This is a given, so I will say the obvious: things are much more complex when you have parts of your solution running in different environments/clouds. In addition to this, banks have a small taste of the challenges when providing API access for external parties for open banking. Many banks are also now joining the BaaS party, typically using third-party solutions, which further adds to the burden on their security teams.
When you consider these requirements, and I know there’ll be others you’ve thought of, it’s easy to see:
- why banks should consider modernising their core as a minimum, if not replacing it altogether.
- why banks and incumbent core vendors can’t migrate their solutions to new technology.
- why the next generation of core banking software is very different from the past.
Conclusion
This week, I’m just saying that in the past, technology simply automated banking. Now, the business of banking is changing and will continue to do so, and much of that is only possible with new technology. One example of this is that BaaS is a shift from banks owning distribution channels to focusing on manufacturing products and services and letting others manage their customers.
I don’t think there is any product on the market that delivers the ultimate core banking solution, certainly not one that can support an entire bank spanning different customer segments, products, geographies and brands. However, some players are much closer to offering ‘one core to rule them all’ than others.
If you think I missed any really important requirements, please don’t hesitate to let me know on LinkedIn and X @DharmeshMistry.
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.
