Zum Inhalt springen
Telekommunikation fraudsicherheitml

Telekomfraud automatisch erkennen: SIM-Swapping, Wangiri, IRSF stoppen

ML-Modelle analysieren Verbindungsdaten in Echtzeit auf typische Betrugsmuster — Wangiri-Rückrufbetrug, International Revenue Share Fraud und SIM-Swapping werden erkannt, bevor der Schaden entsteht.

⚡ Auf einen Blick
Problem
Telekomfraud kostet europäische Netzbetreiber jährlich Milliarden Euro — klassische regelbasierte Systeme erkennen neue Angriffsmuster erst mit wochenlanger Verzögerung, während Fraud-Fenster sich in Minuten schließen.
KI-Lösung
Gradient-Boosted-Trees- und Isolation-Forest-Ensemble auf CDR-Daten und Signalisierungsereignissen erkennen anomale Verbindungsmuster in Echtzeit: ungewöhnliche Anrufketten, Signalsprünge beim SIM-Swapping, typische IRSF-Routen. Fraud-Score → automatische Sperre oder Eskalation.
Typischer Nutzen
Fraud-Losses um 40–60 % reduzierbar; Angriffsmuster innerhalb von Minuten statt Wochen erkannt; direkt messbarer ROI durch Vorher-Nachher-Vergleich der Fraud-Verluste.
Setup-Zeit
18–24 Monate bis produktiver Betrieb (CDR-Infrastruktur, Modelltraining)
Kosteneinschätzung
Spezialsystem 500.000–1,5 Mio. € Gesamtinvestition; Jahreslizenz 200.000–400.000 €; Custom-Pipeline 200.000–800.000 € Entwicklung + 30.000–120.000 €/Jahr Cloud
Regelbasiertes System mit ML-ErgänzungAzure ML / SageMaker Custom-PipelineSubex HyperSense / Neural Technologies
Worum geht's?

Es ist 2:17 Uhr. Marcus Heidler sitzt im Network Operations Center eines deutschen Regionalnetzbetreibers und schaut auf sein Fraud-Management-Dashboard.

Der Alert-Zähler zeigt 40 offene Meldungen — keine davon überschreitet den Schwellenwert für automatische Eskalation. Das System ist kalibriert auf Signifikanzniveau drei, weil darunter zu viele Fehlalarme die Analysten-Queue verstopfen. Was Marcus nicht sieht: Alle 40 Alerts gehören zusammen. Vierzig IRSF-Verbindungen zu Premium-Routen in Ostafrika, alle unter dem Radar, alle zusammen seit 23 Minuten aktiv. Ein koordinierter Angriff — verteilt auf Schwellenwerte, die kein einzelnes Muster auslösen.

Um 2:19 Uhr schläft Marcus Heidler noch. Um 6:14 Uhr, als er die Nachtschicht an seinen Kollegen Jens Vogt übergibt, hat der Angriff 280.000 Euro Fraud-Verlust verursacht. Jens sieht es zuerst in den Verbindungskosten-Statistiken — nicht im Fraud-System.

Das ist kein Versagen von Marcus. Das ist ein Versagen des regelbasierten Systems. Regeln funktionieren gegen bekannte Muster. Koordinierte Angriffe unterhalb der Schwellenwerte sind kein bekanntes Muster — sie sind Taktik.

Das echte Ausmaß des Problems

Die globale Telekommunikationsbranche verlor 2023 schätzungsweise 38,95 Milliarden US-Dollar durch Fraud — ein Anstieg von 12 Prozent gegenüber 2021 laut der Communications Fraud Control Association (CFCA Global Fraud Loss Survey 2023). Das sind 2,5 Prozent der weltweiten Telekommunikationsumsätze, die direkt als Fraud-Verlust abfließen.

Hinter dieser Summe stehen drei dominante Angriffstypen:

  • IRSF (International Revenue Share Fraud): 6,23 Milliarden Dollar allein in 2023 — der volumenstärkste Einzelfraud-Typ. Angreifer generieren künstlichen Traffic zu Premium-Routen in Ländern, wo Nummerninhaber und Carrier an den Verbindungsgebühren mitverdienen. Ein einziger koordinierter Angriff kann innerhalb von Stunden Verluste im sechsstelligen Euro-Bereich verursachen.

  • Wangiri: Japanisch für „einmal klingeln und auflegen”. Automatisierte Systeme rufen Tausende Nummern an, legen nach einem Klingelton auf — und warten darauf, dass Neugierige zurückrufen. Zurückgerufen wird auf eine kostenpflichtige Nummer, oft außerhalb Europas, mit Verbindungskosten von mehreren Euro pro Minute. Die Bundesnetzagentur verzeichnete 2024 insgesamt 154.624 Beschwerden zu Rufnummernmissbrauch — ein neuer Höchststand (Pressemitteilung BNetzA, Januar 2025).

  • SIM-Swapping: Ein Angreifer übernimmt durch Social Engineering oder kompromittierte Callcenter-Prozesse die Kontrolle über eine Mobilfunknummer. Danach kann er SMS-basierte Zwei-Faktor-Authentifizierung abfangen und Bankkonten, E-Mail-Zugänge und andere Dienste kapern. Der BfDI (Bundesbeauftragte für den Datenschutz) hat SIM-Swapping explizit als Authentifizierungs-Risikofeld identifiziert und Netzbetreiber aufgefordert, Callcenter-Prozesse zu härten.

Was alle drei Fraud-Typen gemeinsam haben: Das Fraud-Fenster ist eng. Bei IRSF: Minuten bis Stunden, bevor Verbindungskosten eskalieren. Bei Wangiri: Sekunden pro Anruf, Angriffswellen über Nacht. Bei SIM-Swapping: Die kritische Phase nach dem Swap dauert oft unter 30 Minuten, bevor ein Bankkonto geleert ist.

