Fraud Flow Nodes for Identity & Device
A fraud flow is a graph of nodes. Several of them read identity and device evidence and branch the flow on what they find. This page documents the four that matter for the identity bridge: identitySnapshotGuard, profileLookup, blacklistLookup and velocityCheck. For each: what it does, how you configure it, and how it branches.
These nodes run inside Fraud's flow engine, in-platform. They consume the identity evidence that was already resolved onto the evaluation (see Carrying the Snapshot) — you don't call them directly.
identitySnapshotGuard
The gate that validates the identity snapshot before the rest of the flow relies on it. It checks that input.identity is present, fresh, bound to the right subject and merchant, and decision-grade. If any check fails, the node emits a fail code and the flow branches accordingly.
What it validates
- Presence — an identity snapshot is actually on the input.
- Freshness — the snapshot is not expired or stale.
- Subject binding — the snapshot belongs to the subject/session under evaluation.
- Merchant binding — the snapshot was issued for this merchant.
- Decision grade — the snapshot is graded for downstream decisioning.
Fail codes
| Code | Meaning |
|---|---|
snapshot_missing | No identity snapshot on the input |
not_decision_grade | Snapshot is not decision-grade |
merchant_mismatch | Snapshot was issued for a different merchant |
subject_*_mismatch | Snapshot's subject binding does not match the session |
expired | Snapshot is past its freshness bound |
stale | Snapshot is too old to rely on |
Config
| Option | Effect |
|---|---|
requireDecisionGrade | Require the snapshot to be decision-grade (else not_decision_grade) |
requireMatchingMerchant | Enforce merchant binding (else merchant_mismatch) |
requireMatchingSubject | Enforce subject binding (else subject_*_mismatch) |
maxAgeSeconds | Freshness window; older than this fails expired/stale |
Branches — a pass continues the flow with the validated snapshot; a fail branches to the fail path carrying the specific fail code, so you can route, for example, a snapshot_missing session differently from an expired one.
profileLookup
Looks up an aggregated risk profile for one of several entity types and branches on whether a profile exists. The profile families themselves live in identity; this node reads the aggregated profile keyed for the fraud evaluation.
Config
| Option | Effect |
|---|---|
profileType | Which entity to look up: device, ip, identity or payment |
How it reads — profiles are read from Redis under fraud:profile:* keys, keyed by the resolved entity id for the chosen profileType.
Branches
| Branch | When |
|---|---|
found | A profile exists for the entity — continue with its aggregated history |
not_found | No profile yet — the entity is new to the profile store |
blacklistLookup
Checks the session's markers against block lists and branches on a hit. It covers the highest-signal identifiers.
What it checks — IP, email, device and card markers against their respective block lists.
Branches — a hit branches to the blocked path (carrying which marker matched); a clean lookup continues the flow. Pair it with the snapshot's own ipBlacklisted / fingerprintBlacklisted / deviceTokenBlacklisted flags for defence in depth.
velocityCheck
Counts events over a rolling window, per tenant, and branches when a threshold is crossed. It catches bursts — many attempts from the same entity in a short span — that a single-session view would miss.
How it works — a tenant-scoped rolling-window counter tracks event frequency for the entity under evaluation. When the count in the window exceeds the configured limit, the node branches to its high-velocity path.
Branches — under the limit continues the flow; over the limit branches to the velocity-exceeded path so the flow can add friction or route to review.
How they fit together
A typical identity-aware fraud flow gates on identitySnapshotGuard first, so downstream nodes can trust that a valid, fresh, correctly-bound snapshot is present. It then enriches with profileLookup, screens with blacklistLookup, and rate-limits with velocityCheck — each branch feeding the decision that Fraud ultimately emits (allow / force_3d / review / block).
Next steps
- Carrying the Snapshot — how the snapshot these nodes read is resolved
- Additive Evidence & Trusted Device — what the validated snapshot contributes
- Identity with Fraud — Overview — the evidence-vs-decision boundary