SQL-Muster zur Erkennung von Transaktionsbetrug

(analytics.fixelsmith.com)

17 Punkte von GN⁺ 2026-05-17 | 4 Kommentare | Auf WhatsApp teilen

Bei der Betrugserkennung beginnt die Arbeit oft noch vor Machine Learning damit, Tabellen und Joins sauber aufzusetzen und ungewöhnliche Muster bei Geschwindigkeit, Ort, Betrag, Händler und Uhrzeit mit SQL zu finden
Velocity sucht Intervalle, in denen sich Transaktionen desselben Karteninhabers in kurzer Zeit häufen; dafür braucht es Anpassungen bei Zeitfenster, Schwellenwerten und Whitelists gegen False Positives
Impossible travel erkennt mit LAG() und Distanzberechnung physisch unmögliche Bewegungen wie eine Zahlung in Chicago und 7 Minuten später in Los Angeles als starkes Signal für eine geklonte Karte
Betragsanomalien suchen nach Preisniveaus wie $1.00, $99.99, $499.99, die auf Kartentests oder Regelumgehung hindeuten, sich aber für Leistungszahlungen kaum eignen
Mit plötzlichen Händleranstiegen, Transaktionen außerhalb der üblichen Uhrzeit und aus Window Functions abgeleiteten Spalten lassen sich Transaktionen über mehrere Signale hinweg bewerten und Iterationszyklen von Wochen auf Stunden verkürzen

SQL-Muster, um Betrugssignale in Transaktionsdaten zu finden

Betrugserkennung beginnt oft noch vor Machine Learning oder Graphdatenbanken mit den richtigen Tabellen und Joins sowie SQL, das ungewöhnliche Transaktionsmuster findet
Anwendbar auf Daten, in denen Geld fließt und Logs entstehen, etwa bei Kreditkarten, medizinischen Abrechnungen, E-Commerce, POS oder staatlichen Unterstützungsprogrammen
Bei neuen Datensätzen baut man Muster meist in dieser Reihenfolge auf: Velocity, unmögliche Bewegung, Betragsanomalien, Händlerkonzentration, ungewöhnliche Uhrzeit, Signale auf Basis von Window Functions

1. Velocity: zu viele Transaktionen in kurzer Zeit

Wenn gestohlene Karten oder Konten schnell ausgeschöpft werden sollen, zeigt sich beim selben Karteninhaber oft ein Muster geballter Transaktionen in kurzer Zeit
Eine Basisabfrage gruppiert die Transaktionen der letzten 30 Tage stundenweise und sucht Bereiche, in denen die Zahl der Transaktionen pro cardholder_id einen Grenzwert überschreitet
Die wichtigsten Stellschrauben sind Größe des Zeitfensters und Schwellenwert für die Transaktionsanzahl
- Varianten für 1 Minute, 5 Minuten und 1 Stunde lassen sich parallel ausführen und vergleichen
- Kartentest-Gruppen bündeln Transaktionen oft innerhalb von Sekunden, während Gruppen für Leistungsbetrug über einen halben Tag verteilt agieren können
Auch normale Nutzer können den Grenzwert überschreiten
- Betreiber von Verkaufsautomaten
- Personen, die Prepaid-Karten in großem Umfang aufladen
- Nach der ersten Exploration braucht man daher eine Whitelist für False Positives
Ein Sliding-Window-Ansatz berechnet mit COUNT(*) OVER (...) RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW die Zahl der Transaktionen in den letzten 5 Minuten
QUALIFY funktioniert in Snowflake, BigQuery, Databricks und Teradata
- In Postgres muss die gesamte Abfrage als CTE gekapselt und außen gefiltert werden

2. Impossible travel: physisch unmögliche Bewegung

