Half your SIMs finished the month at 4% of their allowance. A handful hit the ceiling on the 19th and stopped reporting. You paid for both outcomes. The wasted data was billed and the overage was billed on top, and the devices that went quiet were the ones doing the most work.
This is what per-SIM data plans produce at fleet size. The fix is not a bigger plan per device. It is a different unit of allocation.
What IoT SIM data pooling is
Data pooling combines the data allowance of every SIM in a fleet into one shared allocation. A device drawing 400MB a month and a device drawing 2MB a month both take what they need from the same pool. No individual SIM has a cap it hits on its own, and the headroom left by low-use devices covers the high-use ones.
The pool is sized on average usage per SIM multiplied by the number of active SIMs, set at subscription and adjusted as the fleet grows. Usage is monitored against the pool with threshold alerts, rather than against thousands of individual limits.
Why the family plan comparison breaks down
Pooling sounds like a consumer family plan, and marketing copy from connectivity providers leans on that comparison because it is quick to explain. The mechanics look similar. The operating conditions do not.
A family plan has five lines, one country, one carrier, one bill payer who notices immediately when something runs out. Each user has a screen, and a human behind the screen who tops up when prompted. That is the entire model.
An IoT fleet has none of those things.
- The devices are headless. A water meter in a basement has no screen, no user and no way to tell anyone it has stopped. It goes quiet, and quiet looks the same as working.
- Usage is not evenly distributed. A fall-detection sensor connects when an alert fires and sends almost nothing in between. A camera on the same subscription sends constantly. One allowance shape does not fit both.
- The fleet crosses borders. A tracker that leaves Belgium in the morning and arrives in Germany after lunch touches several carrier relationships in a day. Consumer plans treat that as roaming and price it as an exception. For the fleet it is Tuesday.
- Nobody tops up manually. At 5 lines a person reacts to an alert. At 5,000 SIMs a person reacting to alerts is the bottleneck.
- The consequence of running dry is operational, not personal. A phone with no data is an inconvenience. A charge point that stops reporting is revenue lost and an SLA breached.
Stranded data is the cost nobody puts on a slide
Overage charges arrive on an invoice, so they get attention. Stranded data does not appear anywhere. It is allowance that was purchased, allocated to a SIM, and expired unused because it sat on the wrong device.
In a fleet with mixed device types, stranded data is routinely the larger of the two numbers. The way to see it is to pull the usage distribution across the fleet for a full month and compare the median SIM against the top decile. If the median device uses a fraction of its allowance while the top decile breaches, you are paying twice for one problem, and both halves of the bill are avoidable.
What pooling changes operationally
The cost argument is the obvious one. The operational argument is the one that holds even when usage across a fleet is uniform.
One allowance to manage instead of thousands. Forecasting happens against a single pool with a single trend line, not a distribution of per-SIM limits.
New devices inherit the pool. A device shipped into a new market draws from the same allocation on day one. No per-device provisioning decision, no per-country plan to choose.
Alerts become meaningful. A threshold on a single shared pool is a signal worth acting on. Thousands of per-SIM alerts are noise that teams learn to ignore, and ignored alerts are how fleets end up finding problems from customer tickets.
Usage anomalies surface. A device drawing 30 times its normal volume is visible against a pool baseline. The same device hidden inside its own generous per-SIM allowance is not.
Where pooling does not solve the problem
Three limits are worth stating before anyone builds a business case on this.
A pool sized on optimistic usage estimates affects every SIM when it runs out, not one. Shared allocation shares the downside as well as the headroom, so the sizing conversation deserves real numbers from a real month of data.
Pooling improves how data is allocated. It does nothing for coverage. A device with no viable network in a market has a connectivity problem, and no allowance structure fixes that.
Pooling is also not a security measure. Shared data allocation says nothing about where traffic goes once it leaves the radio.
Keeping device traffic off the public internet is a routing decision handled by private networking, and controlling what each device reaches is a separate policy decision again.
How IXT handles it
The IXT Global Data Pool combines the allocation across every SIM in the fleet, across countries and across the 600+ mobile networks One SIM reaches. High-use devices draw from the headroom of low-use devices, and the pool is monitored in the IXT CMP with threshold alerts and live per-SIM usage rather than a 24 to 48 hour reported delay.
Pascal Technologies runs a 5GB shared pool across their vessel fleet for over-the-air software updates and performance monitoring, with vessels moving between countries and no per-vessel overage to reconcile at the end of the month.
Common questions about IoT data pooling
Is pooled data cheaper than per-device plans?
For fleets with uneven usage, pooling removes both overage charges and stranded allowance. For a fleet where every device draws an identical, predictable volume, the saving is smaller and the management argument does the work instead.
What happens when the pool runs out?
Every SIM drawing on it is affected until the pool is topped up. This is the trade-off for sharing the headroom, and it makes accurate sizing at setup the decision that matters most.
Does pooling work across countries?
With a global IoT SIM, yes. The pool is not bounded by market, so a device in Poland and a device in Norway draw from the same allocation.
How do you size a pool?
Average measured usage per SIM multiplied by the number of active SIMs, using a full month of real data rather than a datasheet figure. Devices behave differently in the field than they do on a bench.
Can pooling be added to an existing fleet?
Yes, at subscription level. The devices need no change.
Where to start
Pull one month of per-SIM usage and sort it. Find the median, the top decile and the total allowance purchased. The gap between what you bought and what you used is the size of the problem, and it is a number you already have.
Why trust this guide
This guidance is based on real IoT and OT deployments in regulated industries including energy, utilities, and industrial environments.
IXT designs and operates secure connectivity architectures where:
- devices are deployed across multiple countries and networks
- SIM-level identity is enforced at the network edge
- third-party access is controlled without VPNs
- audit trails are required for regulatory compliance (including NIS2)
The patterns described here reflect how these environments are secured in practice, not theoretical models.
About the author
This article was written by the IXT Connectivity and Security team.
IXT operates a full MVNO core network and delivers secure IoT connectivity across 190+ countries and 600+ mobile networks. The team works directly with industrial, utilities, and infrastructure operators to design and secure large-scale IoT and OT deployments.
Their focus is on network-level Zero Trust architecture, SIM-based identity, and secure device communication without relying on VPNs or endpoint agents.
Related articles