SMS Gateway Setup for Bank OTP: From Specification to Acceptance

Setting up an SMS gateway for bank OTP is a project with three stages: what the flow requires, what that implies for the estate, and what has to be demonstrated before anyone depends on it. Most implementations start at the middle stage and spend the rest of the project discovering the other two.

This article sets out the requirements worth fixing before hardware is discussed, how delivery window, redundancy and audit expectations translate into a specification, and how to run acceptance testing that a regulated flow will actually accept as evidence.

For SMS gateway setup for bank OTP, what has to be fixed before hardware is chosen?

The window, the volume and the record.

Three figures determine almost everything about the estate, and none of them are hardware questions.

The first is the window: how long a customer waits before the flow gives up. That figure, combined with the peak login rate, sets the required delivery rate, and the required rate sets the estate. The second is the volume: peak logins per minute, including the retries that a delay produces, because retries are part of the load the estate carries. The third is the record: what the institution must be able to produce afterwards, which determines the retention and export design rather than the port count.

Fixing those three before a hardware discussion prevents the most common failure in these projects, which is a deployment sized on a volume figure and delivered against a window requirement. The two are not the same calculation, and the difference is usually an order of magnitude. The message framework that carries the traffic is defined in ETSI TS 123 040, and the subscription states the equipment must reach before it can deliver anything are defined in 3GPP TS 24.301.

Delivery window, redundancy and audit expectations

Each one changes the estate in a different way.

The window sets the port count, redundancy sets the number of paths, and the audit requirement sets what the platform has to record and export.

Redundancy deserves its own decision rather than being assumed. A second pool on a different operator addresses the most likely cause of a sustained outage, while a cloud path as fallback provides capacity and reach at a per-message price. Which one is appropriate follows from the response commitment: an institution that has promised customers an authentication service within a defined period needs a second route it has tested. The queue should sit above both paths, so that a failure leaves the work where the surviving path can collect it.

The audit requirement is the part that is usually under-specified. What has to be producible is a record linking a request, a channel, a delivery outcome and the session that completed afterwards, and it has to be producible from systems the institution controls. Access-control and audit objectives that structure this are organised in NIST SP 800-53 Rev. 5, and record-keeping practice for the logs involved is covered in NIST SP 800-92.

Requirement	What it sets	Who decides
Delivery window	Port count and pacing	Product and risk owners
Peak login rate	Rate the estate must sustain	Measured from logs
Redundancy level	Number of independent paths	Risk owner, with engineering input
Record requirement	Retention, export and access design	Compliance owner
Channel scope	Which channels, and what each may authorise	Product and risk owners

SIM and sender identity strategy

The estate is a subscription decision as much as a port decision.

The number of SIMs, the operators behind them and the identity presented to customers are three separate choices that interact.

The SIM estate size follows from the per-number policy: if each subscription may carry a defined volume per period, the estate size follows from the peak divided by that allowance rather than from the port count. Presenting an identity that customers recognise is the second decision, and for a bank it is usually a registered sender identity rather than a raw number, subject to the registration rules of each market. Third, the number a customer can reply to, if replies are supported at all, should be an explicit choice rather than a side effect of the sending path.

All three belong in a per-market record, because the rules and the customer expectations differ. The numbering conventions behind the choices are described in ITU-T E.164, and where the deployment uses centralised SIM storage, the identity of each card is described in ITU-T E.118.

Integration with the authentication platform

The identifier is the integration.

Everything the institution will want to reconcile later depends on a request identifier that it generates and carries through every channel.

That single design decision determines whether a dispute can be answered. Without it, the messaging record and the authentication log are two lists that happen to describe the same events; with it, they join, and the join is the evidence. The identifier should be generated by the institution rather than by a device or an operator, because identifiers produced elsewhere are not guaranteed to be returned unchanged or to be unique across a restart.

The second integration decision is the retry policy. A user-driven retry adds load to the peak that caused the delay, so retries should be timer-driven inside the platform, with a channel switch after a defined interval where a second channel exists. The third is idempotency: a submission that times out must be held rather than resent until its outcome is known, or the customer receives two codes and the record shows two deliveries for one request.

One further item belongs in the requirement set, because it is easy to defer and expensive to add later: the definition of a failed verification. Whether a failure is a code that never arrived, a code that arrived after the window, or a code the customer did not use, the definition determines what the acceptance test measures and what the support desk records. Agreeing it in week one prevents a later dispute about whether the deployment is meeting its commitment.

One more practical note on staging: build the estate before the smoke tests rather than alongside them. Smoke tests run against a partially built estate produce results that describe the build rather than the design, and the interesting failures appear only once the pool is at its intended size and load.

How do you run acceptance testing for a regulated flow?

Test the peak, the failure and the record.

Acceptance for this kind of flow needs to demonstrate three things: that the window is met at the peak rate, that a path failure does not stop delivery, and that the record can be produced afterwards.

The peak test is a load test at the measured peak plus headroom, and its output is a delivery time distribution rather than an average. The failure test removes a path deliberately and measures how long the switch takes and how many requests are affected. The record test picks one request and produces the full chain from the institution’s own systems, which is the test that most often reveals a gap between what the platform records and what the institution can retrieve.

Run the trio before go-live and repeat them after any change to the estate, the routing policy or the authentication platform. A result recorded once is a snapshot of the deployment on the day it was tested, and the tests are cheap relative to discovering their absence during an incident.

Operational handover and evidence

Handover is a document, not a meeting.

The operations team needs the estate inventory, the routing policy, the acceptance results, the escalation path and the runbook for a channel failure.

The estate inventory should name each unit, its SIM assignments and its operator relationships, because the first question in an incident is which subscription is involved. The routing policy should state which traffic uses which path and under what conditions it moves, and it should be verified periodically, since a policy that is not checked drifts onto whichever path is easiest. The acceptance results are the baseline that makes a later degradation visible.

The runbook is the shortest document and the most used. It should state what to check first, what to switch, and who to call, in the order the operator will need them. A runbook that begins with a diagnostic sequence rather than with an escalation list is one that will actually be followed.

A staged implementation plan

The plan is staged so that each phase produces something the institution can test, rather than a sequence of purchases. It begins with the requirements that determine the hardware, continues through acceptance testing, and ends with the operational handover and the evidence the flow has to retain.

1. Fix the window, the peak rate and the record requirement in writing.
2. Derive the port count, the SIM estate size and the pacing from those three figures.
3. Choose the number of paths and the fallback behaviour, and record the routing policy.
4. Integrate the request identifier and the retry policy into the authentication platform.
5. Build the estate, measure the per-SIM rate at the installed position, and re-check the sizing.
6. Run the peak, failure and record acceptance tests.
7. Hand over the inventory, policy, results, runbook and escalation path.
8. Review the acceptance tests after any material change.

The plan is deliberately front-loaded because the three requirements at the start are cheap to change and the estate is not. A project that fixes them in week one spends the rest of its time building; one that fixes them in week ten spends the rest of its time re-sizing.