What a fraud graph is here

Entities (cards, devices, IPs, merchants, accounts) are nodes. Events and shared-attribute links are edges. Fraud is often a relationship problem: a new card on a device that already has a flagged card; a merchant that suddenly shares devices with a known ring; an IP with exploding distinct-account cardinality.

Signals on the decision path

Velocity

How many transactions (or logins, or authorizations) did this card or account produce in 1 minute / 5 minutes / 1 hour / 24 hours? JetGraph keeps those windows as ring counters so the fraud service does not COUNT(*) at query time. Typical published lookup: ~0.05 ms. See performance.

Novelty

Has this card ever transacted at this merchant? Has this user ever used this device? First-time edges are a standard card-fraud and ATO feature. Check existence before insert so you do not mark the current event as historical.

Relationship context

One- and two-hop neighborhood: devices shared across cards, IPs shared across accounts. Cypher example for a ring (shared device with a flagged card) is in the fraud detection documentation.

Neighbor risk

After a node is flagged, neighbors expose max_neighbor_risk_score and flagged-neighbor counts. The next authorization can read contagion without traversing.

Propagation

Flag is an API call, not a nightly connected-component job. Unflag reverses exposure. This is how a single confirmed fraud node becomes a live graph signal.

Cardinality

HyperLogLog neighbor counts: how many distinct cards hit this device, how many accounts share this IP. High cardinality on a shared identifier is a classic mule/ring tell.

Payment, card, and connected-entity risk

The engine does not decide approve/decline. Your rules or model combine:

Transaction velocity on the PAN or token
New merchant / new country / new device edges
Spend or count windows on related edge types
Neighbor fraud score from already-flagged cards or devices
Ring queries when you need an explicit shared-device MATCH

Then you always write the event, including declines, so velocity and novelty stay correct. That loop is the same as real-time risk scoring.

What JetGraph is not in fraud

Not a chargeback product, device fingerprint vendor, or consortium bureau
Not a replacement for 3-D Secure or issuer authorization
Not an investigative graph warehouse for year-long multi-hop research (keep Neo4j/warehouse for that if you need it)

Authorization event
  → GetVelocityCount(card)
  → edge_exists(card, merchant)      // novelty
  → GetNodeContext(card)             // neighbor risk
  → optional MATCH ring pattern
  → your score
  → CreateEdge / upsert (always)
  → FlagNode if decline threshold

Real-time graph-based fraud detection