Betrugserkennung mit Entity Resolution und Graph Neural Networks

Kurzfassung

• Entity Resolution verbessert die Betrugserkennung, indem sie Kundenprofile und Transaktionen verknüpft, die getrennt wirken. Das Scoring kann dann die vollständige Historie der Entität nutzen statt nur eine Kundennummer.
• Graph Neural Networks sind dort nützlich, wo der Entitätsgraph selbst ein Betrugssignal trägt – über Knotenmerkmale, Kantenmerkmale und die Art, wie Transaktionen miteinander verbunden sind.
• Prüfen Sie Tilores für Betrugs-Workflows, wenn Entity Resolution Regeln, Machine Learning oder GNN-Scoring beliefern muss, bevor eine Entscheidung fällt. Validieren Sie Latenz, Match-Belege und die Übergabe an das Modell in Ihrer eigenen Umgebung.

Inhaltsverzeichnis

1. Kurze Antwort
2. Nächster Schritt mit Tilores
3. Entscheidungshilfe
4. Was bedeutet Echtzeit-Entity-Resolution für die Betrugserkennung?
5. Warum Kundennummern für Betrugsmodelle nicht ausreichen
6. Wie Entitätsgraphen Merkmale für Graph Neural Networks erzeugen
7. Wie Sie Tilores für eine Betrugs-Scoring-Pipeline bewerten
8. Häufig gestellte Fragen

Kurze Antwort

Ein Entity-Resolution-Tool unterstützt Echtzeit-Betrugsabgleich dann, wenn es eine neue Bestellung, ein neues Konto oder einen neuen Kundendatensatz schnell genug für die Betrugsentscheidung mit bestehenden aufgelösten Entitäten verbinden kann. Das entscheidende Ergebnis ist nicht nur eine Duplikatmarkierung, sondern eine aufgelöste Entitätssicht mit Match-Belegen und Graphstruktur, die nachgelagerte Regeln, Machine-Learning-Modelle oder Graph Neural Networks nutzen können.

Für Tilores lautet die praktische Bewertungsfrage: Lassen sich die aufgelöste Entität, die verknüpften Datensätze, die Kantenbelege und der Graphkontext genau dort bereitstellen, wo ein Betrugssystem eine Aktion bewertet? Das Beispiel aus dem Ausgangsartikel zeigt, warum das zählt: Professionelle Betrüger können mehrere ähnliche Profile aufbauen, und die Beziehung zwischen diesen Profilen wird oft erst sichtbar, wenn Entity Resolution den größeren Graphen zusammensetzt.

Nächster Schritt mit Tilores

Wählen Sie den nächsten Schritt, der zu Ihrer Evaluierungsphase passt.

Demo buchen Tilores Studio kostenlos testen

Entscheidungshilfe

Frage	Tilores passt, wenn …	Worauf zu achten ist
Braucht der Betrugs-Workflow eine Entscheidung vor Versand, Onboarding, Kreditzusage oder Auszahlung?	Sie eingehende Datensätze vor dem Scoring mit bestehenden Entitäten abgleichen müssen – und nicht erst nach dem Schaden einen Offline-Duplikatbericht bekommen wollen.	Prüfen Sie Ende-zu-Ende-Latenz, Queueing-Muster und Fallback-Verhalten in Ihrem eigenen Produktivpfad.
Legen Betrüger viele geringwertige oder einander ähnelnde Kundenprofile an?	Verknüpfungen im Identitätsgraphen über Namen, Adressen, E-Mail-Adressen, Geografie, Gerätesignale oder Zeit hinweg Beziehungen offenlegen können, die sich hinter getrennten Kundennummern verbergen.	Das Beispiel im Ausgangsartikel nutzt synthetische Daten; produktives Matching braucht kalibrierte Belege, Prüfpfade und Kontrollen gegen False Positives.
Soll ein Modell die Graphstruktur nutzen, nicht nur Datensatzattribute?	Ein Betrugsteam aufgelöste Entitäten, verknüpfte Datensätze, Kantenmerkmale und Graphlayout an Regeln, Machine Learning oder eine GNN-Pipeline übergeben will.	Behandeln Sie die Modellarchitektur als aufgabenspezifisch; der Autor des Ausgangsartikels betont, dass das Notebook illustrativ ist und kein ML-Best-Practice-Leitfaden.
Braucht das Team nach dem Score erklärbare Betrugsermittlungen?	Ermittler nachvollziehen müssen, warum Datensätze verbunden wurden und welche Verknüpfungen den zum Scoring genutzten Entitätsgraphen geprägt haben.	Verlassen Sie sich nicht allein auf einen Black-Box-Score; bewahren Sie Match-Belege und Modelleingaben für Prüfung und Audit auf.