Regelbasierte Systeme erkennen neue Angriffsmuster erst, wenn jemand eine neue Regel schreibt — was Tage bis Wochen dauert. Machine Learning-Anomalie-Erkennung auf Verbindungsdaten verändert dieses Gleichgewicht.

Mit vs. ohne KI — ein ehrlicher Vergleich

KennzahlOhne KI (regelbasiert)Mit ML-Fraud-Detection
Erkennungszeit neue AngriffsmusterTage bis Wochen (neue Regel muss geschrieben werden)Minuten bis Stunden (Anomalie-Scoring in Echtzeit)
False-Positive-Rate20–35 % bei aggressiven Schwellenwerten2–5 % bei trainierten ML-Modellen
IRSF-Erkennungsrate40–60 % (nur bekannte Route-Muster)75–90 % (inklusive neuer Kombinationsmuster)
Koordinierte Angriffe unterhalb EinzelschwellenwertNicht erkanntDurch Korrelationsanalyse erkennbar
Manuelle Analyst-LastHoch — viele Fehlalarme zu prüfenDeutlich reduziert — Triage durch Score-Filterung
Dauer bis automatische ReaktionManuell: 30 Min. bis mehrere StundenAutomatisch: unter 2 Minuten nach Anomalie-Score
Anpassungsaufwand nach TaktikwechselNeuschreiben von RegelwerkKontinuierliches Modell-Retraining auf neuen Daten

Die Vergleichswerte stammen aus Branchenberichten von Subex und CFCA sowie Praxisberichten von Tier-1- und Tier-2-Operatoren. Erkennungsraten variieren stark je nach Datenqualität, Trainingsvolumen und Fraud-Typ.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5) Fraud-Detection spart keine Arbeitszeit im üblichen Sinn — sie verhindert Schaden. Analysten werden entlastet, weil False-Positive-Raten sinken und die Alert-Triage schneller wird. Aber der primäre Wert liegt nicht darin, dass Menschen schneller arbeiten, sondern darin, dass Verluste nicht entstehen. In der Vergleichsgruppe gibt es Use Cases mit weitaus direkterem Zeitgewinn pro Person.

Kosteneinsparung — maximal (5/5) Kein anderer Anwendungsfall in dieser Kategorie hat ein vergleichbares Einspar-Potenzial. Ein einziger IRSF-Angriff kann innerhalb von Stunden sechsstellige Verluste verursachen. Netzbetreiber, die Fraud-Detection implementieren, berichten regelmäßig von Schadensreduktionen im Bereich von Millionen Euro jährlich — und dieser Nutzen ist direkt messbar, weil Fraud-Verluste vor und nach dem System verglichen werden können.

Schnelle Umsetzung — am schwierigsten (1/5) Dies ist der komplexeste Use Case in der Kategorie. CDR-Datenstreaming in Echtzeit aufzusetzen, Signalisierungsdaten aus SS7- und Diameter-Protokollen zu extrahieren, Modelle auf ausreichend historischen Fraud-Daten zu trainieren und das System in die bestehende Netztopologie zu integrieren — das dauert 18–24 Monate in einer realistischen Planung. Kein Pilotbetrieb in Wochen möglich. Die technischen Voraussetzungen sind substanziell.

ROI-Sicherheit — maximal (5/5) Der Nutzen ist direkt messbar: Fraud-Verluste in Euro vor der Implementierung vs. danach. Keine Schätzungen, keine indirekten Effekte. Wenn ein Angriff durch automatische SIM-Sperre nach 90 Sekunden statt nach 4 Stunden gestoppt wird, ist die Differenz in Euro ausrechenbar. Dieser direkte Messbarkeits-Vorteil ist das beste Argument im Business Case.

Skalierbarkeit — maximal (5/5) Ein ML-System, das auf dem CDR-Stream eines Netzes mit 3 Millionen Abonnenten trainiert ist, lässt sich ohne grundlegende Architektur-Änderung auf 10 Millionen skalieren. Die Compute-Kosten steigen proportional zum Datenvolumen, aber die Systeminvestition (Aufbau, Integration, initiales Training) skaliert nicht proportional.

Richtwerte — stark abhängig von Netzgröße, vorhandener Signalisierungsinfrastruktur und internem Fraud-Team.

Die drei Angriffstypen: Was genau erkannt werden muss

ML-Fraud-Detection ist kein generisches Anomalie-System. Jeder der drei Fraud-Typen hat eine eigene Signatur im Verbindungsdaten-Stream — und braucht deshalb eigene Modell-Logik.

IRSF — International Revenue Share Fraud Das Erkennungsmerkmal ist nicht ein einzelner Anruf, sondern eine Anruf-Topologie: Ein oder mehrere Accounts generieren innerhalb kurzer Zeit ungewöhnlich viele internationale Verbindungsversuche zu einer engen Gruppe von Zielnummern in Premium-Route-Destinationen. Die Anrufdauer ist typischerweise kurz bis mittellang — lang genug, damit die Verbindungsgebühr entsteht, kurz genug, um nicht als Gesprächs-Traffic aufzufallen. ML-Klassifikationsmodelle lernen diese Topologie-Muster aus historischen bestätigten IRSF-Vorfällen und können neue Angriffswellen erkennen, auch wenn die Zielnummern oder Destinationen neu sind.

Wangiri-Erkennung Die Signatur ist einfacher, aber die Skalierung ist das Problem: Ein einzelner Wangiri-Anruf sieht aus wie jeder verpasste Anruf. Wangiri-Angriffe sind durch die Menge charakterisiert — Tausende kurze Verbindungsversuche von einer kleinen Gruppe von Ursprungsnummern in kurzer Zeit. Supervised-Learning-Modelle, trainiert auf der Kombination aus Ursprungs-/Zielnummern-Mustern, Anrufdauer-Verteilung und Anruf-Cluster-Struktur, erreichen in der Praxis nach IEEE-Forschungsdaten (Wangiri Fraud: Pattern Analysis and Machine-Learning-Based Detection, IEEE Xplore 2022) Erkennungsraten über 90 Prozent bei False-Positive-Raten unter 5 Prozent.

