An Indian bank's OTP rarely fails at "the vendor" level. It fails on one operator, often in one circle, while the vendor dashboard stays green and the aggregate delivery rate moves by a point. Most banks ask for direct connectivity with at least three telecom operators, delivery "to all telecom circles without any exception", and reports split by operator and circle. But the rerouting is observed at vendor level, and it triggers when the connectivity is down for any particular vendor. An operator that degrades inside a healthy vendor goes unnoticed. It can also fail before any vendor is involved, when the bank's own source system does not generate the OTP or fire the trigger. A middleware layer should catch that as it happens, not in a report after the fact.
Carrier resilience is the ability to keep delivering when one telecom operator or circle degrades, rather than only when a vendor goes down.
Carrier resilience takes three moves.
First, measure delivery for each operator and each circle separately, on comparable traffic, because one national delivery figure hides the single route that is failing.
Second, keep two ways to reach every major operator, usually a direct telco connection and an aggregator, so that traffic has somewhere to go when one of them slows down.
Third, run both under a decision layer above the vendors.
Fyno is that layer: it sits above a bank's aggregators and direct telco connections and reports delivery across all of them, which neither a telco nor an aggregator can do, because each sees only its own traffic.
TLDR
Each section answers one question a bank's IT or procurement team asks once an operator problem has already turned into complaints. The first covers what to measure, the second where India's carrier chain breaks, and the last two how to structure paths without adding engineering load.
How can enterprises benchmark performance across different telecom operators?
What does carrier-grade infrastructure mean for CPaaS and why does it matter?
How can developers minimize time spent maintaining integrations with telecom operators?
How can organizations ensure vendor support for both domestic and international traffic?
How can enterprises benchmark performance across different telecom operators?
For messaging, benchmark operators on your own traffic, not on network speed. Measure delivery success, time to handset and missing delivery reports per operator and circle, split OTPs from bulk, and separate operator failures from handset failures. Compare paths in the same time period, then reconcile monthly against operator-validated data.
Network benchmarks answer a different question
TRAI's quality of service benchmarks and independent tests measure voice and data networks: call drops, throughput, latency. They are the right tool for choosing a corporate mobile plan. They say nothing about whether a bank's OTP reached a customer on one operator in one circle at 8pm on a Friday. That answer exists only in the bank's own delivery reports, which is why the benchmark has to be built from its own A2P traffic.
A messaging scorecard for Indian operators
Method rules that keep the comparison fair
Same hour, same template, same message class. A route measured at 2pm and another at 2am are not comparable.
Segment by circle, not only by operator. An operator can be healthy in one circle and degraded in the next.
Keep OTPs separate from bulk. A bulk campaign on the same route can drag its numbers down and make a good OTP path look bad.
Reconcile against the operator, not the vendor. A vendor's own report on its own route is not an independent measurement.
A 99% aggregate can hide one operator well below it, which is why an evaluation should ask for delivery data by operator, not only in total. Once a route drifts, what happens to each message is a routing decision, covered in delivery failure detection and automatic rerouting.
What does carrier-grade infrastructure mean for CPaaS and why does it matter?
For an Indian bank carrier-grade infrastructure means an independent path into every operator and circle, so that one degraded route does not stall OTPs. A vendor's platform uptime can be perfect while its route into one operator is failing.
Six points where an Indian SMS can fail
Every A2P message in India crosses the same chain: the bank's source system, an aggregator or registered telemarketer, the originating operator (where DLT scrubbing checks the header and template), the terminating operator's network in the customer's circle, and finally the handset. Each link fails differently.
Points 4 and 5 are what proves carrier resilience. They are also where a single-vendor setup is weakest, because the vendor's status page reports on point 3.
How vendor-level monitoring or failover misleads
On a weekday evening, one operator's route in one circle starts to slow. National OTP success of a large bank moves from about 98% to 97%, well inside normal variation. The vendor dashboard stays green, because the vendor is up. But OTP validation for that operator's numbers in that circle drops sharply, customers retry, and the complaints desk hears about it before any alert fires. Nothing in a vendor-level failover rule was ever triggered, because no vendor went down.
The direction nobody plans for: inbound SMS
Resilience is usually discussed for outbound messages. Device binding and pull services run differently: the customer's phone sends an SMS to the bank's long code or virtual mobile number. On one regional rural bank's evaluation call, the team described customers on two specific operators whose messages to the bank were failing at the point of sending, while other customers were unaffected. The fix was simple: use several receiving numbers, each from a different operator and circle, rather than relying on one. So that if one fails, customers can still reach out through another.
Why banks are moving closer to the operator
TRAI makes the bank register every company that carries its messages, from telemarketer to aggregator to operator, and a message that travels an unregistered route is blocked. The record is the bank's responsibility, so each extra company in the chain is another thing to keep current and another way a message can fail. That is the compliance reason banks are shortening the path to the operator.
How can developers minimize time spent maintaining integrations with telecom operators?
Integrate once with a middleware like Fyno, that already speaks each operator's and aggregator's protocol, then add operators by credentials rather than code. Normalise number formats, delivery report schemas and error codes in that layer, and send DLT template IDs explicitly, so that no operator has to guess the template.
What a direct operator connection costs to maintain
Each direct connection adds its own operations and maintenance load, which continues long after go-live:
Protocol and binds. SMPP binds or HTTP APIs, each with its own TPS allocation, reconnect behaviour and credentials.
Delivery report schemas. Different fields, formats and timestamp conventions for the same event.
Error codes. Each operator's own list, which changes. A lot of banks expect the mapping to be reviewed as and when there is a change in the error codes from TELCO/TRAI.
Number formats. Each operator has its own expectations for country codes and national numbers, and source applications usually send one format.
DLT operations. Template and header issues are raised with the operator, and some banks make the vendor "follow up with respective operators regarding DLT issues on behalf of the bank".
Multiply that by three or four operators plus one or two aggregators, and operator maintenance becomes a standing engineering team rather than a project. That is the case against building the normalisation layer in-house, set out in full in build vs buy for notification infrastructure.
Direct telco plus aggregator, not either alone
The pattern that holds up is a mix. A telco delivers best on its own network and gives the bank a delivery report straight from the source. An aggregator reaches every operator and can switch internally when one of its own routes weakens. Neither, on its own, gives the bank an independent comparison. With both behind one single API of Fyno, the bank gets a second path into each major operator and a live benchmark between them, without its source applications knowing which path carried a message.
Banks are increasingly moving towards distribution among:
vendors (SMS Gateways) in a specified ratio within each category of messages,
Operator/ circle wise distribution in case of domestic SMS and
Automatic as well as manual re-routing of SMS to an alternate vendor
The layer that holds those rules is also the only place they can be changed without a release in every source system.
How can organizations ensure vendor support for both domestic and international traffic?
Treat them as two supply chains with separate SLAs. Require at least three domestic operator tie-ups and two international ones, route by country code to a dedicated international path, and measure success separately. Read the exclusions closely: abroad, operator network outages are often carved out of the vendor's SLA.
What bank RFPs require on each side
The risk transfer nobody reads
When an overseas operator goes down, the vendor owes nothing. The customer, often an NRI account holder waiting for an OTP, still does not get the message, and the complaint still lands with the bank. A second international path is the only protection a bank has against a risk its own contract leaves with it.
And every bank seems to be handling this risk differently.
How Fyno fits across operators
Fyno is the Communication Orchestration Platform for BFSI. It sits above a bank's aggregators and direct telco connections and routes across all of them, so that no single pipe decides whether an OTP lands.
Fyno is vendor-neutral by design. CPaaS companies in India route within their own network, Fyno is vendor-neutral, and it connects to 100+ providers as a middleware and deliverability is what it is bought for.
Fyno routes on live performance. Live delivery rates, latency, and vendor health inform every routing decision. Underperforming vendors are automatically deprioritised.
Fyno measures every vendor side by side. Delivery rate, latency and cost per message across all vendors, side by side, with OTP delivery tracked against your 10-second SLA. Every breach timestamped.
Fyno writes one audit trail per message across every vendor and channel.
For how a single failed message is detected and moved, see delivery failure detection and automatic rerouting.
For the delivery outcomes this supports, see 100% deliverability for critical notifications and why message deliverability matters in banking.
For OTP practice, see high-volume OTP delivery for banking leaders.
Summary
Indian OTPs fail by operator and circle, not by vendor. Aggregate delivery rates hide it.
Most banks ask for operator and circle reporting, but write rerouting at vendor level.
Benchmark on your own traffic: success, time to handset, missing DLRs and operator vs handset failures, per operator, circle and message class.
Keep two independent paths into each major operator: a direct telco connection and an aggregator.
Inbound SMS needs the same resilience: numbers across operators and circles.
Abroad, operator outages are often excluded from the vendor's SLA, so the second international path is the bank's own insurance.