Wenn eine Karte in Chicago belastet wird und 7 Minuten später in Los Angeles, ist vermutlich mindestens eine der beiden Transaktionen gefälscht
Dieses Muster ist ein starkes Signal für Kartenklone, denn es gibt kaum legitime Gründe, warum eine Karte innerhalb weniger Minuten an zwei weit entfernten Orten sein sollte
Die Abfrage holt mit LAG() Zeit und Ort der vorherigen Transaktion und berechnet Distanz und Zeit zwischen aktuellem und vorherigem Ort
haversine ist eine Funktion zur Berechnung der Großkreisentfernung (great-circle distance)
- Die meisten Data Warehouses stellen sie bereit
- Falls nicht, lässt sie sich als eigene Funktion gut selbst schreiben
Ein Beispiel-Schwellenwert ist 600mph
- Da die Reisegeschwindigkeit von Verkehrsflugzeugen bei etwa 575mph liegt, wäre selbst per Flugzeug ein solches Tempo nicht möglich
- Senkt man auf 100mph, lassen sich auch schnelle Bewegungen am Boden erkennen, aber dann geraten auch legitime Fälle wie Flugreisende oder Eltern, die ihre Kinder fahren, ins Raster
Aus derselben Familie lassen sich weitere Signale ableiten
- Wenn innerhalb von 5 Minuten in zwei weit entfernten Städten desselben Bundesstaats bezahlt wird, kann das auf eine lokale Klon-Gruppe hindeuten
- Wenn innerhalb einer Stunde in mehreren ZIP-Codes Transaktionen auftauchen, kann das auf eine Skimmer-Gruppe in einer Region hindeuten
- Grenzüberschreitende Transaktionen innerhalb von 10 Minuten können ein Signal für eine internationale Gruppe sein

3. Amount anomalies: ungewöhnliche Transaktionen in bestimmten Betragsbereichen

Bei Betrug treten Betragsmuster, die im normalen Verhalten selten sind, häufig auf
Die Beispielbedingungen suchen nach folgenden Betragsbereichen
- $1.00, $5.00, $10.00
- >= $99.50 und < $100.00
- >= $499.50 und < $500.00
Kleine glatte Dollarbeträge sind meist ein Signal für Kartentests
- Dabei wird geprüft, ob Nummern aus Kartendumps tatsächlich funktionieren, bevor sie weiterverkauft werden
- Dass ein echter Karteninhaber exakt $1.00 für einen Kauf zahlt, ist selten
- Kaffee kostet eher $4.73, Tanken eher $52.81 statt exakt gerundeter Beträge
Beträge knapp unter einem Schwellenwert haben eine andere Bedeutung
- $99.99 kann darauf hindeuten, dass eine Grenze umgangen werden soll, ab der vielerorts ab $100 eine Ausweiskontrolle verlangt wird
- $499.99 kann darauf hindeuten, dass ein tägliches ATM-Limit von $500 umgangen werden soll
- Das ist ein Signal dafür, dass der Händler oder Täter die Regeln kennt und knapp darunter bleibt
Bei Leistungszahlungen helfen gerundete Betragsmuster meist wenig
- Leistungen werden nicht auf dieselbe Weise wie Karten getestet
- Dort sind doppelte Leistungsbezieher oft das wichtigere Signal

4. Suspicious merchants: verdächtige Konzentration auf Händlerebene

Wenn ein bestimmter Kartenleser, etwa an einer Zapfsäule, mit einem Skimmer kompromittiert ist, führt das nicht zu einem Einzelfall, sondern oft zu Dutzenden Betrugsfällen
Alle Karten, die diesen Leser über Wochen genutzt haben, können in irgendeiner Datenbank gelandet sein
Aus Händlersicht zeigt sich das als plötzlicher Anstieg nicht zusammenhängender Karten in kurzer Zeit, oft zusammen mit höheren Beträgen
Ein einfaches Beispiel gruppiert die letzten 7 Tage nach Händler und Stunde und berechnet
- Anzahl eindeutiger Karten
- Gesamtzahl der Transaktionen
- Gesamtsumme der Transaktionen
- Gesucht werden Zeitfenster mit mehr als 20 eindeutigen Karten und mehr als $5000 Gesamtumsatz
Statische Schwellenwerte haben ein Problem bei der Größennormalisierung
- Costco kann diesen Grenzwert in 90 Sekunden überschreiten
- ein Gebrauchtbuchladen fast nie
Besser ist es, jeden Händler mit seiner eigenen historischen Baseline zu vergleichen
- Die letzten 60 Tage werden stundenweise gruppiert
- Für jeden Händler wird auf Basis der vergangenen 168 Stunden-Buckets die durchschnittliche Zahl eindeutiger Karten berechnet
- Gesucht werden Intervalle, in denen die aktuelle Zahl eindeutiger Karten mehr als das Dreifache des historischen Durchschnitts beträgt
168 Stunden-Buckets entsprechen den letzten 7 Tagen in Stundenintervallen
- Tages- und Wochen-Saisonalität ist wichtig
- Selbst dasselbe Café hat am Dienstag um 14 Uhr eine andere Baseline als am Samstag um 9 Uhr
Als Startpunkt kann man das Dreifache des Normalwerts verwenden
- locker genug, um keine Alarmflut zu erzeugen
- streng genug, um tatsächlich auffällige Zeitfenster zu finden

