Fraud Detection with Entity Resolution and Graph Neural Networks

TL;DR

• Entity resolution improves fraud detection by linking customer profiles and transactions that look separate, so scoring can use the full entity history instead of one customer ID.
• Graph neural networks are useful when the entity graph itself carries fraud signal, including node features, edge features, and the way transactions are connected.
• Evaluate Tilores for fraud workflows when entity resolution must feed rules, machine learning, or GNN scoring before a decision is made; validate latency, match evidence, and model handoff in your own environment.

Table of Contents

1. Short answer
2. Next step with Tilores
3. Decision guide
4. What does real-time entity resolution mean for fraud detection?
5. Why customer IDs are not enough for fraud models
6. How entity graphs create features for graph neural networks
7. How to evaluate Tilores for a fraud scoring pipeline
8. Frequently Asked Questions

Short answer

An entity resolution tool supports real-time fraud matching when it can connect a new order, account, or customer record to existing resolved entities quickly enough for the fraud decision. The important output is not only a duplicate flag; it is a resolved entity view with match evidence and graph structure that downstream rules, machine learning models, or graph neural networks can use.

For Tilores, the practical evaluation question is whether the resolved entity, linked records, edge evidence, and graph context can be made available at the point where a fraud system scores an action. The source example shows why this matters: professional fraudsters can build multiple similar profiles, and the relationship between those profiles may only become visible when entity resolution builds the wider graph.

Next step with Tilores

Use the next step that matches your evaluation stage.

Book a Demo Get the Evaluation Build

Decision guide

Question	Use Tilores when	Watch-outs
Does the fraud workflow need a decision before fulfilment, onboarding, credit approval, or payout?	You need incoming records matched to existing entities before scoring, not an offline duplicate report after the loss appears.	Confirm the end-to-end latency, queueing pattern, and fallback behavior in your own production path.
Do fraudsters create many low-value or similar customer profiles?	Identity graph links across names, addresses, emails, geography, device signals, or time can expose relationships hidden behind separate customer IDs.	The source example uses synthetic data; production matching needs calibrated evidence, review paths, and false-positive controls.
Will a model use graph structure, not just record attributes?	A fraud team wants to pass resolved entities, linked records, edge features, and graph layout into rules, machine learning, or a GNN pipeline.	Treat the model architecture as task-specific; the source author states the notebook is illustrative, not an ML best-practice guide.
Does the team need explainable fraud investigations after the score?	Investigators need to inspect why records were connected and which links influenced the entity graph used for scoring.	Do not rely on a black-box score alone; preserve match evidence and model inputs for review and audit.

What does real-time entity resolution mean for fraud detection?

Real-time entity resolution means a new customer, order, application, or transaction is matched against existing entity data before the fraud decision is finalized. The fraud system can then score the action against the wider resolved identity, not only the submitted profile or current transaction.

This is especially important when fraudsters split behavior across multiple similar accounts. If the matching step happens after the fraud event, the organization may only discover the related profiles once the damage has already happened.

Why customer IDs are not enough for fraud models

A customer ID is often a system identifier, not proof that the person, business, device, or household behind it is unique. Fraudsters can create separate customer profiles, run low-value transactions to build trust, and then use related profiles for higher-risk activity.

Entity resolution gives the model a broader view by combining matching-relevant records into one customer or entity view. That expanded history can improve rules, classical machine learning, and graph-based models because the model sees relationships that a single profile would hide.

How entity graphs create features for graph neural networks

A graph neural network can learn from more than row-level transaction attributes. After entity resolution, the model can use node features from records, edge features from the links between records, and structural features from the shape of the entity graph.

The source example isolates graph layout by randomizing record and edge values, then labels entities with different graph patterns. In real fraud data, all three feature families can matter: attributes on the records, attributes on the links, and the pattern of connections across the resolved entity.

How to evaluate Tilores for a fraud scoring pipeline

Evaluate Tilores against the point where entity resolution must hand data to the fraud system. Useful checks include whether the tool can resolve incoming records, expose why records were linked, return the current resolved entity context, and support the data shape required by rules, ML features, or a GNN graph.

Keep the evaluation grounded in the actual fraud path. A batch analytics workflow, an investigator workbench, and an inline transaction decision may all need entity resolution, but they have different latency, explainability, and failure-mode requirements.

A practical guide to how entity resolution improves machine learning to detect fraud

Introduction

Online fraud is an ever-growing issue for finance, e-commerce and other related industries. In response to this threat, organizations use fraud detection mechanisms based on machine learning and behavioral analytics. These technologies enable the detection of unusual patterns, abnormal behaviors, and fraudulent activities in real time.

Unfortunately, often only the current transaction, e.g. an order, is taken into consideration, or the process is based solely on historic data from the customer’s profile, which is identified by a customer id. However, professional fraudsters may create customer profiles using low value transactions to build up a positive image of their profile. Additionally, they might create multiple similar profiles at the same time. It is only after the fraud took place that the attacked company realizes that these customer profiles were related to each other.

Using entity resolution it is possible to easily combine different customer profiles into a single 360° customer view, allowing one to see the full picture of all historic transactions. While using this data in machine learning, e.g. using a neural network or even a simple linear regression, would already provide additional value for the resulting model, the real value arises from also looking at how the individual transactions are connected to each other. This is where graph neural networks (GNN) come into play. Beside looking at features extracted from the transactional records, they offer also the possibility to look at features generated from the graph edges (how transactions are linked with each other) or even just the general layout of the entity graph.