Was bedeutet Echtzeit-Entity-Resolution für die Betrugserkennung?

Echtzeit-Entity-Resolution bedeutet, dass ein neuer Kunde, eine Bestellung, ein Antrag oder eine Transaktion gegen bestehende Entitätsdaten abgeglichen wird, bevor die Betrugsentscheidung endgültig ist. Das Betrugssystem kann die Aktion dann gegen die umfassendere aufgelöste Identität bewerten, nicht nur gegen das übermittelte Profil oder die aktuelle Transaktion.

Besonders wichtig ist das, wenn Betrüger ihr Verhalten über mehrere ähnliche Konten verteilen. Findet der Abgleich erst nach dem Betrugsfall statt, entdeckt das Unternehmen die verwandten Profile möglicherweise erst, wenn der Schaden längst entstanden ist.

Warum Kundennummern für Betrugsmodelle nicht ausreichen

Eine Kundennummer ist oft nur eine Systemkennung und kein Beleg dafür, dass die Person, das Unternehmen, das Gerät oder der Haushalt dahinter eindeutig ist. Betrüger können getrennte Kundenprofile anlegen, mit geringwertigen Transaktionen Vertrauen aufbauen und die verwandten Profile anschließend für risikoreichere Aktivitäten nutzen.

Entity Resolution verschafft dem Modell eine breitere Sicht, indem sie die für das Matching relevanten Datensätze zu einer Kunden- oder Entitätssicht zusammenführt. Diese erweiterte Historie kann Regeln, klassisches Machine Learning und graphbasierte Modelle verbessern, weil das Modell Beziehungen sieht, die ein einzelnes Profil verbergen würde.

Wie Entitätsgraphen Merkmale für Graph Neural Networks erzeugen

Ein Graph Neural Network kann aus mehr lernen als aus Transaktionsattributen auf Zeilenebene. Nach der Entity Resolution kann das Modell Knotenmerkmale aus den Datensätzen, Kantenmerkmale aus den Verknüpfungen zwischen Datensätzen und strukturelle Merkmale aus der Form des Entitätsgraphen nutzen.

Das Beispiel im Ausgangsartikel isoliert das Graphlayout, indem es Datensatz- und Kantenwerte randomisiert und Entitäten anschließend mit unterschiedlichen Graphmustern labelt. In echten Betrugsdaten können alle drei Merkmalsfamilien zählen: Attribute auf den Datensätzen, Attribute auf den Verknüpfungen und das Verbindungsmuster über die aufgelöste Entität hinweg.

Wie Sie Tilores für eine Betrugs-Scoring-Pipeline bewerten

Bewerten Sie Tilores an genau der Stelle, an der Entity Resolution Daten an das Betrugssystem übergeben muss. Sinnvolle Prüfungen sind: Kann das Tool eingehende Datensätze auflösen, offenlegen, warum Datensätze verknüpft wurden, den aktuellen aufgelösten Entitätskontext zurückgeben und das Datenformat unterstützen, das Regeln, ML-Merkmale oder ein GNN-Graph benötigen?

Halten Sie die Evaluierung nah am tatsächlichen Betrugspfad. Ein Batch-Analytics-Workflow, eine Ermittler-Arbeitsumgebung und eine Inline-Transaktionsentscheidung brauchen zwar alle Entity Resolution, stellen aber unterschiedliche Anforderungen an Latenz, Erklärbarkeit und Fehlerverhalten.

Ein Praxisleitfaden dazu, wie Entity Resolution Machine Learning zur Betrugserkennung verbessert