5. Off-hours: Transaktionen außerhalb der üblichen Nutzungszeiten einer Person

Die meisten Menschen haben Gewohnheiten beim Ausgeben
Wenn jemand mit klassischem 9-bis-5-Job plötzlich um 3 Uhr morgens tankt, könnte die Karte von jemand anderem genutzt werden oder die Person ist auf Reisen
Ob eine Reise vorliegt, lässt sich mit anderen Signalen weiter prüfen
Die Abfrage berechnet zunächst für die letzten 90 Tage die Zahl der Transaktionen pro Karteninhaber und Stunde und erkennt nur Zeitfenster mit mindestens 2 Transaktionen als übliche Stunden an
Danach werden neue Transaktionen markiert, wenn ihre Uhrzeit außerhalb des Bereichs earliest_hour bis latest_hour des Karteninhabers liegt
Die Bedingung „mindestens 2 Transaktionen in dieser Stunde“ in der inneren Abfrage ist wichtig
- Sie verhindert, dass ein zufälliger nächtlicher Tankvorgang von vor 3 Monaten bereits als typische Nutzungszeit gilt
- Der Maßstab wird damit nicht an „einmal passiert“, sondern an echte Gewohnheiten angepasst
Nachteil: historische Daten sind nötig
- Für neue Konten gibt es noch keine Baseline
- Für neue Konten kann man Muster der Gesamtnutzerschaft verwenden oder dieses Muster überspringen, bis einige Monate Daten vorliegen

6. Signale mit Window Functions kombinieren

Muster mit Window Functions sind weniger ein eigener Betrugstyp als vielmehr Vorarbeit, um die fünf vorherigen Muster in kombinierbare Signale zu verwandeln
Pro Transaktion lassen sich etwa folgende abgeleitete Spalten erzeugen
- Vergangene Zeit seit der vorherigen Transaktion: timestamp - LAG(timestamp)
- Ob der Händler gewechselt hat: Vergleich zwischen vorherigem merchant_id und aktuellem merchant_id
- Kumulierte Summe der letzten 24 Stunden: SUM(amount) OVER (...)
- Die wievielte Transaktion des Tages es ist: ROW_NUMBER()
Wenn diese Spalten materialisiert vorliegen, schrumpfen Betrugsregeln auf einfache Filterausdrücke
Eine Kartentest-Gruppe lässt sich etwa mit diesen Bedingungen finden
- mindestens die fünfte Transaktion des Tages
- weniger als 60 Sekunden seit der vorherigen Transaktion
- Händler unterscheidet sich von der vorherigen Transaktion
Wenn sich eine neue Betrugshypothese statt als Engineering-Ticket als SQL-Filter ausdrücken lässt, verkürzt sich der Iterationszyklus von Wochen auf Stunden
Dadurch lässt sich mehr Betrug schneller erkennen

Wie man die Muster gemeinsam einsetzt

Kein einzelnes Muster reicht aus
Jedes Muster hat klare Grenzen
- Velocity produziert False Positives etwa bei Betreibern von Verkaufsautomaten
- Geografisch unmögliche Bewegung übersieht Betrug innerhalb derselben Metropolregion
- Betragsanomalien funktionieren außerhalb des Kontexts von Kartentests oft schlecht
- Regeln für ungewöhnliche Uhrzeiten brauchen Verlaufshistorie
In der Praxis funktioniert es, alle Muster auszuführen und jede Transaktion über mehrere Signale hinweg zu bewerten
Transaktionen, die bei drei oder vier Signalen auffallen, sind fast immer Betrug
Transaktionen, die nur ein einziges Signal auslösen, können auch ungewöhnliche, aber legitime Nutzung durch reisende Karteninhaber sein
Wer gerade mit Betrugserkennung anfängt, sollte mit Velocity beginnen
- liefert eine nützliche Menge an Betrugsfällen
- erfasst relativ wenig legitime Aktivität
- ist günstig auszuführen
Wenn die Muster 1 bis 5 bereits vorhanden sind, ist der nächste sinnvolle Investitionspunkt roh abgeleitete Spalten auf Basis von Window Functions
- Einmal gebaut, können sie von allen Analysten im Team genutzt werden
- Das nächste Betrugsmuster wird damit kein eigenes Projekt mehr

