Case study · Telecomunicazioni

Centosessanta caratteri, nessun header e un mittente che mente su chi è.

Un motore di rilevamento per il traffico SMS: classificazione del contenuto, collegamento delle campagne e resistenza all’offuscamento che sconfigge i filtri a parole chiave, esposti attraverso un’API e un livello di query analitiche, con una pipeline di etichettatura che trasforma le decisioni degli analisti nella versione successiva dei modelli. Consegnato 2025–2026. Il cliente è sotto NDA, quindi questa pagina pubblica il sistema e non il committente.

Consegnato
2025–26
Cliente
sotto NDA
Cosa abbiamo costruito
motore di rilevamento classificazione + collegamento delle campagne
Tipi di segnale
3 contenuto, comportamento, routing
Misurato, nostro banco
4.1–4.3× kernel bayesiano, GPU vs CPU
Non dichiarato
un firewall SS7

Perché su questa pagina non ci sono tassi di rilevamento

Esistono. Sono stati misurati sul traffico del cliente e sono coperti dallo stesso accordo che copre il nome del cliente. Pubblicare le cifre operative di qualcun altro per aggiudicarci del lavoro non è uno scambio che siamo disposti a fare, e un fornitore che lo fa con un cliente lo farà anche con voi. Quello che possiamo pubblicare è l’ingegneria, l’architettura e un benchmark che abbiamo eseguito sul nostro hardware — che trovate qui sotto, con l’elenco di tutto ciò che non misura.

Perché gli SMS sono il lato difficile del filtraggio dei messaggi

Una email arriva con header, risultati di autenticazione, un dominio con una reputazione e di solito qualche centinaio di parole di testo. Un classificatore ha qualcosa su cui lavorare. Un SMS arriva con circa centosessanta caratteri, una stringa mittente che può essere falsificata in tutto e per tutto, e nient’altro. Il segnale su cui un filtro antispam si appoggia di norma semplicemente non c’è.

L’informazione interessante, quindi, non sta dentro un singolo messaggio. Sta nella relazione tra i messaggi — lo stesso link abbreviato sotto quattro nomi mittente diversi, lo stesso template con una parola cambiata, gli stessi destinatari colpiti da tre mittenti in un’ora — e nel confronto tra il comportamento di un mittente oggi e il suo comportamento martedì scorso. Un sistema che valuta i messaggi uno per uno intercetterà la prima ondata di una campagna e perderà tutte le ondate successive.

C’è poi un’asimmetria di costo che condiziona ogni decisione di progetto. Un messaggio fraudolento non intercettato danneggia un singolo abbonato. Una password monouso bloccata per errore chiude a un cliente l’accesso alla propria banca, e la colpa non la darà alla banca. Il traffico di servizio ha bisogno di una policy propria e di eccezioni proprie dal primo giorno, non come rimedio dopo il primo reclamo.

Consegnato

Quattro pezzi, e quello che fa migliorare gli altri tre

Questo è il lavoro completato e consegnato, non una roadmap. Ogni pezzo è utile da solo; insieme chiudono un ciclo, ed è questa la parte che conta.

  • 01Classificazione — il contenuto dei messaggi valutato rispetto a pattern noti, con la ragione del punteggio disponibile e non nascosta dentro il modello
  • 02Normalizzazione — alfabeti misti, caratteri simili, spaziature inserite e traslitterazione ridotti a una forma canonica prima di qualsiasi confronto
  • 03Collegamento delle campagne — i singoli messaggi raggruppati per template, link, insiemi di destinatari e infrastruttura di invio condivisi, così che una campagna sia un unico oggetto invece di diecimila
  • 04API e query analitiche — il risultato interrogabile direttamente dal team operativo, non solo attraverso una dashboard che qualcuno deve mantenere

E sotto tutti e quattro, il pezzo noioso da descrivere e decisivo in produzione: una pipeline di etichettatura. Ogni decisione che un analista prende — questa era una frode, questo era un falso positivo, questo template è marketing legittimo — diventa dati etichettati, e i dati etichettati diventano la versione successiva dei modelli. Senza di essa un sistema di rilevamento dà il meglio il giorno in cui va in produzione e peggiora ogni mese che passa, perché i mittenti continuano ad adattarsi e il sistema no.

