Betrugsmanagement in der Telekommunikation (SIM-Box, IRSF, Wangiri, SIM-Swap, A2P-SMS-Betrug)

Telekommunikationsbetreiber verlieren Umsatz und Kundenvertrauen durch Betrug, der über ihre eigenen Netze läuft: Verkehr, der Interconnect-Entgelte umgeht (SIM-Box), Anrufe, die auf Premiumnummern gepumpt werden (IRSF), Ping-Anrufe mit einmaligem Klingeln (Wangiri), gekaperte Rufnummern (SIM-Swap) sowie über graue Routen geleitete oder gefälschte geschäftliche SMS. Betrugsmanagementsysteme bewerten CDR-, Signalisierungs- und Provisionierungsereignisse nahezu in Echtzeit, sperren verdächtige Routen und Rufnummern und geben Betrugsanalysten per ML priorisierte Fälle. LLMs unterstützen bei Fallzusammenfassungen und Streitfällen mit Partnern; die Entscheidung, Kunden zu sperren oder Partner zu kündigen, bleibt bei geschulten Analysten und festgelegten Richtlinien.

Problem & Nutzen

• Wer: Festnetz- und Mobilfunkbetreiber, MVNOs/MVNEs, Großhandelsanbieter (Carrier), CPaaS-/SMS-Aggregatoren und Unternehmen mit großen PBX-/SIP-Beständen (Toll Fraud). Abzugrenzen von ANOM-025, das Endnutzer auf ihren Telefonen schützt, und von ANOM-022 (bankseitige Betrugszahlungen); dieser Anwendungsfall liegt auf der Betreiberseite.
• Heute: regelbasierte Betrugsmanagementsysteme (FMS) mit Schwellenalarmen je Ziel, je Teilnehmer und je Route, dazu manuelle Untersuchung, Testanruf-Plattformen und bilaterale Streitbearbeitung. Die Regeln brauchen ständige Abstimmung; Betrüger wechseln Rufnummern, SIM-Bereiche und Routen innerhalb von Stunden.
• Warum KI hilft: Verhaltens-Baselines je Teilnehmer/Route, unüberwachte Erkennung neuer Muster, Graph-Verknüpfung von SIMs, Geräten und Konten sowie die automatische Anreicherung von Fällen verkürzen die Sichtungszeit der Analysten und das Fenster zwischen Betrugsbeginn und Sperre.
• Ausmaß des Problems: Die Communications Fraud Control Association (CFCA) führt eine periodische globale Umfrage zu Verlusten durch Telekommunikationsbetrug durch [1]. Wir nennen hier keine Gesamtverluste, weil die vollständige Umfrage Mitgliedern vorbehalten ist; Zahlen entnehmen Sie der aktuellen CFCA-Umfrage.

Varianten

