Why Actimize Upgrade Programmes Stall at the Tuning Stage

The pattern

It goes like this. The upgrade is planned as a technical exercise with a regression pack at the end. Environments are built, the new version goes in, the functional testing passes, and the programme reports green for several months.

Then detection output is compared against the old version, the numbers do not match, and nobody can immediately explain why. Alert volumes move. A scenario fires on cases it did not fire on before. Model governance quite reasonably declines to sign off on an unexplained change to a regulated control, and the programme stops — not because anything is broken, but because nobody can prove that it is not.

Upgrades on financial crime platforms fail at sign-off far more often than they fail at deployment.

Why the stall lands at tuning

Tuning is where the regulatory weight of the platform becomes visible. Every threshold on a mature estate is the residue of a decision that was documented and approved, sometimes years ago and often by people who have since left. The current settings are not just configuration; they are an approved control.

Which means an upgrade has to answer a question that ordinary software upgrades never face: is the detection the same? Not “does the system work” but “does it produce the same outcomes, and where it does not, can you explain each difference and show that coverage has not been reduced?”

That is an analytical workstream, not a testing task. It needs someone who can design a comparison, run it across a meaningful data window, investigate every variance and write it up in language a governance committee will accept. If nobody was given that job in the plan, the work starts at the moment the programme thought it was finishing.

The four usual causes

Nobody owns the detection evidence

Test leads own functional and regression coverage. Detection comparison is a different discipline, and on stalled programmes it is usually assumed to be somebody else's. Naming an owner at mobilisation — with the authority to hold the go-live date — removes most of the risk.

Thresholds are carried over without revalidation

Moving the same numbers to a new version feels conservative, and often is not. If underlying calculation, aggregation windows or reference data handling have shifted, identical settings can produce materially different output. The safe assumption is that carried-over thresholds need evidence, not that they need none.

Data feeds are treated as out of scope

An upgrade frequently touches how data arrives — mappings, reference data, enrichment. A field that is now populated slightly differently will change detection while every functional test still passes. Reconciling the feed against source before comparing detection output saves weeks of investigating the wrong layer.

Parallel running is under-resourced

Running old and new side by side needs environments that behave, data volumes that are representative, and time in the plan. It is the first thing compressed when the schedule slips, and compressing it guarantees the sign-off conversation happens without evidence.

What a plan that holds looks like

Two things in that table matter more than the rest. Detection comparison starts at mobilisation, because designing the comparison is itself work. And the governance submission is scheduled with a draft circulated early, so the committee's questions arrive while there is still time to answer them.

Early warning signs

• The plan has a regression phase but no line item for detection comparison.
• Nobody can tell you who signs off model change, by name.
• Threshold carry-over is described as a decision already made.
• Parallel running is scheduled for the last three weeks.
• The delivery lead has run platform upgrades but not on a regulated control.
• Data feed work sits with a different programme and a different date.

Any two of those together is worth raising before the next steering meeting. All six, and the date in the plan is not the date you will hit.