The Real Issue: How Processes Have Evolved - Failure Mode #3: Control stacking in banking processes

When work changes hands too often, controls multiply to manage the uncertainty left behind.

It usually starts with a single event.

An error.

An exam finding.

A breakdown that creates understandable discomfort.

So, a control gets added.

Later, something similar happens. Instead of revisiting the root cause, another control is layered on - just to be safe. Nothing ever comes out.

Over time, processes become surrounded by checks, reviews, approvals, reconciliations - many aimed at the same risk from different angles.

Each control made sense when it was added. Together, they make the work heavier without making it safer.

You can see control stacking in banking processes clearly in everyday bank operations:

Loan boarding reviewed by multiple teams after funding
Account maintenance re‑validated downstream because upstream inputs aren’t trusted
Exception queues where the same issue is reviewed repeatedly with slightly different criteria
Recon items touched multiple times because no one owns fixing the source

Here’s what control stacking reliably produces.

Effort increases without reducing risk: The same risk is reviewed multiple times, often by different teams, using different criteria.
Ownership gets fuzzier, not clearer: When many groups “check the work,” fewer groups feel responsible for getting it right the first time.
The process slows where value is lowest: Controls accumulate downstream, long after the best opportunity to prevent errors has passed.
Staff learn to work around the controls: Not out of malice—but out of necessity. The process becomes harder to complete than to bypass.

Eventually, leaders conclude: “The process is too manual.” “The system can’t handle our controls.” “We need more automation.”

Automation does not resolve the issue of control stacking - it simply causes the stack to execute more quickly.

Unwinding control stacking is not about removing controls - it’s about redesigning how controls work.

Tie controls to clear ownership. When no one owns the outcome, controls multiply to compensate.
Move controls upstream. The earlier an issue is prevented, the fewer checks are needed later.
Enforce trade‑offs. If a new control is added, an old one must come out. Without removal, complexity always wins.
Focus on prevention over detection. Controls that stop errors from happening are far more effective than those that only find them later.

When control stacking is unwound:

Not because the risk went away - but because it was designed into the flow instead of piled on top of it.

That’s the difference between managing risk and engineering it.

Recent Posts