Worauf man achten sollte

Umgang mit NULL
- Reale Transaktionstabellen verwenden NULL oft nicht so wie SQL-Einführungen
- Viele Legacy-Systeme nutzen Sentinel-Werte wie 9999-12-31 für „kein Enddatum“ und 0001-01-01 für „kein Startdatum“
- Wer nur mit IS NULL filtert, kann solche Zeilen unbemerkt übersehen
- Vor dem Schreiben der WHERE-Klausel sollte man die Konventionen der jeweiligen Tabelle prüfen
False Positives
- Jede Regel kann echte Karteninhaber mit ungewöhnlichem, aber legalem Verhalten markieren
- Markierte Fälle brauchen menschliche Prüfung
- Es braucht eine Feedback-Schleife, die Schwellenwerte anhand echter Betrugsfälle und Nicht-Betrugsfälle anpasst
- Wer auf Basis einer einzelnen Regel automatisch blockiert, riskiert Kunden zu verlieren
Datenschutz
- Wenn die Daten PII enthalten, müssen die geltenden Richtlinien zur Datennutzung eingehalten werden
- Zuerst sollte man mit anonymisierten oder Beispiel-Daten arbeiten; Produktionsdaten nur nach Freigabe verwenden
Kosten
- Window Functions auf großen Partitionen sind nicht billig
- Zuerst sollte man den Datumsbereich filtern und erst danach Window Functions anwenden
- Wer LAG() zuerst über zwei Jahre Transaktionen des gesamten Datensatzes laufen lässt und WHERE erst danach anfügt, kann das Warehouse-Credit-Budget schnell stark belasten

4 Kommentare

kaydash 2026-05-17

Das ist wohl eine Methode, die früher im Kernbankensystem und in den Kanalsystemen übernommen wurde.

GN⁺ 2026-05-17

Hacker-News-Kommentare

Ob echte Karteninhaber tatsächlich fast nie etwas für genau 1,00 $ kaufen, hängt doch wohl davon ab, wie der Händler seine Preise festlegt
Wenn jemand auf einer Website etwas kauft, um eine gestohlene Kreditkarte zu testen, kann der Käufer den Preis nicht frei bestimmen
Außerdem wirkt das zu stark auf Situationen wie in den USA zugeschnitten, wo Steuern nicht im Preis enthalten sind; in anderen Regionen sind glatte Preise sehr üblich
Ich bezweifle auch, dass die anderen Kriterien gut funktionieren. Wenn man zum Beispiel Personen markiert, die in den letzten 90 Tagen außerhalb der Zeitfenster transagiert haben, in denen sie normalerweise mehr als zwei Transaktionen tätigen, würde man dann nicht etwa die Hälfte der Menschen markieren?
Es ist unklar, ob das ein Text ist, der komplexes Fachwissen in übermäßig einfache SQL-Abfragen herunterbricht, oder ob alles nur Vermutung und Erfindung ist. Die Sätze „Sechs SQL-Muster zur Erkennung von Transaktionsbetrug“ und „Hier steht nichts, woran ich tatsächlich gearbeitet habe oder das ich selbst gesehen habe“ widersprechen sich
- „Transaktionen außerhalb der üblichen Zeiten“ wirkt wie ein ziemlich grundlegendes Kriterium
  Normalerweise kauft man nicht um 2 Uhr morgens Benzin, Kaffee und Snacks, aber wenn das sehr selten doch passiert, ist es wahrscheinlich ein persönlicher Notfall, und in so einem Moment möchte man nicht auch noch die Bank anrufen
  Ich verstehe, dass opportunistische Diebe zu dieser Zeit ebenfalls aktiv sein können, aber die Kosten von False Positives gibt es eben auch