SIM-Swapping — Verhaltensprofil-Abweichung Hier ist die Datenlage anders: Der Fraud passiert nicht in den Verbindungsdaten selbst, sondern in der Signalisierungsschicht — eine plötzliche Änderung des zugeordneten SIM-Profils für eine Nummer, kombiniert mit anschließendem Verhalten, das vom Basisprofil des Teilnehmers abweicht. ML-Modelle auf Basis von Subscriber-Behavioral-Profiling erkennen: Wer hat diesen Account normalerweise von welcher geografischen Region aus genutzt? Zu welchen Tageszeiten? Mit welchen Anrufmustern? Eine SIM-Swap-Aktion kombiniert mit Zugriffen von einer neuen IMSI und einem veränderten Nutzungsprofil ist das Erkennungsmuster — nicht die Swap-Aktion allein.

Was das System konkret macht

Der technische Kern ist eine Echtzeit-Anomalie-Erkennungs-Pipeline auf CDR-Daten (Call Detail Records) und Signalisierungsereignissen:

Schritt 1: Datenaufnahme in Echtzeit. CDR-Streams fließen aus den Vermittlungsknoten (Switch, SMSC, SGSN/MME) in eine Stream-Processing-Plattform (Apache Kafka ist der industrielle Standard in Telco-Umgebungen). Parallel werden Signalisierungsereignisse aus dem SS7-Stack (MAP-Protokoll für SIM-Swap-Erkennung) und dem Diameter-Stack (für LTE/VoLTE) abgegriffen.

Schritt 2: Feature Engineering. Der CDR-Stream wird in Echtzeit angereichert: Für jeden Account werden gleitende Fenster berechnet (Anrufvolumen letzte 15 Minuten, 60 Minuten, 24 Stunden), Zielnummer-Entropie (wie viele verschiedene Ziele in welchem Zeitfenster?), geografische Sprünge und Protokollanomalien.

Schritt 3: Modell-Scoring. Jedes Feature-Set wird durch ein Ensemble von Modellen geleitet — typischerweise Isolation Forest für generische Anomalie-Erkennung (gut für unbekannte Muster), Gradient Boosted Trees oder Random Forest für klassifizierte bekannte Fraud-Typen, und bei manchen Systemen Graph Neural Networks für die Erkennung koordinierter Angriffe über mehrere Accounts. Das Ergebnis ist ein Fraud-Score pro Account oder Verbindung.

Schritt 4: Aktion. Der Score bestimmt die Reaktion — von “keine Aktion” über “Analyst-Alert” bis zu “automatische Verbindungssperre” oder “SIM-Sperre ausstehend”. Der Schwellenwert für automatische Aktionen ist der kritische Konfigurationsparameter: zu aggressiv gesetzt, entstehen False Positives die Geschäftskunden blockieren; zu defensiv gesetzt, wird Fraud nicht rechtzeitig gestoppt.

Schritt 5: Feedback-Loop. Analysten bestätigen oder verwerfen automatisch generierte Alerts. Dieses Feedback fließt als Trainings-Label zurück ins Modell — das System lernt kontinuierlich, welche Muster in deinem Netz tatsächlich Fraud sind.

Signalisierungsdaten und CDRs: Was der Algorithmus wirklich sieht

Der entscheidende Unterschied zwischen Telekomfraud-Detection und generischer Anomalie-Erkennung liegt in den Datenquellen. Ein einfaches System sieht nur CDRs — die Verbindungs-Logs im Nachhinein. Ein vollständiges System sieht zusätzlich:

  • SS7 MAP-Signalisierung: Jede UpdateLocation-Nachricht (wenn sich ein Gerät neu im Netz anmeldet), jede SendRoutingInfo-Anfrage (wer fragt, wo ein Teilnehmer gerade ist?), und jede RegisterSS-Nachricht (Weiterleitung wird eingerichtet). SIM-Swapping-Angriffe hinterlassen in der MAP-Signalisierung charakteristische Spuren — insbesondere wenn sie mit Call-Forwarding kombiniert werden.

  • Diameter-Protokoll: In LTE-/VoLTE-Netzen ersetzt Diameter das ältere SS7. Unusual Authentication-Requests, HSS-Queries aus unbekannten Quellen und Registration-Events außerhalb des geografischen Musters sind die Erkennungsmerkmale.

  • NRTRDE-Roaming-Daten: Für IRSF über Roaming-Verbindungen sind Near Real Time Roaming Data Exchange-Daten der Schlüssel — sie berichten Roaming-CDRs mit geringer Zeitverzögerung (typisch unter 4 Stunden), was Echtzeit-Erkennung von Roaming-IRSF ermöglicht.

Systeme, die nur CDR-Batch-Daten verarbeiten (nächtliche Importe), können diese Fraud-Typen nicht stoppen — sie können sie höchstens im Nachhinein analysieren. Das ist der wesentliche Qualitätsunterschied zwischen einem Reporting-System und einem Fraud-Detection-System.

Konkrete Werkzeuge — was wann passt

Die Tool-Landschaft für Telekomfraud-Detection ist stärker segmentiert als in den meisten anderen KI-Bereichen: Es gibt Spezialisten für Telekom-Fraud, die nichts anderes machen — und es gibt generische ML-Plattformen, auf denen Custom-Modelle aufgebaut werden können.

Subex HyperSense — Die meistgenannte Wahl für mittlere bis große Netzbetreiber. Über 350 vordefinierte Fraud-Typologien, AI-first Modell-Architektur, eingebettete GenAI für Alert-Erklärungen seit 2025. Referenzoperatoren: Tele2 Group. Betrieb auf Google Cloud verfügbar. Typisch ab 200.000 USD/Jahr. Implementierungszeitraum 6–18 Monate. Kein deutschsprachiger Support.

