IBM Audit Defense for a Large Swedish Bank

Client Profile

The client is a large Nordic bank headquartered in Stockholm with operations across Sweden, Norway, Denmark, and Finland. With a balance sheet exceeding €180 billion and approximately 9,000 employees, the organisation offers retail banking, corporate lending, treasury services, and wealth management. Its IBM technology estate is significant: IBM DB2 underpins the bank's core banking data layer, IBM WebSphere Application Server hosts its internal middleware and transaction processing components, and IBM z/OS on a leased mainframe supports legacy batch processing and overnight settlement workflows. The bank had been an IBM Passport Advantage customer for over 12 years and was operating under a mix of individual product entitlements and a partial Enterprise Licence Agreement (ELA) covering DB2 and MQ.

The IBM Software License Review (SLR) notice arrived in Q3 2025, approximately 18 months after the bank had completed a major infrastructure modernisation programme. The project had migrated a significant portion of the bank's distributed IBM workloads from physical servers onto a VMware vSphere environment, adding two new clusters and 24 ESXi hosts over a six-month rollout period.

The Challenge

IBM's audit claim rested on three distinct compliance arguments, each independently significant, and together producing an opening position of €4.8M. Understanding how IBM constructed the claim is essential to understanding how it was successfully challenged.

ILMT Sub-Capacity Coverage Gaps

IBM's License Metric Tool (ILMT) is mandatory for any organisation using sub-capacity PVU licensing on virtualised infrastructure. Sub-capacity licensing allows an organisation to count only the virtual processor cores assigned to a virtual machine running IBM software, rather than the full physical core count of the underlying host. The financial differential between sub-capacity and full-capacity pricing is substantial — commonly a 70–80% reduction in PVU exposure for heavily virtualised estates.

IBM's auditors identified that 11 of the 24 new ESXi hosts deployed during the infrastructure modernisation project had not had ILMT agents installed within IBM's mandatory 90-day deployment window. The gap period spanned 16 months from initial deployment to the date of audit notification. IBM applied full-capacity pricing — based on the maximum physical core count of each unmonitored host — across all IBM DB2 and WebSphere workloads running on VMs hosted on those 11 servers for the entire 16-month gap period. This calculation alone produced a claimed exposure of €2.7M.

SCRT Mainframe Reporting Gap

The bank's IBM mainframe environment, running z/OS for overnight batch and settlement processing, was licensed on a sub-capacity basis using IBM's Sub-Capacity Reporting Tool (SCRT). SCRT generates monthly reports documenting peak MSU (Million Service Units) consumption, which IBM uses to validate that the bank's mainframe licence entitlement covers actual usage. IBM's Licence Information documents require monthly SCRT reports to be generated, validated, and retained. Any gap in monthly SCRT reporting causes IBM to treat the affected months as non-compliant, reverting to full-capacity mainframe pricing.

During the infrastructure modernisation project, the team responsible for SCRT reporting had been redeployed to support the VMware migration. SCRT reports had not been generated for a 14-month period. IBM's auditors identified the gap and calculated a full-capacity mainframe charge — based on the rated capacity of the leased z/OS LPAR — for each of the 14 missing months. This produced a claimed exposure of €1.6M. The combined ILMT and SCRT claims accounted for €4.3M of IBM's €4.8M opening position.

ELA Scope Misclassification

The remaining €0.5M of IBM's claim related to an alleged misclassification of IBM MQ deployments. IBM asserted that several MQ installations on servers covered by the bank's partial ELA were operating outside the scope of the ELA's authorised deployment zones, thereby requiring separately purchased entitlements. IBM characterised these as unlicensed deployments.

The Approach

Redress Compliance was engaged within ten days of the bank receiving IBM's formal audit findings. The engagement was structured across four parallel workstreams: technical remediation of the ILMT and SCRT gaps, methodology challenge across all three IBM claims, licence position reconstruction, and commercial negotiation with IBM's Software License Management team.

ILMT Remediation and Methodology Challenge

ILMT agents were deployed across all 11 previously unmonitored ESXi hosts within five days of engagement. A full configuration audit of the existing ILMT estate revealed two additional issues: an outdated ILMT software catalog on six hosts that failed to recognise newer versions of WebSphere Application Server, and a quarterly reporting schedule that had lapsed on one cluster. Both were corrected, producing a complete and defensible ILMT coverage position before negotiations began.