- Noch schlimmer. Meiner Erfahrung nach hat Kaffee oft glatte Beträge, und manche Leute tanken absichtlich auf einen exakten Betrag
  Außerdem gibt es Tankstellen, die vorab festgelegte Beträge wie 10, 20 oder 50 Euro verlangen
- Eines Nachts wollte ich in einer Bar, als ich Hunger bekam, eine Tüte Chips kaufen, aber es gab einen Mindestkartenbetrag von 5 £, also bat ich einfach darum, 5 £ abzubuchen
  Daraufhin wurde meine Karte wegen Betrugsverdacht gesperrt, was ziemlich nervig war. Nichts, womit ich mich um 2 Uhr morgens betrunken beschäftigen wollte
  Vielleicht hat man mich vor mir selbst geschützt, aber lästig war es trotzdem
- Ich weiß nicht, ob das heute noch verwendet wird, aber früher gab es Hotels oder Autovermietungen, die vor einer Zimmerreservierung oder Fahrzeuganmietung mit einer 1,00-$-Transaktion die Gültigkeit der Kreditkarte geprüft haben
- Das lässt sich leicht umgehen, wenn man bei Testtransaktionen ein wenig Rauschen einbaut, und mit einer ordentlichen statistischen Analyse könnte man es leicht verbessern
  Und ist nicht genau diese Art heuristischer Mustererkennung, bei der man keine nahezu 100%ige Genauigkeit erwartet, eigentlich etwas, worin AI gut sein sollte?
Das Kriterium „Grenzübertritt innerhalb von 10 Minuten bedeutet internationale Organisation“ könnte auch auf ganz normale Menschen zutreffen, die in Grenzregionen Europas leben
Selbst wenn man Card-not-present-Transaktionen ausnimmt, scheint hier fälschlich angenommen zu werden, dass alle Händlerstandorte exakt gesetzt sind, alle Verkäufe in stationären Läden stattfinden, es keinen mobilen Verkauf gibt und alle Transaktionen online verarbeitet werden
- Als ich vor ein paar Wochen von den USA nach Kanada gefahren bin, waren es wahrscheinlich auch etwa 10 Minuten
Wenn man bis zum Ende liest, zeigt sich, dass der Inhalt leer ist und die Ratschläge sich gegenseitig widersprechen. Das wirkt fast sicher wie LLM-generierter Text
Einerseits heißt es, „dein Team“ solle sich nie auf ein einzelnes Muster verlassen, andererseits könne schon Muster 1 allein „eine nützliche Menge an Betrug“ aufdecken
Dazu kommen seltsame Sätze wie „Jeder Analyst in deinem Team wird sie verwenden, also Window Functions, und das Hinzufügen des nächsten Betrugsmusters wird kein Projekt mehr sein“
Außerdem gibt es eine wenig relevante Diskussion darüber, dass IS NULL-Filterung womöglich nicht angewendet wird, obwohl fast keines der Beispiele überhaupt IS NULL nutzt, und das einzige Beispiel, das es nutzt, steht in einem anderen Kontext
Insgesamt ist es ein schwacher und zu langer Text
Hacker News, das sollte man ansprechen
„Fixel Smith“ ist eine von AI erzeugte Figur, und der Text hat mit Betrugsanalyse fast nichts zu tun. Dieser Name wird für nahezu jede vorstellbare Identität verwendet: Musiker (1), Romanautor (2), Betrugsanalyst (3), Influencer (4) usw.
Der Beitrag hat über 220 Punkte und mehr als 70 Kommentare, aber fast niemand hat bemerkt, dass er ziemlich offensichtlich gefälscht ist, und niemand scheint gesehen zu haben, dass es sich um eine AI-generierte Person handelt
- Hacker News scheint sich zuletzt die frustrierende Gewohnheit angewöhnt zu haben, solche minderwertigen AI-Einreichungen hochzuvoten
  Ich frage mich, ob diese AI-Flut eine unangenehme Wahrheit über das Urteilsvermögen der Community offenlegt oder ob es eher ein Versagen der bisherigen Schutzmechanismen ist, das man einfach beheben könnte
