The “Goldilocks Principle” and how it applies to core banking solutions
On the one hand, we have the old reliables - the 40+ year old systems that have had facelift after facelift in the hopes of remaining relevant and attractive. I think of these as the aging hipsters who are into cosmetic surgery, the latest fashion, being up on all the latest buzzwords and social media trends, but who are on their second knee replacement and taking several heart medications. Beneath the surface of these systems lurks 'green screens,' proprietary databases, 'spaghetti code' and who knows what else. Yes, these systems will run your institution. And if your view of this technology is that it is simply a utility, you want to come into your office in the morning, flip the switch and you don't care about what it does or how it does it, these are just fine. They will keep the lights on.
On the other hand, we seem to be now presented with a new class of solutions, the "neo-cores". The ones that dominate the pages of LinkedIn and trade publications. These solutions are touted for their 'cloud ready', latest technology underpinnings and their openness. I view these as the new high school graduates. They are full of fire and potential. They will spend hours telling you why they are right, and you are wrong. But they have not actually done anything. They certainly check a lot of the boxes that are top of mind for the bankers who are thinking about how they will compete over the next 5, 10, 20 years. They make a great case for flexibility and lower cost models. But (and it's a big but), how many of these can run your institution?
Now before you cry foul, let me explain. Most experts in the core banking space will tell you that it takes 10+ years and several millions of dollars to build out a fully functioning and regulatory compliant core banking solution. So, while I understand that many of the new cores today can run specific departments and/or functions within a financial institution, you have to ask the big question: can this system run my bank?
This too old / too new dilemma is real and it has many financial institutions stuck. I see many CEOs deciding to ride it out with their current vendor, knowing that the relationship / technology, and / or, pricing is not ideal, but trying to make it until that next best thing is ready. I see financial institutions running legacy technology, trying to slowly introduce more modern components into the tech stack, in an effort to hedge their longer-term bets that some of it will get legs and be the solution to their problems.
But, like Goldilocks, there are current "just right" alternatives to consider. While they are few in number, there are solution's available today that:
- Are built on a modern, open, non-proprietary relational database
- Are built using modern languages such as C++ and C#
- Are using modern REST based API's for third party integration
- Are running in the public cloud
- Are a future proof solution that allows you to plug and play whatever solutions, whenever you want
- And ... drum roll ... can actually run your bank or credit union
So, take heart. There are core solutions available to you if you really want to find one that is not too old, not too new, but just right.