The methodology challenge focused on IBM's calculation of the full-capacity PVU baseline. IBM had applied maximum physical core counts across the 11 affected hosts without accounting for CPU resource pool constraints applied within vSphere. The bank's VMware environment used defined resource pools with hard CPU limits — IBM software VMs on the affected hosts had access to a capped allocation equivalent to an average of 38% of each host's physical core count. Partition-level analysis of vCenter configuration records documented this constraint and reduced the technically correct full-capacity baseline by 62% for the ILMT gap period, cutting IBM's ILMT-related claim from €2.7M to approximately €1.03M before any commercial negotiation.

SCRT Gap Defence

The SCRT gap required a different defence approach. Because monthly SCRT reports had not been generated, Redress Compliance could not rely on tooling data to reconstruct the missing period. Instead, the engagement team retrieved historical z/OS system management facility (SMF) records — raw operational logs maintained by the bank's mainframe operations team — covering the 14-month gap. SMF data provides granular CPU utilisation records from which SCRT-equivalent peak MSU calculations can be reconstructed. This reconstruction demonstrated that actual peak MSU consumption during the gap period had never exceeded the bank's licenced MSU entitlement. IBM's full-capacity mainframe charge of €1.6M was therefore unsupported by evidence of any genuine licence shortfall. IBM accepted the SMF-based reconstruction and withdrew the SCRT component of the claim in full.

ELA Scope Clarification

The IBM MQ deployment scope dispute was resolved through a detailed review of the bank's ELA terms against the actual server inventory. IBM's auditors had relied on an outdated infrastructure map submitted by the bank at the start of the audit process — one that did not reflect a server decommission programme completed six months prior to the IBM audit notification. Corrected inventory documentation, cross-referenced against the ELA's authorised deployment zones, established that the MQ deployments IBM had characterised as unlicensed were in fact covered by the ELA. IBM accepted the corrected inventory and withdrew the €0.5M ELA scope claim.

Commercial Negotiation

With the SCRT and ELA components withdrawn entirely, and the ILMT-related claim reduced from €2.7M to approximately €1.03M on technical grounds, Redress Compliance entered commercial settlement negotiations with IBM. The negotiation focused on the residual ILMT claim, where a genuine licence shortfall remained following the resource pool analysis. Over eight weeks of structured negotiation, the final settlement was agreed at €610K, incorporating back-maintenance fees for the corrected shortfall period and a forward-looking compliance commitment.

The Outcome

The final settlement of €610K represented an 87% reduction from IBM's opening claim of €4.8M — a saving of €4.19M. Of that saving, €2.1M was eliminated through the combined SCRT withdrawal and ELA scope resolution; a further €1.67M was eliminated through the ILMT methodology challenge; and the remaining €0.42M was achieved through commercial negotiation on the residual shortfall. The engagement was completed in 16 weeks from initial Redress Compliance instruction to IBM's formal closure of the Software License Review.

The bank also exited the engagement with a fully compliant, audit-ready IBM licence position. ILMT was deployed and correctly configured across the entire vSphere estate, with quarterly snapshot automation in place. A mainframe SCRT reporting calendar was established with designated backup ownership to prevent recurrence during future project resource reallocations. The corrected infrastructure inventory was formalised as a living document linked to the bank's asset management platform, ensuring future IBM audit responses are based on current rather than historical infrastructure data.

Key Takeaways

This case illustrates three principles that appear consistently across IBM audit disputes in large financial institutions. First, IBM's full-capacity calculations are frequently based on default assumptions — maximum physical cores, maximum lookback periods, worst-case LPAR ratings — that are technically incorrect when challenged with documented infrastructure evidence. Organisations that accept IBM's initial methodology without independent scrutiny routinely pay significantly more than their actual licence obligation.

Second, the SCRT gap defence demonstrates that the absence of IBM's own reporting tool does not automatically create an enforceable licence shortfall. Where organisations can produce credible alternative evidence of actual consumption — SMF logs, operational monitoring data, capacity planning records — IBM's methodology claims can often be neutralised entirely. Financial institutions in particular typically maintain rich operational log data that is directly relevant to mainframe licence reconstruction.

Third, infrastructure inventory accuracy is a structural audit defence requirement, not an administrative nicety. IBM's MQ claim in this engagement existed entirely because the bank submitted an outdated inventory at the start of the audit process. Maintaining a current, system-linked asset inventory and verifying its accuracy before responding to any IBM information request can eliminate whole categories of audit claim before negotiations begin.