SQL-Muster zum Erkennen von Transaktionsbetrug

 (analytics.fixelsmith.com)
1 Punkte von GN⁺ 2 시간 전 | 1 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 findet Häufungen von Transaktionen desselben Karteninhabers in kurzer Zeit und erfordert die Anpassung von Zeitfenstern, Schwellenwerten und einer Whitelist für 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 geklonte Karten
  • Betragsanomalien suchen nach Beträgen wie $1.00, $99.99 oder $499.99, die auf Kartentests oder das Umgehen von Regeln hindeuten können, für Benefit-Transaktionen aber weniger gut geeignet sind
  • Mit sprunghaft ansteigenden Händlerwerten, Transaktionen außerhalb der üblichen Zeiten und aus Window Functions abgeleiteten Spalten lassen sich Transaktionen über mehrere Signale hinweg bewerten und Iterationszyklen von mehreren Wochen auf wenige Stunden verkürzen

SQL-Muster zum Aufspüren von Betrugssignalen in Transaktionsdaten

  • Betrugserkennung beginnt oft noch vor Machine Learning oder Graphdatenbanken mit den richtigen Tabellen und Joins sowie SQL zum Finden ungewöhnlicher Transaktionsmuster
  • Lässt sich auf Daten anwenden, in denen Geld bewegt wird und Logs anfallen, etwa bei Kreditkarten, medizinischen Abrechnungen, E-Commerce, POS oder staatlichen Leistungsprogrammen
  • Bei neuen Datensätzen baut man Muster meist in der Reihenfolge Velocity, Impossible Travel, Betragsanomalien, Händlerkonzentration, ungewöhnliche Uhrzeiten und auf Window Functions basierende Signale auf

1. Velocity: zu viele Transaktionen in kurzer Zeit

  • Wenn gestohlene Karten oder Accounts schnell ausgeschöpft werden sollen, zeigt sich beim gleichen Karteninhaber oft ein Muster geballter Transaktionen in kurzer Zeit
  • Die Basisabfrage gruppiert die Transaktionen der letzten 30 Tage stundenweise und sucht Zeiträume, in denen die Anzahl der Transaktionen pro cardholder_id einen Grenzwert überschreitet
  • Die wichtigsten Stellgrößen sind Größe des Zeitfensters und Schwellenwert für die Transaktionsanzahl
    • Versionen mit 1 Minute, 5 Minuten und 1 Stunde lassen sich parallel ausführen und vergleichen
    • Gruppen für Kartentests bündeln Transaktionen oft in wenigen Sekunden, während Gruppen für Benefit-Betrug ü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ßer Zahl aufladen
    • Nach der ersten Analyse ist deshalb eine Whitelist für False Positives nötig
  • Ein Sliding-Window-Ansatz berechnet mit COUNT(*) OVER (...) RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW die Anzahl der Transaktionen in den letzten 5 Minuten
  • QUALIFY funktioniert in Snowflake, BigQuery, Databricks und Teradata
    • In Postgres muss man die gesamte Abfrage in eine CTE kapseln und außen filtern

2. Impossible travel: physisch unmögliche Bewegung

  • Wenn eine Karte in Chicago verwendet wird und 7 Minuten später in Los Angeles, ist wahrscheinlich mindestens eine der beiden Transaktionen gefälscht
  • Dieses Muster ist ein starkes Signal für geklonte Karten, denn es gibt fast keinen legitimen Grund, warum dieselbe Karte in wenigen Minuten an zwei weit entfernten Orten auftaucht
  • Die Abfrage nutzt LAG(), um Zeit und Ort der vorherigen Transaktion zu holen, und berechnet dann Distanz und Zeit zwischen der vorherigen und der aktuellen Position
  • 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 auch selbst implementieren
  • Ein beispielhafter Schwellenwert ist 600mph
    • Ein Verkehrsflugzeug fliegt mit etwa 575mph Reisegeschwindigkeit, also wäre selbst ein Flug zu langsam
    • Senkt man auf 100mph, kann man auch schnelle Bodenbewegungen erfassen, beginnt aber legitime Fälle wie reale Flugreisende oder Eltern mit ihren Kindern mitzuerfassen
  • In derselben Familie gibt es weitere Signale
    • Transaktionen in zwei weit entfernten Städten desselben Bundesstaats innerhalb von 5 Minuten können auf lokale Klon-Gruppen hinweisen
    • Transaktionen in mehreren ZIP-Codes innerhalb einer Stunde können auf eine Skimmer-Gruppe in einer Region hindeuten
    • Grenzüberschreitende Transaktionen innerhalb von 10 Minuten können ein Signal für internationale Gruppen sein