• SIM-Box / Interconnect-Umgehung: SIM-Farmen terminieren internationalen Verkehr als lokale Mobilfunkgespräche. Die Erkennung nutzt Verkehrsprofil-Merkmale (kurze, viele Ziele, gleichförmige Anrufmuster, keine Mobilität, keine Datennutzung) und die Bestätigung per Testanruf.
• IRSF (International Revenue Share Fraud): künstlich aufgeblähter Verkehr zu Premiumzielen, typischerweise über gehackte PBXs oder missbrauchte Anschlüsse. Die Erkennung basiert auf Geschwindigkeit und Zielen, mit schneller Sperre.
• Wangiri (Ping-Anruf) und Rückruf-Betrug: sehr viele ultrakurze Anrufe bei vielen Teilnehmern; Erkennung auf Netzebene plus Warnung der Teilnehmer (siehe ANOM-025).
• SIM-Swap und eSIM-Swap / Kontoübernahme: ungewöhnliche SIM-Wechsel, Rufnummernmitnahmen oder eSIM-Profilübertragungen erkennen; ein SIM-Swap-Signal über Netz-APIs im Stil von CAMARA für Banken und Fintechs bereitstellen [2][3] (Verbindung zu ANOM-022, ANOM-014).
• A2P-SMS-Betrug: Verkehr über graue Routen, SMS-Pumping (künstlich aufgeblähter Verkehr), Fälschung von Absender-IDs und Smishing-Kampagnen an SMS-Firewalls; bei CPaaS-Anbietern zusätzlich Pumping gegen OTP-Endpunkte.
• Abo-/Identitätsbetrug und Endgerätebetrug: synthetische Identitäten, Betrug bei Gerätefinanzierung, Mobile-Money-Betrug (z. B. in Märkten mit starker Mobile-Money-Nutzung).
• Toll Fraud bei Unternehmen: KMU mit SIP-Trunks/Cloud-PBX nutzen die Ausgabenlimits und Zielsperren ihres Betreibers oder UCaaS-Anbieters; KI-basierte Anomaliewarnung ist eine Funktion des Anbieters und kein eigenes Projekt.
• Nicht im Umfang: inhaltsbasierter Schutz von Endnutzern auf dem Gerät (ANOM-025), Überwachung durch Strafverfolgung (eigenes Rechtsregime; hier nicht dokumentiert).

So funktioniert es

1. CDR/signalling/SMS/provisioning streams
2. normalisation & enrichment (rate tables, number ranges, device DB)
3. streaming feature store
4. rules + supervised models (gradient boosting) + unsupervised anomaly detection + graph linkage
5. alarm scoring
6. auto-action (throttle/block/route change) or analyst case
7. LLM case summary
8. analyst decision
9. feedback labels
10. retraining

Zentrale Komponenten: - Streaming-Erfassung von CDRs (Latenz von Sekunden bis Minuten); die Latenz bestimmt, wie viel IRSF-Schaden vermieden wird. - Merkmale: Verteilungen der Gesprächsdauer, Answer-Seizure-Ratio, Entropie der Ziele, Fan-out der B-Nummern, Tageszeit, Mobilität/Zellnutzung je SIM, Verhältnis von Daten zu Sprache, Verhältnisse von SMS-Absendern zu -Empfängern, Konversionsraten (zugestellte gegenüber verifizierten OTPs zur Erkennung von Pumping). - Modelle: Gradient-Boosting-Bäume für gelabelte Betrugstypen, Isolation Forest/Autoencoder oder Baselines je Entität für neuartige Muster, Graph-Clustering für SIM-/Geräte-Ringe. - LLM-Schicht: fasst die Belege eines Falls zusammen, entwirft Streitnotizen für Partner und interne Berichte und beantwortet Fragen der Analysten anhand der Fallakte. Sie trifft keine Sperrentscheidungen. - Mensch-in-der-Schleife (Human-in-the-Loop): Analysten bestätigen Sperren über sichere automatisierte Maßnahmen hinaus (zum Beispiel die Sperre des Dienstes eines Postpaid-Kunden oder die Beendigung einer Carrier-Route), bearbeiten Streitfälle mit Kunden und labeln Ergebnisse.

Datenaufbereitung

Benötigte Daten: Verbindungsdatensätze, Signalisierungs- und SMS-Logs, Provisionierungs- und SIM-Daten, Tariftabellen und Rufnummernbereiche, Gerätedatenbanken und Fallergebnisse. Sie liegen typischerweise in Mediations- oder Abrechnungssystemen, im HLR/HSS und in SMS-Gateways, teils in Dateiexporten von Carriern und in den Tabellen der Analysten.

Typische Lücken: uneinheitliche CDR-Formate zwischen Netzelementen, verzögerte Feeds, fehlende Labels für bestätigten Betrug, veraltete Tariftabellen und Rufnummernbereiche, doppelte Teilnehmeridentitäten und Zugriffsbeschränkungen, weil CDRs personenbezogene Verkehrsdaten sind.