Neural Technologies Optimus — Spezialist mit über 30 Jahren Telco-Branchenerfahrung. Besondere Stärke: integrierter Signalisierungs-Stack für SS7- und Diameter-Überwachung, sodass keine separate Signaling-Gateway-Integration nötig ist. Das SCAMBlock-Modul deckt Wangiri und Robocall-Erkennung auf Netzebene ab. Kein öffentliches Preismodell. Implementierungszeitraum 6–12 Monate.

SAS Fraud Management — Primär auf Finanzinstitute ausgerichtet, aber von einigen Netzbetreibern für die Billing-Fraud-Komponente eingesetzt. Vorteil: Forrester-Leader-Status und Explainable AI für regulatorische Nachweispflichten. Nachteil: Keine Telecom-spezifischen Signalisierungs-Module. Ab 500.000 EUR/Jahr, 12–24 Monate Implementierung.

Azure Machine Learning + Apache Kafka — Für Netzbetreiber, die keine End-to-End-Vendor-Lösung wollen, ist eine Custom-Pipeline auf Azure ML mit eigenem Kafka-Stream-Processing eine Alternative. Vollständige Kontrolle über Modell-Architektur und Datenhosting in der EU (Frankfurt-Region). Erheblicher Entwicklungsaufwand: Mindestens 12–18 Monate für ein produktionsreifes System, eigene Data-Science-Kapazität erforderlich.

Amazon SageMaker — Ähnliche Ausgangslage wie Azure ML. Vorteil: AWS Kinesis für CDR-Streaming ist gut etabliert und mit SageMaker direkt integrierbar. Nachvollziehbar für Teams mit bestehendem AWS-Stack. EU-Region (Frankfurt) verfügbar für DSGVO-konformes Hosting.

Zusammenfassung: Wann welcher Ansatz

  • Vollständiges Telco-Fraud-System mit Signalisierungsmodulen → Subex HyperSense oder Neural Technologies Optimus
  • Schwerpunkt Wangiri/Robocall-Blocking → Neural Technologies SCAMBlock-Modul
  • Custom-Pipeline, volle Datenkontrolle, eigenes Data-Science-Team → Azure ML oder SageMaker
  • Billing-Fraud-Erkennung mit Explainability-Anforderungen → SAS Fraud Management

Rechtliche Besonderheiten: TKG, TDDDG und DSGVO

Dieser Abschnitt enthält rechtliche Orientierungspunkte — keine Rechtsberatung. Für verbindliche Einschätzungen zu eurer spezifischen Systemarchitektur wendet euch an einen Rechtsanwalt für Telekommunikationsrecht oder konsultiert die Beratungsangebote der Bundesnetzagentur (BNetzA).

CDR-Daten sind personenbezogene Verkehrsdaten Call Detail Records (CDRs) sind Verkehrsdaten im Sinne des TDDDG (Telekommunikation-Telemedien-Datenschutzgesetz). § 9 TDDDG erlaubt die Verarbeitung von Verkehrsdaten, soweit sie für die Erbringung des Telekommunikationsdienstes oder zur Abrechnung notwendig ist. Für die Fraud-Detection — die über Abrechnungszwecke hinausgeht — ist eine eigene Rechtsgrundlage notwendig.

Die verbreitete Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse): Der Netzbetreiber hat ein berechtigtes Interesse daran, Fraud zu verhindern — sowohl im Eigeninteresse (Schutz vor Erlösausfällen) als auch im Interesse seiner Kunden (Schutz vor SIM-Swapping und Identitätsmissbrauch). Dieser Ansatz muss jedoch mit einer Interessenabwägung belegt werden, die dokumentiert, dass das Interesse des Betreibers die Grundrechte der betroffenen Teilnehmer überwiegt. Klärt das mit eurem Datenschutzbeauftragten.

TKG §165 — Technische Schutzmaßnahmen als Pflicht § 165 des Telekommunikationsgesetzes verpflichtet Betreiber öffentlicher Telekommunikationsnetze und Anbieter öffentlich zugänglicher Telekommunikationsdienste dazu, technische und organisatorische Schutzmaßnahmen zu treffen. Fraud-Detection ist in diesem Kontext nicht nur erlaubt — es ist eine gesetzlich verankerte Schutzpflicht. Das stärkt die Rechtsgrundlage für die Verarbeitung.

Automatische SIM-Sperre — rechtliche Risiken Die Frage, ob eine automatische SIM-Sperre durch das ML-System ausgelöst werden darf, ist rechtlich sensibel. Eine automatisierte Einzelentscheidung, die den Telekommunikationsdienst für einen Teilnehmer unterbricht, greift in das Vertragsverhältnis ein und kann bei Fehlern (False Positives) Schadensersatzpflichten auslösen.

Empfohlener Ansatz: Automatische Sperre nur für eindeutige, hochpunktierte Fraud-Scores in Verbindung mit einem sofort ausgelösten manuellen Prüfprozess. Für niedrigere Scores: Alert an Fraud-Analysten, Sperre erst nach menschlicher Bestätigung. Blendet dazu in euer Fraud-Management-System eine Auditpfad-Funktion ein — jede automatisch ausgelöste Sperre muss mit dem zugehörigen Fraud-Score und dem auslösenden Datensatz dokumentiert sein, um regulatorische Prüfungen bestehen zu können.

Rufnummernmissbrauch und BNetzA-Zusammenarbeit Bei Wangiri-Fraud haben Netzbetreiber die Möglichkeit, auffällige Rufnummern bei der Bundesnetzagentur zur Abschaltung zu melden. 2024 hat die BNetzA rund 6.500 Nummern abgeschaltet. Das ML-System kann als Zulieferer für diese Meldeprozesse dienen — automatisch identifizierte Wangiri-Nummern werden als Meldungskandidat markiert, bevor sie an die BNetzA weitergegeben werden.

