In this chapter
We'll find a real, hidden connection between two accounts that share no direct relationship, using a genuine breadth-first shortest-path search across identity signals like shared devices and cards — the concrete mechanism behind real fraud-ring detection.
The Problem in Real Life
ACC-4471 and ACC-8820 don't look related at all. Different signup dates, different referral sources, no REFERRED_BY relationship between them anywhere in GreenMart's graph. A one-hop traversal between them finds nothing, because there's nothing directly connecting them.
Sarah asks a different question: not "are these two directly connected," but "is there any path between them at all, however many hops it takes?"
They don't share a referral. Let's see if they share anything else.
Sarah
"Are These Directly Connected?" vs. "Is There Any Path At All?"
Path finding asks a bigger question
Not "are these directly connected," but "is there any path at all, of any length, through any relationship type?"
Relationship depth is just hop count
A direct connection is depth 1, a connection-of-a-connection is depth 2 — SHORTEST_PATH finds the real depth, not a guessed one.
Identity relationships reveal hidden ties
SHARED_DEVICE and SHARED_CARD each look individually explainable — only suspicious once a real path connects them at the right depth.
No guessing which tables to join
A relational answer means guessing the join depth in advance; SHORTEST_PATH finds whatever the actual shortest connection is.
Fraud Detection & Shortest Paths
Path finding asks a genuinely different question than a single traversal does: not "does this exact relationship connect these two nodes," but "is there any chain of relationships, of any type, that connects them — and if so, what's the shortest one?" Relationship depth is just how many hops that chain takes: a direct relationship is depth 1, a friend-of-a-friend is depth 2, and so on.
This simulator's SHORTEST_PATH(a, b) runs a real breadth-first search across every relationship in the graph, regardless of type — treating the fraud graph as one connected structure, not a single relationship type in isolation.
a1 (ACC-4471) and a2 (ACC-8820) share no direct relationship — no REFERRED_BY, nothing. But a1 shares a device with a3, and a3 shares a card with a2. SHORTEST_PATH walks through both identity relationships — SHARED_DEVICE and SHARED_CARD — regardless of type, and finds the real, 4-hop, 5-node path connecting two accounts that looked completely unrelated.
CREATE (a1:Account {id: 'ACC-4471'})CREATE (a2:Account {id: 'ACC-8820'})CREATE (a3:Account {id: 'ACC-9912'})CREATE (d1:Device {id: 'DEV-fp-2201'})CREATE (c1:Card {id: 'CARD-ending-4410'})CREATE (a1)-[:SHARED_DEVICE]->(d1)CREATE (a3)-[:SHARED_DEVICE]->(d1)CREATE (a2)-[:SHARED_CARD]->(c1)CREATE (a3)-[:SHARED_CARD]->(c1)SHORTEST_PATH(a1, a2)
SHORTEST_PATH takes bound variables (a1, a2 — nodes already created or matched earlier in the script), not arbitrary property values — the same way every other pattern in this simulator refers to nodes it already knows about.
This is fraud detection made concrete: a real fraud ring rarely shares one obvious signal. It's spread across several weaker ones — a device here, a card there — each individually explainable (people share devices with family, cards get reissued), only suspicious in combination, at the right depth. A relational answer to "are these accounts secretly related" would mean guessing which tables to join, and how many times, before even starting — and guessing wrong means missing the connection entirely. SHORTEST_PATH doesn't require guessing the depth in advance; it finds whatever the actual shortest connection turns out to be.
This doesn't mean every path the database finds is fraud — a genuinely coincidental shared device is possible. What it means is that the question "how, if at all, are these two connected" becomes something GreenMart can actually ask and get a real, complete answer to, instead of a question that was practically unaskable before.
Key Takeaway
A fraud ring rarely announces itself through one shared signal — it hides across several weak ones, at a depth nobody thought to check by hand. Path finding doesn't require guessing how many hops to look; it finds the real shortest connection, whatever depth that turns out to be.
Why This Matters
This is the payoff this whole Act has been building toward since the very first chapter's incident — a ring that was invisible to a per-account, per-relationship-type review becomes a real, findable answer once path finding is available as a genuine tool, not a manual guessing exercise.
GreenMart can now find a hidden connection between two accounts without knowing in advance what kind of relationship — or how many hops — actually links them. Fraud rings aren't the only pattern worth walking a graph for, though — the next chapter turns the exact same mechanism toward something GreenMart's customers actually want.