Schritte der Aufbereitung: CDRs in ein Schema normalisieren und streamen (siehe PREP-005, PREP-007), mit Ziel- und Tarifreferenzen anreichern (PREP-012), stabile Merkmalsdefinitionen je SIM, Route und Absender aufbauen, Labels aus früheren Alarmen und Streitergebnissen gewinnen (PREP-020) und Betrugskategorien festlegen (PREP-019). Mit den Analysten einen Testdatensatz bekannter Betrugsepisoden erstellen (PREP-018). Teilnehmerkennungen für die Entwicklung pseudonymisieren und niemals rohe CDRs an externe LLMs senden (PREP-022). Werkzeuge: Kafka oder Redpanda, Flink, ClickHouse, dbt. Etwa 40 bis 50 Prozent des Aufwands fließen in Feeds und Merkmale; siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• enterprise (Betreiber): A, weil spezialisierte Plattformen für Betrugsmanagement in der Telekommunikation Umgehung, IRSF, SMS- und Roaming-Betrug mit Partnerdaten und ausgereiften Integrationen abdecken; B passt zu Betreibern, die eigene Merkmale wollen.
• developer: C, weil Kafka, Flink und Open-Source-Anomalieerkennung einen eigenen Stack erlauben, wobei HW2 für Zusammenfassungen genügt.
• smb (kleine MVNOs, CPaaS-Anbieter, Wiederverkäufer): A, weil ein verwalteter Betrugsdienst oder eine Firewall Schutz ohne Data-Science-Team bietet.

Weg A — Kaufen (Standardsoftware)

Spezialisierte Telekommunikations-FMS-/Revenue-Assurance-Plattformen sind für Betreiber die Standardwahl. Anbieter sind unter anderem Subex (FraudZap, KI-gestütztes Betrugsmanagement für Umgehung, SMS, Abonnements, Roaming und IRSF [4]), Mobileum (Risikomanagement, Roaming- und Signalisierungssicherheit), Enea/AdaptiveMobile Security (SMS- und Signalisierungs-Firewalls), Syniverse, Cleartouch, Araxxe und Lanck Telecom (Frankreich, EU) sowie CPaaS-seitige Werkzeuge von Infobip und Sinch (Fraud Guard / Schutz vor SMS-Pumping). Prüfen Sie Produktlinien und aktuelle Eigentümer bei jedem Anbieter, denn die Branche hat sich konsolidiert. A wählen, wenn Sie Betreiber oder MVNO ohne großes Data-Science-Team sind; MVNOs beziehen das Betrugsmanagement oft von ihrem MVNE. Prüfen Sie EU-Hosting, Datenresidenz und Bedingungen zu Unterauftragsverarbeitern.

Weg B — Auf Cloud-KI-Diensten aufbauen

Nutzen Sie einen verwalteten Streaming- und ML-Stack (Kafka/verwaltete Entsprechungen, einen Cloud-Feature-Store, Dienste für Gradient Boosting und Anomalieerkennung) in einer EU-Region, dazu eine LLM-API (in der EU gehostete Endpunkte großer Clouds oder EU-Anbieter wie Mistral) ausschließlich für Fallzusammenfassungen. Realistisch für CPaaS-Anbieter, große Unternehmen und MVNOs, die eigene Merkmale wollen. Senden Sie niemals rohe CDRs oder Teilnehmerkennungen an ein LLM; senden Sie pseudonymisierte Fallbelege. Das Sperren in Echtzeit darf nicht von einem LLM-Aufruf abhängen.

Weg C — Selbst betreiben (Open Source)