Signalisierungsüberwachung und Datenschutz Die Auswertung von SS7- und Diameter-Signalisierungsdaten ist in ihrer Tiefe besonders sensibel: Standortverfolgungsdaten und Rufumleitung-Konfigurationen können in falschem Kontext als Überwachungsmaßnahmen gewertet werden. Stellt sicher, dass die Signalisierungsauswertung ausschließlich auf Fraud-relevante Ereignisse beschränkt ist und keine umfassende Bewegungs- oder Verhaltensanalyse von Teilnehmern ermöglicht, die über den Fraud-Erkennungszweck hinausgeht.

Was es kostet — realistisch gerechnet

Einmalige Implementierungskosten Die Implementierungskosten setzen sich zusammen aus: Systemlizenz und Integrationsprojekt, CDR-Streaming-Infrastruktur (falls noch nicht vorhanden), Modelltraining auf historischen Fraud-Daten und UAT (User Acceptance Testing) mit dem Fraud-Team.

  • Spezialisiertes Telco-Fraud-System (Subex, Neural Technologies): 500.000–1,5 Mio. Euro Gesamtinvestition inklusive Lizenz und Implementierungsprojekt — typisch für einen Netzbetreiber mit 2–5 Millionen Abonnenten
  • Custom-Pipeline auf Azure ML oder SageMaker: 200.000–800.000 Euro Entwicklungsaufwand, ohne laufende Cloud-Compute-Kosten

Laufende Kosten (jährlich)

  • Lizenz Telco-Fraud-Spezialsystem: ab 200.000–400.000 Euro/Jahr (Subex) bzw. auf Anfrage (Neural Technologies)
  • Cloud-Compute für Custom-Pipeline: 30.000–120.000 Euro/Jahr je nach CDR-Volumen und Scoring-Frequenz
  • Fraud-Team-Betrieb: 1–3 Vollzeitstellen für Alert-Triage, Modell-Monitoring und BNetzA-Koordination — ohne dieses Team funktioniert kein System

Was du dagegenrechnen kannst Für einen Netzbetreiber mit 3 Millionen Abonnenten und einem ungeschützten jährlichen Fraud-Verlust von 4 Millionen Euro (IRSF, Wangiri, SIM-Swapping zusammen) bedeutet eine 50-prozentige Reduktion: 2 Millionen Euro eingespartes Fraud-Volumen. Bei einer Gesamtinvestition von 1,5 Millionen Euro (Jahr 1 inklusive Implementierung) und 400.000 Euro laufend ist der ROI im zweiten Jahr positiv. Die Rechnung ist aggressiv — Praxisberichte zeigen, dass die Erkennungsrate in den ersten 12 Monaten niedriger ist, weil Modelle noch trainiert werden.

Ehrliche Einschätzung: Der Business Case für dieses System rechnet sich nur, wenn der tatsächliche Fraud-Verlust das Investitionsvolumen signifikant übersteigt. Für Netzbetreiber mit weniger als 500.000 Abonnenten und nachweislichen jährlichen Fraud-Verlusten unter 500.000 Euro sind regelbasierte Systeme wirtschaftlich überlegen.

Wie du den Nutzen tatsächlich misst Die Grundlage der ROI-Messung ist eine Fraud-Verlust-Baseline: Was war der monatliche Fraud-Verlust in den 12 Monaten vor dem System-Start? Nach dem Start: Wie entwickelt sich derselbe Wert? Ergänze diese Kennzahl durch False-Positive-Rate (wie viele legitime Verbindungen wurden geblockt?) und Alert-Volumen vs. konfirmierte Fraud-Fälle als Qualitätsmaß für den Analysten-Aufwand.

Drei typische Einstiegsfehler

1. Das CDR-Streaming als Infrastruktur-Nebenprojekt behandeln. CDR-Daten existieren in jedem Netz — aber nicht in einer Form, die für Echtzeit-Fraud-Detection nutzbar ist. Viele Projekte scheitern daran, dass CDR-Exports als Batch-Jobs (täglich, nächtlich) laufen, während das Fraud-System Minuten-aktuellen Stream erfordert. Die Umstellung auf Stream-Processing über Apache Kafka oder eine äquivalente Plattform ist ein eigenständiges Infrastrukturprojekt mit einem Zeitaufwand von 3–6 Monaten — und kein Nebenprojekt. Wer das unterschätzt, startet das Fraud-Detection-Projekt mit halbem Datenfundament.

2. Das Modell einmal trainieren und als fertig betrachten. Fraud-Taktiken verändern sich schnell. Ein Modell, das auf IRSF-Mustern aus dem Jahr 2023 trainiert wurde, erkennt neue Routen-Kombinationen aus dem Jahr 2025 schlechter — weil Angreifer bewusst neue Destinationen wählen, die das Modell nicht kennt. Das ist kein hypothetisches Risiko, sondern Standard-Verhalten im Fraud-Ökosystem. Der GLF Fraud Report 2024 bestätigt: 48 Prozent der befragten Operatoren berichten von hohem IRSF-Volumen, obwohl Gegenmaßnahmen implementiert wurden — ein Indiz für adaptive Angriffstaktiken. Ohne strukturierten Retraining-Zyklus (quartalsweise, nach jedem bestätigten Major-Incident) degradiert die Erkennungsleistung. Modell-Monitoring ist Pflichtbetrieb, kein Zusatzaufwand.

3. Den Schwellenwert für automatische Sperre zu aggressiv kalibrieren. False Positives in der Fraud-Detection sind nicht nur Datenpunkte — sie sind Vorfälle, die Unternehmensbeziehungen beschädigen. Ein europäischer Netzbetreiber, der nach einem größeren Fraud-Vorfall die IRSF-Erkennungsschwellenwerte aggressiv nachschärfte, berichtete innerhalb von zwei Wochen, dass Enterprise-Kunden blockierte Konferenzschaltungen meldeten und internationale Callcenter Verbindungsraten um bis zu 40 Prozent einbrachen — Support-Tickets verdreifachten sich (Branchenbericht, anonymisiert). Das System war technisch korrekt kalibriert gegen IRSF-Muster, aber der Kollateralschaden an legitimem Traffic war nicht vorhergesehen worden. Kalibrierung gegen Fraud ist kein rein technischer Parameter — es ist eine Geschäftsentscheidung, die Fraud-Team, Netzmanagement und Kundenservice gemeinsam treffen müssen.

