← Back to US Banking Information

Run vs Change the Bank: the 2026 portfolio baseline for investment realism

How to frame spend categories so executives can validate ambition, protect resilience, and prevent “crowding out”

InformationFebruary 17, 2026

Reviewed by

Ahmed AbbasAhmed Abbas

At a Glance

A run vs change-the-bank baseline quantifies operational workload, transformation capacity, dependencies, risks, controls, and performance metrics, establishing a fact-based starting point to balance day-to-day operations with accountable, staged change delivery.

Why run/change baselines are now a strategy validation tool

For many banks, the limiting factor on digital ambition is not the target architecture or the product roadmap. It is the spending mix: the proportion of funds consumed by keeping services safe, compliant, and resilient versus funds available to change how the bank competes. A Run vs Change baseline provides an objective reference point for that mix so leaders can test whether strategic commitments are realistic under current operating constraints.

In 2026, this baseline is also becoming a governance instrument. Supervisors increasingly expect evidence of operational resilience, third-party oversight, and control effectiveness. Those expectations are often funded out of “run” capacity, even when the work involves modern engineering and automation. Without a clear baseline, executives can unintentionally approve transformation plans that assume capacity that does not exist, or they can overfund maintenance work that hides as “change.”

Core definitions that make the baseline exam- and board-usable

Run the Bank (RTB): non-discretionary operating continuity

Run the Bank represents the costs required to keep the lights on: transaction processing, platform operations, security and control operation, infrastructure maintenance, support, and mandatory regulatory commitments. RTB is not “low value” spend; it is the spend that preserves safety and soundness. The baseline challenge is ensuring RTB is measurable and transparent rather than spread across change initiatives and vendor programs.

Change the Bank (CTB): discretionary investment to alter outcomes

Change the Bank captures discretionary spend that materially changes capability, cost structure, customer experience, or risk outcomes: new digital journeys, platform modernization, advanced analytics and AI capabilities, and cloud-enabled operating model change. In a mature baseline, CTB is not defined by project labels; it is defined by the value hypothesis, the intended control impacts, and the expected operating cost consequences.

The 2026 shift: from Run/Change to Run–Grow–Transform

Banks increasingly move beyond a two-bucket view because it hides the difference between incremental growth work and true structural transformation. A three-tier model is often used in 2026 to give executives more granular control over trade-offs and sequencing.

Category Purpose Typical inclusions Key governance question
Run Maintain safe, compliant operations Operations, security controls, resilience testing, regulatory commitments, platform support Are we reducing unit cost without weakening control effectiveness?
Grow Expand revenue and capacity within the current model Channel enhancements, automation with near-term ROI, product extensions, capacity upgrades Is value measurable and does it avoid creating new run burden?
Transform Change the operating model and cost base Core modernization, large-scale cloud and data platform shifts, operating model redesign, AI-enabled capability uplift Can the bank sustain delivery and control changes at scale?

This framing supports strategy validation because it separates “more of the same” from “fundamental change,” which is where risk concentration, delivery fragility, and benefits overstatement most frequently occur.

Where the baseline breaks down in 2026

The crowding-out effect is now a resilience problem

Historically, many banks have seen RTB consume the majority of spend, leaving limited headroom for discretionary change. In 2026, the risk is not simply slower innovation. If RTB is inflated by manual controls, brittle legacy dependencies, and duplicated platforms, the bank becomes less able to fund the resilience and cyber upgrades that examiners expect, while still lacking capacity to modernize.

Run and change blur under continuous delivery

Continuous delivery and incremental modernization make “run” and “change” harder to separate. Security hardening, observability rollout, resiliency work, and dependency remediation often ship as frequent releases. A usable baseline therefore needs rules that classify spend by outcome and lifecycle impact, not by whether it sits in a project plan.

Transformation can quietly increase run costs

Cloud adoption, data platform investment, and AI enablement can reduce unit costs over time, but in the short term they can raise RTB through dual-running, new skill needs, added control requirements, and vendor spend. Without explicit baselining, programs can claim CTB benefits while quietly expanding RTB obligations, creating an affordability trap that reduces future strategic options.

Implementation practices that create an objective baseline

Define classification rules that survive governance challenge

An objective baseline requires clear decision rules: what counts as mandatory, what counts as discretionary, and what evidence is required to classify spend. For example, security controls required to meet regulatory obligations should not be re-labeled as “transformation” to protect discretionary headroom. Likewise, product enhancements that permanently increase operational complexity should be charged for their long-term RTB impact.

Measure “run unit economics,” not just totals

Total RTB can look flat while risk rises if volumes grow and controls degrade. Banks strengthen baselines by tracking unit costs and operational signals such as incident rates, change failure rates, and availability impacts. This reframes run optimization away from broad cost cuts and toward disciplined engineering that reduces repeat work and stabilizes services.

Quantify the run impact of change before funding decisions

Investment cases should include a run impact line: incremental operations effort, control testing needs, monitoring coverage, vendor obligations, and decommissioning plans. Requiring this for Grow and Transform categories improves prioritization because it forces an explicit trade-off between benefits and the run burden that must be sustained.

Make decommissioning and duplication reduction a first-class target

The fastest path to freeing capacity is often eliminating duplicated capabilities, retiring brittle applications, and simplifying data and integration estates. If decommissioning is not measurable in the baseline, transformation can become additive: new platforms arrive, old ones remain, and RTB expands.

Creating a baseline that tests whether investment ambitions are realistic

For boards and executive committees, the core decision is sequencing: how much the bank can change while maintaining control effectiveness, resilience, and regulatory credibility. A portfolio baseline becomes strategic when it translates this question into evidence: current run intensity, the affordability of dual-running, the ability to execute decommissioning, and the control capacity to govern AI, cloud, and third-party dependencies.

In that context, assessment-driven baselining can improve decision confidence by linking spend categories to capability maturity. When dimensions such as governance effectiveness, delivery discipline, operational resilience readiness, and control evidence quality are evaluated against portfolio artifacts, leaders can see whether the current operating model can absorb additional change without compounding risk. That is the lens in which DUNNIXER is used by some executives via the DUNNIXER Digital Maturity Assessment, aligning investment prioritization to what the organization can reliably execute today.

Related Briefs

Reviewed by

Ahmed Abbas
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.

References