- Ich habe den Artikel auf dem Handy geprüft und nur kurz in die Kommentare geschaut. Es ist nicht immer leicht zu erkennen, ob etwas AI-generiert oder redigiert wurde, aber hier war es schon auf den ersten Blick allein an den Zitaten offensichtlich
  Wenn man annimmt, dass alle Kommentare in gutem Glauben geschrieben wurden, ist es ziemlich beunruhigend, dass selbst hier die AI-Kompetenz so niedrig ist
- Selbst bei flüchtigem Hinsehen wirkt das wie eine extrem produktive Einzelperson oder wie ein Bot
  Die Romane haben fast nichts mit den Analyseartikeln zu tun, und die Analyseartikel selbst scheinen einen LLM-Stil zu haben, weshalb alles verdächtig wirkt. Angesichts dessen, dass sich der Originaltext mit Betrug befasst, ist das ironisch
- Ich wäre eher überrascht, wenn die meisten Menschen routinemäßig die Autoren von dem prüfen würden, was sie lesen
  Ehrlich gesagt beachte ich meist nicht einmal die Byline, geschweige denn andere Teile der Website
- Das ist eindeutig ein tatsächlich existierender Artikel. Natürlich sieht er so aus, als hätte ihn ein LLM geschrieben, aber wenn der schlimmste Vorwurf an den Text nur ist, dass er wie ein LLM wirkt, dann ist das möglicherweise gar keine inhaltliche Kritik
  Ob der Inhalt erfunden ist oder nicht, ist unklar, aber man kann den Textinhalt kritisieren, ohne darüber zu spekulieren, ob ihn ein LLM geschrieben hat oder ob es Fiktion ist. Es gibt viel konkretere Mängel
Wir entwickeln das Open-Source-Sicherheits-Framework tirreno
Ich habe Zweifel an dem hier beschriebenen Ansatz. Unmögliche Reisen sind zum Beispiel eine legitime und weit verbreitete Technik, aber sie betrifft das Online-Nutzerverhalten auf Basis von IP-Adressen
In tirreno gibt es separate Regeln für Fälle, in denen klar ist, dass eine IP von Apple Relay oder VPN/Tor kommt, und das sind getrennte Flags
Ich denke, einige oder alle Beispiele sind LLM-generiert. Der Kontext ist durcheinander, und Orte, die bei Kartenzahlungen in großem Stil GPS-Positionen sammeln, gibt es in der Realität nicht
1. https://github.com/tirrenotechnologies/tirreno
Das ist eher regelbasierte Logik, die als SQL-Abfragen kodiert wurde, ohne zugrunde liegende Daten
Es gibt jede Menge Schwellwerte, aber keine Daten, die zeigen, dass diese Schwellwerte sinnvoll sind
Die Behauptung in der Art von „Betrugserkennung in Transaktionsdaten ist größtenteils SQL, nicht Machine Learning, keine Graph-Datenbank und auch nichts, was Gartner dieses Jahr hochjubelt“ ist nur dann gerechtfertigt, wenn man den gesamten Bereich der Program Integrity behandelt
Wenn damit das Problemfeld gelöst wird, ist ein einfacherer und gröberer Ansatz womöglich besser
Fintech-Kunden wollen in der Regel wissen, ob eine gerade stattfindende Transaktion betrügerisch ist, und sie wollen innerhalb weniger Millisekunden eine Antwort über hochdimensionale Daten hinweg. Das ist ein Arbeitsmaßstab, bei dem relationale Datenbanken solche Echtzeitbeschränkungen schwer erfüllen können; stattdessen werden sie für andere Zwecke wie das Laden historischer Daten genutzt
Deshalb kommen In-Memory-Datenbanken, Stream-Processing-Engines und auch Machine Learning ins Spiel
Trotzdem sind einige Punkte des Autors valide, besonders das Problem, mit verrauschten Warnmeldungen umzugehen; das ist ein allgemeines Problem, das über Performance Engineering hinausgeht, daher bin ich auf den nächsten Artikel gespannt
- Meiner Erfahrung nach ist das Beschriebene genauer gesagt eher Betrugsprävention als Betrugserkennung. In ausgereiften Setups existieren beide nebeneinander und ergänzen sich
  In der Prävention ist man immer durch Latenzanforderungen, verfügbare Daten und ein unvollständiges Bild des Nutzerverhaltens eingeschränkt. Mit Machine Learning und Regeln trifft man schnelle Entscheidungen und deckt die meisten Fälle ab, aber wegen dieser Einschränkungen kann man nicht jeden Betrug präzise verhindern
  Erkennung beschäftigt sich mit den Folgen danach. Üblicherweise analysiert ein Analystenteam genehmigte Transaktionen, um nach Anzeichen von Betrug zu suchen. Das ist besonders wichtig bei Betrugsarten ohne externe Signale wie Chargebacks oder Kundenbeschwerden. Plattformintegrität ist ein solches Beispiel, und auch Geldwäschebekämpfungssysteme im Fintech müssen aktiv nach Betrug suchen
  Dass beide komplementär sind, liegt auch daran, dass erkannte Transaktionen die Labels liefern, mit denen das nächste Präventionsmodell trainiert und bewertet wird
