International SMS firewalls sit at the interconnect. They protect traffic arriving from abroad. They do not see on-net spam, internal SMS storms, grey routes via local SIM boxes, flash-call abuse, or sender-ID spoofing of your bank and government brands. The Local SMSC Firewall sits in front of — or alongside — your Local SMSC, and addresses every one of them.
Operators that pair their international firewall with a local-core firewall
Inline inspection without inline risk. Every rule runs in monitoring mode before it ever blocks; every decision is attributable to the rule that made it.
Per-message, end-to-end inline overhead.
Every rule can run log-only before it ever blocks.
Allow, block, throttle, tag-and-route.
Co-managed, self-service, or fully-managed.
The firewall sits between every traffic source and your messaging core — SMPP, HTTP, internal APIs, internal apps, external partners — and inspects every message before it touches the Local SMSC.
SMPP, HTTP, internal APIs — internal apps and external partners alike. Every path into the messaging core is in scope.
Type detected: A2P, P2P, flash-call, test traffic, system messages. Context tagged before any rule fires.
Content, behavioural, and contextual rules combined. Per-route, per-sender, per-segment, per-hour-of-day.
Allow · block · throttle · tag-and-route. Every decision logged with the rule that made it.
Approved traffic forwarded to the Local SMSC. Blocked traffic dropped with an evidence record retained.
SMPP, HTTP, internal APIs — internal apps and external partners alike. Every path into the messaging core is in scope.
Type detected: A2P, P2P, flash-call, test traffic, system messages. Context tagged before any rule fires.
Content, behavioural, and contextual rules combined. Per-route, per-sender, per-segment, per-hour-of-day.
Allow · block · throttle · tag-and-route. Every decision logged with the rule that made it.
Approved traffic forwarded to the Local SMSC. Blocked traffic dropped with an evidence record retained.
Four reasons operators put a dedicated firewall at the Local SMSC, even when they already run an international one at the interconnect.
International firewalls protect inbound A2P from abroad. Internal SMS storms, on-net phishing, local SIM-box grey routes, and sender-ID spoofing of local banks come from inside the network — and need a firewall on the inside.
Inline inspection is a non-starter if it adds noticeable latency. The firewall is engineered for fast-path decisioning on the messaging core and measured continuously against your own SMSC baseline.
No rule blocks production traffic without first running log-only against real traffic and proving its false-positive rate. Promotion to enforce is a single change with a full audit trail, and every block is reversible.
Clear separation between operator-defined policy and BroadNet recommendations. Approval workflows for sensitive rule changes. Complete audit trail of who changed what, when, and why.
Four action types
The rule engine combines content, behavioural and contextual signals, but the action it takes is always one of four. Each is auditable, reversible, and rolled out in monitoring mode first.
Route normally to the Local SMSC. No restriction. Logged with the rule that approved it for audit.
Reject the message and persist the reason. Evidence retained for RA / regulator / brand-protection inquiry.
Apply a rate cap by sender, IP, account, or partner. Message continues, but flow is controlled.
Attach metadata or redirect to an alternative path for special handling, monetisation, or extra inspection.
Service tiers
Three operating models. Most operators start co-managed during pilot and graduate to whichever model their team prefers once they are comfortable with the rule set.
Your team owns day-to-day operations: rule edits, alert triage, change windows. BroadNet supports complex tuning, threat-intelligence updates, and incident escalation.
Full control of the policy framework. BroadNet supplies training, documentation, runbooks, and an escalation line for platform-level issues. Ideal for operators with mature security teams.
BroadNet handles rule management, monitoring, tuning, and incident response. Operator sets policy direction and reviews monthly results. The minimal-overhead option.
Capabilities
Misconfigured internal systems create loops that can flatten a Local SMSC in minutes. Per-source rate limits, burst detection, and automatic throttling stop the storm before customer service hears about it.
Maintain whitelists of approved bank, government, and OTT sender IDs in coordination with the brand. Block look-alikes, mixed-case impersonations, and unregistered senders claiming protected identities.
Repeated short-duration calls for OTP verification correlated with SMS activity. Decide commercially: block, allow with monitoring, or route to a paid path. Cross-links to /operators/flash-call.
A2P traffic delivered via consumer SIM cards bypasses commercial agreements. Pattern analysis identifies SIM-box behaviour on your own network; blocked traffic produces evidence for the RA team.
Every rule can run in log-only mode before it ever blocks. Validate against real production traffic, measure false-positive rate, then promote to enforce with one click and a full change log.
Detailed message logs with the rule that fired, exportable as CSV / JSON / PDF for partner disputes and regulatory inquiries. Retention configured to your IT and compliance policy.
Threat coverage
| Attack vector | Local firewall control | Outcome |
|---|---|---|
| Internal SMS storms & loops | Per-source rate limits, burst detection and automatic throttling on the local core. | The storm is contained before the Local SMSC is flattened. |
| On-net sender-ID spoofing of local banks | Brand-coordinated whitelists with look-alike, mixed-case and unregistered-sender detection. | Local-brand impersonation blocked with a full audit trail. |
| On-net A2P grey routes (local SIM boxes) | A2P-vs-P2P pattern analysis and SIM-box fingerprinting on your own network. | Bypass blocked and evidenced for the RA team. |
| Flash-call & voice-OTP abuse | Correlation of short-duration verification calls with SMS activity, decided by policy. | Block, monitor, or route to a paid path — a commercial choice, not a blind drop. |
| Rule changes risking false positives | Every rule runs in log-only monitoring mode against live traffic before it enforces. | False-positive rate is measured first; promotion to enforce is one auditable click. |
On-premise deployable, audit-ready, regulator-recognised in every market we serve.
Pair with
International A2P firewall at the interconnect. The pair to local-core protection — together, they cover both inbound-from-abroad and on-net threats.
Learn moreDedicated detection for OTT verification bypass at the international voice ingress. Used by the Local SMSC Firewall for voice ↔ SMS correlation.
Learn moreCarrier-grade messaging core. The Local SMSC Firewall sits inline / proxy in front of this gateway in most deployments.
Learn moreInternational firewalls protect traffic arriving from abroad — they sit at the interconnect. The Local SMSC Firewall sits in front of, or alongside, your Local SMSC and protects the messaging core. It addresses threats that originate within your network or that bypass international protections: misconfigured internal systems, on-net spam, grey routes via local SIM boxes, sender-ID spoofing of local brands, and flash-call abuse. The two solutions are complementary and most operators run both.
Typically under 10 milliseconds per message, end-to-end. Inspection and decisioning run in real time on optimised in-memory paths. For reference, normal network variation is often 50–100 ms, so the firewall is a fraction of that. We measure and publish per-rule latency during the pilot.
Every rule can be deployed in monitoring mode first — it logs every match but never blocks. You see exactly what would be rejected, measure the false-positive rate, and only promote the rule to enforce when you are comfortable. If a false positive does occur once enforcing, the detailed log shows the exact rule and content that triggered, and the rule can be adjusted or the sender whitelisted within minutes.
Both work. Three tiers are available: fully-managed (BroadNet operates the firewall, you set policy), co-managed (your team drives day-to-day, BroadNet supports complex tuning and incidents), and self-service (you run everything, BroadNet provides training, documentation, and platform-tier escalation). Most operators start co-managed during pilot and move to whichever model their team prefers.
The firewall is typically deployed on-premise within your data centre. Message content is analysed in real time and not retained — only metadata and rule-match evidence is logged. Log retention and access controls follow your internal IT and compliance policies. No content leaves your network without your explicit approval.
A typical engagement begins with a technical workshop between your network, security, and IT teams and BroadNet engineers, followed by a pilot on a subset of routes or partners (every rule running monitor-only at first), and then a progressive enforcement rollout. The full path — workshop to full enforcement — takes several months in most deployments, with the exact timeline depending on environment complexity and the rule-tuning cadence you want.
Detailed message logs attribute every decision to the rule that produced it. Blocked grey-route attempts, SIM-box-pattern traffic, and unauthorised A2P-as-P2P deliveries are exportable as evidence packages — CSV / JSON / PDF — for partner disputes and regulator inquiries. The RA team gets attributable evidence that a previously invisible loss has been quantified and addressed.
Yes. The firewall integrates with common monitoring stacks, ticketing systems, and SIEM platforms via API and syslog. Security events appear in the operational workflows your teams already use. Specific integrations are scoped during the technical workshop.
Question not here? Ask our engineering team
In-network SMS and SS7 firewalls stop grey routes and fraud at line rate while legitimate traffic flows untouched.
Bring your network, security, and IT teams. We will scope the integration, design the initial rule set, and run the first phase in monitoring mode — no production blocking until you decide.