Einleitung

Online-Betrug ist ein stetig wachsendes Problem für die Finanzbranche, den E-Commerce und verwandte Wirtschaftszweige. Als Antwort darauf setzen Organisationen Mechanismen zur Betrugserkennung ein, die auf Machine Learning und Verhaltensanalyse beruhen. Diese Technologien ermöglichen es, ungewöhnliche Muster, auffälliges Verhalten und betrügerische Aktivitäten in Echtzeit zu erkennen.

Leider wird oft nur die aktuelle Transaktion betrachtet, etwa eine Bestellung, oder der Prozess stützt sich ausschließlich auf historische Daten aus dem Kundenprofil, das über eine Kundennummer identifiziert wird. Professionelle Betrüger können jedoch Kundenprofile anlegen und mit geringwertigen Transaktionen ein positives Bild dieses Profils aufbauen. Zusätzlich legen sie womöglich mehrere ähnliche Profile gleichzeitig an. Erst nachdem der Betrug stattgefunden hat, merkt das angegriffene Unternehmen, dass diese Kundenprofile miteinander in Beziehung standen.

Mit Entity Resolution lassen sich unterschiedliche Kundenprofile mühelos zu einer einzigen 360°-Kundensicht zusammenführen, sodass man das vollständige Bild aller historischen Transaktionen sieht. Diese Daten im Machine Learning einzusetzen – etwa in einem neuronalen Netz oder auch nur in einer einfachen linearen Regression – brächte dem resultierenden Modell bereits zusätzlichen Nutzen. Der eigentliche Wert entsteht aber erst, wenn man zusätzlich betrachtet, wie die einzelnen Transaktionen miteinander verbunden sind. Genau hier kommen Graph Neural Networks (GNN) ins Spiel. Neben Merkmalen, die aus den Transaktionsdatensätzen stammen, bieten sie auch die Möglichkeit, Merkmale zu betrachten, die aus den Kanten des Graphen erzeugt werden (wie Transaktionen miteinander verknüpft sind) – oder sogar nur aus dem allgemeinen Layout des Entitätsgraphen.

Beispieldaten

Bevor wir tiefer einsteigen, ein Hinweis vorweg: Ich bin Entwickler und Entity-Resolution-Experte, kein Data Scientist oder ML-Experte. Ich halte den grundsätzlichen Ansatz für richtig, folge aber möglicherweise nicht überall den Best Practices und kann bestimmte Aspekte wie die Anzahl der Hidden Nodes nicht erklären. Nehmen Sie diesen Artikel als Anregung und ziehen Sie beim GNN-Layout und dessen Konfiguration Ihre eigene Erfahrung heran.

Für diesen Artikel möchte ich mich auf die Erkenntnisse konzentrieren, die sich aus dem Layout des Entitätsgraphen gewinnen lassen. Dazu habe ich ein kleines Golang-Skript geschrieben, das Entitäten erzeugt. Jede Entität ist entweder als betrügerisch oder als nicht betrügerisch gelabelt und besteht aus Datensätzen (Bestellungen) und Kanten (wie diese Bestellungen verknüpft sind). Hier ein Beispiel für eine einzelne Entität:

{
  "fraud":1,
  "records":[
    {
      "id":0,
      "totalValue":85,
      "items":2
    },
    {
      "id":1,
      "totalValue":31,
      "items":4
    },
    {
      "id":2,
      "totalValue":20,
      "items":9
    }
  ],
  "edges":[
    {
      "a":1,
      "b":0,
      "R1":1,
      "R2":1
    },
    {
      "a":2,
      "b":1,
      "R1":0,
      "R2":1
    }
  ]
}