Apache Kafka oder Redpanda und Apache Flink für Streaming; ClickHouse oder Apache Druid für CDR-Analysen; XGBoost/LightGBM, PyOD oder scikit-learn für Modelle; eine Graphdatenbank (z. B. Neo4j, Memgraph) für die SIM-/Geräte-Verknüpfung; ein Open-Weight-LLM (z. B. Modelle der Klasse Llama oder Mistral, aktuelle Lizenzen prüfen) für Zusammenfassungen auf einer Workstation-GPU. Die CDR-Volumina in der Telekommunikation sind groß, daher sind Speicher und Stream-Verarbeitung der Kostentreiber, nicht die GPU. Sinnvoll für Tier-1/2-Betreiber mit Datenteams und Souveränitätsanforderungen; hoher Betriebsaufwand. Signalisierungs-Firewalls und Testanruf-Plattformen erfordern in der Regel weiterhin spezialisierte Produkte.

Weg D — Eigenes Training

Lohnend für betreiberspezifische Muster: Klassifikatoren für Betrugstypen, trainiert auf jahrelang gelabelten Alarmen, Baselines je Route, Graph-Embeddings für SIM-Ringe. Benötigt gelabelte Fallergebnisse (Hunderte bis Tausende je Betrugstyp), stabile Merkmalsdefinitionen und Drift-Überwachung. Das Feintuning eines LLM ist selten nötig; Retrieval über die Fallhistorie genügt.

Stand der Technik (2026)

