Run vs Change the Bank Budgeting (Capital Allocation Discipline) | US Banking Brief

Why the run versus change split has become a strategy validation test

The budget line between “Run the Bank” (RTB) and “Change the Bank” (CTB) is often treated as a finance construct. In practice, it is a strategy validation mechanism. If a bank’s strategic plan assumes rapid digital modernization, new product velocity, and material experience improvements, then the implied CTB capacity must be plausible given the operational, control, and delivery demands embedded in RTB. Industry perspectives describing the “dual imperative” in banking highlight that operational efficiency and innovation are not competing narratives but simultaneous obligations that must be balanced continuously rather than reconciled annually.

The executive risk is that the framework becomes a proxy for comfort rather than a tool for realism. When RTB is managed primarily as an immovable cost base and CTB is justified primarily through aspirational benefits, capital allocation can drift away from true constraints: resilience obligations, regulatory change demand, technology debt, cyber exposure, and the bank’s proven ability to deliver change without degrading service. Commentators in The Banker and practitioner writing on RTB and CTB frequently point to this conundrum: investment intent is clear, but the mechanics of redirecting spend from legacy burdens to strategic outcomes are structurally difficult inside conventional budgeting cycles.

What RTB and CTB mean in capital allocation and planning

RTB as the bank’s operating control surface

RTB is not simply “keeping the lights on.” In capital allocation terms, it is the spend that protects the franchise: transaction processing stability, customer service continuity, regulatory compliance delivery, security operations, infrastructure reliability, and the maintenance burden of legacy applications. The finance planning implication is that RTB contains obligations with hard downside risk if underfunded, including control failures, service disruptions, and delayed regulatory delivery. This is why many banks treat large portions of RTB as effectively non-discretionary even when cost reduction pressure is high.

CTB as the bank’s ability to translate ambition into executable programs

CTB represents the funded change portfolio: modernization programs, process redesign, platform migration, product and channel innovation, and the delivery capacity that enables strategic outcomes. In capital planning terms, CTB is discretionary only in theory. In reality, it is constrained by delivery throughput, change governance, and operational resilience tolerance. Arthur D. Little’s analysis of banking IT spend patterns underscores a persistent executive challenge: without an operating model that can consistently convert investment into outcomes, shifting the mix from RTB to CTB can raise delivery risk as much as it raises strategic optionality.

RTB and CTB as an executive comparison

Feature	Run the Bank (RTB)	Change the Bank (CTB)
Primary focus	Day-to-day operations and stability	Innovation, transformation, and strategic growth
Typical activities	Transaction processing, servicing, legacy maintenance, regulatory delivery, controls operation	New products and journeys, modernization, automation, process improvement, digital transformation
Primary goal	Operational efficiency, risk management, uninterrupted service	Improved customer outcomes, competitive advantage, long-term simplification
Budgeting logic	Recurring run rate, often optimized via cost control and uptime objectives	Program and portfolio funding, justified through outcomes and strategic contribution
Risk appetite	Low risk tolerance, prioritizing reliability and proven processes	Higher change risk, including newer technologies and delivery approaches

Where the framework breaks in practice

When RTB becomes a permanent claim on discretionary capital

RTB costs tend to rise when complexity rises. Application sprawl, bespoke integrations, fragile batch chains, duplicated data pipelines, and manual controls all increase the run burden. If capital allocation treats those costs as inevitable, the bank can end up financing yesterday’s architecture indefinitely, with CTB reduced to a residual category. Several practitioner commentaries on RTB and CTB describe this pattern as structural: RTB “crowds out” CTB not because leaders reject innovation, but because the institution lacks a disciplined mechanism for retiring complexity and reallocating savings to change.

When CTB is overpromised and under-governed

CTB portfolios frequently accumulate commitments that are individually rational but collectively infeasible. Strategy teams can articulate an ambition for faster product cycles, cloud migration, AI adoption, and process digitization, but the delivery organization may not have the testing maturity, data discipline, or change governance to run these streams safely at scale. Outcome-oriented budgeting arguments in industry writing emphasize that framing CTB as “projects” can itself be part of the problem, because it encourages time-boxed initiatives rather than durable product and platform ownership that reduces run costs over time.

When incentives create a false binary between stability and progress

The RTB/CTB split can become organizational theater: teams label work as “change” to secure investment, while the underlying work actually patches operational deficits. Conversely, truly transformative efforts can be pushed into RTB because they are required for resilience or compliance. Articles arguing that “run versus change is a fiction” are best interpreted as a warning about this incentive trap: the categories can obscure the fact that modern operating models demand continuous change to sustain safe operations.

Capital allocation implications executives should treat as non-negotiable

Resilience and security consume both run and change capacity

Operational resilience, cybersecurity, and third-party oversight are not confined to RTB. They also gate CTB. Modernization programs that expand dependency chains, introduce new platforms, or increase release frequency can increase resilience requirements and control evidence demand. Executive capital planning therefore needs an explicit view of how CTB initiatives change RTB obligations over time, including runbooks, monitoring, incident response, and auditability. Practitioner writing on navigating RTB and CTB stresses that security and resilience must be designed into both categories, or the apparent CTB progress converts into an expanded RTB burden later.