Was mit der Einführung wirklich passiert — und was nicht

Telekomfraud-Detection ist kein Produkt, das man kauft und einschaltet. Es ist ein Infrastrukturprojekt mit einem langen Anlaufpfad — und die Widerstände kommen selten aus der Technik.

Das Fraud-Team ist erst Skeptiker, dann Treiber. Fraud-Analysten, die seit Jahren mit regelbasierten Systemen arbeiten, sind oft skeptisch gegenüber ML-Scoring. Verständlich: Das Modell gibt einen Score, erklärt aber nicht automatisch, warum. Moderne Systeme haben Explainability-Funktionen (welche Features haben am stärksten zum Score beigetragen?), aber die Bereitschaft, einem Score zu vertrauen statt einem manuell nachvollziehbaren Regelwerk, muss erarbeitet werden. Investiere in der Einführungsphase bewusst Zeit dafür, dass das Fraud-Team versteht, wie das Modell funktioniert — nicht nur, was es meldet. Teams, die das Modell verstehen, werden zu seinen stärksten Verfechtern; Teams, die es als Blackbox erleben, untergraben es durch Nicht-Nutzung.

Rechtliches und regulatorisches Sign-off dauert länger als geplant. Die juristische Prüfung der Datenverarbeitungsgrundlagen (TDDDG, DSGVO, TKG), die Abstimmung mit dem Datenschutzbeauftragten und die interne Freigabe für automatische Sperr-Aktionen: Plane 3–6 Monate dafür ein. Projekte, die mit der technischen Einführung beginnen und die juristische Prüfung parallel laufen lassen, landen regelmäßig in der Situation, dass technisch ein fertiges System wartet, aber rechtlich kein Go gegeben werden kann.

Die ersten 90 Tage im Produktivbetrieb sind kritisch für die Modellgüte. Das Modell hat in dieser Phase noch wenige bestätigte True-Positive-Samples aus deinem spezifischen Netz. False-Positive-Raten sind zu Beginn höher als nach 12 Monaten Betrieb. Dieser Anlaufpfad muss gegenüber dem Management kommuniziert werden — sonst entsteht nach der ersten monatlichen Auswertung der Eindruck, das System funktioniere nicht. Definiere vor dem Go-live, welche KPIs nach 30, 90 und 180 Tagen realistisch erwartet werden.

Realistischer Zeitplan mit Risikohinweisen

PhaseDauerWas passiertTypisches Risiko
Infrastruktur-Assessment & PlanungMonat 1–2CDR-Streaming-Situation prüfen, Signalisierungsarchitektur dokumentieren, Vendor-Auswahl startenCDR-Daten nur als Batch verfügbar — Stream-Infrastruktur muss zuerst gebaut werden
CDR-Streaming-InfrastrukturMonat 2–6Kafka-Stream oder äquivalent aufbauen, Echtzeit-CDR-Export aus Vermittlungsknoten einrichtenIntegration mit Legacy-Switching-Hardware komplex — unerwartete Vendor-Abhängigkeiten
Juristisches & datenschutzrechtliches Sign-offMonat 3–6 (parallel)TDDDG-/DSGVO-Rechtsgrundlage klären, Datenschutzfolgenabschätzung, Abstimmung BfDI-PositionVerzögerung durch Datenschutzbeauftragten-Prüfung oder externe Anwaltsabstimmung
System-Konfiguration & Modell-TrainingMonat 6–12Historische Fraud-Daten aufbereiten, Baseline-Modelle trainieren, Alert-Schwellenwerte kalibrierenZu wenige historisch bestätigte Fraud-Samples — erschwert Supervised-Learning-Qualität
Pilotbetrieb Alert-onlyMonat 12–16System läuft, generiert Alerts, Analysten entscheiden — keine automatischen SperrenFalse-Positive-Rate zu hoch → Analystenwiderstand, Alert-Fatigue
Produktivbetrieb mit Auto-AktionenMonat 18–24Automatische Sperre bei Hoch-Score-Alerts, Analyst-Prüfung für Mittel-Scores, kontinuierliches RetrainingÜber-aggressiver Schwellenwert blockt legitime Enterprise-Verbindungen

Häufige Einwände — und was dahintersteckt

„Wir haben ein regelbasiertes System, das gut genug ist.” Regelbasierte Systeme sind gut gegen bekannte Muster. Das Grundproblem: IRSF-Angreifer testen neue Routen-Kombinationen bewusst so, dass sie unter bekannten Regeln fliegen. Koordinierte Angriffe, die unter Einzelschwellenwerten bleiben, sind eine explizite Umgehungsstrategie. Ob dein System gut genug ist, lässt sich beantworten: Berichte der tatsächlichen Fraud-Verluste zeigen, wie viel durch das bestehende System nicht erkannt wird. Wenn du diesen Wert nicht hast, ist das selbst ein Signal.

„Der ROI ist nicht nachweisbar — wir wissen nicht, wie viel Fraud wir verlieren.” Das Henne-Ei-Problem: Ohne Fraud-Detection-System keine präzise Baseline, ohne Baseline kein Business Case. Der Ausweg ist eine Stichproben-Analyse: Audit einen repräsentativen Monat der CDR-Daten mit einem Fraud-Spezialisten (viele Anbieter machen das als Pre-Sales-Analyse). Subex HyperSense und Neural Technologies Optimus bieten kostenlose Proof-of-Concept-Analysen an, die typische Fraud-Muster in deinen historischen Daten identifizieren — ohne Systemkauf. Das Ergebnis dieser Analyse ist dein Business-Case-Fundament.

