Core Banking systems hint at why banks find Agile a challenge

“There’s no way we’d ever build our own core banking system.”

This is a natural reaction from Chief Technology Officers and others across our many banking clients. Understandably so: as their name implies, core banking platforms are central to the operations of most banks, powering basic processes such as cash management which customers rely upon as part of their day-to-day banking service. Accordingly, banks approach changes to their core banking systems with great caution. Updates are infrequent and require meticulous planning; outright replacement is only considered out of necessity – generally, once the functionality has lagged so far behind a bank’s operational needs that it constrains or threatens the provision of customer services. As a result, many such systems in use today were built on mainframe technologies that are now decades behind the state of the art.

It’s easy to surmise that the design of such critical infrastructure is best left to specialists who really understand core banking processes – processes which should, in principle, vary little from one bank to another. It follows as a matter of course that, where the requirement exists, a commercial off-the-shelf core banking product will ultimately offer the best route.

And yet, consider the following:

• Core banking products are expensive. Licensing for leading vendor offerings typically runs to several thousand pounds per bank user, per year. External support for initial configuration, deployment and integration typically runs into millions, even for small firms with limited service offerings. And vendors are acutely aware that once implemented within a bank, their product is set to enjoy a stable tenure of ten years or more, making it hard to apply downward pressure on on-going maintenance and licensing costs.
• Core banking implementations are hard to deliver and don’t always pay off. Budget and timeline overruns are common and attributable to typical factors: unforeseen complexity, limited access to skilled resources, and operational challenges of updating core infrastructure whilst maintaining business as usual. Cognizant have estimated that 25% of core banking change projects fail, and 50% fail to meet the transformation objectives driving them.
• Whilst nominally offering functionality ‘out of the box’, core banking products often require significant customisation to tailor their behaviour and integration to the requirements of the bank – adding project complexity and cost.
• Treating a core banking product as a ‘black box’ invites risk given its operationally critical role. To avoid this, banks’ own technologists need to acquire and retain deep, detailed expertise of all the processes automated by the solution.
• Third party core banking solutions undermine a bank’s agility to evolve their architecture. Without the freedom to change and extend the behaviour and data model down to code/schema level, architects are constrained in how they can adapt a core banking solution to support the delivery of new digital services. Often, they find themselves bridging functional gaps with additional third party and custom components, resulting in mounting technical debt as complexity increases.

Perhaps for these reasons, many challenger banks have taken a different route. Eschewing a core banking application as a fixed component has enabled them to adopt new architectural patterns such as microservices at an enterprise-wide level, enabling innovation at a rate unthinkable for traditional banks. Starling, for example, boast of performing multiple releases of their online services every day, and launching corporate accounts from scratch in around six weeks.

It could be assumed that such radical approaches are only open to smaller banks. Ironically, however, it is generally the larger institutions who have the software development resources to make self-build a realistic option for such major technology components.

We do not, realistically, expect many such institutions to opt for self-build core banking any time soon. The reasons are ultimately the same: in regarding core banking systems as both high risk and non-differentiating, banks will inevitably opt for a buy rather than build route, accepting the many implications and constraints of this.

This does offer a useful lesson, however. In seeking to fully embrace agile innovation, banks need to be prepared to challenge their own thinking, particularly their bias toward the status quo. Those that can do this successfully may enjoy greater competitive success in the digital age.