Mbanq engineering executive warns banks over application sprawl

Large banks that run thousands of applications face rising technology complexity, higher operating burdens and slower digital change, according to Igor Kostyuchenok, senior vice-president of engineering at Mbanq. In a Finextra Community opinion piece, Kostyuchenok argued that a bank with 3,000 applications is dealing less with a coherent technology plan than with accumulated systems from acquisitions, business-line purchases and unfinished IT programmes.

Kostyuchenok said each application adds integration work, security exposure, vendor oversight, compliance duties, licence expense and demand on engineering teams. He wrote that an estate of 2,000 applications leaves no single system well understood, while 5,000 makes the overall architecture difficult to comprehend.

The argument is material for banks investing in artificial intelligence and real-time decisioning. Kostyuchenok said a fraud model depends on the data it can access, a credit decision system is constrained by the slowest link in its chain, and AI programmes require clean, current data across product lines. Where customer information is split across dozens of systems that do not exchange data effectively, he argued, AI tools cannot form a complete view.

How software sprawl builds up

Kostyuchenok identified mergers and acquisitions as the main cause of application proliferation. In his account, acquired banks often bring separate core systems, lending platforms, card processors and customer relationship management tools. Because full integration can be costly, those systems remain in place, while middleware, flat files and manual processes become the practical connection layer between them.

He also pointed to business-led technology purchasing. When central IT teams cannot deliver quickly enough, individual divisions may buy reporting tools, workflow software or customer systems for their own needs. Kostyuchenok said these decisions can appear reasonable on their own, while collectively creating an application estate that no one deliberately designed.

The obstacle is also institutional, he wrote. Applications have owners, budgets and internal influence attached to them. Removing software can therefore affect people and power structures as much as systems, which may lead technology leaders to add new tools rather than retire old ones.

Data first, then system reduction

Kostyuchenok said banks should not attempt to cut every application at once. He argued that chief technology officers should begin by mapping systems that hold or process customer, transaction and financial data, then trace how information moves between them.

Under that approach, the first priority is to identify points where data from multiple sources already comes together. Kostyuchenok said those platforms should become the foundation for consolidation. Banks can then retire systems at the edge that perform functions already covered elsewhere, provided data is moved out before the system is shut down.

He warned that removing an application before rebuilding the surrounding integration can make data inaccessible. Once data flows are understood and alternative platforms are in place, he wrote, application counts can fall materially within 12 months, including by half in some cases, because the architecture no longer depends on the surplus systems.

Finextra labels the post as external content provided without editing and says it reflects the author’s views. Kostyuchenok concluded that the CTO’s role is to understand the application estate, decide which systems no longer belong and impose discipline before approving further additions.

This story draws on original reporting from Finextra Research.