# Wie Banken die Zustellung von Einmalpasswörtern und Betrugsfälle überwachen sollten

> Die KPIs, die Banken im Dashboard benötigen, die Betrugssignale, bei denen es sich lohnt, Alarm zu schlagen, und der operative Leitfaden für die OTP-Fehlermodi, die am ehesten Kosten verursachen.

- Kanonische URL: https://www.broadnet.me/de/blog/bank-otp-delivery-monitoring-fraud-playbook
- Sprache: de
- Zuletzt aktualisiert: 2026-10-20
- Herausgeber: BroadNet (https://www.broadnet.me)

- Veröffentlicht: 2026-04-30
- Autor: BroadNet Industry Research

Für eine Bank ist ein Einmalpasswort (OTP) keine bloße Benachrichtigung. Es dient der Kontrolle der sicherheitsrelevantesten Kundenprozesse – Login, Transaktionsbestätigung, Hinzufügen von Zahlungsempfängern, Kartenaktivierung und Geräteverknüpfung. Ein nicht zugestelltes OTP führt zu einem blockierten Kunden; ein zugestelltes OTP, das abgefangen, wiederholt eingegeben oder durch automatisierte Tests aufgebraucht wird, verursacht direkte Betrugsverluste und erfordert eine Auseinandersetzung mit der Aufsichtsbehörde. Banken benötigen daher im Vergleich zu anderen A2P-Anbietern eine präzisere OTP-Praxis: bessere Instrumente, eine proaktivere Betrugserkennung und einen dokumentierten Handlungsplan für vorhersehbare Fehler. So sieht diese Praxis aus.

## Die fünf KPIs, die an die Wand gehören

Die meisten Banken messen die Zustellung von Einmalpasswörtern (OTP) anhand einer einzigen Kennzahl – der „Zustellungsrate“ –, die jedoch fast immer ungenau ist. Denn die vom Messaging-Anbieter angegebene Zustellungsrate bezieht sich auf die Erfolgsquote der Übermittlung und nicht darauf, wie viele OTPs tatsächlich einen Kunden erreichten, der sie verwendet hat. Fünf Kennzahlen, erfasst pro Kanal und pro Zielbetreiber, liefern ein realistisches Bild.

1. Die End-to-End-Zustellungsrate gibt den Anteil der OTP-Anfragen an, bei denen der Zielbetreiber innerhalb des Gültigkeitszeitraums des OTP eine positive DLR-Antwort (DLR = [DLR](https://www.broadnet.me/answers/what-is-dlr)) zurückgegeben hat. Dies ist die tatsächliche Zustellungsrate, nicht die Annahmequote der Anfragen.
2. Latenz p50, p95, p99 – Übermittlung an das Endgerät, pro Kanal, pro Zielbetreiber. Erfasst als Zeitreihe, nicht als Einzelwert; Alarmbedingung ist die Verschlechterung gegenüber einem gleitenden Basiswert, nicht ein absoluter Schwellenwert.
3. Wiederholungsrate – Anteil der OTP-Anfragen, die innerhalb des Gültigkeitszeitraums zu einer vom Benutzer oder System ausgelösten erneuten Übermittlung führten. Eine steigende Wiederholungsrate ist das früheste Anzeichen für eine Verschlechterung der primären Zustellung; sie geht dem tatsächlichen Rückgang der Zustellungsrate fast immer voraus.
4. Ablehnungsrate aufgrund der Absender-ID – Anteil der Übermittlungen, die aufgrund der Absender-ID an der Betreibergrenze abgelehnt wurden. Ein Wert ungleich null deutet auf ein Registrierungsproblem hin; dies sollte als Nulltoleranz gemeldet werden.
5. OTP-Abschlussrate – der Anteil der OTP-Anfragen, bei denen der Nutzer den Code erfolgreich eingegeben hat. Dies ist die einzige wirtschaftlich relevante Kennzahl; alle anderen Werte fließen in sie ein. Eine Zustellungsrate von 99 % bei einer Abschlussrate von 70 % bedeutet, dass die Nachricht zu langsam ankam oder die Benutzerfreundlichkeit bei der Eingabe mangelhaft ist; eine Zustellung ohne Abschluss ist kein Erfolg.

## Betrugssignale, die Anlass zur Warnung geben

Die OTP-Infrastruktur stellt gleichzeitig eine Angriffsfläche für OTP-Angriffe dar. Drei Missbrauchskategorien sind häufig, die sich alle anhand der bereits von der Bank erfassten Daten erkennen lassen.

### 1. Wiederholte OTP-Anfragen für dieselbe MSISDN

Ein Angreifer, der den OTP-Ablauf eines einzelnen Kontos untersucht – manuell oder per Skript –, erzeugt eine charakteristische Signatur: zahlreiche OTP-Anfragen für eine Telefonnummer, oft zeitlich eng beieinander, manchmal mit wechselnden IP-Adressen oder User-Agent-Strings in der Ursprungssitzung. Ein legitimes Äquivalent (ein Benutzer, der den Code tatsächlich nicht finden kann) unternimmt maximal drei bis fünf Versuche innerhalb weniger Minuten; ein Angriffsprofil umfasst Dutzende oder Hunderte. Die Alarmschwellen sollten daher hoch angesetzt sein: Mehr als zehn OTP-Anfragen für eine MSISDN innerhalb von fünfzehn Minuten deuten fast immer entweder auf einen Angriff oder eine fehlerhafte Integration hin, die beide Aufmerksamkeit erfordern.

### 2. Geografische und verhaltensbezogene Anomalien

Eine OTP-Anforderung aus einer Sitzung in einem Land für eine Telefonnummer, die ursprünglich einem anderen Land zugeordnet war, ist nicht zwangsläufig Betrug – es könnte sich um einen Kunden auf Reisen handeln. Dennoch ist eine zusätzliche Authentifizierung ratsam, anstatt die Anforderung stillschweigend zu akzeptieren. In Kombination mit Änderungen des Geräte-Fingerabdrucks (neuer Browser, neue Geräte-ID, neue App-Installation) verstärkt sich das Signal. Das Risikomanagement der Bank sollte dies bereits für die Transaktionsautorisierung berücksichtigen; die Ausweitung auf die OTP-Vergabe ist ein schneller Erfolg.

### 3. Gedrosselte Aufzählung und Credential-Stuffing

Ein versierter Angreifer ermittelt Kontokennungen über den Passwortwiederherstellungsprozess, indem er bewusst die OTP-Drosselung pro Konto unterschreitet und gleichzeitig viele Konten parallel prüft. Charakteristisch ist eine hohe Anzahl von OTP-Anfragen über viele verschiedene MSISDNs aus einem kleinen Quellbereich, oft mit niedrigen individuellen Zählungen pro MSISDN, die unterhalb der Alarmschwelle pro Konto liegen. Zur Erkennung ist eine Aggregation über alle Quellquellen (IP, Geräteklasse, Sitzungsmuster) hinweg erforderlich, anstatt pro Konto. Genau dieses Muster wird bei SMS-Pumping-Angriffen verwendet, mit denen Angreifer die OTP-Infrastruktur ausnutzen, um die Provisionen der Anbieter pro Nachricht zu monetarisieren. Schutz davor schützt gleichzeitig vor Betrug und steigenden Anbieterkosten.

## Der operative Leitfaden für die vorhersehbaren Ausfallmodi

Drei Arten von OTP-Vorfällen treten bei jeder Bank immer wieder auf. Ein schriftlicher Handlungsplan für jeden einzelnen – und nicht etwa eine unter Druck erstellte Notfallanleitung – kann den Unterschied zwischen einer 15-minütigen und einer 4-stündigen Problembehebung ausmachen.

### Playbook 1 – Verschlechterung der Routenführung des Zielbetreibers

Signal: Die Latenz (p95) steigt bei einem bestimmten Zielbetreiber, während sie bei den anderen konstant bleibt; die Zustellungsrate zu diesem Betreiber sinkt. Maßnahme: Sicherstellen, dass die Verschlechterung routenseitig und nicht intern ist (die Übermittlungsakzeptanz liegt weiterhin bei 100 %); OTP-Verkehr für diesen Betreiber auf die sekundäre Route im Routing-System umleiten; das NOC des Providers zur Bestätigung und voraussichtlichen Ankunftszeit benachrichtigen. Wiederherstellung: Sobald die Metriken der primären Route 30 Minuten lang wieder im Normbereich liegen, wiederherstellen. Das vollständige Playbook sollte zehn Zeilen umfassen und vierteljährlich geübt werden.

### Playbook 2 – Anstieg der Absender-ID-Ablehnungen

Signal: Die Ablehnungsrate der Sender-ID steigt sprunghaft von null auf einen Wert ungleich null, fast immer für einen bestimmten Zielmarkt. Maßnahme: Prüfen Sie, ob die Registrierung der Sender-ID bei der zuständigen Aufsichtsbehörde des Zielmarktes abgelaufen oder widerrufen wurde (häufigste Ursache). Bestätigen Sie dies mit dem lokalen Aggregator. Verwenden Sie gegebenenfalls eine alternative registrierte Sender-ID für den betroffenen Markt und eskalieren Sie die Registrierung. Die Wiederherstellungszeit wird von der Aufsichtsbehörde und nicht von der Bank vorgegeben. Ziel des Playbooks ist es, die Auswirkungen während der Wartezeit zu minimieren.

### Playbook 3 – koordinierter OTP-Pumpangriff

Signal: Die Kosten pro erfolgreichem OTP steigen stark an; das Anfragevolumen an bestimmte Nummernkreise (oftmals angrenzende Premium-Nummern oder bestimmte Ländervorwahlen) schnellt sprunghaft in die Höhe; die Erfolgsquote dieser Anfragen liegt nahe null. Maßnahme: Aktivieren Sie die Zulassungsliste für Zielvorwahlen, falls noch nicht geschehen (dies ist die wirksamste Kontrollmaßnahme), drosseln Sie die OTP-Versandkette über die betroffenen Ursprungspfade und kontaktieren Sie das Betrugsteam Ihres Messengerdienstes. Wiederherstellung: Deaktivieren Sie die Zulassungsliste, sobald der Angriff beendet ist – für die meisten Banken ist eine dauerhafte Deaktivierung nicht ratsam. Siehe [HLR Lookup pre-flight](https://www.broadnet.me/products/hlr-lookup) als strukturelle Schutzmaßnahme gegen diese Art von Angriffen.

## Architektonische Entscheidungen, die die Spielpläne ermöglichen

Die wichtigsten Handlungspläne basieren allesamt auf architektonischen Entscheidungen, die vor dem Ereignis getroffen wurden, nicht auf Improvisationen währenddessen. Drei davon sollten besonders sorgfältig durchdacht werden.

- Mehrkanal-OTP von Anfang an – mindestens SMS und Sprachanruf; idealerweise SMS, WhatsApp-Authentifizierungsvorlage und Sprachanruf mit dokumentiertem automatischem Failover. Failover ist eine Steuerungsfunktion, kein Fallback; es sollte pro Route und Kategorie ohne Codeänderungen aufrufbar sein.
- Telemetriedaten zu Zustellung und Latenz pro Kanal und Betreiber – ohne diese Daten sind die oben genannten Dashboards nur ein Wunschtraum. Die Daten müssen vom Messaging-Anbieter als strukturierte DLR-Feeds und nicht als monatliche PDF-Berichte bereitgestellt werden.
- Dokumentiertes Absenderkennungsverzeichnis mit Ablaufdaten – dieses Verzeichnis sollte vom Compliance-Team der Bank geführt werden, nicht vom Messaging-Anbieter; Versäumnisse, die durch die mangelnde Überwachung der Verlängerung durch einen Anbieter verursacht werden, sind immer noch das Problem der Bank, wenn der Datenverkehr ausbleibt.

## Gespräch mit dem Anbieter – welche Daten sollten zurückfließen?

Ein bankenüblicher Messaging-Vertrag legt die vom Anbieter zurückgegebenen Betriebsdaten fest, nicht nur die Stückpreisliste. Erwarten Sie mindestens Folgendes:

- Echtzeit-DLR-Webhooks, die die Bank authentifizieren kann (etwa eine [HMAC-SHA256-Signatur](https://www.broadnet.me/answers/hmac-sha256-dlr-signing) mit gemeinsamem Secret, falls der Provider Callbacks signiert, oder eine IP-Zulassungsliste), damit die Bank die Übermittlungen mit der tatsächlichen Zustellung in ihrem eigenen SIEM abgleichen kann.
- Tägliche Zustellungs- und Latenzberichte, aufgeschlüsselt nach Zielbetreiber, Absender-ID und Route, geeignet zur Integration in den Observability-Stack der Bank.
- Monatliche Zusammenfassungen von Vorfällen mit Zeitleiste, Ursache und Abhilfemaßnahmen für alle anbieterseitigen Vorfälle, die den Datenverkehr der Bank beeinträchtigt haben.
- Direkte Eskalationskontakte beim NOC und Betrugsteam des Anbieters, auf der Grundlage einer SLA mit festgelegten Reaktionszeiten.

> Der OTP-Dienst von BroadNet liefert kanal- und betreiberspezifische Analysen zu Zustellung, Latenz und Abschluss als strukturierte Feeds – und die gleiche Betrugserkennungsschicht, die die Betreiberseite schützt, steht auch Unternehmenskunden von OTP als Vorab-Bewertung der Anfragen zur Verfügung, bevor diese in abrechnungsfähige Sendungen umgewandelt werden.

## Regulatorische Bereitschaft – die oft übersehene Dimension

Zentralbanken und Finanzaufsichtsbehörden stellen bei Prüfungen zunehmend explizite Fragen zur OTP-Infrastruktur: Wie sieht die Service-Level-Vereinbarung (SLA) aus? Wie funktioniert der Failover? Wie ist der Prüfpfad dokumentiert? Wie werden Betrugsmuster erkannt und darauf reagiert? Banken, die innerhalb von fünf Minuten anhand eines vorgefertigten Dossiers antworten können, bestehen die Prüfung problemlos; Banken, die die Antwort erst während der Prüfung zusammenstellen müssen, fallen durch. Die oben genannten KPIs und Playbooks bilden die Grundlage für dieses Dossier; sie sollten sowohl als Compliance- als auch als operative Dokumente betrachtet werden.

## Ein häufiges Anti-Muster, um in den Ruhestand zu gehen

Viele Banken implementieren OTP als Bestandteil des Authentifizierungsdienstes, anstatt es als eigenständiges System zu betreiben. Die Folge: Die Messaging-Integration liegt in der Verantwortung desjenigen, der den Authentifizierungsablauf ursprünglich entwickelt hat – oft jemand, der inzwischen das Team gewechselt hat. Niemand achtet auf die Telemetriedaten zur Zustellung pro Mitarbeiter. Erste Anzeichen einer Beeinträchtigung sind plötzliche Anrufe beim Kundensupport, die das Support-Team nicht auf ein Messaging-Problem zurückführen kann. Die Lösung ist strukturell: Ein benannter Verantwortlicher für die OTP-Infrastruktur mit einem kleinen, festen Team (oder ein klar benanntes Partnerteam), eine vierteljährliche Überprüfung des KPI-Dashboards und eine jährliche, umfassende Übung der oben genannten Vorgehensweisen anhand eines realistischen Vorfallszenarios. Die Anbieter von Messaging-Diensten für institutionelle Banken führen im Rahmen der Zusammenarbeit vierteljährliche gemeinsame Überprüfungen mit ihren Kunden durch; falls Ihr Anbieter dies nicht tut, fragen Sie danach.

## Wie Qualität in Zahlen aussieht

Eine gut funktionierende OTP-Infrastruktur einer Bank, die über direkte Betreiberrouten in einen regulierten GCC-Markt sendet und die oben beschriebene Fallback-Kette sowie die Betrugskontrollen nutzt, sollte folgende Werte erreichen: eine End-to-End-Erfolgsrate von über 99 % (nicht nur Zustellung – der Kunde muss die Identität tatsächlich bestätigt haben), eine p95-Latenz von unter fünf Sekunden auf dem primären Kanal, eine Ablehnungsrate aufgrund der Sender-ID von null, eine Wiederholungsrate von unter 3 % (darüber hinaus verschlechtern sich sowohl die Benutzerfreundlichkeit als auch die Kosten) und eine Blockierung betrugsbezogener OTP-Anfragen von unter 1 % des legitimen Datenverkehrs (falsch-positive Ergebnisse sind relevant – eine zu aggressive Blockierung führt zu Problemen mit der Kundenzufriedenheit). Banken, die diese Werte deutlich unterschreiten, weisen eine oder mehrere der sieben Fehlerursachen aus dem [Leitfaden zur Fehlerbehebung bei der OTP-Zustellung](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting) in der Produktion auf; diagnostizieren Sie die Ursache, bevor Sie Optimierungen vornehmen.

## Weiterführende Lektüre

- [Warum OTP-Nachrichten fehlschlagen und wie man Zustellungsprobleme behebt](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting)
- [Wie sich die Flash-Call-Verifizierung auf die A2P-Einnahmen der Betreiber auswirkt](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact)
- [Omnichannel-Messaging-Strategie für E-Commerce und Logistik](https://www.broadnet.me/blog/omnichannel-messaging-ecommerce-logistics-strategy)
- Glossar – [Was ist OTP?](https://www.broadnet.me/answers/what-is-otp), [Was ist SMS-Pumping?](https://www.broadnet.me/answers/what-is-sms-pumping), [Was ist ein DLR?](https://www.broadnet.me/answers/what-is-dlr)
- Produktseiten – [OTP-Dienst](https://www.broadnet.me/products/otp) und [MyOTP Sprach-OTP](https://www.broadnet.me/products/myotp)
- Abdeckung — [UAE OTP- und TDRA-konformes Routing](https://www.broadnet.me/coverage/uae)