3. Amount anomalies: ungewöhnliche Betragsbereiche

  • Bei Betrug gibt es Betragsmuster, die häufig auftreten, bei normaler Nutzung aber selten sind
  • Die Beispielbedingungen suchen nach folgenden Betragsbereichen
    • $1.00, $5.00, $10.00
    • $99.50 oder mehr und unter $100.00
    • $499.50 oder mehr und unter $500.00
  • Kleine glatte Dollar-Beträge sind meist ein Signal für Kartentests
    • Es geht darum zu prüfen, ob aus einem Kartendump stammende Kartennummern noch funktionieren, bevor sie weiterverkauft werden
    • Echte Karteninhaber kaufen nur selten etwas für genau $1.00
    • Ein Kaffee kostet eher $4.73, Tanken eher $52.81, also keine exakt gerundeten Beträge
  • Beträge knapp unter einem Grenzwert haben eine andere Bedeutung
    • $99.99 kann darauf hindeuten, dass jemand eine Schwelle von $100 umgehen will, ab der vielerorts ein Ausweis geprüft wird
    • $499.99 kann darauf hindeuten, dass jemand ein tägliches ATM-Limit von $500 umgehen will
    • Das ist ein Signal dafür, dass der Akteur die Regeln kennt und bewusst darunter bleibt
  • Bei Benefit-Transaktionen helfen gerundete Betragsmuster deutlich weniger
    • Benefits werden nicht auf dieselbe Weise per Kartentest geprüft
    • Wichtiger sind dort meist doppelte Empfänger

4. Suspicious merchants: auffällige Konzentration auf Händlerebene

  • Wenn ein bestimmter Kartenleser, etwa an einer Zapfsäule, mit einem Skimmer infiziert wird, führt das nicht zu einem Einzelfall, sondern oft zu Dutzenden Betrugsfällen
  • Alle Karten, die diesen Leser über mehrere Wochen genutzt haben, können in einer fremden Datenbank gelandet sein
  • Aus Händlersicht zeigt sich das als kurzfristiger sprunghafter Anstieg der Zahl nicht miteinander verbundener Karten sowie höherer Transaktionsbeträge als üblich
  • Ein einfaches Regelbeispiel gruppiert die letzten 7 Tage nach Händler und Stunde und berechnet
    • Anzahl eindeutiger Karten
    • Gesamtzahl der Transaktionen
    • Gesamtsumme der Transaktionen
    • Gesucht werden Stunden, in denen die Zahl eindeutiger Karten über 20 und die Gesamtsumme über $5000 liegt
  • Statische Schwellenwerte haben ein Problem bei der Größenanpassung
    • Costco kann diesen Wert in 90 Sekunden überschreiten
    • Ein Antiquariat fast nie
  • Besser ist es, jeden Händler mit seiner eigenen historischen Baseline zu vergleichen
    • Die letzten 60 Tage werden stundenweise aggregiert
    • Für jeden Händler wird die durchschnittliche Zahl eindeutiger Karten über die letzten 168 Stunden-Buckets berechnet
    • Gesucht werden Zeiträume, in denen die aktuelle Zahl eindeutiger Karten mehr als das Dreifache des historischen Durchschnitts beträgt
  • 168 Stunden-Buckets entsprechen den stündlichen Intervallen der letzten 7 Tage
    • Tages- und Wochen-Saisonalität ist wichtig
    • Selbst im selben Café unterscheiden sich Dienstag 14 Uhr und Samstag 9 Uhr in der Baseline
  • Als Startpunkt kann das Dreifache des Üblichen dienen
    • Locker genug, um nicht von Alerts überflutet zu werden
    • Streng genug, um tatsächlich ungewöhnliche Stunden zu finden

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

  • Die meisten Menschen haben gewisse Ausgabengewohnheiten
  • Wenn jemand mit einem 9-bis-5-Job plötzlich um 3 Uhr morgens tankt, kann das bedeuten, dass die Karte von jemand anderem genutzt wird oder die Person auf Reisen ist
  • Ob jemand auf Reisen ist, lässt sich mit weiteren Signalen prüfen
  • Die Abfrage ermittelt zunächst für die letzten 90 Tage pro Karteninhaber und Stunde die Transaktionsanzahl und erkennt nur Stunden mit mindestens 2 Transaktionen als übliche Zeitfenster an
  • Danach werden neue Transaktionen erkannt, deren Uhrzeit außerhalb des Bereichs earliest_hour bis latest_hour dieses Karteninhabers liegt
  • Die Bedingung „mindestens 2 Transaktionen in dieser Stunde“ in der inneren Abfrage ist wichtig
    • So wird verhindert, dass ein einmaliges nächtliches Tanken vor 3 Monaten in die übliche Zeit fällt
    • Die Schwelle orientiert sich an echten Gewohnheiten statt an „einmal vorgekommen“
  • Der Nachteil ist, dass historische Daten nötig sind
    • Neue Accounts haben keine Baseline
    • Für neue Accounts kann man Zeitmuster der Gesamtpopulation verwenden oder dieses Muster auslassen, bis genug Historie vorhanden ist

