Additive Evidence & Trusted Device

A resolved identity snapshot does not replace Fraud's own view of the session — it adds to it. Fraud's live-signal analysis always runs on its own; the snapshot rides on top and enriches the picture. This page explains that additive model, the one strong thing a trusted snapshot derives (trustedDevice), and an important honesty note: the snapshot's identityRiskLevel verdict is carried across the bridge but is not read by the fraud decision today.

The additive model

The rule is simple and worth internalising: live signals always run; the snapshot never bypasses them.

Fraud computes its own live-signal analysis for every evaluation — device, IP, fingerprint, velocity, and so on.
When an identity snapshot is available, it is merged onto that analysis rather than swapped in. The merge appends the snapshot's findings, reasonCodes and tags to what live analysis already found, and stamps a signal:identity_snapshot_linked tag so the decision trail shows the snapshot was in play.

A snapshot is never a raw pass-through. There is no path where the identity snapshot alone decides the outcome — it is always additional evidence layered onto Fraud's own live analysis. The signal:identity_snapshot_linked tag is your audit marker that the merge happened.

Deriving `trustedDevice`

The strongest thing the snapshot contributes is a trustedDevice derivation — a single boolean that says this device is safe to treat as known-good. It is derived only when all of these hold:

trustedDevice =
     knownDevice
  && stableDevice
  && !vpnDetected
  && !proxyDetected
  && !torDetected
  && !ipBlacklisted
  && !fingerprintBlacklisted
  && !deviceTokenBlacklisted

A device is trusted only if it has been seen before (knownDevice), its fingerprint is stable across sessions (stableDevice), it is not arriving over an anonymising network, and it is not on any block list.

⚠️

trustedDevice is derived only from a trusted snapshot — a signed/verified assertion or a server-side resolve. An untrusted (unsigned inline) snapshot never derives trustedDevice; it can only fill in missing gaps such as a fingerprintId or ipAddress. See Carrying the Snapshot for the three trust levels.

The anonymising-network override

Because trustedDevice requires !vpnDetected && !proxyDetected && !torDetected, an anonymising network overrides device familiarity. A device can be perfectly known and stable, but if the session arrives over a VPN, proxy or Tor exit, the trusted-device derivation collapses to false. Anonymising-network posture wins over "we've seen this device before" — a known device on Tor is not treated as a trusted device.

`identityRiskLevel` is carried, not read

The snapshot's canonical verdict, identityRiskLevel (clean … critical), travels across the bridge inside the merged snapshot. But it is honest to be precise about what drives the decision:

⚠️

identityRiskLevel is carried but not consumed by the fraud decision today. Fraud reads the concrete signals — knownDevice, stableDevice, the blacklist flags, vpnDetected/proxyDetected/torDetected, and the merged findings/reasonCodes/tags. It does not branch on identityRiskLevel. The level is available for audit and for your own logic, but what moves a fraud decision today is the device/network signals and Fraud's own analysis — not the identity verdict band.

What the merge changes, in practice

A trusted, known, stable, clean-network device yields trustedDevice = true, which lets Fraud treat the session as low-friction.
An anonymising network, a blacklist hit, or an unstable/unknown device prevents trustedDevice and keeps the session on Fraud's normal live-analysis path.
The snapshot's findings, reasonCodes and tags are appended to the decision trail so the outcome is explainable — you can see both what live analysis found and what identity contributed.

Notes

The additive merge and the trustedDevice derivation are internal to Fraud. As a merchant you observe the effect through the fraud decision and its reason trail, not through a separate call.
Keep FRAUD_TRUST_UNSIGNED_SNAPSHOT at its default false unless you have a specific reason: it is the switch that would let an unsigned snapshot reach the trusted derivations.

Next steps

Carrying the Snapshot — the three trust levels feeding this page
Fraud Flow Nodes — the guard and lookup nodes around this merge
The Risk Snapshot — every field the merge draws on

Carrying the Snapshot Fraud Flow Nodes