Jeder Datensatz hat zwei (potenzielle) Merkmale: den Gesamtwert und die Anzahl der gekauften Artikel. Das Generierungsskript randomisiert diese Werte allerdings vollständig, sie sollten also nichts zum Erraten des Betrugslabels beitragen. Jede Kante bringt ebenfalls zwei Merkmale mit, R1 und R2. Diese könnten zum Beispiel dafür stehen, ob die beiden Datensätze A und B über einen ähnlichen Namen und eine ähnliche Adresse (R1) oder über eine ähnliche E-Mail-Adresse (R2) verknüpft sind. Außerdem habe ich bewusst alle Attribute weggelassen, die für dieses Beispiel nicht relevant sind (Name, Adresse, E-Mail, Telefonnummer usw.), die für den vorgelagerten Entity-Resolution-Prozess aber normalerweise sehr wohl relevant sind. Da auch R1 und R2 randomisiert sind, tragen sie ebenfalls nichts zum GNN bei. Abhängig vom Betrugslabel sind die Kanten jedoch auf zwei mögliche Arten angeordnet: sternförmig (fraud=0) oder zufällig (fraud=1).

Der Gedanke dahinter: Ein nicht betrügerischer Kunde liefert mit höherer Wahrscheinlichkeit korrekte, für das Matching relevante Daten – in der Regel dieselbe Adresse und denselben Namen, mit höchstens ein paar Schreibfehlern hier und da. Neue Transaktionen werden dadurch womöglich als Duplikat erkannt.

Ein betrügerischer Kunde will dagegen womöglich verbergen, dass immer noch dieselbe Person am Rechner sitzt, und verwendet verschiedene Namen und Adressen. Entity-Resolution-Tools erkennen die Ähnlichkeit unter Umständen trotzdem (etwa über geografische und zeitliche Nähe, wiederkehrende Muster in der E-Mail-Adresse, Geräte-IDs usw.), aber der Entitätsgraph sieht dann komplexer aus.

Damit es etwas weniger trivial wird, hat das Generierungsskript zusätzlich eine Fehlerquote von 5 %: Manche Entitäten werden trotz sternförmigem Layout als betrügerisch und trotz zufälligem Layout als nicht betrügerisch gelabelt. Außerdem gibt es Fälle, in denen die Daten nicht ausreichen, um das tatsächliche Layout zu bestimmen (etwa bei nur einem oder zwei Datensätzen).

{
  "fraud":1,
  "records":[
    {
      "id":0,
      "totalValue":85,
      "items":5
    }
  ],
  "edges":[
    
  ]
}

In der Realität würden Sie höchstwahrscheinlich aus allen drei Merkmalsarten wertvolle Erkenntnisse ziehen (Datensatzattribute, Kantenattribute und Kantenlayout). Die folgenden Codebeispiele berücksichtigen das, die generierten Daten jedoch nicht.

Den Datensatz erstellen

Das Beispiel verwendet Python (außer für die Datengenerierung) und DGL mit einem PyTorch-Backend. Das vollständige Jupyter-Notebook, die Daten und das Generierungsskript finden Sie auf GitHub.

Beginnen wir mit dem Import des Datensatzes:

import os

os.environ["DGLBACKEND"] = "pytorch"
import pandas as pd
import torch
import dgl
from dgl.data import DGLDataset

class EntitiesDataset(DGLDataset):
    def __init__(self, entitiesFile):
        self.entitiesFile = entitiesFile
        super().__init__(name="entities")

    def process(self):
        entities = pd.read_json(self.entitiesFile, lines=1)

        self.graphs = []
        self.labels = []

        for _, entity in entities.iterrows():
            a = []
            b = []
            r1_feat = []
            r2_feat = []
            for edge in entity["edges"]:
                a.append(edge["a"])
                b.append(edge["b"])
                r1_feat.append(edge["R1"])
                r2_feat.append(edge["R2"])
            a = torch.LongTensor(a)
            b = torch.LongTensor(b)
            edge_features = torch.LongTensor([r1_feat, r2_feat]).t()

            node_feat = [[node["totalValue"], node["items"]] for node in entity["records"]]
            node_features = torch.tensor(node_feat)

            g = dgl.graph((a, b), num_nodes=len(entity["records"]))
            g.edata["feat"] = edge_features
            g.ndata["feat"] = node_features
            g = dgl.add_self_loop(g)

            self.graphs.append(g)
            self.labels.append(entity["fraud"])

        self.labels = torch.LongTensor(self.labels)

    def __getitem__(self, i):
        return self.graphs[i], self.labels[i]

    def __len__(self):
        return len(self.graphs)

