Most fraud investigations inside an operator start with a number that does not reconcile.

Interconnect revenue on a corridor drops while traffic volume holds steady. Or the wholesale team notices a partner whose termination volume tripled in a quarter with no commercial explanation. Or the retail side gets a complaint from a bank whose customers received texts from the bank's own sender ID that the bank never sent. None of these arrive labelled as security incidents. They arrive as anomalies in somebody's spreadsheet, and the work of connecting them to a fraud pattern is where the firewall stops being a product and becomes a practice.

Plenty has been written about what an SMS firewall is. Less has been written about how operators actually run one, which is a question of topology, tuning, metrics and internal ownership rather than feature lists.

Topology decides what you can detect

Where the firewall sits determines which frauds are even visible to it, and this is the decision that constrains everything afterwards.

An operator handling only mobile-originated traffic sees what its own subscribers send, which catches SIM farms and outbound spam. An operator inspecting mobile-terminated traffic sees what the outside world is sending to its subscribers, which is where impersonation, grey routes and interception attempts live. Most serious deployments cover both, and treat them as separate policy domains because the threat models barely overlap.

Home routing changes the picture

SMS home routing, specified in 3GPP work on the subject, inserts a router in the home network so that terminating messages are delivered through it rather than direct to the serving switch. The security consequence is that an external party querying for routing information gets an answer from the router, not the subscriber's real IMSI and serving node.

That single architectural choice removes a large class of reconnaissance. Without it, anyone with interconnect access can ask the network where a subscriber is and which SIM identity to target. Operators that deployed home routing early spend noticeably less time on interception attempts than those still exposing subscriber identifiers at the border.

The signalling policy nobody sees

On the signalling side, operator configuration follows the categorisation approach the GSMA set out in its interconnect security guidance, particularly FS.11 for SS7 and the equivalent work for Diameter.

The logic is that signalling messages sort into groups by where they can legitimately originate. Some operations only ever make sense inside the home network and should never be accepted from an interconnect at all. Others are legitimate only from a network where one of your subscribers is currently roaming, which makes them checkable against your own roaming records. A third group is broadly legitimate but still requires plausibility checks, because a valid message type carrying implausible parameters is the most common shape of an attack.

Most firewall configuration work is in that third group. Blocking messages that should never appear is trivial. Deciding whether a plausible-looking operation is genuine takes state, history and someone who understands the network.

Detection techniques that carry the load

Correlation

The most productive technique in messaging fraud is correlation between related operations.

A legitimate terminating message is normally preceded by a routing enquiry from the same party. When a delivery attempt arrives with no such enquiry, or the enquiry came from a different network entirely, the message is very likely faked. Operators run this correlation continuously, hold state for a short window, and treat mismatches as high-confidence signals. It catches the crude end of A2P faking reliably, which is a large share of volume.

Plausibility

Every parameter in a message can be checked against something the operator already knows. Does the originating global title belong to the network it claims? Is the subscriber actually roaming in the country implied by this operation? Does the sender ID belong to a registered brand, and is that brand a customer of the party submitting the traffic? Does the destination range even exist in the numbering plan?

Individually these are weak signals. Combined, they produce a score, and scoring beats fixed rules because fraud patterns change faster than change control processes.

Behaviour over time

Velocity checks per originating party, per sender ID, per destination range. Distribution of destinations compared to that party's historical pattern. Time-of-day profiles, since campaigns and fraud have different clocks. Sudden appearance of URL shorteners in content from a sender that never used them.

The threshold question is always the same: how large a deviation justifies action. Set it tight and you block real traffic. Set it loose and you become the market's preferred termination point for anyone with volume to hide.

What this actually stops

Faked and spoofed A2P traffic is the volume case. Commercial messages presented as ordinary person-to-person traffic, or injected directly with forged origin information, avoid A2P termination charges. Blocking or reclassifying them is the core of A2P revenue protection, and it is the reason firewall business cases get approved when other security proposals do not.

Smishing campaigns at scale are the customer-harm case. An operator that can enforce sender ID entitlement stops a category of attack that no amount of consumer education addresses, because recipients reasonably treat a sender name as identity.

SIM box bypass shows up on the originating side. A SIM farm terminating international voice or messaging traffic through consumer SIMs produces a distinctive footprint: heavy outbound volume, negligible inbound, no meaningful mobility, and cell-level patterns that look nothing like a person. Firewall and fraud management systems catch this by pattern rather than by inspecting individual messages.

