Eine Engine zur Transaktionskategorisierung aufbauen

Die Transaktionskategorisierung ordnet jeder Kontozeile eine Kategorie aus einer festen Taxonomie zu, sodass aus “TFR 4829 CONTACTLESS PRET A MANGER LONDON” die Kategorie Essen und Trinken mit einem bekannten Merchant dahinter wird. Bau sie in Schichten: Das Merchant-Enrichment löst den Rohstring zu einer Entität auf, deterministische Regeln behandeln die wiederkehrenden Fälle mit hoher Konfidenz, und ein Modell deckt den Long Tail ab. Der Feedback-Loop, der das Ganze korrigiert, ist wichtiger als das Modell selbst.

Kategorisierung ist deshalb schwierig, weil die Eingabe absichtlich verlustbehaftet ist. Kontobeschreibungen sind gekürzt, abgekürzt, mit Terminal-IDs und Zahlungssystem-Rauschen aufgefüllt und werden von jedem Institut anders formatiert. Open-Banking-Daten helfen, weil sie strukturiert und über die Provider hinweg standardisiert sind, aber der Merchant-String darin ist immer noch das, was der Acquirer der Transaktion aufgestempelt hat. Zwei Kaffees aus demselben Laden können als drei verschiedene Strings ankommen, je nachdem, welches POS-Terminal sie abgerechnet hat. Bevor ein Modell überhaupt eine Transaktion zu sehen bekommt, ist der Großteil des nützlichen Signals bereits zerhackt, und es zurückzugewinnen ist das eigentliche Engineering-Problem.

Im Merchant-Enrichment steckt die Genauigkeit

Enrichment ist Entity Resolution gegen einen unsauberen, driftenden Referenzbestand. Das Ziel ist es, einen rohen Descriptor auf eine stabile Merchant-Identität abzubilden und dieser Identität dann Attribute anzuhängen: einen normalisierten Namen, einen Kategorie-Hinweis, eine Website, ein Logo und, wo auffindbar, eine eingetragene juristische Person.

Die Pipeline, die wir bauen, sieht ungefähr so aus:

• Den Rohstring normalisieren: Scheme-Präfixe, Terminalnummern, Datumsangaben, Ortsauffüllungen und Referenzcodes entfernen. Das ist unglamouröse Regex- und Lookup-Arbeit, und sie bewegt die Genauigkeit stärker als jede Modellentscheidung.
• Zu einem Kandidaten-Merchant auflösen, mithilfe einer Kombination aus exaktem und Fuzzy-Matching gegen einen Referenzbestand, disambiguiert über MCC, Betragsmuster und Geografie.
• Den Kategorie-Hinweis aus dem aufgelösten Merchant anhängen, der zu einem starken Feature für den Classifier wird und nicht zur endgültigen Antwort.

Der Referenzbestand driftet. Merchants benennen sich um, werden übernommen, wechseln den Acquirer und eröffnen unter neuen juristischen Personen. Behandle ihn als gepflegtes Asset mit Lineage: Jeder Enrichment-Datensatz sollte mitführen, woher das Mapping stammt und wann es zuletzt bestätigt wurde, damit du sechs Monate später, wenn eine Kategorie falsch aussieht, nachvollziehen kannst, welche Regel oder welcher Match sie erzeugt hat. Ohne diese Lineage debuggst du Kategorisierung durch Raten.

Eine Anmerkung zur Point-in-Time-Korrektheit, denn sie beißt Leute, die Enrichment leichtfertig bauen. Wenn dein Referenzbestand heute sagt, ein Merchant sei “Lebensmittel”, darfst du dieses Label nicht rückwirkend auf eine Transaktion von vor zwei Jahren anwenden, wenn der Merchant damals ein Restaurant war. Für die Budgetierung interessiert das niemanden, aber fürs Underwriting ist es Leakage: Du nutzt Informationen, die zum Entscheidungszeitpunkt gar nicht existierten. Versioniere den Referenzbestand und verknüpfe Transaktionen mit dem Stand, den er am Transaktionsdatum hatte.

Regeln und Modell, in dieser Reihenfolge

