From a Core Banking solution (CBS) with modules for different business lines comprising of deposits, lending, payments, trade which was integrated in the late 1990s through 2000s, focus has shifted to hollowing the core/componentization. From Banks to IT vendors to analysts, the mantra has been same - breaking the CBS into smaller components or build smaller applications which are microservices enabled enabling smooth deployment and easy upgrade. Managing the core banking which has become a behemoth of sorts for banks/IT vendors with multiple ends connected to CBS has been challenging.  With digitization and the constant change in consumer behavior, the transactions hitting the core has drastically increased. Banks continue to experiment with patching/tooling and inhouse development to meet these needs though it is insufficient. The resultant is that the upgrade of Core banking /architecture though a necessity is becoming unthinkable to the CTO/CIO of Banks considering the risks/downtime/migration/integration and the likes.

While CBS has evolved, large banks has taken different approaches and started experimenting with multi system/multi-vendor management for many business lines like lending/Trade/Treasury/Payments knowing the limitations in terms of functionality/processes and moved away from being dependent on monolithic Core. Based on the increased business demands and the necessity for innovation to have an edge on the competitors, Banks are exploring more specialized solutions in multiple areas.  Banks have multiple options to choose from to deploy solutions catering to specialized areas thereby providing better customer experience. Bank’s started using disparate systems for micro loans, retail loans, corporate loans- from origination to lending management to loan collections as the business expanded during the period. Within the Retail lending, there were possibilities of isolated systems for gold loans/Home Loans/Loan against securities because of the complexity of processing for these loans which was unique. While customization within the larger Retail lending system for these products was an option in the short run, Banks felt the need to move to different systems/products over time discarding the cost factor. With disparate systems, Banks faced challenges of integration with Master data Management- Customer, Reference master, Holiday master, Accounting and GL to maintain the single source of truth but were successful. Like Retail loans, in the case of Corporate Loans, Banks moved to multiple systems as no single system was able to meet the varying needs- Term Loans, Syndicated loans, Structured loans, Construction loans all with varying processes and complexity. In a nutshell, Banks reduced dependency on CBS to meet the lending needs and moved to specialized systems. But when volumes and complexity increased, they faced challenges within the specialized systems.

Similarly in the case of payments, with increasing regulations and need for adoption for local/global standards like ISO 20022, RTGS, MT to MX for SWIFT, Banks depended on multiple subsystems to meet the needs of Real time payments, file Based payments, cross border payments - here again the life cycle processes/message types /interfaces varied. The trend continued for Trade Finance services where banks brought different specialized systems for conventional trade, supply chain finance and forex remittances. Banks also adopted different systems for Treasury- may be a global IT system catering to large set of asset classes- Money Market, Securities, Derivatives etc and local software for local products/requirements. During this time Banks also implemented Enterprise General Ledger reducing the dependency on Core for consolidation of the accounting portfolio.

While Core was having limited functionality for many specialized areas, Banks were forced to move to multiple subsystems for processing business for different functional areas and Core remained only for accounting/GL consolidation.  The significance and advantage of Core started subsiding after 2 decades of dominance CBS remained a necessity for banks.

While multiple subsystems were the order of the day for different business lines, Banks remained closely tied up with one single Core Banking solution/single vendor. The concept of multiple subsystems for Core or different core banking systems within a Bank remained in theory – almost unthinkable. With composability and microservices architecture, the Core banking vendor created multiple sub systems to larger remain in relevance to supplement the core. Multiple new CBS vendors with new technology/contemporary architecture cropped up trying to compete with traditional players but lacked in functionality. The maintenance of Core Banking was challenging with different regulations/processes /products which were required to be built within the Core and upgrading to latest version was not an option but mandatory for Banks.  The most common question for a Bank CTO to CBS vendor as part of version upgrade was “How long will the version remain before another upgrade “. To keep changes in technology and to meet market requirements, the CBS vendor was forced to release minor versions every 6 months or so. But still there remained huge gaps with demand from customers/banks increasing and development of functionality within CBS lessened- design issues, domain issues, data base compatibility notwithstanding. Design of new architecture and technology with open systems, open APIs, open database, open platforms were mandated for the core based on market or bank or regulatory or cloud needs.

Multiple central banks in different countries introduced the concept of digital banks which could either be a new entrant or a digital arm of existing bank. This also opened the topic of multi core systems within the banking framework, but banks extended the existing core rather than adopting a new CBS for these needs.
In some of the markets like India/South Asia, the volumes of transactions were quite high, and CBS was subjected to a severe stress test and newer models evolved mostly to meet the high availability and high-performance needs. The number of processors and cores required to handle the high volume was increasing resulting in high costs. Most of the regulators in these markets were not open for cloud adoption which could have helped the application scale horizontally or vertically.

Considering the difficulty in management and maintenance of a single CBS, Banks have still not explored the multi- CBS options where multiple CBS coexists to meet specific needs- business line alignment, performance and scalability needs, new architecture, and technology for innovation ecosystem for the Bank. The current processes of customizing the core beyond its capability impacted the overall performance of the core, making it risky and unviable. From a product perspective, minimizing the customization within the Core has to be the prerogative for Banks and IT vendors.  With master data management and rule engine, multi-CBS management is an option for the Bank to explore from a futuristic perspective for robustness, growth and innovation.

To conclude, while banks have already adopted multi systems for different business interests like lending and Trade, multi -CBS systems will evolve in the next decade and next set of business innovations will emerge out of this. This may possibly reduce the subsystems/number of systems for specialized areas and have stable core systems to meet the needs. While specialized system may score well on functionality and processes, scaling up and modernizing the architecture has always been a challenge for these systems which will be met by robust CBS systems. Multi CBS adoption in banks can challenge the CBS vendors and may increase the competition within the CBS vendors but will also ensure faster development, scaling on architecture and build for the future. This will reduce the monopoly of one CBS vendor prevalent in one geography and not in another and possibly multi- CBS will reduce cost and improve overall business for the Bank. Few years ago, banks were looking at consolidating multiple disparate systems for better management of functions and reducing complex integrations. Thanks to technology, in today’s world of APIs and micro services architecture, seamless integration between multiple systems is very easy to achieve. Unlike earlier, multiple vendors can jointly be part of a Bank’s ‘banking system’ which will act as the ‘Core’ to support the overall banking functions and processes.