„18–24 Monate sind zu lang — bis dahin ist die Technologie schon veraltet.” Die Implementierungszeit ist keine technologische Limitierung, sondern eine Folge der Infrastruktur-Komplexität (CDR-Streaming, Signalisierungs-Integration, Modelltraining) und regulatorischer Anforderungen. Technologie-Veralterung ist in diesem Bereich kein ernsthaftes Risiko: Die Grundarchitektur aus Stream-Processing, ML-Scoring und Feedback-Loop ist stabil — was sich ändert, sind die Fraud-Typen, gegen die das System trainiert wird. Das System ist so gebaut, dass es sich durch Retraining anpassen lässt, nicht durch Ersatz.

Woran du merkst, dass das zu dir passt

  • Du bist Netzbetreiber mit mehr als 500.000 aktiven Abonnenten — unter diesem Schwellenwert sind die Trainings-Datenvolumen für aussagekräftige ML-Modelle zu gering
  • Deine nachgewiesenen jährlichen Fraud-Verluste übersteigen 1 Million Euro — darunter rechnet sich die Investition nicht
  • Du hast oder kannst ein dediziertes Fraud-Team aufbauen — mindestens ein bis zwei Fraud-Analysten für Alert-Triage und Modell-Monitoring
  • CDR-Daten stehen dir zeitnah zur Verfügung — oder du bist bereit, in Stream-Infrastruktur zu investieren
  • Du hast Zugriff auf SS7- oder Diameter-Signalisierungsdaten — für SIM-Swapping-Erkennung unerlässlich
  • Dein Netz ist an internationale Interconnect-Verbindungen angeschlossen — ohne Interconnect kein IRSF-Risiko, aber auch kein Bedarf für IRSF-Detection

Wann dieses System (noch) nicht das richtige ist — drei harte Ausschlusskriterien:

  1. Unter 500.000 aktive Abonnenten oder Subscriber-Volumen zu niedrig für ML-Training. Ein Anomalie-Erkennungsmodell braucht ausreichend historische Fraud-Samples, um zwischen normalem und fraudulentem Verhalten unterscheiden zu können. Bei zu geringem Datenvolumen überwiegen Rauschen und False Positives. MVNOs unter diesem Schwellenwert sind besser mit regelbasierten Systemen bedient — oder mit einer Managed-Service-Option eines größeren Carriers, der das Fraud-System für mehrere kleinere Operatoren zusammen betreibt.

  2. Kein dediziertes Fraud-Team und keine Bereitschaft, eines aufzubauen. Ein ML-System ohne Analysten, die Alerts prüfen, Feedback ins Modell geben und Schwellenwerte kalibrieren, ist kein funktionierendes Fraud-Management — es ist eine Alert-Schleuder, die sich schnell in einem Zustand stabiler Ignoranz einpendelt. Die häufigste Form des Scheiterns in diesem Bereich ist nicht technisch, sondern organisatorisch: Das System läuft, aber niemand schaut hin.

  3. Keine Echtzeit-CDR-Streaming-Infrastruktur und kein Budget dafür. Batch-basierte CDR-Verarbeitung (Tagesbatch, Nachtimport) ist kein Fundament für Fraud-Detection. Bis ein Nacht-Batch verarbeitet ist, hat ein IRSF-Angriff sein Fenster vollständig genutzt. Die Infrastruktur-Investition in Real-time CDR-Streaming ist kein Add-on — sie ist Voraussetzung. Wer diese Investition nicht leisten kann oder will, sollte mit einem Managed-Service-Anbieter sprechen, der die Infrastruktur mitbringt.

Das kannst du heute noch tun

Der sinnvollste erste Schritt ist keine Systemauswahl — es ist eine Datenqualitäts-Analyse: Wie vollständig und wie aktuell sind eure CDR-Daten? In welchem Format liegen sie vor? Wie groß ist das Zeitfenster zwischen Verbindungsende und CDR-Eintrag?

Die meisten Fraud-Detection-Anbieter (Subex HyperSense, Neural Technologies Optimus) bieten kostenlose Analyse-Workshops an, in denen sie eure historischen CDR-Daten auf typische Fraud-Muster untersuchen. Das Ergebnis zeigt, wie groß das tatsächliche Fraud-Exposure ist — und bildet die Grundlage für einen belastbaren Business Case.

Für eine erste interne Analyse — bevor du mit Anbietern sprichst — kannst du diesen Prompt verwenden, um eine strukturierte Bestandsaufnahme eurer Fraud-Situation und CDR-Infrastruktur zu erstellen:

Bestandsaufnahme: Fraud-Situation und CDR-Infrastruktur
Du hilfst mir, eine strukturierte Bestandsaufnahme unserer Telekomfraud-Situation zu erstellen. Ich bin [DEINE ROLLE] bei einem Netzbetreiber mit ca. [ANZAHL] Abonnenten. Stell mir folgende Fragen und fasse die Antworten strukturiert zusammen: 1. Welche Fraud-Typen beobachten wir aktuell? (IRSF, Wangiri, SIM-Swapping, andere?) 2. Wie messen wir aktuell unsere Fraud-Verluste? (Billing-Differenzen, manuelle Stichproben, Kundenreklamationen?) 3. In welchem Format liegen unsere CDR-Daten vor? (Echtzeit-Stream, stündlich, täglich, nächtlich?) 4. Haben wir Zugriff auf SS7- und Diameter-Signalisierungsdaten? 5. Gibt es ein dediziertes Fraud-Team oder ist Fraud-Monitoring eine Nebenaufgabe? 6. Welche regelbasierten Systeme nutzen wir heute? Erstelle danach eine Einschätzung: - Welche Fraud-Typen haben bei uns das größte Risikopotenzial? - Welche Dateninfrastruktur-Lücken müssen vor einem ML-System geschlossen werden? - Was ist der realistische erste Schritt in Richtung ML-basierte Fraud-Detection? [DEINE ANTWORTEN AUF DIE FRAGEN HIER EINFÜGEN]
Funktioniert mit ChatGPT, Claude, Gemini
Beispiel-Ausgabe

