PAiCore designs and operates carrier-grade SMSC infrastructure for mobile network operators. By 2026, its operator customers were facing the same accelerating problem as every other tier-1 messaging network: SMS spam and phishing campaigns mutating faster than rule engines could keep up, spanning dozens of languages, and rotating templates within hours of being blocked. PAiCore set out to give those operators a content-aware classification layer that fit cleanly inside the SMSC's existing routing and filter pipeline — without shipping subscriber message bodies to a cloud AI endpoint, and without handing policy decisions to a black-box appliance.
"Through the strategic integration of OpenTextShield (OTS) with the PAiCore SMSC, we are officially launching an advanced solution designed to neutralize spam and phishing in real time."
— PAiCore Technology, launch announcement
Challenge
The classical answer to SMS abuse — a regex-based firewall with hand-curated keyword and URL blocklists — was failing PAiCore's operator customers on three fronts.
Rules went stale within days. Spammers rotated templates, swapped URL shorteners, used Unicode lookalikes, and switched locales faster than the team writing rules could ship updates. Detection accuracy started at 85–92% on day one and decayed from there.
Multilingual traffic broke single-language patterns. Operators in PAiCore's customer base served dozens of languages across their footprint. A rule engine tuned for English-language phishing missed Arabic, Portuguese, Mandarin, and Russian variants of the same campaigns. Hiring per-language rule authors was neither scalable nor sustainable.
Cloud AI APIs weren't compatible with the operator latency budget — or the regulatory environment. Inline SMS classification needs to add tens of milliseconds, not tens of seconds. And shipping subscriber message content to a third-party cloud creates a compliance conversation no operator's legal team wants to have.
What PAiCore needed was a content classification signal that held up across languages, generalized to new templates without rule rewrites, ran on-premise at SMSC latency, and arrived as a clean signal — not a black-box decision the SMSC had to defer to.
Solution
PAiCore evaluated commercial AI APIs and several rule-based vendors before selecting OpenTextShield (OTS) together with TelecomsXChange. OTS is an open-source, multilingual BERT-based content classifier: given the body of an SMS, it returns a label (ham, spam, or phishing) and a probability. It does one thing — classify content — and does it well across 50+ languages, with 99.7% accuracy on blended production test sets.
OTS does not attempt to identify A2P bypass traffic, score sender ID reputation, decide a route, or flag grey-route interconnects. Those are decisions about traffic metadata and patterns, not message content — and they belong in the SMSC's rule engine, not in the classifier.
How the integration works
PAiCore built a new component for the integration — the OTS bridge — designed from the ground up to run at carrier scale. The bridge sits between the SMSC and OpenTextShield: it takes the message body off each submit_sm, calls OTS's prediction endpoint, and hands the classification result back to the SMSC's rule engine. Building the bridge as a dedicated component — rather than wiring the SMSC directly to the model — lets PAiCore handle batching, connection pooling, retry and timeout policy, and back-pressure on its own terms. The rule engine and the inference layer stay decoupled, and the integration sustains SMSC-grade throughput without one side dragging the other down.
OpenTextShield itself ships as a multi-arch Docker image (linux/amd64 + linux/arm64), which lets PAiCore deploy it the same way it deploys every other piece of its stack: pull the pinned image, run it with --gpus all, and the inference service is up. Containerizing the model keeps its lifecycle — version pinning, rolling upgrades, retraining drops — independent of both the bridge and the SMSC, so each layer can move at its own cadence.
For every submit_sm the SMSC processes:
- The SMSC hands the message body to the OTS bridge.
- The bridge calls the local OpenTextShield
/predict/endpoint, which runs the message through the mBERT classifier on GPU and returns a label (ham/spam/phishing) plus a probability. - The bridge returns the result to PAiCore's programmable rule engine, which consumes it alongside its existing signals — sender ID, originating route, message rate, destination MCC/MNC, customer tier, time-of-day, prior-incident flags — and applies the operator's policy: forward, drop, quarantine, throttle, route to manual review, or send to a different downstream.
- The classification event is logged for audit and analytics; aggregate counts are scraped from
/metricsby the operator's existing Prometheus stack.
Why the division of labor matters
A single-vector firewall — "the AI says spam, drop it" — is brittle. False positives on legitimate enterprise traffic are expensive; false negatives on novel phishing templates are damaging. Operators need to combine signals.
PAiCore's SMSC is flexible enough to layer the OTS content signal alongside everything else the operator already knows about a message. An OTS phishing label on a message from a verified bank sender ID is treated very differently from the same label on an unknown shortcode arriving over a brand-new interconnect. Aggregate behavior over time — bursts, fan-out, repetition — is detected by SMSC-side counters, not by OTS. Combining content labels with rate signals is what catches campaign-style abuse. Customer tier, regulatory carve-outs, and language-specific exceptions are all expressible as programmable rules consuming the OTS signal as one input among many.
Content classification by a specialized model, policy enforcement by a programmable SMSC. Together they cover ground neither could on its own — and the operator owns every line of policy that ties them together.
Results
The joint solution is now in production at PAiCore's operator customers and has been published in the GSMA's member resources as a working reference architecture for AI-driven SMS content classification at the SMSC layer.
- 99.7% classification accuracy across blended ham/spam/phishing test sets, holding steady across 50+ languages.
- Sub-50ms p95 classifier overhead on a co-located NVIDIA T4 with FP16 and dynamic batching — orders of magnitude faster than any cloud AI API and well inside the SMPP timeout headroom operators run with.
- 100% on-premise inference. Subscriber message bodies never cross an external boundary. Only labels, probabilities, and aggregate metrics are exposed.
- Operator-owned policy. PAiCore's programmable rule engine composes OTS content labels with sender ID, route, rate, and customer signals — the operator decides what each combination means.
- Continuous model updates shipped through the OTS Professional release cadence; new spam and phishing template detection lands without retraining work on PAiCore's side.
- Published in the GSMA member resources. The integration now stands as a reference architecture other operators and SMSC vendors can replicate.
"This is an A.I. use we can proudly get behind — flexible SMSC routing and filter rules + a dynamic open source A.I.-powered SMS firewall."
— Celeo Arias, Open Source Telecom Solutions
About PAiCore
PAiCore designs and operates carrier-grade SMSC infrastructure for mobile network operators. The full GSMA writeup of the joint solution is available on the GSMA member resources page. Operators evaluating a similar deployment can contact the TelecomsXChange team to discuss the OpenTextShield Community and Professional editions.