Regulatory change is often the hidden driver of the run rate

Regulatory delivery can appear as “business as usual,” but it behaves like a recurring change portfolio with fixed deadlines and high consequence. Banks that underestimate this dynamic can inadvertently starve CTB of talent and funding, then compensate through late-cycle reallocations that degrade delivery quality and increase control risk. Strategic investing frameworks in financial services emphasize the need for explicit prioritization mechanisms that surface these unavoidable obligations early in planning, rather than allowing them to emerge as surprise overrides.

Automation and modernization only pay back if the operating model can capture savings

CTB cases often assume that automation, process redesign, and platform consolidation will reduce unit costs. The practical constraint is whether the bank can actually remove capacity and simplify controls once change is delivered. Without governance that forces decommissioning, rationalization, and control redesign, savings remain theoretical and RTB does not decline. Industry commentary on process automation in banking frequently highlights speed and cost benefits, but the executive lesson is that these benefits require disciplined retirement of old work, not just the addition of new tooling.

A more realistic approach to RTB and CTB prioritization

Move from project funding to outcome and capability funding

Outcome-led budgeting reframes the question from “how much are we spending on change” to “what outcomes are we purchasing, and what capabilities will remain when the initiative ends.” This approach integrates RTB and CTB into persistent value streams, where the same teams own run reliability and change delivery for defined products and platforms. Practitioner writing on integrating RTB and CTB concepts argues that this reduces handoff risk and makes trade-offs explicit: if the bank wants higher feature throughput, it must also fund the engineering and control practices that keep production stable.

Treat the RTB to CTB mix as a signal, not a target

Boards and executive committees often ask for a target ratio between run and change. Ratios can be useful for benchmarking, but they can mislead if they are treated as the objective. A high CTB share may indicate ambition, but it can also indicate that RTB has been artificially suppressed, storing up resilience and control issues. Conversely, a high RTB share may reflect legacy burden, but it can also reflect disciplined funding of resilience. The decision value comes from linking the mix to observable capability signals: delivery predictability, incident trends, audit findings, technical debt trajectory, and measurable simplification.

Use capital planning gates that reflect change capacity and risk capacity

A practical executive discipline is to require that major CTB asks demonstrate three forms of readiness. First, delivery readiness: clear scope, accountable ownership, and credible sequencing. Second, control readiness: testing discipline, evidence capture, and operational resilience design. Third, absorption readiness: the business and operations functions can adopt the change without creating permanent workarounds. This shifts prioritization from persuasion to proof and reduces the likelihood that capital allocation validates ambition that the organization cannot execute safely.

Executive questions that improve investment focus in annual planning

Which RTB costs are true obligations, and which are symptoms of complexity that should be retired through funded simplification
Which CTB initiatives have an explicit payback path in the form of decommissioning, reduced manual controls, or reduced exception handling
Where does the change portfolio increase operational dependency chains, and what additional run obligations will be created
Which regulatory and resilience commitments are effectively fixed in-year change demand and must be planned as portfolio constraints
What evidence exists that the bank can deliver at the planned throughput without increasing incident rates, audit issues, or production instability
Where are talent bottlenecks concentrated, and are they being treated as structural constraints rather than resourcing inconveniences

Strategy validation and prioritization for focused investment decisions

A credible RTB and CTB budgeting framework does more than separate costs. It tests whether strategic ambitions are realistic given current digital capabilities and whether capital allocation is aligned to the bank’s actual constraints. If the bank cannot evidence delivery predictability, control maturity, and operational resilience at the pace implied by the strategic plan, then a CTB-heavy portfolio may represent unpriced risk rather than purposeful investment. Conversely, if RTB dominates because complexity cannot be retired, then strategic ambition is being financed without the prerequisite simplification required to sustain it.

A digital maturity assessment makes this test explicit by translating broad investment narratives into measurable capabilities that executives can govern. The relevant dimensions are the same ones that determine whether RTB can be reduced without raising risk, and whether CTB can be increased without overwhelming control capacity: technology estate health, automation and simplification discipline, data and control evidence practices, delivery governance, and resilience operations. Used in this decision context, DUNNIXER helps leaders benchmark the current state, identify which investments are prerequisites versus accelerators, and increase confidence in sequencing and trade-offs through the DUNNIXER Digital Maturity Assessment.

Reviewed by

Ahmed Abbas

The Founder & CEO of DUNNIXER and a former IBM Executive Architect with 26+ years in IT strategy and solution architecture. He has led architecture teams across the Middle East & Africa and globally, and also served as a Strategy Director (contract) at EY-Parthenon. Ahmed is an inventor with multiple US patents and an IBM-published author, and he works with CIOs, CDOs, CTOs, and Heads of Digital to replace conflicting transformation narratives with an evidence-based digital maturity baseline, peer benchmark, and prioritized 12–18 month roadmap—delivered consulting-led and platform-powered for repeatability and speed to decision, including an executive/board-ready readout. He writes about digital maturity, benchmarking, application portfolio rationalization, and how leaders prioritize digital and AI investments.

Run vs Change the Bank Budgeting: Capital Allocation Rules That Fund Executable Portfolios