Kill your core

Understanding coreless banking

“Coreless” in this banking context doesn’t mean “without a core banking system”, but rather “core banking system functions are accessed via an independent banking domain layer using well defined APIs”. This approach is supported by industry architecture and service models like that being developed by industry group Banking Industry Architecture Network (BIAN), who are currently working on their next iteration of the Coreless Banking Model, which defines banks’ semantic APIs and data models to support customer-centric value chains.

Coreless banking is a revolutionary architectural approach that decouples traditional, monolithic core systems into a network of interconnected microservices grouped according to and managed in their respective business (sub)domains. It prioritizes agility, scalability, and adaptability, allowing banks to rapidly innovate and respond to market demands without being constrained by legacy infrastructure. By adopting a coreless architecture, banks can choose best-of-breed solutions for different functionalities, leverage cloud-native technologies, and focus on developing their own differentiating features. This leads to improved efficiency, reduced costs and enhanced customer experiences.

Benefits of coreless banking:

• Agility and flexibility. Banks can respond quickly to market changes and customer needs.

• Cost reduction. Reduced reliance on legacy systems and efficient use of cloud technologies to lower costs and scale economically with increasing transaction volumes.

• Innovation. Banks can focus on developing differentiating features and creating a superior customer experience.

• Simplified regulatory compliance. Commodity core ledgers can be chosen for their proven track records in meeting regulatory requirements.

Coreless banking architecture naturally supports multi-core or co-existence deployments, where universal, thin, next-gen ledger can interoperate with a specialist core banking system providing support for some specific products (cards or asset finance are some examples of such solutions). Modern integration capabilities of such systems allow for very flexible deployment options, with a mix of cloud and on-premise systems seamlessly combined.   

The early days: The monolithic core

In the 1960s and 1970s, banks relied on a single, all-encompassing in-house core banking system (CBS). This monolithic system handled everything from account management and transaction processing to interest calculations and fee charging. BankOps users accessed these functions directly through the system's interface.

The rise of specialized systems

As banking products became more complex, in-house CBSs struggled to keep up. Banks responded by adding specialized core ledgers for products like credit cards and mortgages. These systems had their own ledgers, product definitions, pricing rules, and business logic, often with their own dedicated UIs for BankOps users.

While this approach offered a tactical solution, it created long-term challenges. It became difficult to maintain a holistic view of customer accounts and transactions, requiring users to navigate multiple systems and leading to fragmented processes and data silos.

Front-end and workflow integration: A partial solution

The development of front-end and workflow platforms offered a partial remedy. Banks could build or acquire applications to create a common UX layer over the various core systems. This allowed for a single set of user credentials, a consistent look and feel, consolidated role-based access rights, and cross-system workflows.

However, this approach was limited by the integration capabilities of the underlying core systems. Many functions remained tightly coupled with their original UIs, requiring users to switch between systems for complex operations, leading to risky “swivel chair” processes. The ideal model of seamless integration remained elusive and the users were required to use the core system-provided UIs to execute more complex or product-specific operations. The ideal model presented on the diagram above was not possible to fulfil and the resulting real-life architecture looked rather like on the diagram below:

The emergence of the banking domain layer

Banking products evolved from standalone offerings to bundled packages, integrating features like sweeping and mortgage offsets. This demanded deeper integration between core systems and new business logic. The rigid coupling of product features and core systems became inadequate, prompting banks to externalize components for greater agility and control in responding to market demands and regulatory changes. The need for cross-product features, coupled with demands for greater agility in responding to market changes, led to the creation of the banking domain layer (BDL). This layer externalized functions like pricing, product rules and customer management from the core systems, giving banks greater control and flexibility.

While the BDL addressed some challenges, legacy systems' limited integration capabilities persisted. Banks still relied on core system UIs for certain operations, hindering a fully centralised front-end experience.

The dawn of coreless banking

Several developments paved the way for the next evolutionary step – coreless banking:

• APIs and real-time events: These technologies became the standard for integration, enabling seamless and (near) real-time communication between systems.

• New generation of core banking ledgers: These modern ledgers are designed with headless usage and excellent integration capabilities, readily supporting an ecosystem of complementary components.

• Cloud and SaaS adoption: The ability to deploy and run core systems in the cloud or as SaaS offerings made them more attractive, eliminating the need for long-term infrastructure investments.

New core banking systems, free from rigid UIs and business features, allow banks to evolve their architecture by separating standard product features from those that offer unique value. Banks now have the flexibility to decide which functionalities reside in the core system versus the banking domain layer, driven by strategic goals rather than technical limitations.

The coreless architecture

In a coreless architecture, banks divide product features into two categories:

• Non-differentiating, standard features. These are handled by the core ledger, ensuring efficiency and stability.

• Differentiating, value-add features. These reside in the BDL, allowing banks to innovate and tailor products.

This approach allows banks to build their architecture as a composition of best-of-breed components, including both standard core systems and their own custom-built services. The core ledger focuses on transactional processing and calculations, while the BDL handles the unique features that set the bank apart.

With reduced reliance on inflexible legacy systems, banks gain architectural freedom to select the best components from various vendors, including core banking. By focusing core systems on basic functions and exposing features through a standardised model, the overall architecture becomes adaptable, composable and independent of specific core systems, promoting flexibility and agility.

How to make it happen?

Even though the strategic way forward is clear, the core system transformation is never easy and risk free, it also has a price to be paid in money and business disruption. It is critically important to execute this process so that the tactical costs don’t outweigh future gains. Below are a few important considerations:

• It's about the business, not the systems. The reasons and goals of the transformation have to be expressed in the business terms and aligned with the business stakeholders from day one.

• Thin slices are easier to work with. Find use cases in need of innovations; those underinvested in recent years, where better client experience, process digitization, self-service or just automation through integration will make the material difference to the business and implement the new architecture end-to-end for just one use case. Use the experience to plan the evolution of your engineering and business teams to the new model and kick-off the platform and domain capabilities.

• Evolve at steady pace. Follow the thin-slice strategy, building the transformations as a series of iterations, extending foundation/platforms together with domain capabilities. Each iteration should be an extension of the previous one, introducing new business capabilities/products/processes. 

• Start migration early. Data migration should be a prominent part of the transformation journey from the beginning. The close cooperation of the migration team with the launch teams is a good way to discover early and manage data quality and scope issues. It is also an excellent tool to discover and map out those various functions performed by the legacy systems that are not explicitly documented or known.