6. Signale mit Window Functions kombinieren

  • Das Muster mit Window Functions ist kein eigener Betrugstyp, sondern Vorarbeit, um die fünf vorherigen Muster in kombinierbare Signale zu verwandeln
  • Pro Transaktion lassen sich etwa folgende abgeleiteten Spalten erzeugen
    • Verstrichene Zeit seit der vorherigen Transaktion: timestamp - LAG(timestamp)
    • Ob sich der Händler geändert hat: Vergleich von 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 solche Spalten materialisiert sind, schrumpfen Betrugsregeln auf einfache Filterausdrücke
  • Gruppen für Kartentests lassen sich mit folgenden Bedingungen finden
    • mindestens die fünfte Transaktion des Tages
    • weniger als 60 Sekunden seit der vorherigen Transaktion
    • anderer Händler als bei der vorherigen Transaktion
  • Wenn sich neue Betrugshypothesen nicht als Engineering-Ticket, sondern als SQL-Filter formulieren lassen, verkürzt sich der Iterationszyklus von mehreren Wochen auf wenige Stunden
  • Dadurch lässt sich mehr Betrug schneller erkennen

Wie die Muster zusammen verwendet werden

  • Kein einzelnes Muster ist für sich genommen ausreichend
  • Jedes Muster hat klare Grenzen
    • Velocity erzeugt False Positives wie Betreiber von Verkaufsautomaten
    • Geografisch unmögliche Bewegungen übersehen Betrug innerhalb einer einzigen Metropolregion
    • Betragsanomalien funktionieren außerhalb des Kontexts von Kartentests oft schlecht
    • Regeln für ungewöhnliche Uhrzeiten brauchen Historie
  • In der Praxis funktioniert es, alle Muster laufen zu lassen und jede Transaktion über mehrere Signale hinweg zu bewerten
  • Transaktionen, die bei drei oder vier Signalen auffallen, sind fast immer Betrug
  • Transaktionen mit nur einem Signal können auch nur eine ungewöhnliche, aber legitime Nutzung eines reisenden Karteninhabers sein
  • Wer neu mit Betrugserkennung beginnt, sollte mit Velocity anfangen
    • Es deckt eine nützliche Menge an Betrug auf
    • Es erfasst relativ wenig normale Aktivität
    • Auch die Ausführungskosten sind gering
  • Wenn die Muster 1 bis 5 bereits vorhanden sind, ist die nächste Investition in rohe Spalten auf Basis von Window Functions sinnvoll
    • Einmal erstellt, können alle Analysten im Team sie nutzen
    • Das Hinzufügen des nächsten Betrugsmusters wird dadurch kein eigenes Projekt mehr

Worauf man achten sollte

  • Umgang mit NULL

    • Reale Transaktionstabellen verwenden NULL oft nicht so, wie man es aus SQL-Einführungen kennt
    • Viele Legacy-Systeme nutzen stattdessen Sentinel-Werte wie 9999-12-31 für „kein Enddatum“ oder 0001-01-01 für „kein Startdatum“
    • Wer mit IS NULL filtert, kann solche Zeilen unbemerkt übersehen
    • Deshalb sollte man erst die Konventionen der jeweiligen Tabelle prüfen und dann die WHERE-Bedingung schreiben

  • False Positives

    • Jede Regel kann echte Karteninhaber erfassen, die sich ungewöhnlich, aber legal verhalten
    • Markierte Fälle brauchen menschliche Prüfung
    • Es braucht eine Feedback-Schleife, um Schwellenwerte anhand echter und nicht echter Betrugsfälle anzupassen
    • Ein automatisches Blocken auf Basis einer einzelnen Regel kann Kunden kosten

  • Datenschutz

    • Wenn die Daten PII enthalten, müssen die geltenden Richtlinien zur Datennutzung eingehalten werden
    • Zuerst sollte man mit anonymisierten oder Sample-Daten arbeiten und Produktionsdaten erst nach Freigabe verwenden

  • Kosten

    • Window Functions auf großen Partitionen sind nicht billig
    • Deshalb sollte man zuerst nach Datumsbereich filtern und danach Window Functions anwenden
    • Wer erst LAG() über zwei Jahre Transaktionen des gesamten Datensatzes laufen lässt und das WHERE später anhängt, kann das Credit-Budget des Warehouses schnell aufbrauchen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
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

    1. https://www.amazon.it/Forged-Soundtrack-Explicit-Fixel-Smith...

    2. https://fixelsmith.com

    3. https://analytics.fixelsmith.com/

    4. https://www.instagram.com/fixeltales/

    • 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 Kunden­erfahrungsfaktor
    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