RBS Locked Out 6.5 Million Customers Over One Batch Update. The Failure Wasn't the Change — It Was Not Knowing What It Touched.

The Meltdown Wasn’t About Old Code

On June 19, 2012, someone at RBS applied what was supposed to be a routine update to CA-7, the batch scheduling software that controls overnight job processing for RBS, NatWest, and Ulster Bank. The update went wrong. A relatively inexperienced operative, backing out of the upgrade, ended up deleting the files holding the schedule for that night’s batch run, so the overnight jobs didn’t run — or ran incorrectly. The result: 6.5 million customers locked out of their accounts for four days, wages and payments not posted, and eventually £56 million in regulatory fines once the FCA finished investigating.

The postmortems that followed pointed at inadequate testing and poor documentation around the update procedure — not at COBOL itself, and not at the age of the batch jobs. The system had been running that schedule for years without incident. What failed was the ability to know, before the change went out, exactly what that scheduler update would touch.

TSB’s 2018 Migration Told the Same Story at Larger Scale

TSB’s IT migration disaster six years later followed a similar shape, at a bigger scale and a longer timeline. An independent review by Slaughter and May found that IT contractor Sabis had recommended testing only one of two new data centers to avoid interrupting ATM service — and live-environment testing didn’t happen until after all customer data had already been migrated. The two data centers, meant to be configured identically, turned out to be inconsistent in ways that only surfaced once real traffic hit them. Of roughly 2,000 defects the testing process actually surfaced, only 800 were reported to the board before go-live. The bill: £366 million in total costs, 80,000 customers who left the bank, and a further £48 million fine from the PRA and FCA — plus a personal fine for the bank’s former CIO for failing to properly oversee the migration.

Neither incident was a story about code nobody could read anymore. Both were stories about a change — a scheduler config, a data center cutover — going out without anyone having a reliable, complete answer to “what does this actually touch?”

Impact Analysis Is Still the Unsolved Part of Modernization

That gap hasn’t closed with time. Celent’s analysis of 127 core banking transformation projects run between 2015 and 2025 puts the overall failure rate at 37%, and separate Gartner research finds that roughly half of core banking transformations fail to meet their original objectives or get abandoned outright due to complexity. The split by approach is telling: “rip-and-replace” cutovers fail about 58% of the time, while phased migrations succeed around 71% of the time — phased migration works better largely because it forces teams to understand and validate one slice of dependencies at a time instead of betting the whole estate on one cutover night.

That’s the same lesson RBS and TSB paid for the hard way: the risk in legacy systems isn’t concentrated in the code being old. It’s concentrated in nobody having a current, trustworthy map of what depends on what before someone changes it.

Why an AST Graph Is an Impact-Analysis Tool, Not Just a Reading Aid

This is the problem Legacy Dragon’s interactive AST graph is actually built to solve, beyond the raw speed of parsing a 1,200-line COBOL program in about 6 milliseconds. A graph that maps control flow and data dependencies structurally — which programs call which paragraphs, which jobs read which files, which copybook fields feed which downstream calculations — is the thing you’d want in hand before touching a batch scheduler or cutting over a data migration, not the thing a review team reconstructs by hand after an outage has already happened. Because it’s generated deterministically from the source itself rather than from documentation that ages the moment it’s written, regenerating that graph after every change keeps the blast-radius picture current instead of stale.

None of this claims a dependency graph would have single-handedly prevented RBS’s scheduler corruption or TSB’s data-center mismatch — those failures had organizational and process causes too, not just technical ones. What a structural, always-current map of dependencies does change is whether “what else does this touch” is a question a team can actually answer before a change ships, instead of one investigators spend months answering afterward.

---

Trying to answer “what does this actually touch” before your next legacy change ships? See how Legacy Dragon’s AST graph works at dragon.aitytech.com, read more on why it starts from a deterministic graph instead of a generative rewrite, or reach us at hello@aitytech.com.