“The core doesn’t have to go. But it mustn’t determine everything either.”

Urs: What naturally interests me most in my role is this: What are banks really dealing with right now? Do they want to get rid of their core system, or is it more about being able to evolve their IT more flexibly? 
André: I think it’s often the latter. Banks want to become more innovative and faster without immediately calling their proven core system into question. They have to figure out where the existing vendor supports their plans and where they need additional freedom. 

Urs: André, is this the great reconciliation with the core banking system? Four years ago it felt like every other bank wanted something new. And now suddenly many more want to stick with what they have. 
André: (laughs) It’s not quite that simple, of course. Banks are looking at the matter more soberly today. Switching a core banking system is a huge undertaking. It costs money, ties up resources, and comes with risks. If the existing vendor evolves its solution in a sensible way, it’s absolutely legitimate to continue down that path. 

Urs: So better to stick with what you know than to embark on an adventure? 
André: No, that would be too simplistic. What matters isn’t whether a bank stays or switches. What matters is whether its core banking system fits its strategy. Established vendors have done quite a bit in recent years to further develop their solutions and communicate their plans more clearly. That builds trust. At the same time, a bank has to check whether that development actually covers what it needs itself. 

Urs: Especially at Finnova, a lot has happened with Neo. Yet you keep hearing that new core solutions still can’t do everything that established systems have built up over years. 
André: That’s an important point. With a new system, it’s not just about what’s on the roadmap. It’s about what actually works in live banking operations today. Feature parity doesn’t just come automatically. On top of that, there are the specific requirements of the Swiss market. An alternative has to prove itself in practice, not just on a presentation slide. That explains why a switch is currently not necessarily an obvious choice for many institutions. 

Urs: Then the matter is actually clear: you stick with the vendor and follow its roadmap. 
André: Hold on. That’s exactly where it gets interesting. (laughs) Trust is good, but the bank has to know its own direction. If I simply align my IT strategy with whatever my core banking vendor develops next, I give up a piece of control. The vendor’s roadmap has to fit mine, not the other way around. 

Urs: And how does a bank create that leeway without turning the entire core banking system upside down? 
André: By not trying to solve everything through the core. New digital offerings, data applications, or AI solutions can be built specifically outside the core system. The prerequisites are clean interfaces, controlled data access, and an architecture that allows change without having to touch the overall system every time. That way a bank can continue to evolve the existing core and at the same time become more independent. What’s decisive are very practical questions: How long does it take to implement a new function? What does it cost over its entire lifecycle? What operational and integration risks arise? And how easily can we replace individual components or vendors later? Banks should review these criteria regularly. That’s how they identify where the existing core still fits and where they need more leeway. 

Urs: AI is likely to change these possibilities again. With AI, it becomes more attractive to develop certain functions yourself. At the same time, the question arises which applications are better bought and how to combine everything sensibly. 
André: Absolutely, and you’ve just laid that out clearly in your blog that was published recently. But a core banking system is more than code: processes, data, regulatory requirements, and highly critical operations are part of it too. AI can accelerate development, but it doesn’t make a complete rebuild realistic overnight. What matters is where in-house development pays off and where a standard solution is the better choice. Banks need an architecture that enables both and also leaves them room to maneuver in the future. 

Urs: If we come back to the IFZ study: Is it more sensible for a bank today to stay with the existing vendor? 
André: That can’t be answered across the board. Maybe it makes sense to stay with the vendor and modernize selectively. Maybe a switch will be needed in the long term. What’s important is that the bank knows its options and steers its decisions itself. It doesn’t have to know today exactly what its IT will look like in ten years. But it should avoid unnecessarily boxing itself in with today’s decisions. 

Urs: And that applies regardless of whether a bank works with Avaloq, Finnova, or Temenos? 
André: Absolutely. It’s not about favoring a particular vendor or fundamentally calling one into question. What matters is whether the solution fits the bank’s strategy and whether it can continue to evolve without being dependent on the core for every change. 

Urs: And where does Inventx come into play? 
André: We support banks in evolving their overall IT in such a way that it remains stable and at the same time becomes more agile. That includes operating existing systems sensibly, integrating new capabilities, and making dependencies transparent. A system change is not automatically the best solution. Nor should loyalty to the existing vendor prevent a bank from exploring new paths. 

Urs: So the decisive question isn’t whether a bank stays or switches. It’s whether it can still decide for itself tomorrow what it wants to change. 
André: Exactly. Stay stable without standing still. 
 
Source: IFZ survey of Lucerne University of Applied Sciences and Arts