Prima normalizzare, poi confrontare — la differenza è la quinta ondata

Quando un filtro inizia a lasciar passare qualcosa, l’istinto è aggiungere regole. Il mittente sostituisce una lettera con una simile di un altro alfabeto, e allora aggiungete quel carattere. Inserisce un punto in mezzo a una parola, e aggiungete anche quello. Sei mesi dopo il set di regole è immanutenibile e resta comunque un passo indietro, perché generare varianti costa poco al mittente e molto a voi.

Ridurre il testo a una forma canonica prima del confronto inverte questa economia. Alfabeti misti, caratteri visivamente confondibili, punteggiatura e spazi inseriti, traslitterazione tra sistemi di scrittura — tutto si riduce alla stessa rappresentazione, così mille varianti generate diventano una sola cosa da riconoscere. Il motore cerca quindi varianti di una campagna nota e non ripetizioni esatte.

È anche il punto in cui il traffico multilingue smette di essere un problema separato e diventa lo stesso problema. Una rete che trasporta più di una lingua, con abbonati che cambiano alfabeto a metà frase e scrivono la propria lingua in caratteri latini, mette fuori gioco subito un filtraggio ingenuo — ed è gestita dallo stesso livello di normalizzazione che gestisce l’evasione deliberata.

Dove sta andando

Chiedere “questo mittente è cambiato” invece di “questo messaggio sembra cattivo”

Il motore consegnato valuta i contenuti e raggruppa le campagne. La linea di ricerca che stiamo sviluppando sopra di esso modella il comportamento normale di ciascun mittente e rileva il punto in cui cambia — e così intercetta un’identità mittente legittima che è stata compromessa con la stessa facilità con cui intercetta una nuova identità fraudolenta appena registrata. Questa parte è in sviluppo, non è un deliverable consegnato, ed è segnalata come tale deliberatamente.

Il metodo è il rilevamento bayesiano online dei punti di cambiamento. Ogni mittente porta con sé una distribuzione su quanto è durato il suo regime comportamentale attuale; ogni nuovo batch di traffico aggiorna quella distribuzione; uno spostamento netto al suo interno è il segnale. L’attrattiva per questo problema è che produce una probabilità con le evidenze allegate invece del superamento di una soglia, così un analista può vedere perché un mittente è stato segnalato — e così che l’obiezione ovvia possa avere una risposta onesta: un’anomalia temporale non è una frode confermata, e il sistema è progettato per presentarla come un motivo per guardare.

Cosa abbiamo misurato e cosa no

Tenere aggiornato un modello per ogni mittente di una rete è un problema di aritmetica prima che di modellazione, quindi abbiamo misurato il percorso critico: l’aggiornamento della distribuzione a posteriori, in batch su 10.000 serie alla volta.

64 ipotesi / serie

  • CPU 16.73 ms
  • GPU 3.90 ms
  • 4.3× più veloce

256 ipotesi / serie

  • CPU 68.02 ms
  • GPU 16.44 ms
  • 4.1× più veloce

Condizioni

  • Mediana degli aggiornamenti in batch
  • float32, GPU sincronizzata
  • Baseline CPU single-thread
  • September 2026

Hardware

  • Apple M5, PyTorch 2.14
  • Una macchina da sviluppo
  • Non una GPU da datacenter
  • Non CUDA

Cosa non è questo numero

Misura un solo kernel — l’aggiornamento a posteriori del punto di cambiamento — e nient’altro. La decodifica del protocollo, la stima del rischio di coda, la correlazione delle campagne e qualsiasi azione eseguita sulla rete sono fuori dalla misurazione. È un test numerico locale su una macchina di classe portatile, non un benchmark di una pipeline di rilevamento completa e non è confrontabile con il dato di throughput dichiarato da un fornitore per un firewall inline.

Lo pubblichiamo comunque, con tutto questo allegato, perché è il numero che abbiamo davvero. Un solo rapporto misurato, con la sua metodologia scritta, vale più di una pagina di dichiarazioni di throughput che nessuno può riprodurre.

Cosa c’è sotto

Il contenuto dei messaggi non lascia mai la rete in cui è arrivato

