Why "Wait Until Next Year's Budget Cycle" Is Now the Most Expensive Decision in Banking

Why "Wait Until Next Year's Budget Cycle" Is Now the Most Expensive Decision in Banking
Matt Deaton - Chief Growth Officer at Devsu
Matt Deaton
May 12, 2026
Share this article

Every IT capital request that gets pushed to next year's budget cycle carries an implicit assumption. 

The assumption is that next year's conditions will be more favorable for the work than this year's. More tooling. More talent. More clarity. A better political moment with the board. A more predictable interest rate environment. A clearer view of what AI is going to do to the industry. 

It's a reasonable assumption in most categories of capital spending. For modernization specifically, it has stopped being true. 

The math behind deferral has shifted. Four mechanisms, each measurable, each independently sourced, now make "wait until next year" the single most expensive decision a financial institution can make in 2026. None of them are speculative. None of them depend on a particular interpretation of where the industry is heading. They are simply the conditions of the labor market, the regulatory posture, and the integration landscape as they exist today. 

This is not an argument that every institution should commit to a multi-year rip-and-replace program. It is an argument that the deferral itself has acquired a price tag, and the price has gotten high enough that it deserves a line item on the executive committee agenda. 

The setup: banking already spends more on technology than any other industry 

A reasonable place to start is the obvious counterargument: we're already spending plenty on technology, we just need to spend it better. 

The data behind that claim is real. McKinsey research finds that banks' IT spending reached 10.6% of revenue and 20.0% of expenses in 2022, with banking typically spending 6–12% of revenue on technology, more than any other major industry, well ahead of telecommunications, media, and technology at 3.75–5.00%. The global figure is roughly $600 billion a year.

If you stop the analysis there, the conclusion writes itself: the industry has a spending efficiency problem, not a spending volume problem. Optimize what you're already paying for. Defer the capital request. 

The conclusion is wrong, but not because the spending data is wrong. It's wrong because the spending volume hides a composition problem. Most of that 10.6% is locked into keeping existing systems alive. McKinsey reports that technology leaders globally now plot themselves into four archetypes based on "run" intensity (revenue share spent keeping systems running) versus "change" investment, with most companies, banks included, trapped in high-run, low-change quadrants.

That is the trap that makes deferral so dangerous. Every year of delay shifts more dollars into "run" and fewer into "change." The institution feels like it is investing in technology while structurally falling further behind. 

What follows is the math on why that gap is now compounding faster than it used to. 

Mechanism one: the talent pool gets smaller every year, not larger 

The legacy engineering labor market is in structural decline. 

Industry estimates consistently put the average COBOL programmer at around 58 years old, with roughly 10% of the cohort retiring each year. Fewer than 2,000 COBOL programmers graduated worldwide in 2024 by most labor-market estimates, and more than 85% of US universities have dropped COBOL from the curriculum since the 1990s. RPG, the AS/400 / IBM i language that still runs significant portions of community-bank and credit-union infrastructure, is in worse shape, with the typical RPG programmer now around 70 years old. 

The implication is not subtle. Each year of deferral is a year in which: 

  • A measurable share of the people who could have done the discovery work retire. 
  • The wage premium for the remaining specialists rises, particularly during forced-modernization episodes when consent-order deadlines concentrate demand. 
  • The institutional knowledge inside the institution, the specific quirks of the specific batch process that the specific person remembers, moves closer to becoming undocumented. 

There is no labor-market mechanism that reverses this. The pipeline is not refilling. The institutions that wait are not waiting for the talent situation to improve, because it will not. They are waiting for it to get worse. 

This matters for budget timing in a specific way. The first phase of any serious modernization, discovery, dependency mapping, decoding the business logic embedded in legacy code, requires people who can read that code. Waiting until the talent has retired means starting modernization without the people who could have made it succeed. 

The uncomfortable implication: the optimal time to modernize is when you still have the legacy specialists to inform the work, not when you no longer do. 

Mechanism two: integration debt compounds faster than budgets reduce it 

The second mechanism is quieter than the talent cliff, but arguably more expensive. 

McKinsey's research on banking IT architecture found that the average number of applications used in banking IT increased from 133 per billion dollars in revenue in 2013 to 224 in 2022, a jump of more than 68%, while the number of application vendors grew almost 60% over the same period. McKinsey & Company 

Every new application added to the existing landscape becomes another integration that has to be maintained. Mid-size institutions typically accumulate one to three new applications per year that further entangle with the legacy core, CRMs, payments rails, analytics platforms, vendor-specific compliance tools, AI experiments, BSA/AML monitoring overlays. 

The consequence is mechanical. Deferring modernization does not freeze the integration landscape in place; it lets the landscape grow more complex while waiting. By the time the institution decides to start, the system that needs to be modernized is not the system that existed when the decision was first deferred. It is a more entangled, more vendor-coupled, more brittle version of that system. 

McKinsey's research on banking architecture finds that on modern modular, API-enabled stacks, new solutions reach production in three to four months. On legacy architecture, the same work takes nine to 18 months. That gap widens every year deferral continues, because every new integration added during the deferral period extends the legacy side of the comparison. 