• Architektur: Verschiebung von Batch-Regeln zu Streaming-ML mit automatisierten, umkehrbaren Maßnahmen und von Silos je Anbieter zu gemeinsamen Plattformen für CDR-, Signalisierungs- und SMS-Daten.
• Netz-APIs: CAMARA, ein Open-Source-Projekt der Linux Foundation, das von Betreibern bereitgestellte Dienst-APIs definiert [2], enthält eine SIM-Swap-API, die Informationen über jüngste Änderungen der SIM-Zuordnung zu einer Rufnummer liefert [3]. Banken nutzen solche Signale als zusätzlichen Faktor bei Risikoentscheidungen zu Zahlungen und Kontowiederherstellung. Die Verfügbarkeit variiert je nach Betreiber und Land.
• Agentische Assistenten: Anbieter vermarkten KI-Agenten für Betrugsermittlungen (zum Beispiel Subex' AI Agents Squad mit einem Fraud Investigative Agent [4]); behandeln Sie diese als Unterstützung der Analysten und validieren Sie die Ausgaben anhand von Belegen.
• Betrug mit Hilfe generativer KI: KI-generierte Stimmen und Texte machen Social-Engineering-Kampagnen billiger (siehe SEC-011); die Erkennung auf Betreiberseite stützt sich auf Verkehrsverhalten statt auf Inhalte.
• Grenzen und Fehlerbilder: Konzeptdrift, wenn Betrüger sich anpassen; legitimer Verkehr mit hohem Volumen (Callcenter, Notfallbenachrichtigung, Marketingkampagnen, Roaming-Spitzen), der Falsch-Positive verursacht; spärliche Labels; Betrug, der normale Nutzung nachahmt; betreiberübergreifende blinde Flecken (jeder Betreiber sieht nur seinen eigenen Verkehr); Latenz bei der CDR-Erfassung. Zu viel Sperren stört Kunden und kann Dienstverpflichtungen verletzen.

Gemeinsame Bausteine & Kombinationen

• Gemeinsame Bausteine: Streaming-Erfassung, Feature Store, tabellarisches ML und Anomalieerkennung, Graphanalyse, Fallmanagement und Rückkopplungsschleife, identisch mit ANOM-001 (Kartenbetrug) und ANOM-002 (Geldwäsche); dieselbe Graph-Engine bedient ANOM-004 (gefälschte Konten und Plattformmissbrauch).
• ANOM-022 und ANOM-014: SIM-Swap- und Rufnummernverifizierungs-Signale speisen die bankseitigen Prüfungen zu APP-Betrug und Identitätsnachweis.
• ANOM-025: Erkennung auf Betreiberseite und Betrugswarnungen auf dem Gerät ergänzen sich (gemeinsame Daten zur Reputation von Rufnummern).
• SEC-002, SEC-005, SEC-006, SEC-011: Informationen zu Smishing und Phishing, Verhaltens-Baselines von Nutzern, Netzüberwachung und Erkennung von Deepfake-Stimmen nutzen Merkmale und Bedrohungs-Feeds mit.
• ANOM-005: Methoden zur Anomalieerkennung in Zeitreihen für Netztelemetrie werden mit der industriellen Anomalieerkennung geteilt.
• Hardware: Die Streaming- und Speicherschicht dominiert; eine einzelne HW2-GPU deckt LLM-Zusammenfassungen und Embeddings ab. Die Echtzeit-Bewertung läuft auf CPU.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis wenige Monate für die Integration der Feeds, danach laufende Abstimmung; die Lizenz richtet sich meist nach Verkehrsvolumen oder Teilnehmerzahl. Weg B: Monate; Kostentreiber sind Streaming-Rechenleistung und Speicher. Weg C: Quartale; Personal und Speicher. Weg D: ergänzt ein Data-Science-Team und Labeling-Aufwand.
• Kennzahlen: Betrugsverlust als Anteil am Umsatz; Zeit von Betrugsbeginn bis zur Sperre; Präzision der Alarme und Falsch-Positiv-Rate bei legitimem Verkehr; Fälle je Analyst und Stunde; Anteil automatisch erledigter Alarme; über Streitfälle zurückgeholter Umsatz; SIM-Swap-Vorfälle, die zu einer Kontoübernahme führen; Kundenbeschwerden wegen unberechtigter Sperren.

Menschen & Veränderung

Beginnen Sie mit der Leitung und dem Leiter von Betrugsabwehr oder Revenue Assurance, dann IT und Netzbetrieb, die die Feeds liefern und Sperren durchführen, sowie IT-Sicherheit. Die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte muss eingebunden sein, weil CDRs und Verkehrsdaten personenbezogene Daten sind und dem Fernmeldegeheimnis (TDDDG) unterliegen; eine Datenschutz-Folgenabschätzung (DSFA) ist im Teilnehmermaßstab wahrscheinlich, und jeder Anbieter braucht einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO.

Betriebsrat: kommt darauf an. Er ist beteiligt, wo Analystenkonsolen die individuelle Bearbeitung und Leistung protokollieren (§87 Abs. 1 Nr. 6 BetrVG); die Betrugserkennung selbst überwacht Verkehr, nicht Beschäftigte. Informieren Sie ihn nach §90 Abs. 1 Nr. 3, wenn sich Arbeitsabläufe ändern. Kleine Anbieter ohne Betriebsrat überspringen diesen Schritt, sollten die Beschäftigten aber dennoch anhören.

Maßnahmen zur KI-Kompetenz (AI Act Art. 4) sollten Analysten beim Lesen von Alarmwerten unterstützen und vermitteln, dass das LLM nur zusammenfasst. Starten Sie einen Pilot mit einem Betrugstyp, etwa SMS-Pumping oder IRSF, und betreiben Sie ihn im reinen Alarmmodus, bevor Sie das automatische Drosseln einschalten. Typische Bedenken sind unberechtigte Sperren legitimer Kunden und Alarmflut; begegnen Sie ihnen mit ausschließlich sicheren automatischen Maßnahmen, Freigabe durch Analysten bei Sperren von Postpaid-Diensten und einem Beschwerdeverfahren. Siehe GUIDE-005, GUIDE-011 und GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Typische Systeme zur Betrugserkennung haben minimales Risiko. Anhang III Nr. 5 Buchst. b führt die Bewertung der Kreditwürdigkeit als Hochrisiko auf, schließt aber KI-Systeme zur Erkennung von Finanzbetrug aus [5]. Telekommunikationsnetze fallen nicht unter die Kategorie kritische Infrastruktur (Sicherheitsbauteile) des Anhangs III, außer das System wirkt als Sicherheitsbauteil des Netzes, was dieser Anwendungsfall normalerweise nicht tut. Ergebnis: minimal, wobei die KI-Kompetenz nach Art. 4 gilt. Prüfen Sie erneut, wenn die Werte in Entscheidungen über den Zugang natürlicher Personen zu wesentlichen Diensten einfließen (zum Beispiel kreditähnliche Entscheidungen über die Eignung für Prepaid gegenüber Postpaid).
• DSGVO / ePrivacy: CDRs und Signalisierung sind personenbezogene Daten und Verkehrsdaten. Das deutsche TDDDG und die nationalen Umsetzungen der ePrivacy-Richtlinie sowie das Telekommunikationsgesetz erlauben die Verarbeitung von Verkehrsdaten zur Erkennung von Betrug und Missbrauch unter bestimmten Bedingungen; klären Sie die Rechtsgrundlage (Zweckbindung, Speicherfristen, Erforderlichkeit) mit der bzw. dem Datenschutzbeauftragten und einer Fachanwältin bzw. einem Fachanwalt für Telekommunikationsrecht. Automatisches Sperren, das Einzelne betrifft, löst die Schutzvorkehrungen nach Art. 22 DSGVO aus (menschliche Prüfung und ein Weg zum Widerspruch). Analysieren Sie zu diesem Zweck keine Gesprächsinhalte.
• Branchenrecht: Fernmeldegeheimnis, NIS2 und nationale Vorschriften zur Telekommunikationssicherheit, Regeln zu Rufnummernübermittlung (CLI) und Rufnummernfälschung durch nationale Regulierer (in Deutschland die Bundesnetzagentur) sowie vertragliche Interconnect-Bedingungen für Streitfälle.
• Risiken und Gegenmaßnahmen: unberechtigte Sperren (umkehrbare Maßnahmen, Allow-Lists, schneller Widerspruch), Modelldrift (Überwachung und Champion/Challenger), Zugriff von Insidern auf Teilnehmerdaten (rollenbasierter Zugriff, Protokollierung), Datenabfluss über LLMs (pseudonymisieren, EU-Hosting, keine rohen CDRs in Prompts).

Erste Schritte

1. Ermitteln Sie die Ausgangslage: Betrugsverlust nach Typ, mittlere Zeit bis zur Erkennung und Sperre sowie Präzision der Alarme aus Ihrem bestehenden FMS.
2. Erfassen Sie die Daten-Feeds (CDR-Latenz, Signalisierung, SMSC, Provisionierung) und stimmen Sie Rechtsgrundlage und Speicherfristen mit der bzw. dem Datenschutzbeauftragten ab.
3. Beginnen Sie mit einem Typ mit hohem Verlust (typischerweise IRSF oder SIM-Box) und ergänzen Sie ML-Bewertung neben den bestehenden Regeln im Schattenmodus.
4. Ergänzen Sie Fallmanagement mit Rückmelde-Labels; erproben Sie dann LLM-Zusammenfassungen an pseudonymisierten Fällen.
5. Prüfen Sie für SIM-Swap, Signale im Stil von CAMARA für Bank- oder Fintech-Partner bereitzustellen, und legen Sie SLAs und den Umgang mit Einwilligungen fest [2][3].

Quellen

1. CFCA (Communications Fraud Control Association), insights and fraud loss survey page, https://cfca.org/insights-intelligence-2/ (accessed 2026-10; survey figures are in a member-gated PDF and are not quoted)
2. CAMARA project (Linux Foundation open-source network APIs), https://camaraproject.org/ (accessed 2026-10)
3. CAMARA SimSwap API repository, https://github.com/camaraproject/SimSwap (accessed 2026-10)
4. Subex, telecom fraud management and AI products, https://www.subex.com/ (accessed 2026-10)
5. EU AI Act Annex III, https://artificialintelligenceact.eu/annex/3/ (accessed 2026-10)