È la linea architetturale su cui progettiamo, e non è una funzionalità — è il vincolo che decide se un sistema come questo sia installabile o no. I corpi dei messaggi, lo stato dei modelli e il registro delle decisioni restano dentro il perimetro dell’operatore. Ad attraversare il confine c’è un breve elenco di contatori aggregati: quale installazione, quale versione, se è in salute, quanto volume per la fatturazione.

L’alternativa — inviare in streaming i messaggi degli abbonati al cloud di un fornitore per la valutazione — è più semplice da costruire e quasi impossibile da difendere. Non supera una verifica di protezione dei dati nella maggior parte delle giurisdizioni e, negli approvvigionamenti regolamentati delle telecomunicazioni, di solito non supera il primo questionario. Progettare per l’inferenza locale dall’inizio costa una volta in lavoro di ingegneria; farlo a posteriori costa il contratto.

Rilevamento

  • Classificazione del contenuto
  • Feature in streaming
  • Correlazione delle campagne
  • Profilazione bayesiana (in sviluppo)

Dati

  • Restano nella rete dell’operatore
  • Accesso per ruoli
  • Registro decisioni e audit trail
  • Finestre di conservazione concordate

Interfacce

  • API per le operazioni
  • Query analitiche
  • Integrazione con un gateway esistente
  • Nessun componente inline presupposto

Esce dal perimetro

  • Stato dell’installazione
  • Versione
  • Volume aggregato
  • Nessun contenuto dei messaggi

Il team — 10 persone

  • 1project manager
  • 1analista di sistema
  • 1designer UI/UX
  • 3analisti ML, dati e trading
  • 1ingegnere QA
  • 1ingegnere DevOps
  • 1sviluppatore back-end
  • 1sviluppatore front-end

Tre analisti contro due sviluppatori. Il lavoro di rilevamento non si vince scrivendo più codice — si vince con le persone che sanno distinguere una campagna fraudolenta da una campagna di marketing, e che continuano ad avere ragione anche dopo che i truffatori si sono adattati.

Su cosa insisteremmo prima, la prossima volta

Concordare la policy per le password monouso e il traffico di servizio prima che il primo modello venga addestrato, non dopo il primo reclamo. Sono i messaggi che un abbonato nota immediatamente quando non arrivano, e sono strutturalmente simili al traffico di massa che state cercando di bloccare. Hanno bisogno di un percorso proprio attraverso il sistema dal primo giorno.

Costruire la pipeline di etichettatura nel primo mese e non nel sesto. Sembra un’infrastruttura che si può rinviare, ed è l’unica ragione per cui il sistema è migliore nel secondo anno che nel primo. Ogni mese senza di essa è un mese di decisioni degli analisti buttate via.

E stabilire cosa al sistema è permesso fare prima di perfezionare quello che riesce a vedere. La qualità del rilevamento è un problema di ingegneria di forma nota; l’autorità di agire su un rilevamento è un problema organizzativo, e richiede più tempo. Un sistema che vede tutto e non può fare nulla è uno strumento di reportistica che nessuno ha chiesto.

Domande

Rilevamento delle minacce SMS, risposte dirette

Che cosa ha effettivamente costruito Far Rainbow qui?

Un motore di rilevamento per il traffico SMS: classifica il contenuto dei messaggi, collega i singoli messaggi in campagne, resiste all’offuscamento che i mittenti usano per eludere i filtri ed espone il risultato attraverso un’API e query analitiche che un team operativo può interrogare direttamente. Attorno c’è una pipeline di etichettatura, perché le decisioni prese dagli analisti umani diventino dati di addestramento per la versione successiva dei modelli. È stato consegnato tra il 2025 e il 2026.

Perché il cliente non viene nominato?

L’incarico è coperto da un accordo di riservatezza che riguarda sia il cliente sia il traffico. Possiamo descrivere il sistema che abbiamo costruito e le decisioni ingegneristiche che lo sostengono. Non possiamo dire su quale traffico gira, in quale mercato, né cosa vi ha trovato. Sotto NDA, in una riunione, possiamo andare molto più a fondo.

Perché su questa pagina non ci sono cifre sui tassi di rilevamento?