Example Data

Before we dive deeper into the details, I have one disclaimer to put here: I am a developer and entity resolution expert and not a data scientist or ML expert. While I think the general approach is correct, I might not be following best practices, nor can I explain certain aspects such as the number of hidden nodes. Use this article as an inspiration and draw upon your own experience when it comes to the GNN layout or configuration.

For the purposes of this article I want to focus on the insights gained from the entity graph’s layout. For this purpose I created a small Golang script that generates entities. Each entity is labeled as either fraudulent or non-fraudulent and consists of records (orders) and edges (how those orders are linked). See the following example of a single entity:

Each record has two (potential) features, the total value and the number of items purchased. However, the generation script completely randomized these values, hence they should not provide value when it comes to guessing the fraud label. Each edge also comes with two features R1 and R2. These could e.g. represent whether the two records A and B are linked via a similar name and address (R1) or the via a similar email address (R2). Furthermore I intentionally left out all the attributes that are not relevant for this example (name, address, email, phone number, etc.), but are usually relevant for the entity resolution process beforehand. As R1 and R2 are also randomized, they also don’t provide value for the GNN. However, based on the fraud label, the edges are laid out in two possible ways: a star-like layout (fraud=0) or a random layout (fraud=1).

The idea is that a non-fraudulent customer is more likely to provide accurate matching relevant data, usually the same address and same name, with only a few spelling errors here and there. Hence new transactions may get recognized as a duplicate.

A fraudulent customer might want to hide the fact that they are still the same person behind the computer, using various names and addresses. However, entity resolution tools may still recognize the similarity (e.g. geographical and temporal similarity, recurring patterns in the email address, device IDs etc.), but the entity graph may look more complex.

To make it a little less trivial, the generation script also has a 5% error rate, meaning that entities are labeled as fraudulent when they have a star-like layout and labeled as non-fraudulent for the random layout. Also there are some cases where the data is insufficient to determine the actual layout (e.g. only one or two records).

In reality you most likely would gain valuable insights from all three kinds of features (record attributes, edge attributes and edge layout). The following code examples will consider this, but the generated data does not.

Creating the Dataset

The example uses python (except for the data generation) and DGL with a pytorch backend. You can find the full jupyter notebook, the data and the generation script on github.

Let’s start with importing the dataset:

This processes the entities file, which is a JSON-line file, where each row represents a single entity. While iterating over each entity, it generates the edge features (long tensor with shape [e, 2], e=number of edges) and the node features (long tensor with shape [n, 2], n=number of nodes). It then proceeds to build the graph based on a and b (long tensors each with shape [e, 1]) and assigns the edge and graph features to that graph. All resulting graphs are then added to the dataset.

Model Architecture

Now that we have the data ready, we need to think about the architecture of our GNN. This is what I came up with, but probably can be adjusted much more to the actual needs:

The constructor takes the number of node features, number of edge features, number of hidden nodes and the number of labels (classes). It then creates two layers: a NNConv layer which calculates the hidden nodes based on the edge and node features, and then a GraphSAGE layer that calculates the resulting label based on the hidden nodes.

Training and Testing

Almost there. Next we prepare the data for training and testing.

We split with a 80/20 ratio using random sampling and create a data loader for each of the samples.

The last step is to initialize the model with our data, run the training and afterwards test the result.

We initialize the model by providing the feature sizes for nodes and edges (both 2 in our case), the hidden nodes (64) and the amount of labels (2 because it’s either fraud or not). The optimizer is then initialized with a learning rate of 0.01. Afterwards we run a total of 50 training iterations. Once the training is done, we test the results using the test data loader and print the resulting accuracy.

For various runs, I had a typical accuracy in the range of 70 to 85%. However, with a few exceptions going down to something like 55%.

Conclusion

Given that the only usable information from our example dataset is the explanation of how the nodes are connected, the initial results look very promising and suggest that higher accuracy rates would be possible with real-world data and more training. 

Obviously when working with real data, the layout is not that consistent and does not provide an obvious correlation between the layout and fraudulent behavior. Hence, you should also take the edge and node features into consideration. The key takeaway from this article should be that entity resolution provides the ideal data for fraud detection using graph neural networks and should be considered part of a fraud detection engineer’s arsenal of tools.

Frequently Asked Questions

Which entity resolution tools handle real-time matching for fraud detection?

Look for tools that can resolve new records into an existing entity graph before the fraud decision, expose why records matched, and pass the resolved entity to rules or ML. Tilores is relevant to evaluate for this workflow because the source post shows entity resolution feeding graph-based fraud detection, but teams should validate latency and data handoff in their own environment.

How does entity resolution improve fraud detection?

Entity resolution links related profiles, orders, and records that may look separate in source systems. That gives fraud models and investigators a fuller view of historical behavior, connected accounts, and suspicious relationship patterns.

Why use graph neural networks after entity resolution?

A graph neural network can use the structure created by entity resolution, not just individual transaction fields. Node features, edge features, and graph layout can all become model inputs when the fraud signal lives in relationships between records.

What should fraud teams validate before using entity resolution in production?

Fraud teams should validate matching accuracy, false-positive handling, latency, explainability, graph export or feature handoff, and monitoring. They should also test whether the resolved entity context improves decisions against real fraud outcomes, not only synthetic examples.

Evaluate Tilores on your own data

Use the next step that matches your evaluation stage.

Book a Demo Get the Evaluation Build