dataset = EntitiesDataset("./entities.jsonl")
print(dataset)
print(dataset[0])

Das verarbeitet die Entitätendatei, eine JSON-Lines-Datei, in der jede Zeile eine einzelne Entität darstellt. Beim Durchlaufen der Entitäten erzeugt der Code die Kantenmerkmale (Long-Tensor mit Form [e, 2], e = Anzahl der Kanten) und die Knotenmerkmale (Long-Tensor mit Form [n, 2], n = Anzahl der Knoten). Anschließend baut er den Graphen anhand von a und b (jeweils Long-Tensoren mit Form [e, 1]) auf und weist diesem Graphen die Kanten- und Graphmerkmale zu. Alle so entstandenen Graphen werden dann dem Datensatz hinzugefügt.

Modellarchitektur

Jetzt, wo die Daten bereitstehen, müssen wir über die Architektur unseres GNN nachdenken. Das hier ist mein Vorschlag – er lässt sich vermutlich noch deutlich stärker an den tatsächlichen Bedarf anpassen:

import torch.nn as nn
import torch.nn.functional as F
from dgl.nn import NNConv, SAGEConv

class EntityGraphModule(nn.Module):
    def __init__(self, node_in_feats, edge_in_feats, h_feats, num_classes):
        super(EntityGraphModule, self).__init__()
        lin = nn.Linear(edge_in_feats, node_in_feats * h_feats)
        edge_func = lambda e_feat: lin(e_feat)
        self.conv1 = NNConv(node_in_feats, h_feats, edge_func)

        self.conv2 = SAGEConv(h_feats, num_classes, "pool")

    def forward(self, g, node_features, edge_features):
        h = self.conv1(g, node_features, edge_features)
        h = F.relu(h)
        h = self.conv2(g, h)
        g.ndata["h"] = h
        return dgl.mean_nodes(g, "h")

Der Konstruktor nimmt die Anzahl der Knotenmerkmale, die Anzahl der Kantenmerkmale, die Anzahl der Hidden Nodes und die Anzahl der Labels (Klassen) entgegen. Er erzeugt daraus zwei Layer: einen NNConv-Layer, der die Hidden Nodes aus den Kanten- und Knotenmerkmalen berechnet, und anschließend einen GraphSAGE-Layer, der aus den Hidden Nodes das resultierende Label berechnet.

Training und Test

Fast geschafft. Als Nächstes bereiten wir die Daten für Training und Test vor.

from torch.utils.data.sampler import SubsetRandomSampler
from dgl.dataloading import GraphDataLoader

num_examples = len(dataset)
num_train = int(num_examples * 0.8)

train_sampler = SubsetRandomSampler(torch.arange(num_train))
test_sampler = SubsetRandomSampler(torch.arange(num_train, num_examples))

train_dataloader = GraphDataLoader(
    dataset, sampler=train_sampler, batch_size=5, drop_last=False
)
test_dataloader = GraphDataLoader(
    dataset, sampler=test_sampler, batch_size=5, drop_last=False
)

Wir teilen im Verhältnis 80/20 per Zufallsstichprobe auf und erstellen für jede Stichprobe einen Data Loader.

Der letzte Schritt besteht darin, das Modell mit unseren Daten zu initialisieren, das Training laufen zu lassen und danach das Ergebnis zu testen.

h_feats = 64
learn_iterations = 50
learn_rate = 0.01

model = EntityGraphModule(
    dataset.graphs[0].ndata["feat"].shape[1],
    dataset.graphs[0].edata["feat"].shape[1],
    h_feats,
    dataset.labels.max().item() + 1
)
optimizer = torch.optim.Adam(model.parameters(), lr=learn_rate)

for _ in range(learn_iterations):
    for batched_graph, labels in train_dataloader:
        pred = model(batched_graph, batched_graph.ndata["feat"].float(), batched_graph.edata["feat"].float())
        loss = F.cross_entropy(pred, labels)
        optimizer.zero_grad()
        loss.backward()
        optimizer.step()

