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, it uncovered something surprising.
This “clean” transaction was secretly connected to a known fraud case through two hops.
And that’s when 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.
And fraudsters know this.
So they don't reuse the exact same details.
Instead, they build networks.
They reuse 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 these hidden connections, we started modeling transactions differently.
Instead of storing everything in tables, we built a relationship graph using Amazon Neptune.
In this system:
- Every transaction is a node
- Every entity (phone, email, card, device) is also a node
- Relationships connect them
So a transaction might look like this:
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.
They become part of a network of identities.
Fraud rarely happens alone. It usually exists inside a network of relationships.
The First Fraud Case
Let’s go back to the real example.
A transaction T1 happened earlier.
It used:
Phone → P1
Email → E1
Later, the customer 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.
Why?
Because blocking everything with a single connection can create too many false positives.
So the system allowed it.
But the graph remembered the relationship.
The Transaction That Exposed the Network
Now comes the interesting part.
A third transaction arrived.
Transaction T3
Phone → P3
Email → E2
At first glance, it looked completely unrelated to the fraud.
Different phone.
Different email from the fraud case.
Different card.
But the graph engine performed a traversal.
And it found this path:
T3 → E2 → T2 → P1 → T1 (Fraud)
T3 was two hops away from a confirmed fraud transaction.
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
And it does this in milliseconds.
Real-Time Fraud Detection
When a new transaction arrives:
- It is inserted into the graph
- The system explores nearby relationships
- It checks if the transaction connects to known fraud patterns
- The decision happens before authorization
All of this happens in about 50ms.
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.
And unless you're looking at the network, you'll never see it.
Top comments (0)