The Fintech Development Problem Nobody Budgets for: Legacy Infrastructure

A team develops a new wallet, a new payment flow, or a new API layer, and the final product itself comes together on schedule. After that, it has to connect to a bank's core system or a partner's back office, and suddenly the timeline stops moving: the product is complete, but the infrastructure it depends on is not. This was not anticipated at the kickoff meeting, because this problem never shows up in a product specification. It is one layer below the surface, in a system not owned by the product team and rarely visible until integration begins. In fintech development, this happens often enough to deserve its own name: the new-product, old-core problem.

Take a digital wallet that needs to settle transactions with a partner bank. The wallet's own architecture assumes near-real-time confirmation: when a customer taps to pay, the transaction either clears or fails within seconds. The bank, on the other hand, continues to process settlements through a nightly batch export, a fixed file generated once a day. There is no API in front of it. You cannot ask the system whether a transaction cleared at 2 pm. The answer only exists once the overnight run has finished.

One detail on the bank's side reshapes the wallet's entire architecture. The product team now has to build a holding state for transactions that are technically pending until the next batch confirms them, design around a settlement window instead of a settlement moment, and explain to users why a transfer says "processing" for hours rather than seconds. The initial product specification doesn't include any of that, which is a gap we cover in more detail in our piece on digital wallet providers. It surfaces only once integration begins, and by then, it has already altered the delivery date.

Core banking systems rarely stay outdated by accident. A mistake there carries different stakes than a bug in a customer-facing app because touching them entails touching the system of record for every account balance and every regulatory report the bank files. Documentation is often thin or missing, written by people who left years ago, which makes any change harder to scope with confidence.

There is also a straightforward incentive mismatch. While a core banking transformation must compete for funding against features that the board and customers can actually see, the core itself, as long as it is still running, does not look like it needs anything. Legacy systems in banking survive not because no one notices them, but because everyone who could replace them has a short-term reason not to. As a result, the core continues to function just well enough that no one prioritises fixing it, right up until a new product directly depends on it.

Once you know where the gap sits, there are really only two structural ways to close it, and the choice between them shapes the schedule, the risk the business is taking on, and how much disruption it has to absorb along the way. Both are worth understanding before deciding which one fits the system in front of you.

A full replacement means designing a new core system and switching over to it in one move. Although it might be effective, it concentrates risk into a single cutover point, and a bank that processes live payments has little appetite for a weekend where everything might not come back up correctly afterwards. The strangler pattern takes the opposite approach. Components of the old system are replaced one at a time, with the new and old running side by side, until each piece is fully migrated and the legacy component can be switched off. Hollinford's breakdown of the strangler pattern in practice goes into this in more depth, including where it tends to go wrong.

For a fintech product, this is not a theoretical concern. Payments cannot stop clearing, and onboarding cannot pause while a core system is rebuilt underneath them, because both are revenue and both become visible to customers the moment they fail. In this situation, component-by-component migration usually works better than a complete rewrite because each component can be tested and rolled back separately, preventing transactions that haven't been touched yet from being cancelled due to an issue with one component. The migration schedule is actually determined by the business's tolerance for risk in each area rather than by a set cutover date, and the most customer-visible and riskiest flows are typically moved last rather than first.

Building the fintech product and modernising the core underneath it are entirely different jobs, which is why treating them as one project usually slows both down. A team like Qulix is built to design and ship the product itself: the wallet, the payment flow, the API layer that customers actually touch. It takes a different kind of team to audit a core banking system, map out what depends on it, and plan a safe migration. These tasks are more closely related to systems archaeology than product development.

That kind of audit-and-migration work is exactly what consultancies that specialise in legacy system modernisation provide, and Hollinford's work in this space is a useful example of what it looks like in practice. Before suggesting whether to stabilise, migrate, or replace a system, it is necessary to evaluate what it truly supports, including the undocumented reports and integrations built around it. Bringing in that kind of partner early, before the product team hits the wall rather than after, is usually the difference between a modernisation plan and a delay.

A fintech product can be built in months. The infrastructure it depends on, a partner's core banking system, a bank's settlement process, often cannot be changed on the same timeline, and pretending otherwise is how launch dates slip. You will not fix this by building faster. What fixes it is spotting the infrastructure gap before the build starts, not after integration testing reveals it, and bringing in the right expertise for the core system while the product team stays focused on the product.