Mitarbeiter:in

Wir sind ein regionaler Netzbetreiber mit 2 Millionen Abonnenten. IRSF haben wir durch Billing-Differenzen identifiziert — etwa 80.000 Euro im letzten Quartal, schätzen wir. CDRs bekommen wir als Nachtbatch. SS7 haben wir, aber kein Monitoring. Fraud-Analysen macht unser Netzmanagement-Team nebenbei.

KI-Assistent

Bestandsaufnahme Fraud-Situation: **Fraud-Risiko-Einschätzung:** - IRSF: Hohes Risiko — 320.000 Euro/Jahr geschätzte Verluste, nur durch Billing-Differenz erkannt. Koordinierte Angriffe unterhalb der Erkennungsschwelle wahrscheinlich unentdeckt. - Wangiri: Unbekanntes Risiko — keine aktive Erkennung vorhanden. - SIM-Swapping: Unbekanntes Risiko — kein SS7-Monitoring, kein Subscriber-Behavioral-Profiling. **Dateninfrastruktur-Lücken:** - CDR als Nachtbatch: kritische Lücke für Echtzeit-Fraud-Detection. IRSF-Fenster liegt oft unter 4 Stunden — Nachtbatch erkennt den Schaden, stoppt ihn nicht. - SS7 vorhanden aber ohne Monitoring: Potenzial für SIM-Swapping-Erkennung ungenutzt. **Realistischer erster Schritt:** 1. CDR-Streaming-Analyse: Können CDRs aus euren Switching-Systemen in nahezu-Echtzeit exportiert werden? Das klärt, ob Infrastruktur-Investition notwendig ist. 2. Historische Fraud-Analyse: Ladet einen Fraud-Spezialisten (Subex HyperSense, Neural Technologies Optimus) zu einer CDR-Analyse-Session ein — kostenlos als Pre-Sales-Workshop. Ergebnis: realistische Fraud-Exposure-Schätzung. 3. Fraud-Team-Entscheidung: Bevor ein System eingeführt wird, muss klar sein, wer die Alerts betreut.

Quellen & Methodik

  • CFCA Global Fraud Loss Survey 2023: Communications Fraud Control Association, November 2023. Globale Fraud-Verluste: 38,95 Mrd. USD (12 % Anstieg vs. 2021). IRSF-Anteil: 6,23 Mrd. USD. URL: cfca.org/wp-content/uploads/2023/11/Global-Fraud-Loss-Survey-2023.pdf
  • BNetzA Pressemitteilung Januar 2025: Bundesnetzagentur, 15. Januar 2025. Über 150.000 Beschwerden zu Rufnummernmissbrauch im Jahr 2024. URL: bundesnetzagentur.de/SharedDocs/Pressemitteilungen/DE/2025/20250115_RufMiss.html
  • GLF Fraud Report 2024: Global Leaders Forum / i3Forum, 2024. 50 % der Operatoren berichten erstmals seit 2018 von Rückgang in Fraud-Volumen; 48 % berichten weiterhin hohes IRSF-Volumen. URL: glfcommunity.com
  • IEEE Xplore — Wangiri Fraud Detection: „Wangiri Fraud: Pattern Analysis and Machine-Learning-Based Detection.” IEEE Journals & Magazine, DOI: 10.1109/ACCESS.2022.xxxx. Erkennungsraten über 90 % bei False-Positive-Raten unter 5 % mit Ensemble-ML-Ansatz.
  • BfDI-Position SIM-Swapping: Bundesbeauftragter für den Datenschutz und die Informationsfreiheit, 2023. SIM-Swapping als Authentifizierungs-Risikofeld; Aufruf zur Härtung von Callcenter-Prozessen. URL: bfdi.bund.de/SharedDocs/Kurzmeldungen/DE/2023/14_Authentifizierung.html
  • TDDDG § 9 — Verarbeitung von Verkehrsdaten: Telekommunikation-Telemedien-Datenschutzgesetz, aktuelle Fassung. Maßgeblich für Rechtsgrundlage CDR-Verarbeitung.
  • Subex HyperSense Praxisberichte: Subex Limited, publizierte Einführungsstudien 2023–2025. False-Positive-Senkung von 12 % auf unter 3 % nach 3-monatigem Feedback-Loop. URL: subex.com
  • Implementierungskosten und Betriebsmodelle: Erfahrungswerte aus Branchenberichten und Anbieter-Dokumentation für Tier-2-Netzbetreiber (2–5 Mio. Abonnenten, Stand Mai 2026).

Du willst wissen, ob euer aktuelles CDR-Setup als Grundlage für ML-Fraud-Detection reicht — und welcher der drei Fraud-Typen bei euch das größte ungebundene Risiko hat? Meld dich — das lässt sich mit einer strukturierten Datenanalyse in wenigen Wochen klären.

Diesen Inhalt teilen:

🤝

Interesse an diesem Use Case?

Schreib uns, wenn du mehr erfahren oder diesen Use Case für dein Unternehmen umsetzen möchtest. Wir melden uns zeitnah bei dir.

Deine Daten werden ausschließlich zur Bearbeitung deiner Anfrage verwendet (Art. 6 Abs. 1 lit. b DSGVO). Mehr in unserer Datenschutzerklärung.

Kostenloser Newsletter

Bleib auf dem neuesten
Stand der KI

Wähle deine Themen und erhalte relevante KI-News, Praxistipps und exklusive Inhalte direkt in dein Postfach – kein Spam, jederzeit abmeldbar.

Was interessiert dich? Wähle 1–3 Themen — du bekommst nur Inhalte dazu.

Mit der Anmeldung stimmst du unserer Datenschutzerklärung zu. Jederzeit abmeldbar.

Kostenlos
Kein Spam
Jederzeit abmeldbar