How to buy a 4th-generation core

A decision that defines a decade.

Buying a core is often framed as a technology decision. In reality, it is much more. It is a structural decision about how a financial institution will compete, scale and evolve, and how quickly it can do so. Its consequences therefore will span a decade or more.

Part 1 of this playbook focuses on how to choose correctly: what defines a 4th-generation core, where trade-offs arise, how risks shift rather than disappear, how to build a business case, and how to embed an operating model that sustains change over time.

Redefining the role of the core

For decades, functionality was king. Software was expensive to build, and third-party integrations were difficult to manage. The safest decision was thus to buy the most functionally rich platform available. Core systems were expected to do far more than record-keeping – everything from campaigns to reporting.

That logic no longer applies. Software costs have fallen. APIs are standardised. Event-driven architectures allow systems to interact without being tightly coupled. The ecosystem is no longer the risk; architectural rigidity is.

Yet many institutions are still buying core systems as if integration were the challenge and vertical integration the safer default. In doing so, they are not eliminating legacy. They are recreating it in a modern form.

The answer is not breadth, but discipline.

The answer is not breadth, but discipline. In modern architecture, the core is deliberately stripped back. Its role is two-fold: to serve as the authoritative system of record for transactions and positions, and to act as the stable nexus around which a best-of-breed ecosystem can be assembled.

Many of the functions historically performed by legacy core systems, such as customer interaction and analytics, are decomposed into specialised components. This is not cosmetic. It separates ledger authority from innovation layers. It allows the core to be upgraded without destabilising surrounding capabilities, and for the surrounding capabilities to evolve without compromising structural integrity.

If the core attempts to do everything, it becomes the constraint. Conversely, when the core is constrained to its true purpose as a real-time system of record, publishing authoritative event updates and ensuring every surrounding system operates from the same source of truth, it removes system constraints and opens up long-term adaptability and strategic freedom.

The evolution of core banking

From standalone monolith to ecosystem orchestrator.

The non-negotiables of a 4th-generation core

Understandably, every core banking vendor lays claim to offering the latest technologies. However, there are certain pre-requisites for being a 4th-generation core that can be claimed but are harder to substantiate. For instance, hosting an application in the cloud is not the same thing as being cloud-native. Similarly, adding APIs to a tightly coupled platform doesn’t give composability, it creates latency and complexity.

Even when re-hosted, re-skinned or API-enabled, product logic built over decades persists beneath the surface. Upgrades may be technically possible but are operationally avoided. Each modification increases regression risk. Institutions delay version adoption not for lack of ambition, but because structural revalidation is too costly. Legacy is not eliminated, it is containerised.

A true 4th-generation core is defined by its capacity to absorb change without structural compromise.

It must support zero-downtime upgrades and releases. It must sustain high transaction throughput as volumes rise, scaling elastically without redesign. Resilience must be engineered so failures are isolated and contained, not allowed to cascade into customer-facing disruption. It must enable rapid product iteration without structural rework. Extensibility should allow differentiation without blowing up cost of ownership.

Critically, it must be genuinely composable: interactions occur through stable APIs and published domain events, not hard-coded or fragile point-to-point integrations. Components can be assembled, replaced and evolved independently, without compromising ledger authority or upgrade paths.

If releasing a product or responding to regulation still requires major projects, version locks or structural rework, it is not a 4th-generation core.