Mechanism three: the regulatory bar is rising, not holding 

The third mechanism is the one CFOs underweight most consistently. 

The OCC has spent the past three years moving decisively against banks whose legacy IT controls cannot meet current supervisory expectations. The pattern is now established. Looking at OCC enforcement releases from 2023 through 2025, IT-control language appears in a striking share of consent orders and formal agreements. 

Vast Bank's October 2023 order, terminated only in September 2025 after nearly two years of remediation, cited unsafe or unsound practices including those related to capital and strategic planning, project management, liquidity risk management, information technology controls, and risk management for new products. The terminations themselves illustrate the cost: institutions remained under active supervisory constraint for 18 to 24 months while remediating IT-control deficiencies that, in many cases, were rooted in legacy system limitations.

The broader pattern is captured in a recent industry analysis: consent orders are legally binding, publicly filed, and often impose operational limits until remediation is complete, they typically signal systemic control weaknesses rather than isolated issues, and executing them strains resources, staff morale, and leadership focus on strategic priorities.

The Bank of America case is instructive on the direction of travel. As recent analysis put it, the consent order sends a broader message to the industry: regulators expect continuous investment in BSA compliance, and outdated monitoring systems are a liability in an era where financial crime is increasingly sophisticated.

The realistic forecast for 2026 and 2027 is not that supervisory expectations on IT controls will hold steady. It is that they will continue to tighten. Every year of deferral is a year of accumulating exposure to a remediation event that,when it arrives, will require a forced modernization done under regulator supervision, time pressure, and quarterly board reporting. Forced modernizations consistently cost more, take longer, and produce worse outcomes than voluntary ones. 

Mechanism four: the "tooling will improve" argument is now spent 

For most of the past decade, the rational deferral argument had a fourth pillar: wait for better tools. The argument was credible. Modernization tooling was immature. AI-assisted refactoring was a research demo. Dependency-mapping software was either expensive enterprise tooling or hand-built scripts. 

That argument has run out of road. 

AI-augmented modernization is now production-grade for the regulated, legacy-heavy environments that banks, credit unions, and insurers operate in. Discovery cycles that previously took three to six months can now be completed in under three weeks against undocumented codebases. Refactoring patterns that previously required senior specialists doing painstaking review can now be done with human-in-the-loop AI assistance at meaningfully higher throughput. None of this replaces engineering judgment, the human-in-the-loop is the point, but it changes what a small team can credibly execute inside a 90-day pilot. 

This matters for the deferral argument in a specific way. The institution that defers in 2026 is no longer waiting for tooling to mature. The tooling has matured. The institution is waiting for something else, political readiness, budget cycle alignment, organizational appetite, and the cost of that wait is no longer offset by the value of better tooling arriving later. 

The total cost of deferring three decisions for one more year 

The three decisions that show up on most executive agendas year after year, and almost never get made, are: 

  • The channel layer decision. Modernize the customer-facing mobile and web experience now, or wait for next year's budget cycle? Annual deferral cost for a typical mid-size bank, expressed in deposit attrition and foregone acquisition: roughly $4M to $15M, escalating as the competitive gap widens. 
  • The fraud and AML decision. Replace the rules-only fraud engine and modernize transaction monitoring, or extend the existing vendor contract one more time? Expected annual deferral cost: $1M to $3M in expected value, with significant variance — quiet years are near zero, but a year with a major attack or BSA/AML enforcement event runs into multiples of the modernization cost. 
  • The core modernization decision. Begin the strangler-pattern work on the core now, or wait until the current vendor contract is up for renewal? Annual deferral cost: $5M to $25M, with the upper end applying to institutions running undocumented or under-staffed legacy cores. 

For most mid-size US financial institutions, the combined year-over-year cost of these three deferrals falls between $10M and $40M. 

That is the figure the CFO needs to walk into the next board meeting with, not as an argument that every initiative must be funded this year, but as an honest accounting of what the alternative actually costs. 

What changes in 2026 

Three years ago, the rational deferral argument was credible. Tooling was immature, talent was less scarce, and the regulatory posture was softer. None of those conditions still hold. 

The honest comparison facing executive teams in 2026 is no longer "do nothing versus take a risk." It is take the risk of action versus take the risk of inaction. Both have costs. Both have failure modes. Each institution will weigh them differently. 

What has changed is that the cost of inaction is now measurable, and the institutions running the math are increasingly arriving at the same conclusion. 

The first move is not a multi-year program. It is a bounded 90-day proof of value scoped against one specifically-identified pain point, a single high-volume transaction, a single agent-facing workflow, a single fraud-monitoring component, with a written go/no-go recommendation at day 90. 

That is a defensible commitment. "Wait until next year" no longer is. 

Explore more about Velx here!

Share this article

Subscribe to our newsletter

Stay informed with the latest insights and trends in the industry

By subscribing you agree to with our Privacy Policy and provide consent to receive updates from our company.