Client Environment and IBM Dependencies
The client is a mid-sized regional bank with its headquarters in Abu Dhabi and branch operations across five Gulf Cooperation Council states. The bank had been an IBM customer for over two decades, with a core banking platform built on IBM WebSphere Application Server, IBM DB2 as the primary relational database, and IBM MQ handling all inter-system messaging for payments, settlement, and regulatory reporting workflows.
Financial services organisations have particular IBM compliance vulnerabilities that differ from other sectors. Core banking and payment processing infrastructure requires high availability — typically implemented through clustered or mirrored server configurations — and IBM's licensing treatment of high-availability clusters is one of the most complex and frequently disputed areas of IBM compliance. Additionally, the strict regulatory environment in the UAE and GCC banking sector meant the institution could not accept extended disruption to its IBM software estate during the audit period, limiting the remediation options available to the team.
The bank had licensed the majority of its IBM middleware under the legacy Processor Value Unit metric, purchasing entitlements through a combination of direct IBM contracts and regional distributor arrangements over the preceding decade. The institution's IT team was aware that IBM had been transitioning to the Virtual Processor Core metric for many products but had not undertaken a systematic review of whether the bank's existing entitlements remained valid under the new metric for currently deployed versions of the software.
IBM's Audit Letter and Initial Claim
IBM's Software Licence Verification letter arrived during the bank's Q3 audit period and initially appeared to be a routine review. IBM requested deployment inventory data covering the middleware estate and asked specifically for ILMT quarterly compliance reports for all virtualised environments. The bank's IT operations team, experienced in regulatory audits but unfamiliar with the specific requirements of IBM software licence audits, assembled the requested data and provided it to IBM within the initial 30-day window.
The data submission proved consequential. The ILMT reports provided to IBM showed intermittent coverage gaps — periods where ILMT agents had not been running on certain VMware clusters due to infrastructure maintenance windows and a migration from one VMware vCenter cluster to another eighteen months previously. IBM's auditors identified these coverage gaps and applied full-capacity billing for the periods where ILMT data was absent, calculating the exposure across the bank's entire physical server footprint rather than the virtual infrastructure actually running IBM software.
IBM's initial Effective Licence Position, issued approximately eight weeks after the data submission, presented a claim in the multiple millions. The claim had three primary components: first, full-capacity billing for the ILMT coverage gap periods, treating every physical core in the bank's primary data centre as chargeable IBM processor capacity; second, a metric transition shortfall asserting that the bank's current WebSphere deployments required VPC entitlements rather than the PVU entitlements held; and third, a high-availability cluster dispute claiming that the bank's standby DB2 instances in its disaster recovery data centre required separate licences rather than falling within the failover exemption that the bank believed applied.
The bank engaged Redress Compliance after receiving IBM's draft ELP, recognising that the claim required independent specialist analysis before any response was made.
Is your bank or financial services organisation facing an IBM audit?
Redress Compliance has extensive experience in financial services IBM compliance, including ILMT remediation and HA cluster disputes.The Three Core Disputes
Dispute 1: ILMT Coverage Gaps and Full-Capacity Billing
The ILMT — IBM License Metric Tool — is the only approved mechanism for demonstrating sub-capacity licence entitlement in virtualised environments. IBM's position was straightforward: for the periods where ILMT agents were not reporting, the bank lost its sub-capacity licensing eligibility and owed full-capacity licensing fees across all physical cores in the hosting environment.
The sub-capacity licensing policy is clear that ILMT must be correctly configured and reporting continuously. However, Redress Compliance's technical review found that the ILMT coverage gaps were much narrower than IBM's calculation assumed. IBM had treated the entire period from the start of the first coverage gap to the ILMT restoration as a single continuous gap requiring full-capacity billing. In practice, the gaps were concentrated during a two-week VMware cluster migration window and a subsequent five-week period during which ILMT agents on the new cluster were being re-deployed. The physical cores required under full-capacity billing for these specific windows were substantially fewer than IBM's calculation implied, because only a subset of the bank's physical server estate actually hosted IBM software workloads.
A more precise technical argument, supported by VMware vCenter performance data, server allocation records, and ILMT gap documentation, reduced the ILMT dispute component from IBM's original figure to approximately 30 percent of the initial claim value.
Dispute 2: The PVU-to-VPC Metric Transition
The PVU-to-VPC transition is one of the most technically complex and commercially consequential shifts in IBM licensing in the past decade. IBM's PVU metric assigned licence values to processor types based on a processor value unit table — a specified number of PVUs per core varying by processor architecture and model. IBM's VPC metric counts Virtual Processor Cores directly. The transition from PVU to VPC affects both the unit of measurement and the total licence quantity required, and the conversion does not produce identical results for every environment.
IBM's claim asserted that the bank's current WebSphere Application Server deployments, running on current-version software, required VPC entitlements. The bank held PVU entitlements. IBM's position was that PVU entitlements do not cover current-version WebSphere requiring VPC licensing, creating a complete shortfall rather than a conversion shortfall.
Redress Compliance's response challenged this interpretation on two grounds. First, by reviewing the bank's IPLA licence agreements for the relevant WebSphere products, it was established that the licence terms applicable to the bank's purchase included no version restriction and contained a cross-metric use right provision that IBM's audit team had not applied. Second, where cross-metric use rights were not available for specific products, a conversion analysis demonstrated that the PVU quantity held was sufficient to cover the VPC requirement under IBM's own PVU-to-VPC conversion table for the processor types in use. The metric transition dispute was substantially eliminated through this analysis.
Dispute 3: High-Availability Cluster Licensing
IBM's licensing rules for high-availability and disaster recovery configurations contain specific exemptions that allow certain standby or passive instances to be unlicensed or licensed at reduced rates. The conditions for these exemptions are precise: the standby instance must not be actively processing transactions, it must be activated only during a failover event, and the activation must be temporary — typically defined as no more than 30 days in a 12-month period.
The bank's disaster recovery DB2 configuration met the criteria for IBM's cold standby exemption for the majority of the audit period. IBM's auditors, however, had identified that the disaster recovery instances were periodically activated for DR testing exercises and had treated these activation events as potentially voiding the passive-standby exemption for the entire year. Redress Compliance documented each DR test activation period, demonstrating that the aggregate activation time across all DR test events was well within the 30-day annual threshold, and that no transaction processing occurred on the DR instances during test activations. IBM accepted this documentation and withdrew the HA cluster dispute.
Settlement and Forward Compliance Architecture
With all three core disputes addressed, the residual exposure was limited to genuine licence shortfalls for specific ILMT gap periods and a small number of additional DataPower Gateway appliances that had been deployed without corresponding entitlements. IBM's fiscal year ends on December 31, and the Q4 window (October through December) provides disproportionate leverage for organisations that have completed their technical counter-analysis before year-end — IBM's compliance teams face strong pressure to resolve outstanding claims before December 31. This engagement was timed to reach the settlement table in Q4, which strengthened the commercial outcome. The settlement was agreed at 14 percent of IBM's initial ELP value, with no back-maintenance penalties or retroactive fees.
The settlement structure included a commitment from the bank to deploy ILMT correctly across the full IBM estate with zero coverage gaps and to implement a quarterly ILMT compliance reporting process with internal audit oversight. The bank also undertook a forward-looking licence optimisation review, identifying IBM products that had been licenced but were running below the PVU threshold — savings that partially offset the settlement cost in the first year of the revised maintenance arrangement.
Redress Compliance's post-settlement advisory included a PVU-to-VPC transition roadmap for all remaining PVU-licensed products in the bank's estate, ensuring that the metric transition issue identified during the audit does not recur as the bank upgrades software versions in subsequent years. Understanding the PVU-to-VPC conversion table and maintaining up-to-date entitlements that reflect the current metric for each deployed product is essential for any organisation that has been an IBM customer for more than five years and is upgrading to current-version software releases.
IBM Compliance Considerations Specific to Financial Services
Banks and financial services organisations face IBM compliance challenges that are structurally different from those in other sectors. Several factors amplify IBM audit risk in financial services environments specifically.
High-availability and disaster recovery requirements mean that IBM software is almost always deployed in active-passive or active-active cluster configurations. The licensing treatment of these configurations — particularly the passive-standby exemption rules — requires careful management. DR test activations, which are mandatory under regulatory requirements in most jurisdictions, can inadvertently void the passive-standby exemption if not documented correctly and kept within IBM's annual threshold.
Regulatory change programmes drive frequent infrastructure transformation in banking — core banking migrations, payment modernisation initiatives, cloud migrations to hybrid environments. Each transformation event is a potential IBM compliance trigger: new deployments require entitlement verification, migrations may change the applicable licence metric, and ILMT coverage must be maintained continuously even during infrastructure transitions. The ILMT agents do not migrate automatically — they must be explicitly deployed on new infrastructure as part of any migration project's completion criteria.
For financial services organisations in the Middle East and GCC, the additional complexity of regional data residency requirements and multi-jurisdictional regulatory frameworks means that IBM deployments are often spread across multiple physical data centres in different countries, each requiring independent ILMT coverage. IBM's sub-capacity licensing policy applies per deployment location — a coverage gap in one data centre creates full-capacity billing exposure for that location regardless of ILMT coverage in other locations.