Inflated traffic is the case where the operator's interest is complicated. Automated clients drive verification sends that nobody reads, and the volume is billable, so the incentive to detect it does not come from the P&L. It comes from enterprise customers who have started auditing their own verification funnels and disputing invoices, and from the reputational cost of being the network where pumping traffic terminates.

Interception reconnaissance is the quiet one. Routing enquiries that harvest subscriber identifiers at scale, from parties with no reason to send messages, are a precursor to interception rather than an attack in themselves. They are also easy to see once you look, and they are one of the better arguments for treating signalling monitoring as a continuous function rather than a project.

Tuning, and the asymmetry nobody warns you about

The costs of the two error types are not remotely equal.

Letting spam through produces complaints and slow reputational damage. Blocking a bank's one-time passwords for forty minutes produces an executive escalation, a commercial dispute, and a fraud team that loses the argument for tighter thresholds for the next two years. Operators who have been through it once tend to build the same defences: staged rollout of new rules in monitor-only mode, a fast rollback path, per-customer exception handling, and a clear on-call route for enterprise partners whose traffic has been affected.

Monitor-only deployment deserves particular emphasis. A rule that has been running against live traffic for two weeks without blocking anything tells you exactly what it would have caught and what it would have broken. Skipping that step to move faster is the most common cause of a firewall programme losing internal credibility in its first quarter.

Who owns it internally

This sounds like an organisational footnote. It is not, and it predicts programme outcomes better than most technical choices.

A firewall owned solely by network operations gets configured for stability and left alone, because changing a working system carries risk and no reward. Owned solely by the fraud or security team, it gets aggressive rules and poor visibility into the commercial relationships behind the traffic it is blocking. Owned solely by wholesale, it becomes a billing instrument and the security cases get deprioritised whenever a partner complains.

The deployments that work have a shared operating model: security sets detection policy, wholesale owns the commercial consequence of blocking a partner, and network operations owns availability. The specific structure matters less than the fact that someone senior can adjudicate when those three interests conflict, which they will, roughly monthly. A modern SMS firewall platform supports this by producing evidence each function can act on, rather than a single dashboard aimed at one of them.

Measuring the programme honestly

Blocked message volume is the metric everyone reports and the least informative one available. It rises when attacks rise and when rules get sloppy, and nothing in the number distinguishes those cases.

More useful measures: A2P traffic reclassified from P2P and correctly billed, expressed as recovered revenue. Interconnect disputes raised and their outcomes. Complaint volume about impersonated sender IDs, tracked per brand. Time from a new fraud pattern appearing to a rule being live. False positive incidents, counted and reviewed rather than quietly resolved.

Industry loss estimates give some external context. The Communications Fraud Control Association's periodic surveys have put global telecom fraud losses in the tens of billions of dollars annually across all fraud types, which is useful for a board slide and useless for operational decisions. The internal metrics are what tell you whether the programme is working.

Limits worth stating plainly

A firewall inspects what crosses the network. It cannot see traffic that never does, which is most of what happens on encrypted messaging apps, and it cannot repair the underlying weakness of SMS as an authentication factor. Operators that deploy one and describe the authentication problem as solved are setting up a future incident.

Rich messaging complicates matters further. As RCS traffic grows, inspection has to extend to message types and sender verification models that SMS filtering was never designed around, and the tooling is less mature than the marketing suggests.

The realistic framing is that a firewall raises the cost of attacking the network and gives the operator evidence about who is doing what. That is worth a great deal. It is not the same as making the channel safe.

Key takeaways

• Topology determines detection. Cover both originating and terminating traffic, and treat them as separate policy domains with different threat models.
• Deploy SMS home routing. It removes an entire class of reconnaissance by keeping subscriber identifiers out of interconnect responses.
• Correlating a delivery attempt against the routing enquiry that should precede it is the highest-yield detection technique available.
• Score plausibility across multiple weak signals instead of relying on fixed rules that fraud patterns outpace.
• Roll every new rule out in monitor-only mode first. Skipping this is how firewall programmes lose internal credibility.
• Blocking a bank's OTP traffic costs far more politically than letting spam through. Build exception handling and a rollback path before you need them.
• Share ownership across security, wholesale and network operations, and name whoever adjudicates when those interests conflict.
• Report recovered A2P revenue, dispute outcomes and false positive incidents. Blocked message volume tells you almost nothing.