All Products
Live Interactive Demo

The fraud ring that
only temporal queries could catch.

Walk through a real insurance fraud investigation. Run live queries against a graph database that remembers every claim, every relationship, and every change — at every point in time.

The scenario

It's October 2025. You're an insurance fraud investigator at Meridian Shield. Claims at one of your body shops — "Acme Auto Body" — have been escalating for months. You suspect organized fraud, but you need proof. The dataset spans 9 months: 67 claimants, 47 claims, 7 doctors, 3 lawyers, and 3 body shops.

Your task: Reconstruct the timeline. Identify the ring. Quantify the loss.

200
Total nodes in the graph
9 mo
Timeline span
47
Claims to investigate
$634K
Total exposure

1. Travel back in time

Use point-in-time queries to see how Acme Auto Body looked at three different moments.

1

Acme on day 30 — everything looks normal

Query the body shop at February 15, 2025 (just 30 days after they joined the network).

MATCH (s:BodyShop {id: 'shop:acme-auto-body'})
RETURN s.name AS name, s.status AS status, s.rating AS rating, s.notes AS notes
// AT '2025-02-15'
Why this matters: Most graph databases can only show you the current state. Graphiquity stores every version of every node. The AT parameter resolves the entire query at a historical moment — no audit tables required.
2

Acme on day 90 — rating slips

Now query the same node at May 1, 2025. Notice the change.

MATCH (s:BodyShop {id: 'shop:acme-auto-body'})
RETURN s.name AS name, s.status AS status, s.rating AS rating, s.notes AS notes
// AT '2025-05-01'
What changed: Rating dropped from B to C, with notes about customer complaints. An adjuster looking at this in real time wouldn't have known the historical context. Graphiquity captures every transition.
3

Acme today — revealed as fraud

Query the current state. See what investigators uncovered.

MATCH (s:BodyShop {id: 'shop:acme-auto-body'})
RETURN s.name AS name, s.status AS status, s.rating AS rating, s.notes AS notes
The story unfolds: Same node, three different snapshots, no extra schema. Every query you just ran is impossible on a traditional graph database without manually building an audit log layer.

2. See the full version history

Trace every change to a node from creation to today — built-in.

4

The complete timeline of Acme's transformation

One procedure call returns every version, with timestamps and properties.

MATCH (s:BodyShop {id: 'shop:acme-auto-body'})
CALL db.history(id(s)) YIELD version, validFrom, properties
RETURN DISTINCT version, validFrom, properties.status AS status, properties.rating AS rating
ORDER BY version
Built-in audit trail: Every Graphiquity node has automatic version history with _valid_from and _valid_to timestamps. The db.history() procedure walks the entire chain.

3. Diff the entire graph between two moments

Find every change that happened between February and August.

5

What changed in 6 months?

Run a snapshot diff between Feb 15 and Aug 15. See exactly what flipped from "Active" to "Under Investigation".

CALL db.diff('2025-02-15', '2025-08-15')
  YIELD entityId, changeType, label, property, before, after
WHERE property = 'status' AND before <> after
RETURN label, before, after LIMIT 20
The whole network shifted: Acme + 3 doctors + 1 lawyer all transitioned to "Under Investigation" together. That's the signature of a coordinated investigation — visible in one query.

4. Find the fraud ring

Use graph traversal to find structural fraud signals.

6

Claimants who share addresses

In a normal claim population, no two policyholders share the same exact address. Here, four addresses each have 8–9 claimants. That's the fraud ring.

MATCH (p:Person)-[:FILED]->(c:Claim)-[:REPAIRED_AT]->(s:BodyShop {name: 'Acme Auto Body'})
RETURN p.address AS address, count(DISTINCT p) AS claimants
ORDER BY claimants DESC LIMIT 10
Structural fraud signal: Real claimants have unique addresses. When 9 different people on 9 different policies all share one apartment, that's not a coincidence — it's organized fraud.
7

Every claim flows through the same lawyer

In normal operations, claimants pick their own lawyers. Here, one attorney represents nearly every claim.

MATCH (c:Claim)-[:REPAIRED_AT]->(:BodyShop {name: 'Acme Auto Body'})
MATCH (c)-[:REPRESENTED_BY]->(l:Lawyer)
RETURN l.name AS lawyer, l.firm AS firm, count(c) AS claims_handled
The funnel effect: A single lawyer (Solomon Reed) handles every fraudulent claim. Combined with the shared addresses, this is a complete fraud topology.

5. Quantify the damage

How much did Meridian Shield lose before catching the ring?

8

Total fraud exposure

Aggregate every claim that flowed through Acme.

MATCH (c:Claim)-[:REPAIRED_AT]->(:BodyShop {id: 'shop:acme-auto-body'})
RETURN count(c) AS total_claims,
       sum(c.amount) AS total_exposure,
       avg(c.amount) AS avg_claim_amount
$634K in 9 months. That's the cost of not having temporal graph queries. The fraud ring would have been visible in week one if anyone had asked the right question. Graphiquity makes asking the right question trivial.

Build this on your own data.

Every query you just ran is standard Cypher. Every temporal feature is built-in. No audit tables, no ETL pipelines, no custom storage layer.