Es wurde gesagt, wenn eine Karte in Chicago durchgezogen und 7 Minuten später in Los Angeles erneut genutzt wird, müsse eine der beiden Transaktionen gefälscht sein; ich frage mich, wie das bei Online-Shopping funktioniert
Wenn ich auf dem Sofa sitze und etwas bei Amazon kaufe, welcher Ort wird dann eingetragen?
Und es scheint auch Grenzfälle zu geben, in denen Ehepartner ein Online-Konto gemeinsam nutzen und eine Person auf Reisen mit den gespeicherten Kartendaten einkauft
- Eine Karte zu ziehen, einzustecken oder zu halten ist eine Card-present-Transaktion. Das Eingeben der Kartennummer, wie beim Online-Shopping, ist eine Card-not-present-Transaktion
  Händler und Banken können diesen Unterschied erkennen
- Das lässt sich über die Transaktionsmetadaten unterscheiden. Ich habe bei einer Kreditkartenfirma gearbeitet
- Soweit ich weiß, unterscheidet das System zwischen Card-present und Card-not-present
Dass „dieser Ansatz nicht funktioniert, bis genug Historie vorhanden ist, und neue Konten keine Baseline haben“, ist ein unterschätzter Kundenerfahrungsfaktor
Wenn meine Karte abgelehnt wird, weil ich Neukunde bin oder ein neues Muster zeige, fühlt es sich an, als würde die Software gut arbeiten
Wenn aber eine Transaktion abgelehnt wird, obwohl es eine von mir bestätigte Historie gibt, dann nervt mich ein naiver und paranoider Algorithmus
- Der Anreiz der Banken ist es, Betrug zu reduzieren
  Betrügerische Transaktionen führen am Ende zu Rückbuchungen oder Erstattungen, und die Verluste trägt die Bank. Eine abgelehnte Transaktion erzeugt nur einen verärgerten Kunden, der sich beschwert und es bald wieder vergisst. Die Last der externalisierten Kosten landet also beim Kunden
  Deshalb haben Banken einen Anreiz, auf der vorsichtigeren Seite zu irren und Transaktionen auch bei False Positives abzulehnen
Ist der Kern von Machine Learning nicht gerade, solche Regeln aus Daten zu lernen?
Der richtige Ansatz wäre aus meiner Sicht, mit einem Machine-Learning-Modell Muster zu finden, die mit Betrug korrelieren, und dann zu bewerten, welche davon plausibel sind. So könnte man sogar neue Hypothesen entdecken
- Alles, was sich nicht erklären lässt und nicht deterministisch iterativ verbessern lässt, ist für die Ablehnung von Finanztransaktionen zu riskant
  Ein menschlicher Analyst sollte dem Compliance-Team in einer 5-Minuten-E-Mail erklären können, warum eine bestimmte Transaktion abgelehnt wurde und was man anders hätte tun müssen, um die nachteilige Entscheidung zu vermeiden
  Wenn man mit Machine Learning ein Problem behebt, entstehen oft zwei neue, noch nicht klar sichtbare Probleme. In Bezug auf Regressionen oder unerwartete Nebenwirkungen, wenn sich Dinge im Lauf der Zeit ändern, überrascht SQL im Allgemeinen deutlich weniger

aliveornot 2026-05-19

Ich habe mich gefragt, was mit „runden Beträgen“ gemeint ist … es war wohl rounded.

xguru 2026-05-19

Warum wurde das so übersetzt? schluchz Ich habe es korrigiert.