Perché quelle che abbiamo appartengono al cliente. I tassi di rilevamento, i tassi di falsi positivi e i volumi di traffico sono misurati sul suo traffico e sono coperti dallo stesso accordo che copre il suo nome. Preferiamo pubblicare un solo numero misurato sul nostro hardware, con la metodologia completa, che tre percentuali di grande effetto che nessuno può verificare.

È un firewall SS7?

No, e non sosteniamo di averlo costruito. Un firewall di segnalazione sta inline sul percorso di rete e prende decisioni a livello di protocollo; costruirne uno da zero è un progetto diverso, con rischi diversi. Quello che abbiamo costruito è il livello di rilevamento e classificazione. Dove un operatore ha già un gateway di segnalazione, ci integriamo con la sua API; dove non ne esiste uno, il componente di rete viene definito come un lavoro a sé e non dato tacitamente per scontato.

Perché classificare gli SMS è più difficile che classificare le email?

La lunghezza e l’assenza di struttura. Una email porta con sé header, risultati di autenticazione, una storia di reputazione e di solito testo sufficiente perché un classificatore abbia qualcosa su cui lavorare. Un SMS vi dà circa centosessanta caratteri, una stringa mittente che può essere falsificata e nessun header degno di questo nome. Quasi tutto il segnale utilizzabile sta nel modo in cui un mittente si comporta nel tempo e nel modo in cui un messaggio assomiglia ad altri messaggi: per questo qui il collegamento delle campagne e la profilazione comportamentale pesano più della sola classificazione del contenuto.

Come gestite il testo offuscato deliberatamente?

Normalizzando prima del confronto, invece di confrontare con più accanimento. Alfabeti misti, caratteri simili, spazi e punteggiatura inseriti, traslitterazione tra sistemi di scrittura — tutto viene prima ridotto a una forma canonica, ed è lì che avviene il confronto. Il motore cerca quindi varianti di una campagna nota e non ripetizioni esatte: è la differenza tra intercettare la prima ondata e intercettare la quinta.

Che cos’è un profilo bayesiano del mittente, in parole semplici?

Un modello di come è fatta la normalità per un mittente specifico — a quest’ora, in questo giorno della settimana, con questo volume, con questa composizione di destinatari — e una probabilità che quello che sta facendo in questo momento se ne discosti. Risponde a “questo mittente è cambiato” invece che a “questo messaggio sembra cattivo”, e così intercetta un sender ID legittimo che è stato compromesso con la stessa facilità con cui intercetta uno nuovo e fraudolento. Uno scostamento dalla normalità è un motivo per guardare, non un verdetto: un’anomalia non è una prova di frode, e il sistema è costruito per dirlo.

Perché tutto questo ha bisogno di una GPU?

Perché l’unità di lavoro utile è un modello per mittente, tenuto aggiornato, e una rete ha moltissimi mittenti. Valutarli uno alla volta su una CPU è il collo di bottiglia; la stessa aritmetica eseguita in batch su migliaia di profili è ciò per cui esiste una GPU. La nostra misurazione di quel kernel è su questa pagina, con le avvertenze che le competono.

Dove risiede il contenuto dei messaggi?

All’interno del perimetro dell’operatore. È il principio architetturale su cui progettiamo: il contenuto dei messaggi, lo stato dei modelli e il registro delle decisioni restano nella rete da cui provengono, e l’unica cosa che attraversa il confine sono contatori aggregati — stato dell’installazione, versione, volume per la fatturazione. Un’architettura che invia i corpi dei messaggi al cloud di un fornitore è un’architettura che non regge alla domanda di un’autorità di vigilanza e che, in diverse giurisdizioni, non regge nemmeno alla fase di approvvigionamento.

Può funzionare sul nostro traffico?

È una domanda che ha una risposta vera, non commerciale, e dipende dal punto di integrazione. Il livello di rilevamento è portabile; ciò che varia è se la vostra piattaforma può eseguire l’azione che volete — osservare, limitare la frequenza, trattenere, rifiutare — e se gli eventi ci arrivano con abbastanza contesto da valere una valutazione. Il primo passo onesto è una breve sessione tecnica sulle vostre interfacce, non un documento di proposta.