Carrying the Snapshot into Fraud
Before Fraud can layer identity evidence onto its analysis, it has to get that evidence for the session in front of it. It does this through an internal resolver — resolveDecisionArtifacts — that finds the IdentityDecisionSnapshot and its signed assertion, decides how much to trust them, and hands them to the fraud analysis. This all happens in-platform over authenticated gRPC; there is no snapshot endpoint you call yourself.
Everything on this page is platform-internal. As a merchant you never invoke the resolver — you send identity's SDK context and, at the payment surface, the checkout live-analyze bootstrap. Fraud does the resolving on your behalf.
The resolution path
The resolver tries the fastest source first and falls back to a fresh fetch only on a miss.
Correlation ids come in
The fraud evaluation carries the identifiers that pin the session to its identity evidence: merchantId, and any of snapshotId, traceId, paymentId or checkoutSessionId. These are the request's correlation keys — they let the resolver locate exactly the right snapshot rather than a stale or unrelated one.
Redis cache lookup
The resolver checks a set of cache keys keyed on those correlation ids:
identity:snapshot:*
identity:trace:*
identity:payment:*
identity:checkout:*
identity:session:*A hot session — one that identity analysed moments ago on the same request path — is served straight from cache. No cross-service call.
Cache miss → internal gRPC resolve
On a miss, the resolver reaches identity over an internal gRPC bridge, authorised with an identity:read scope on an internalAuthToken. The request carries the same correlation ids. Identity returns the artifacts and they are cached for the next reader.
What comes back
The resolver returns the decision artifacts for the session:
| Artifact | What it is |
|---|---|
identitySnapshot | The full IdentityDecisionSnapshot — scores, per-family signals, identityRiskLevel, findings |
identityAssertion | The signed, non-repudiable assertion over the snapshot (when identity minted one) |
expiresAt | Freshness bound — after this, the artifacts are stale and must not be trusted as fresh |
The assertion is the trust anchor. It is asymmetrically signed so Fraud can verify it came from identity and was not altered in transit — the same assertion you would verify against /.well-known/jwks.json.
Three sources, three trust levels
An identity snapshot can reach the fraud analysis by three different routes, and each carries a different amount of trust. This distinction matters, because only a trusted snapshot is allowed to influence the strongest derivations (see Additive Evidence & Trusted Device).
| # | Source | How it arrives | Trust |
|---|---|---|---|
| 1 | Signed assertion | assertion present → signature verified | trusted |
| 2 | Unsigned inline snapshot | snapshot handed in inline, no valid signature | untrusted (by default) |
| 3 | Server-side resolve | resolver fetched it in-platform (cache or gRPC) | trusted |
An unsigned inline snapshot is untrusted by default. It can only fill in missing gaps (e.g. a missing fingerprintId or ipAddress) — it cannot drive the trusted derivations. The FRAUD_TRUST_UNSIGNED_SNAPSHOT flag (default false) can promote it to trusted, but leaving it off is the safe posture. A snapshot that was resolved server-side, or that carries a verified signature, is trusted without the flag.
Notes
- The resolver's identity is always platform-internal. The
identity:readscope on the internal token is what authorises the read — there is no public credential for it. - Correlation via
traceIdis the thread that ties an identity analysis, a payment intent and a fraud decision to one session. When you carry identity's returnedtraceIdforward, you make the whole chain auditable end to end. - A snapshot past its
expiresAtis stale. Freshness is one of the checks theidentitySnapshotGuardnode enforces inside a fraud flow.
Next steps
- Additive Evidence & Trusted Device — what a resolved snapshot does to the decision
- Fraud Flow Nodes — the
identitySnapshotGuardfreshness/binding checks - Assertions & JWKS — verifying the signed assertion yourself