Swedish Bank. IBM audit closed 91 percent down.

A large Swedish bank ran a heavily virtualized IBM estate on VMware. The audit priced every host at full capacity. Proving what the clusters actually allocated closed the claim 91 percent down.

Why did IBM audit the Swedish bank?

IBM audited the bank because ILMT agents were missing from a slice of its VMware estate, and a partial gap on a dense cluster is the most profitable finding an IBM auditor can make. The estate ran Db2 under core banking, MQ across payments, and WebSphere behind customer channels.

Where agents were missing, the auditor priced the whole cluster at full capacity. Hosts that had never run an IBM image were counted because a VM theoretically could have moved there.

• Audit trigger: ILMT agent gaps on a minority of virtualized hosts.
• Publisher position: full capacity PVU across every cluster touched by IBM workloads.
• Customer reality: IBM VMs were pinned to a fraction of the allocated cores.

How was the IBM audit claim defended?

The defense replaced the auditor's theoretical mobility argument with allocation facts. vCenter histories showed where IBM VMs actually ran and what they could consume, and remediated ILMT restored sub capacity eligibility across the estate.

1. Export vCenter allocation and vMotion history for every cluster in the claim.
2. Separate hosts that ran IBM images from hosts that never did.
3. Document DRS rules and affinity settings that pinned IBM workloads.
4. Close the ILMT agent gaps and validate reporting cluster by cluster.
5. Re run the PVU model on documented allocation and settle the residual.

What did the vCenter history actually prove?

It proved the mobility argument was theoretical. The IBM VMs had lived on the same pinned hosts for years, under affinity rules the auditor's model ignored, and the documented core allocation was a fraction of the cluster ceiling.

Why are VMware estates exposed in IBM audits?

VMware estates are exposed because IBM's sub capacity terms make ILMT the price of admission, and any gap lets the auditor price theoretical VM mobility instead of actual allocation. The denser the cluster, the bigger the multiple.

Did the bank have to redesign its clusters?

No. It formalized what already existed: the affinity rules pinning IBM workloads became documented policy, so the licensing position now survives any future audit without constraining operations.

What was the commercial outcome for the bank?

The audit closed 91 percent below the opening claim, settled on documented allocation at contract rates, with ILMT validated across the estate and the pinning rules written into policy.

• Claim reduction: 91 percent off the opening position at close.
• Settlement basis: documented core allocation, not cluster ceilings.
• Forward posture: ILMT coverage monitored as a monthly control, not an annual scramble.

Was the 91 percent reduction unusual?

It was at the high end, and the density explains it. The bigger the gap between cluster ceiling and pinned allocation, the more a records driven defense recovers. Dense virtualization cuts both ways.

Where the common advice on ILMT gaps is wrong

The standard advice treats any ILMT gap as a lost position: pay for the gap period, negotiate the rate, move on. We disagree. In roughly 20 to 30 IBM audit defenses Fredrik Filipsson supported in 2024 to 2025, vCenter allocation histories defeated whole cluster extrapolation in nearly every case where the infrastructure team had kept standard logs. The contractual ILMT requirement is real, but the commercial negotiation runs on evidence, and allocation evidence is usually recoverable. The buyer side move is to fight the extrapolation, not apologize for the gap: remediate ILMT forward, evidence the history backward, and settle only the hosts that actually ran IBM code.

What the engagement data shows

Three cuts of our advisory engagement file frame the size of the opportunity.

What to do next

Six moves turn this case into a smaller number on your own IBM exposure.

A sequence you can run this quarter

1. Map ILMT agent coverage against your full VMware inventory.
2. Document the DRS and affinity rules that pin IBM workloads today.
3. Set vCenter log retention long enough to evidence allocation history.
4. Close agent gaps now, before an audit letter makes them expensive.
5. Re run your own PVU position on allocation facts each quarter.
6. If a notice arrives, route everything through one channel with legal review.

White Paper · IBM

IBM Audit Defense Guide

The buyer side framework we use with Fortune 500 clients defending IBM software audits. Read it free.

Read the white paper

Frequently asked questions

What triggered the IBM audit at the Swedish bank?

ILMT agent gaps on a minority of virtualized hosts triggered it, which let the auditor price entire VMware clusters at full capacity PVU.

How much was the IBM audit claim reduced?

The claim closed 91 percent below the opening position, settled on documented core allocation at contract rates rather than cluster ceilings at list.

Does a partial ILMT gap really expose the whole cluster?

In the auditor's opening model, yes. In practice, vCenter allocation and affinity evidence routinely defeats whole cluster extrapolation during negotiation.

What VMware evidence helps most in an IBM audit?

vCenter allocation history, vMotion logs, and DRS affinity rules. Together they prove which hosts ran IBM images and what those workloads could consume.

Did the bank pay list price on the settlement?

No. The documented residual settled at contract rates, and back maintenance applied only from dates the evidence supported.