Core banking architecture: From technical debt to future-proof solutions

What is the fundamental problem with legacy core banking systems?

Udo Oehmig, CTO of BANCOS AG: The main problem is that legacy systems have grown organically – in some cases over decades. Every extension and every workaround is built on top of the previous one. Eventually, the system becomes so complex that nobody can see the bigger picture anymore. The longer such a monolithic core banking architecture is retained, the more it drives up technical debt overall.

What specific implications does this have for day-to-day banking operations?

Three in particular. Firstly: stability becomes a risk rather than something to be taken for granted. A system that nobody fully understands becomes a dangerous dependency. Secondly: rolling out new features is becoming increasingly expensive and time-consuming. And thirdly: integration with external systems is simply becoming commercially unviable.

Added to this is another factor that is becoming increasingly significant: many new technologies can only be used to a limited extent, or not at all, on such a basis – above all, artificial intelligence.

Another risk is often underestimated: the staff. Why?

Because specialist knowledge for code that is decades old is no longer available on the market. When the people who really understand such a system retire or leave the company, that knowledge goes with them.

We know this from our own experience. Our legacy product ran on Informix 4GL – a technology that has been around since the 1980s. Migrating our customers away from this platform is currently one of our biggest challenges. This gives us a very clear insight into what banks with such systems are going through – we’re not speaking in theoretical terms here, but based on our own experiences.

How did we get started on developing the new generation of BANCOS Core Banking?

One point was key: we didn’t refactor. We built it from scratch. That’s a fundamental decision – because when you refactor an existing system, you carry over the mindset of the old system. A genuine fresh start, on the other hand, allows you to make the right decisions from the ground up.

What is the specific architecture of the new BANCOS core banking system?

The platform is cloud-native from the ground up – and deliberately cloud-provider-agnostic. This means a bank is not tied to a specific hyperscaler. For us, this is not just a technical issue, but above all a question of sovereignty: the bank retains control – over its operations, its infrastructure and its data.

We consistently rely on open standards and open-source components – for example, PostgreSQL as the database, Kubernetes for operations, and Terraform for infrastructure-as-code. These are not niche choices – they are the industry standard.

The architecture of the core banking system as a whole is modular and API-first. Each module can be deployed independently, and every interface is accessible via an API – for external partners, for AI applications, and for whatever the future may bring.

What does this core banking architecture mean for AI readiness and long-term stability?

The key point is this: for us, AI readiness is not a feature that is added as an afterthought – it is inherent in the architecture. Clean APIs, a data lake approach to data access, and a system that does not create proprietary data silos. This means that a bank’s data is not stored in scattered, isolated repositories, but is accessible – and that is precisely what is required for AI to deliver added value at all.

As a result, we can offer a future-proof system that is open and modular in design. Such a core banking architecture helps to ensure that technical debt is not allowed to accumulate further, but is structurally prevented.