EXCLUSIVE: “Freedom Fighter” – Cornel Dixon, Plumery in ‘The Fintech Magazine’

The gap between what a bank wants to offer its customers and what its system will allow not only hobbles them, but carries a hidden cost. Plumery’s Cornel Dixon is determined to set banks free.

The core (centralised online real-time environment) is the crown jewels of any bank, protected with a phalanx of protocols, an arsenal of encryption, and a mindset that will defend it to the death. That’s understandable. It needs to be strong, stable and resilient: it’s the beating heart of every operation, the repository for every customer’s personal identifiable information, and exposing it to anything that might compromise its performance is done under extreme caution.

“Oftentimes, when you look at making a core replacement or changing the core, that’s a major risk. The core is not a fast-moving piece of technology and, to be fair, it probably shouldn’t be,” says Cornel Dixon. “But the layer you want speed on and the layer that you want stability and reduced operational risk on, are often blended together or even the same. And in that instance, it’s a real challenge. Making one change can potentially break the entire chain.”

As Head of Growth at Plumery, Dixon is in the business of change, just not the kind that keeps bank executives awake at night. Instead, he advocates for a fully core-insulated approach to modernisation that also releases banks from an under-appreciated cost – vendor lock-in.

“I’ve seen this firsthand several times, unfortunately,” says Dixon. “A bank wants to release a new product, a new feature. We’ve all been there. Customers are asking for it. The market is asking for it.

“Fantastic! How do we get it done? Well [your partners tell you], we can’t do it because the core doesn’t allow it. We can’t do it because we don’t have that capability somewhere in the back end, outside of the core. We can’t do it because our digital platform has some constraints on how we build the app, the UI, the UX, the data layer, whatever it might be.

“That dependency on a vendor turns into meetings, which turn into escalations, workarounds and potentially even concessions. That time cost – something that could have been shipped potentially in two weeks or a month – might turn into two months, three months, maybe even longer.”

If Cloud and APIs were supposed to solve the dependency problem, they haven’t for a lot of banks, says Dixon. So, Plumery came up with an alternative. It offers a platform layer on which banks can build digital experiences while the core remains untouched. It also allows them the freedom to buy or build, depending on budget, skills and strategy, meaning they are not totally dependent on a technology partner and the delivery time remains under their control.

“Dependency is something we really rail against here. Being free of those constraints is important (and) I think key and critical nowadays. That’s because waiting on your backend is a recipe for disaster. Customers aren’t waiting. The market’s not waiting,” says Dixon.

The challenge is as much an issue for the first generation of neobanks who now find themselves sitting on ageing foundational architecture, as it ever was for older legacy institutions, says Dixon. Although the mindset is different.

“On the one hand, more traditional banks underestimate the value of speed. And it’s not their fault, right? If you own a house and you’ve lived in that house for a very long time, and especially if it’s an older building, renovations can be time-consuming and difficult.

“Digital challengers move very quickly. They see a problem, they want to capture the market as quickly as they can because they know that not to move, not to fix a problem, not to find a solution for the customers, means they lose a competitive advantage. That said, they maybe don’t appreciate the regulatory and compliance aspects of financial services in the same way that a traditional bank does, and underestimate a lot of the heavy lifting that’s required.

“But the thing that both neo and legacy banks have in common is that often they have almost false choice. They will choose between ‘we have to build everything ourselves’, and that’s potentially great for the strategy, but it also means that you end up as a bank having to own your legacy in one way or another.

“Or they lean into software companies and vendors that can provide them with the acceleration, but often they get locked into the constraints of the technology, the solution, or the platform that they’re buying.

“That means that, after a few years or even months, they come up against the constraints of technology, whether that is via ownership or by delegated control. And the banks that are able to navigate that and find partners that can actually offer them independence where it matters, they’ll be able to deliver quickly.

“The key thing when looking at the architectural and more process-orientated aspects of delivery is to examine how a bank can take the fast layer, typically digital, that needs to move quickly and innovate, and make sure it’s decoupled from that more resilient, risky layer, in order to change its speed.”

For the entire time he has been involved in fintech, Dixon says this particular space –transformation – has been likened to open heart surgery because core replacement is such a massive undertaking.

“The decision-making around how it’s implemented – how it works, all the risks involved – takes time. They go through all the processes and committees. And then, it’s one, two, three, sometimes more than five years before it’s finished.

“If it takes you a year to roll something out, but it takes your competitor six months, three months or a month, that is a huge competitive disadvantage and a huge risk that’s being absorbed.”

A conscious decoupling

For every organisation doing it right, there are plenty of others getting it wrong, often in ways that are entirely predictable, says Dixon, and could have been avoided by implementing an architecture and strategy that decouples those two key technology layers. ‘Getting it right’ is entirely possible, he says, even if your operational footprint is large and complex. As Dixon puts it: “If you’re operating in one country, you might have multiple challenges on the back. But scale that out for a multi-jurisdictional bank or entity, and that problem then can potentially be two three, 10 times more complex.”

The platform architecture gives them the freedom and agility to’ ‘pick the right battles, place the right bets’ by country, by use case, by line of business, adds Dixon.

“That’s super important. And then being able to essentially not have to build up that same work over and over again, per channel, whether that’s mobile, web, genAI, etc.

“We’ve been working with an organisation that has been doing that exact work, cascading about nine apps across about three countries essentially down into three apps or a single app if you actually look at the code base, and pointing on the backend to different cores.

It’s something most banks don’t think about architecturally from the beginning.

“We break up the dependency between the channels, the orchestration and the back end. We split that up, and we give that foundation, that agility, that speed to customers.”

Plumery, he adds, wants to leave a positive legacy in an organisation, not a load of outdated coding, so old that no-one knows how to change it.

“We want to make sure that, a bit like Shopify or any of those really great Cloud-first kind of companies, everything is documented,” says Dixon. “Training materials are there. Enablement is there. So, it doesn’t really matter who joins or leaves the organisation, it holds the knowledge, not one individual,” he says.

Event-driven architecture

In January 2026, Plumery released AI Fabric, which aims to create an AI-ready foundation for AI-assisted digital banking. Based on an event-driven data approach, the new solution gives financial institutions a standardised way to connect AI and genAI models/agents to banking data, thereby eliminating the need for bespoke system integrations.

It moves institutions away from so-called brittle point-to-point architectures towards an event-driven API-first architecture that scales with innovation. In short, a software design model built around the publication, capture, processing and storage of changes in the system when they occur, and in real or near- real time, thereby removing the need for delayed, batch-based snapshots and enabling AI to assist where it matters most: in-journey, in-context, and in-the-moment.

By reducing those point-to-point integrations and one-off data pipelines, an institution can lessen operational complexity and technical debt, making change cheaper, safer and more predictable, adds Dixon. It also enables them to swap AI capabilities as the ecosystem evolves – exposing high-quality, domain-oriented banking events and data streams in a consistent, governed, reusable way, across products, channels and customer journeys.

“If we want people to take one word away about who we are, what we do, what we give our customers, it’s independence,” says Dixon. “That includes being independent of us. We’re perfectly happy if somebody has a use case that we’ve never heard of and they want to release to the market. Please do! Provide value to your customers and lean on us as an accelerator and as a strong foundation to make that the case.”

This article was published in The Fintech Magazine Issue #38, Page 16-17

The post EXCLUSIVE: “Freedom Fighter” – Cornel Dixon, Plumery in ‘The Fintech Magazine’ appeared first on FF News | Fintech Finance.