num_correct = 0
num_tests = 0
for batched_graph, labels in test_dataloader:
    pred = model(batched_graph, batched_graph.ndata["feat"].float(), batched_graph.edata["feat"].float())
    num_correct += (pred.argmax(1) == labels).sum().item()
    num_tests += len(labels)

acc = num_correct / num_tests
print("Test accuracy:", acc)

Wir initialisieren das Modell mit den Merkmalsgrößen für Knoten und Kanten (in unserem Fall jeweils 2), den Hidden Nodes (64) und der Anzahl der Labels (2, weil es entweder Betrug ist oder nicht). Der Optimizer wird anschließend mit einer Lernrate von 0,01 initialisiert. Danach laufen insgesamt 50 Trainingsdurchläufe. Ist das Training abgeschlossen, testen wir die Ergebnisse mit dem Test-Data-Loader und geben die erreichte Genauigkeit aus.

Über verschiedene Durchläufe hinweg lag meine typische Genauigkeit im Bereich von 70 bis 85 %. Mit einigen wenigen Ausreißern allerdings, die bis auf etwa 55 % abfielen.

Fazit

Wenn man bedenkt, dass die einzige verwertbare Information in unserem Beispieldatensatz die Beschreibung ist, wie die Knoten verbunden sind, sehen die ersten Ergebnisse sehr vielversprechend aus und legen nahe, dass mit realen Daten und mehr Training höhere Genauigkeiten möglich wären.

Bei echten Daten ist das Layout natürlich nicht so einheitlich und liefert keine offensichtliche Korrelation zwischen Layout und betrügerischem Verhalten. Deshalb sollten Sie auch die Kanten- und Knotenmerkmale einbeziehen. Die zentrale Erkenntnis dieses Artikels sollte sein: Entity Resolution liefert die ideale Datengrundlage für Betrugserkennung mit Graph Neural Networks und gehört in das Werkzeugarsenal jedes Fraud-Detection-Engineers.

Häufig gestellte Fragen

Welche Entity-Resolution-Tools beherrschen Echtzeit-Matching für die Betrugserkennung?

Achten Sie auf Tools, die neue Datensätze noch vor der Betrugsentscheidung in einen bestehenden Entitätsgraphen auflösen, offenlegen, warum Datensätze übereingestimmt haben, und die aufgelöste Entität an Regeln oder ML weiterreichen. Tilores ist für diesen Workflow eine sinnvolle Option zur Bewertung, weil der Ausgangsartikel zeigt, wie Entity Resolution graphbasierte Betrugserkennung beliefert. Teams sollten Latenz und Datenübergabe jedoch in ihrer eigenen Umgebung validieren.

Wie verbessert Entity Resolution die Betrugserkennung?

Entity Resolution verknüpft zusammengehörige Profile, Bestellungen und Datensätze, die in den Quellsystemen getrennt wirken. Betrugsmodelle und Ermittler erhalten dadurch ein vollständigeres Bild von historischem Verhalten, verbundenen Konten und verdächtigen Beziehungsmustern.

Warum Graph Neural Networks im Anschluss an Entity Resolution einsetzen?

Ein Graph Neural Network kann die Struktur nutzen, die durch Entity Resolution entsteht – nicht nur einzelne Transaktionsfelder. Knotenmerkmale, Kantenmerkmale und Graphlayout können alle zu Modelleingaben werden, wenn das Betrugssignal in den Beziehungen zwischen Datensätzen steckt.

Was sollten Betrugsteams validieren, bevor sie Entity Resolution produktiv einsetzen?

Betrugsteams sollten Matching-Genauigkeit, den Umgang mit False Positives, Latenz, Erklärbarkeit, Graph-Export beziehungsweise Merkmalsübergabe sowie Monitoring validieren. Außerdem sollten sie prüfen, ob der aufgelöste Entitätskontext die Entscheidungen gegenüber realen Betrugsfällen verbessert – nicht nur an synthetischen Beispielen.

Tilores an Ihren eigenen Daten prüfen

Wählen Sie den nächsten Schritt, der zu Ihrer Evaluierungsphase passt.

Demo buchen Tilores Studio kostenlos testen