The bank's mainframe bill is a four hour window, managed or not
IBM mainframe software bills in monthly license charges measured in MSU, and the four hour rolling average sets the peak that drives the number: you are billed for the busiest sustained window, not for the month. In regulated banking estates the discipline has a second constraint, because cost control must never undercut the resilience and audit obligations the regulator expects, and the estates that manage both do it through timing, not capacity cuts.
Prepared by Redress Compliance · August 7, 2026 · IBM advisory. Based on 10 to 15 IBM Z estates in banking and financial services reviewed 2024 to 2025.
Executive summary
One batch window set the peak in three of four banks.
The monthly charge follows the highest sustained four hour window, and in our banking reviews a single batch window, often running only a few hours, set the monthly peak in three of four banks: the regulated core, z/OS, Db2, CICS, IMS, and MQ, bills on MLC, so that one window prices the whole stack.
Because the average smooths short spikes, a brief spike matters less than a sustained peak, and the capacity management aimed at the four hour window is the most direct lever on the monthly number.
Soft capping cut metered MSU 8 to 18 percent with no service impact.
Defined MSU limits hold partitions below a planned level, controlling the metered charge: map which workloads create the monthly peak, cap the non critical and test partitions, and reschedule discretionary batch away from the peak window.
The banking constraint shapes the method, cap only what is safe to cap and keep headroom for failover, because the regulator expects the capacity to exist even when the meter should not be paying for it at peak.
Half the estates had never modeled Tailored Fit Pricing against their real profile.
TFP trades the monthly peak for an annual consumption commitment, rewarding growing or variable load and penalizing anyone who commits on a bad baseline: model the real annual consumption, compare the committed cost against the capped MLC trajectory.
And keep an exit and review point in the agreement.
Container Pricing adds the modernization tool, isolating new workloads from the general MLC peak so a new application prices on its own terms instead of raising the bank's peak.
The audit readiness is monthly, because the regulated environment demands defensible numbers. Sub capacity reports, capping policies, and the monthly peak history are the records that support both the bill and the audit, reconciled every month rather than rebuilt at notice.
The account team advice to negotiate a deeper MLC discount inverts the working sequence: capacity discipline lowers the number the discount is applied to, which compounds in your favor every single month, and the discount conversation goes best against a peak already managed.
The pricing models, compared for a regulated estate
| Model | Basis | Best fit |
|---|---|---|
| MLC sub capacity | The peak 4HRA in MSU | Stable, capped workloads |
| Tailored Fit Pricing | Annual consumption commitment | Growing or variable load |
| Container Pricing | Isolated workload terms | New applications and modernization |
| Soft capping | A defined MSU limit | Cost discipline on the peak |
| IPLA one time charge | Owned license plus support | Tools and utilities |
MLC is a capacity charge, and timing is the cost driver. You are billed for the peak your workloads reach, not for steady state, the peak is measured continuously and reported monthly, and different products carry different MLC rates across the same window.
The three watch items for a bank: shift discretionary batch out of the peak window, soft cap test and development partitions, and watch month boundaries, where a single peak sets the charge for the period it lands in.
Cutting the bill without adding regulatory risk
- Manage the meter, never the resilience: banks cut the bill through soft capping and scheduling, not by cutting capacity the regulator expects them to hold.
- Map the peak makers first: identify which workloads create the monthly four hour peak before any cap is set, because the wrong cap starves the wrong work.
- Cap the non critical tier: test, development, and discretionary partitions take the defined limits; the critical online path keeps its headroom.
- Keep the failover arithmetic explicit: the capacity held for resilience is a regulatory obligation, and the capping design documents that it survives every limit.
- Reschedule the batch: discretionary windows moved off the online peak drop the 4HRA directly, the cheapest MSU that will ever be saved.
The IBM Z mainframe negotiation brief
The MLC mechanics, the capping design, the TFP decision, and the renewal sequence worked on a representative regulated estate.
Get the white paper →Tailored Fit Pricing and Container Pricing, modeled not assumed
TFP replaces the monthly peak with an annual consumption commitment governed through the Passport Advantage structure, and it rewards exactly one profile, predictable growth on a variable load, while punishing a commitment set on an unrepresentative baseline: model real annual consumption.
Compare the committed cost against the capped MLC trajectory the discipline above produces, and keep an exit and review point in the agreement, because half the banking estates we reviewed had never run the comparison at all.
Container Pricing answers the modernization question, isolating new workloads from the general MLC peak so a new digital banking application prices on its own terms instead of lifting the bank wide 4HRA.
The general capacity engineering underneath, profile, shift, cap, runs in the mainframe optimization guide, the operational levers in the MSU reduction guide, and the strategy layer in the mainframe CIO advisory.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across banking estates, 2024 to 2025
Across roughly 10 to 15 IBM Z estates in banking and financial services Morten Andersen reviewed between 2024 and 2025, peak capacity discipline cut MLC more reliably than any discount:
Metered MSU reduced with no service impact, once the peak makers were mapped and capped.
Banks priced for the month by one batch window running a few hours.
The audit readiness thread runs through everything in a regulated estate: sub capacity reports, capping policies, and the monthly peak history are the records that defend both the bill and the examination, and they are maintained monthly or they are not defensible at all.
On the mainframe you are billed for a four hour peak, not for the month, and the bank that manages the window, documents the resilience arithmetic, and models TFP against its real profile before IBM proposes one arrives at the renewal with the bill already lowered and the evidence already filed.
Your first five moves
- Map which workloads set the monthly four hour peak, the single batch window that priced three of four banks.
- Soft cap non critical and test partitions, the 8 to 18 percent cut that carried no service impact.
- Document the failover headroom explicitly, so cost discipline never reads as a resilience gap to the regulator.
- Model TFP against your real profile with an exit point, the comparison half the estates had never run.
- Reconcile sub capacity reports monthly, the defensible record for bill and audit alike. The IBM practice runs the estate with you.
Frequently asked questions
How does IBM mainframe MLC pricing work?
Monthly license charges meter software by capacity in MSU, billed each month against the peak your workloads reach rather than steady state: the four hour rolling average sets the number, and the core banking stack, z/OS, Db2, CICS, IMS, and MQ, commonly bills on it.
Sub capacity pricing bills the measured peak rather than the full box, reported monthly.
What is the four hour rolling average?
The billing basis: IBM charges the highest sustained four hour window in the month, so the average smooths brief spikes while a sustained window sets the bill.
That makes timing the cost driver, and in our banking reviews a single batch window running a few hours set the monthly peak in three of four banks, which is why capacity management aims at the window.
How do banks cut mainframe costs without adding risk?
By managing the metered peak, never the resilience: disciplined soft capping cut metered MSU 8 to 18 percent with no service impact, applied to non critical and test partitions after mapping which workloads create the peak, with discretionary batch rescheduled off the window.
The capacity the regulator expects for failover stays held and documented; the meter just stops paying peak rates for timing accidents.
Should a bank move to Tailored Fit Pricing?
Model it first: TFP trades the monthly peak for an annual consumption commitment that rewards growing or variable load and punishes a bad baseline, and half the banking estates we reviewed had never compared it against their actual profile.
Model real annual consumption against the capped MLC trajectory, and keep an exit and review point in the agreement.
What is IBM Container Pricing?
A model that isolates new workloads from the general MLC peak, pricing them on their own terms: for a bank adding digital applications.
It means modernization workloads do not lift the estate wide four hour rolling average, which keeps the new application's economics separate from the regulated core's peak.
What mainframe records does a regulated bank need for audit?
Sub capacity reports, capping policies, and the monthly peak history, reconciled every month: they are the evidence supporting both the bill and any examination, and in a regulated environment the numbers must be defensible continuously rather than rebuilt under notice.
Monthly reconciliation is the discipline that makes the same file serve cost control and compliance at once.
