#65 - 5-min guide to entity resolution tools

So a vendor just demoed their graph-based entity resolution feature and it looked... impressive.

Nodes connecting to other nodes, fraud rings lighting up on screen like fireworks, and that cool drag-and-drop feel.

But here's the thing: not all graph solutions are created equal.

Some are built for real-time fraud detection. Others are built as case investigation tools focusing on visualization.

And if you don't ask the right questions up front, you'll only figure out which one you bought after it's too late to matter.

Today I want to share the criteria I use to assess which tools can actually solve my client’s problem from the ones that just look pretty in demos.

Is it real-time or not?

Let's start with the most critical question that somehow gets glossed over in sales calls.

Can this technology actually run in real-time, or is it only available for post-transaction case management?

And if they say it's real-time, follow up immediately: under what limitations?

Because real-time graph analysis at scale is technologically challenging. Even more challenging? Extracting valuable insights from it in milliseconds while a user is waiting to complete their payment.

Most vendors will tell you "yes, we support real-time" without mentioning that it only works for single-hop lookups on a limited subset of entity types. 

Why does this matter so much?

If you're mainly looking for an exploration tool to help investigators dig into suspicious accounts during onboarding or AML reviews, the visualization part might be all you need. 

In fact, that's where many graph tools excel.

But if you want to use entity insights to inform real-time decisions (like in payment fraud), then real-time capabilities aren't optional. They're the entire point.

That new device that just appeared in your customer’s account? If it’s already linked to 47 old, undisputed payments… well, that changes its risk considerably.

Being able to extract this insight in real-time would do wonders for your conversion rate.

Do entities follow a type template?

Here's where things get interesting.

Ask your vendor: do your entities follow a type template, or can they link anything to anything?

Templates sound limiting at first. As I always say, there's no one-size-fits-all in risk management.

But here's what most people miss: when dealing with entities, we need to decide upfront what kind of entities we want to cluster together.

Are we clustering events from the same person? Accounts from the same business? Transactions from the same fraud ring? Each requires different logic.

Without a template, you get chaos. Here’s why: 

Your template decision determines which link types are relevant, what combinations make sense, what insights are worth extracting, and what common assets should we ignore because they're just noise.

I've seen plenty of graph implementations that mindlessly link everything together. Same IP? Linked. Same email domain? Linked. Same first name? Why not, linked.

(OK, I never really saw that last one, but you catch my drift.)

The bottom line is that generic entities tend to explode into thousands of nodes the moment someone logs in from a Starbucks Wi-Fi. 

You end up with "entities" that are technically correct but operationally useless. That’s not helpful.

You should confirm that the use-case you have in mind fits a template available from your vendor. If it doesn't, the tool probably won't help much.

That said, templates are still just starting points. If you have a specific datapoint you think is valuable for linking, knowing you can customize the template to include it is powerful. 

Just make sure that customization is actually feasible, not just theoretically possible.

What else should you check?

A few other points that I want to quickly cover:

Hop depth: Can the system explore multiple hops while building entities, or does it only link first-degree connections?

If it's just first-degree, that's a block/allow list with a fancier UI. Real added value hides beyond them, and your team cannot access it efficiently themselves.

Data scope: Will the graph consist only of your data, or does it include the vendor's entire network?

This has massive privacy implications. Sometimes competitive ones too. 

Obviously, more data is better for detection, but depending on the use-case and your local regulations, you may want to avoid it. Make sure you understand what you're signing up for.

Fuzzy linking: Sometimes fuzzy linking is almost a must to enable basic capabilities, as in the example of addresses. If it’s not normalized, you’d miss too many connections.

But in other cases, the fuzziness comes from defining a link type as a combination of assets, and not just one. For example, device_id + name.

How do you know which ones are important? Well, it depends on your use-case.

Common asset handling: How does the system prevent entities from exploding when they hit common assets like a default phone value or public Wi-Fi?

Are these static blocklists that someone maintains manually? Dynamic lists you can configure on the fly? Or algorithmic detection that identifies common assets by seeing consistently high shared event counts?

The more sophisticated the approach, the fewer false positives you'll see.

The bottom line

Graph-based entity resolution can be incredibly powerful when done right.

But "done right" means different things to different teams: real-time capabilities, thoughtful templating, and proper common asset handling are some of the features you may want to dig deeper at.

It’s not about rating which solutions are good and which are bad.

It’s about ensuring which solutions can actually solve your particular needs.

So before you get dazzled by fancy UI, make sure you're asking these questions.

Have experience with graph implementations that went well or poorly? Hit reply, I'd love to hear what you learned.

In the meantime, that’s all for this week.

See you next Saturday.

P.S. If you feel like you're running out of time and need some expert advice with getting your fraud strategy on track, here's how I can help you:

Free Discovery Call - Unsure where to start or have a specific need? Schedule a 15-min call with me to assess if and how I can be of value.
​Schedule a Discovery Call Now »​

Consultation Call - Need expert advice on fraud? Meet with me for a 1-hour consultation call to gain the clarity you need. Guaranteed.
​Book a Consultation Call Now »​

Fraud Strategy Action Plan - Is your Fintech struggling with balancing fraud prevention and growth? Are you thinking about adding new fraud vendors or even offering your own fraud product? Sign up for this 2-week program to get your tailored, high-ROI fraud strategy action plan so that you know exactly what to do next. ​
Sign-up Now »

Enjoyed this and want to read more? Sign up to my newsletter to get fresh, practical insights weekly!

<