Sizing a 16-port SMS modem for fintech OTP is not a question about sixteen ports. It is a question about how many codes must be delivered inside a window during the busiest minute of the week, and whether the answer fits.
This article sets out how authentication traffic peaks differently from campaign traffic, how to derive a port count from the peak rate, why the delivery window rather than throughput is the real constraint, and how to size redundancy and fallback for a path that users notice immediately.
Why does fintech OTP traffic peak differently when sizing a 16-port SMS modem?
Because the peak follows user behaviour, not a schedule.
Authentication volume clusters around the moments people start work, receive a salary, see a notification or try to complete a transaction, and it spikes further when something goes wrong.
Three properties distinguish it from campaign traffic. It arrives without a schedule, so the peak cannot be moved to a quiet period. It is intolerant of delay, so a queue that would be acceptable for a marketing message becomes a support contact within a minute. And it is self-amplifying, because a user who does not receive a code requests another one, which adds load to the peak that caused the delay. A deployment sized on the daily average therefore fails precisely when it is most visible.
The practical implication is that the sizing figure is a rate, not a volume. A daily volume can be delivered over twenty-four hours; the peak rate has to be delivered in seconds, and only the rate determines how many ports have to be transmitting at once. The message layer that carries the traffic is defined in ETSI TS 123 040, and the subscription states a modem passes through before it can carry anything are defined in 3GPP TS 24.301.
How do you derive port count from the peak authentication rate?
Divide the peak rate by the per-SIM rate.
The arithmetic is simple and the inputs are the work: the peak rate is measured from logs, and the per-SIM rate is measured on the network rather than assumed.
Both measurements need care. The peak rate should be taken from the busiest minute of a representative week rather than from an average, and it should be taken after any retries have been counted, because retries are part of the load the estate has to carry. The per-SIM rate should be measured on the operators and tariffs the deployment will actually use, since it depends on what the network accepts rather than on what the device allows. The framework above the two is defined in 3GPP TS 23.040, which is the reference for what the network is expected to do with each submission.
Headroom is the third input and is usually set as a proportion of the measured peak rather than as a port count. A common approach is to size the estate so that the measured peak occupies a defined share of capacity, which leaves room for the amplification effect described above and for a port being out of service. Where the deployment already has a 16-port pool, the calculation answers a different question: how much of the peak that pool can serve, and therefore how much traffic must be routed elsewhere.
| Input | Where it comes from | Common mistake |
|---|---|---|
| Peak authentication rate | Busiest minute of a representative week | Using the daily average |
| Retry multiplier | Counted from logs | Assuming one request per login |
| Per-SIM rate | Measured on the target operator | Assuming the device limit is the network limit |
| Headroom | Policy decision | Zero, on the basis that the peak is the peak |
What is the real constraint: throughput or delivery window?
The window, in almost every case.
A pool can deliver a large volume over an hour and still fail an authentication flow that expects a code within thirty seconds.
That is why the sizing exercise has to start from the window rather than from the volume. If the flow abandons a verification after thirty seconds, the estate has to deliver the peak rate within thirty seconds, not within the hour, and the port count follows from the shorter period. The difference between the two answers can be an order of magnitude, which is the reason deployments that look generously sized on a volume basis fail under load.
The window also determines what happens to messages that miss it. Where a code is abandoned and a retry is issued, the original is still in the queue, so the estate carries both the retry and the abandoned message. Cancelling superseded messages by request identifier is the control that prevents the queue filling with codes nobody will use, and it belongs in the application rather than in the gateway.
Redundancy for an authentication path
The path needs a second route that has been exercised.
Authentication is a user-facing service with an immediate consequence, so the redundancy question is not whether to have a second path but how quickly it can take over.
Two arrangements cover most deployments. A second pool on a different operator provides route diversity, which addresses the most common cause of a sustained authentication outage. A cloud path as a fallback provides capacity diversity and geographic reach at the cost of a per-message price, and it is what many deployments use for overflow rather than for primary traffic. Both need the queue to sit above the paths, so that a failure leaves the work where the surviving path can collect it.
Whichever is chosen, the switch has to be tested. A fallback that has never carried traffic is a plan rather than a capability, and an authentication path is the wrong place to discover the difference. The redundancy should also be sized for the peak rather than for the average, because the failure is most likely to occur at a moment of high load.
One final input belongs in the worksheet even though it is not a rate: the operator’s own view of the estate. Where a large pool shares a single account or a single commercial relationship, a problem with that relationship affects every port at once, and the sizing exercise should record which ports depend on which account so that a risk to the peak can be seen rather than assumed away.
Fallback behaviour when a message is delayed
The user should not be the retry mechanism.
A delay should trigger a defined action inside the platform rather than a second request from the user, because a user-driven retry adds load to the condition that caused the delay.
Three behaviours are worth designing explicitly. The first is a timer-driven retry on the same channel, which catches transmission failures without user involvement. The second is a channel switch after a defined interval, using voice or another messaging path. The third is a visible status in the interface that tells the user what is happening, because a user who can see that a code is in flight waits rather than requesting again. The third is the cheapest of the three and the most often omitted.
Where the deployment routes across several operators or areas, a delay on one path can be handled by resending through another, and the resend has to be suppressed for duplicates at the recipient. The identifier that makes this possible is the same one used for reconciliation, which is why the identifier should be generated by the institution rather than by a device.
Latency measurement at the installed position
Measure where the modem will be, not where it is convenient.
Radio conditions at the installed position differ from the bench, and a rate measured in a good location will overstate what the deployment can deliver.
Two measurements matter for sizing. The first is the submission rate, or how many messages per minute a single SIM can submit while maintaining its delivery ratio. The second is the delivery time distribution, from submission to receipt, at the intended load. Together they answer the sizing question and identify the constraint: a pool whose submission rate is adequate but whose delivery times are long is limited by the network rather than by the device, and adding ports will not change it.
Recording the number of active ports alongside both figures is what makes them usable. The port-level interface that exposes this information is standardised in ETSI TS 127 005, and the practice of keeping the measurement with its context is the subject of NIST SP 800-92.
A sizing worksheet
The worksheet starts from the authentication peak rather than from a port count, because the peak is the figure the deployment has to meet. Each line produces an input to the next, and the result is a pool size with a stated reserve rather than a range of options.
- Peak authentication rate: logins per minute at the busiest minute of a representative week.
- Retry multiplier: retries divided by unique requests, from the same logs.
- Effective peak rate: peak multiplied by the retry multiplier.
- Per-SIM rate: measured on the target operator at the installed position.
- Ports required: effective peak divided by the per-SIM rate.
- Headroom: the policy share of capacity that must remain free.
- Fallback: the rate the second path can carry, and how quickly it takes over.
- Window: the time within which a code must arrive for the flow to succeed.
The worksheet produces a port count, a headroom figure and a set of assumptions that can be revisited. Where the answer is that a 16-port pool cannot serve the peak within the window, the follow-on questions are how much traffic to route to a fallback and whether the flow’s window should be extended, which is a product decision rather than an infrastructure one.
Size from the busiest minute and the delivery window. Send your peak login rate, retry multiplier and target window to service@telarvo.com, or review the published configurations on the SMS modem range and the SK-SMS Gateway range. Telarvo publishes the SK-SMS gateway range, the TYH modem pools and the TGW SMS machine on its product pages, and the configurations referenced above come from those listings.
FAQ
Is 16 ports enough for a fintech OTP service?
It depends entirely on the peak rate and the delivery window, which is why the question should be answered with a calculation rather than a rule. Sixteen ports is ample at low volume and insufficient where the busiest minute coincides with a login spike, and the same pool can be adequate in one market and not in another. The calculation needs the measured per-SIM rate, not the port count.
Should OTP traffic share hardware with campaign messaging?
It can share hardware and should not share a queue. A campaign filling the queue delays verification codes, and the delay is the one users notice. Reserve capacity or a separate path for authentication traffic, and treat the separation as a design decision rather than a tuning parameter. Queue separation is what makes the guarantee hold on the busiest day.
How much headroom should a verification estate have?
Enough to absorb the retry amplification that a delay causes, plus room for a port being out of service. A common approach is to set a policy share of capacity that must remain free at the measured peak, and to treat any excursion above it as a signal to add capacity rather than to push harder. Express the reserve as a rule the operator can apply.
Why did delivery slow down after a marketing campaign started?
Because the two workloads are competing for the same radios and often the same queue. Campaign traffic occupies the transmit path and the queue, so verification codes wait behind it. Separating the queues or reserving capacity for authentication is what prevents a campaign from becoming an authentication incident. The separation should be tested under a real campaign rather than assumed.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “Is 16 ports enough for a fintech OTP service?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It depends entirely on the peak rate and the delivery window, which is why the question should be answered with a calculation rather than a rule. Sixteen ports is ample at low volume and insufficient where the busiest minute coincides with a login spike, and the same pool can be adequate in one market and not in another. The calculation needs the measured per-SIM rate, not the port count.”
}
},
{
“@type”: “Question”,
“name”: “Should OTP traffic share hardware with campaign messaging?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It can share hardware and should not share a queue. A campaign filling the queue delays verification codes, and the delay is the one users notice. Reserve capacity or a separate path for authentication traffic, and treat the separation as a design decision rather than a tuning parameter. Queue separation is what makes the guarantee hold on the busiest day.”
}
},
{
“@type”: “Question”,
“name”: “How much headroom should a verification estate have?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Enough to absorb the retry amplification that a delay causes, plus room for a port being out of service. A common approach is to set a policy share of capacity that must remain free at the measured peak, and to treat any excursion above it as a signal to add capacity rather than to push harder. Express the reserve as a rule the operator can apply.”
}
},
{
“@type”: “Question”,
“name”: “Why did delivery slow down after a marketing campaign started?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Because the two workloads are competing for the same radios and often the same queue. Campaign traffic occupies the transmit path and the queue, so verification codes wait behind it. Separating the queues or reserving capacity for authentication is what prevents a campaign from becoming an authentication incident. The separation should be tested under a real campaign rather than assumed.”
}
}
]
}