The Fraud That Was Two Hops Away

Source: Dev.to

At 2:17 AM, a payment request hit our system.
Everything looked clean: new phone number, new email, new card. Any normal fraud system would approve it instantly. Ours almost did too, but before the transaction completed our graph engine performed a relationship traversal—and within 50 milliseconds uncovered something surprising. This “clean” transaction was secretly connected to a known fraud case through two hops, and the transaction was blocked.

The Problem With Traditional Fraud Systems

Most fraud systems treat transactions like isolated events. A payment comes in and we ask questions like:

• Has this card been reported before?
• Has this email been used in fraud?
• Is this phone number suspicious?

If everything looks new, the transaction usually passes. Fraudsters know this, so they don’t reuse the exact same details. Instead they build networks, reusing parts of their identity across different transactions—sometimes a phone number, sometimes an email, sometimes a device. Individually, these transactions look harmless, but together they tell a different story.

Thinking in Relationships Instead of Rows

To uncover hidden connections we started modeling transactions as a relationship graph using Amazon Neptune.

• Every transaction is a node.
• Every entity (phone, email, card, device) is also a node.
• Relationships connect them.

Example

T1
├── Phone: P1
└── Email: E1

If another transaction uses the same phone number, it connects to the same node:

P1
├── T1
└── T2

Over time, transactions stop being isolated records and become part of a network of identities.

Fraud rarely happens alone; it usually exists inside a network of relationships.

The First Fraud Case

A transaction T1 happened earlier, using:

• Phone → P1
• Email → E1

The customer later reported it as fraud, so we marked T1 as fraudulent in the graph.

A Suspicious But Allowed Transaction

Later another transaction appeared:

• Transaction T2
• Phone → P1
• Email → E2

This shared the same phone number as the fraudulent transaction, but we didn’t block it. Blocking everything with a single connection would create too many false positives, so the system allowed it while remembering the relationship.

The Transaction That Exposed the Network

A third transaction arrived:

• Transaction T3
• Phone → P3
• Email → E2

At first glance it seemed unrelated: different phone, different email from the fraud case, different card. However, the graph engine performed a traversal and found this path:

T3 → E2 → T2 → P1 → T1 (Fraud)

T3 was two hops away from a confirmed fraud transaction, triggering a block.

Why This Works

Fraudsters rarely operate using a single identity. They build fraud infrastructures using:

• Burner phone numbers
• Disposable emails
• Shared devices
• Mule accounts

Each transaction may look legitimate on its own, but the network behind it tells the real story. Graph intelligence lets us detect:

• Fraud rings
• Shared infrastructure
• Hidden identity connections
• Multi‑hop fraud relationships

All in milliseconds.

Real‑Time Fraud Detection

When a new transaction arrives:

1. It is inserted into the graph.
2. The system explores nearby relationships.
3. It checks if the transaction connects to known fraud patterns.

The decision happens before authorization, typically in about 50 ms, fast enough to stop fraud before the payment completes.

Final Thought

Fraud isn’t just about suspicious transactions; it’s about suspicious relationships. The most dangerous transaction isn’t always the one directly linked to fraud. Sometimes it’s the one two hops away. Unless you’re looking at the network, you’ll never see it.