Run vs Change the Bank Capacity Model (Throughput Allocation) | US Banking Brief

Why RtB versus CtB is back on the executive agenda

In banking, transformation ambition is increasingly constrained by a simple reality: the same people, platforms, and governance forums must deliver both stable operations and continuous change. The classic Run the Bank (RtB) versus Change the Bank (CtB) distinction remains useful, but only when it is used as a capacity model rather than as an accounting label.

Executives validating ambition level are effectively asking an ambition reality-check question: how much change can the bank absorb without degrading operational resilience, control performance, and customer service, and what must be stopped or simplified to create room for strategic work.

Define RtB and CtB in operational terms, not organizational silos

Run the Bank: stability, efficiency, and control continuity

RtB covers the activities required to keep services safe, compliant, and available. This includes day-to-day customer operations, transaction processing, incident management, and business continuity. In technology and operations, RtB also includes maintaining existing platforms, supporting regulatory reporting and ongoing oversight activities, and sustaining the controls that supervisors expect to be continuously effective.

RtB is not discretionary. If RtB is under-resourced, the outcome is not simply slower change; it is higher incident volume, control breaks, and escalating remediation load that consumes even more capacity.

Change the Bank: delivery of new capabilities and structural simplification

CtB includes initiatives that materially change how the bank competes and operates: new products and experiences, cloud and platform adoption, AI and automation, data and analytics modernization, and core upgrades. CtB should also include the work that removes future RtB burden, such as decommissioning, standardization, and reducing integration sprawl.

In practice, the line blurs because modern outcomes are always both running and changing. Payments, digital channels, fraud, and cyber defenses must evolve continuously. Treating them as episodic CtB projects often leads to an accumulation of temporary fixes that permanently raise RtB costs.

The ambition reality check: cost, complexity, and capacity constraints

RtB versus CtB becomes decision-useful when it is translated into the constraints that govern throughput. Three constraints repeatedly determine whether strategy is realistic.

Cost: the RtB “tax” and the CtB illusion of available funding

Banks commonly describe a majority share of spend as RtB and a smaller share as CtB. The problem is not the split itself, but the hidden consumption that sits outside program baselines: audit and exam work, remediation obligations, third-party risk management, unplanned incidents, and policy and control updates. These demands consume the same constrained roles that CtB relies on, reducing the “usable” portion of both budgets and time.

Complexity: when the portfolio creates more work than it delivers

Complexity is the primary multiplier of cost and time. Parallel architectures, duplicated tools, bespoke integrations, and inconsistent data definitions increase testing effort, release risk, and evidence production. A transformation portfolio becomes unrealistic when each incremental change increases the burden to run, govern, and assure the environment.

Capacity: the bottlenecks are roles and decisions, not headcount

Capacity constraints typically sit with product ownership, platform and data engineering, cyber and resilience engineering, control owners, testers, operational SMEs, and the decision forums that unblock work. When these bottlenecks are spread across too many initiatives, throughput falls, quality degrades, and the bank compensates with workarounds that raise RtB burden.

A practical RtB versus CtB capacity model executives can govern

A workable capacity model helps leaders convert debate into decisions. The goal is not to perfect categorization but to quantify trade-offs and protect execution quality.

1 Classify work by outcome and obligation

Classify demand into three buckets: mandatory obligations (regulatory, remediation, and resilience work), run sustainability (platform upkeep, controls, service management), and strategic outcomes (growth, customer experience, structural simplification). This makes explicit when CtB plans are being built on capacity that is already committed.

2 Measure “usable capacity” for constrained roles

For constrained roles, track available hours after obligations and operational volatility are deducted. Treat sustained incident volume, recurring audit requests, and repeated rework as signals that usable capacity is overstated. If the model assumes 100% availability, it is not a capacity model; it is a wish list.

3 Quantify the dual-running and transition load

Transformation creates a transition load that behaves like RtB: parallel run, additional monitoring, reconciliation, procedural updates, and training-to-proficiency time. Executives should require that this transition load is forecast, staffed, and funded explicitly, otherwise CtB will cannibalize RtB and increase operational risk.

4 Require stop decisions and decommissioning as capacity creation

Capacity is created when the bank stops work, retires systems, and removes complexity. If the plan only adds CtB initiatives without specifying what will be decommissioned or deprioritized, the portfolio is structurally unrealistic. Make decommissioning and standardization visible as first-class work with owners and dates.

5 Align governance to throughput, not reporting volume

Governance should accelerate decisions and reduce rework. Standard patterns for security, compliance, and evidence expectations reduce late-stage friction. Where governance multiplies forums and bespoke reporting, it becomes a capacity drain that cannot be offset by delivery methodology changes alone.

Integrating RtB and CtB through outcome-led funding

Many banks are moving toward outcome-led funding and more continuous delivery models to reduce the artificial boundary between run and change. The executive ambition check is whether the model actually reduces complexity and decision latency, or whether it simply renames work while leaving underlying constraints untouched.

A practical posture is to fund outcomes (for example, a customer journey, a payments capability, or a fraud domain) with explicit allocation for both reliability and evolution. This creates a clearer accountability loop: teams own service stability, control performance, and delivery throughput, while leaders can make trade-offs transparently rather than through periodic budget reshuffles.

Using maturity evidence to validate ambition in the RtB versus CtB model

A disciplined ambition reality check benefits from evidence about the bank’s actual digital capability, not just its declared priorities. A digital maturity assessment supports this by mapping RtB and CtB constraints to measurable readiness across platform modernization, delivery discipline, data and analytics foundations, operating model effectiveness, and integrated risk and control execution.

Used for strategy validation and prioritization, the assessment helps executives identify where RtB cost and complexity are structurally consuming CtB capacity, which modernization moves will reduce future run burden, and how quickly the bank can responsibly increase change throughput without compromising resilience. Within that governance framing, DUNNIXER can be referenced as one assessment approach, with the DUNNIXER Digital Maturity Assessment helping leaders quantify constraints, set realistic sequencing, and improve decision confidence when calibrating ambition against deliverable capacity.

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 Capacity Model: Allocating Throughput Without Stalling Transformation