Teile die Arbeit nach Konfidenz auf. Eine wiederkehrende Gehaltsgutschrift von einem bekannten Arbeitgeber, ein monatliches Abo bei einem namentlich bekannten Anbieter, eine Kreditrate an das eigene Institut: Diese brauchen kein probabilistisches Modell. Sie brauchen eine deterministische Regel, die jedes Mal gleich feuert und einen Audit-Trail schreibt. Regeln geben dir Straight-Through Processing für die langweilige Mehrheit und einen Begründungsstring, den du einem Prüfer oder einer Aufsichtsbehörde zeigen kannst.

Das Modell verdient sich seinen Platz am Long Tail, bei den Beschreibungen, die zu nichts sauber passen. Hier sind die praktischen Optionen:

• Ein Gradient-Boosted Classifier über gebaute Features (normalisierte Tokens, MCC, Betragsbuckets, Vorzeichen, Wiederkehr-Signale, der Kategorie-Hinweis aus dem Enrichment) ist eine starke, günstige, erklärbare Baseline. Fang hier an.
• Ein feingetunter Text-Classifier über die Beschreibung hilft bei wirklich neuartigen Strings, zu höheren Kosten und geringerer Interpretierbarkeit. Greif erst dazu, wenn das Boosted-Modell ein Plateau erreicht, nicht früher.

Setze pro Kategorie ein False-Positive-Budget und route nach Konfidenz. Vorhersagen mit hoher Konfidenz werden automatisch verbucht. Alles unterhalb der Schwelle geht in eine Prüf-Queue, und diese menschlichen Entscheidungen sind die Labels, die die nächste Version nachtrainieren. Die Schwelle ist ein Business-Hebel: Eine Underwriting-Pipeline verträgt weit weniger stille Fehlkategorisierungen als ein Ausgabenanalyse-Dashboard, also können sich die beiden ein Modell teilen, aber keine Schwelle.

Halte die Taxonomie klein und stabil. Jedes Mal, wenn jemand eine Blattkategorie hinzufügt, verschwimmen die Grenzen und deine Precision pro Klasse sinkt. Die Taxonomie zu ändern ist eine Migration, kein Config-Edit, denn sie interpretiert stillschweigend jede historische Vorhersage neu.

Der Feedback-Loop ist das Produkt

Eine Kategorisierungs-Engine ist nur so gut wie der Loop, der sie korrigiert, und dieser Loop muss ebenso bewusst gebaut werden wie das Modell.

• Pflege ein versioniertes Eval-Set: eine geschichtete, von Hand gelabelte Stichprobe, die den realen Traffic widerspiegelt, nicht einen bequemen. Berichte Precision und Recall pro Kategorie. Die Gesamtgenauigkeit ist hier so gut wie nutzlos, denn 90 % insgesamt können eine dir wichtige Kategorie verdecken, die bei 40 % liegt.
• Erfasse jede Korrektur eines Nutzers oder Prüfers als gelabeltes Event, mit dem Input so, wie er zum Vorhersagezeitpunkt aussah. Diese Korrekturen sind deine wertvollsten Trainingsdaten, weil sie sich genau auf die Fälle konzentrieren, bei denen das Modell danebenlag.
• Achte auf Drift. Merchant-Verhalten, Beschreibungsformate und Ausgabenmix verschieben sich alle, und Quartalsend- und Saisonmuster verschieben die Kategorieverteilungen. Überwache die Konfidenzverteilung und die Rate der Prüf-Queue über die Zeit; eine steigende Queue-Rate ist meist Drift, der sich ankündigt, bevor deine Genauigkeitsmetrik ihn einfängt.
• Versioniere den gesamten Stack zusammen: Referenzbestand, Regeln, Modell und Taxonomie. Wenn eine Kategorie umkippt, willst du beantworten können, welche Änderung das verursacht hat, und das geht nur, wenn jedes Element versioniert und die Lineage intakt ist.

Trainiere auf ein Signal hin nach, nicht nach Zeitplan. Wenn das Eval-Set oder die Prüf-Queue-Rate zeigt, dass das Modell abgerutscht ist, trainiere nach; ein Datum im Kalender ist für sich genommen kein Grund. Bau den Loop so, dass das Ausliefern eines korrigierten Referenz-Mappings oder einer neuen Regel eine Änderung mit wenig Zeremoniell und klarem Audit-Trail ist. In der Produktion kommen die meisten deiner Genauigkeitsgewinne aus diesen kleinen Korrekturen, nicht aus einer neuen Modellarchitektur.