Orders, one assessment each

To follow every order, assess each order once, with the v1.1 request and the tag trade. The body carries no order data: no instrument, side, quantity, price or amount. FingerTrackID assesses the device and the access behind the order; your system already has the order.

Sizing

A high-frequency order flow needs a capacity review with FingerTrackID before go-live: request rate, retention and console volume are sized for your flow, not assumed.

Flow

1. Prepare in the browser. With the collection recipe, call prepareNextAction() on activity in the order form (its focusin and pointerdown), never when the trading screen loads. The helper keeps the collection fresh inside your application’s evidence window (60 or 300 seconds, the evidence window) and collects again only when it would expire.
2. For each order, take an event context. Call takeActionContext() once per order, at its submit; it waits at most your own ceiling (the SDK lifecycle). Each order gets its own event from the latest collection, with a budget of 5000 ms per lookup since SDK 0.2.0. If no context arrives in time, continue with null: the assessment comes back without a score, and a missing context is never a reason to hold the order. One SDK session issues at most 128 event contexts; the helper collects again before that.
3. Assess from your backend. Send POST /v1/assessments with the v1.1 body and "tag": "trade". Derive external_event_id and idempotency_key from your order ID, so a retry of the same order is the same operation. Both references are required.
4. Report what you did. Send the action and the outcome by assessment_id, as for any other assessment (feedback).

No order triggers an external lookup or a new collection: every order reuses the session’s fresh evidence.

A synthetic body for one order, formatted for reading:

{
  "schema_version": "event-assessment-request.v1.1",
  "external_event_id": "evt_trade_0001",
  "idempotency_key": "idem_evt_trade_0001",
  "occurred_at": "2026-11-03T14:05:22.481Z",
  "subject_ref": "usr_5c0e",
  "account_ref": "acc_77d2",
  "event_context_token": "ect_trade_0001",
  "tag": "trade",
  "deadline_ms": null
}

What to look at on the console

Reading	What it shows
Events with the same tag on the account	The burst of trade events from one account in the last minute, five minutes and hour
Events with the same tag on the device	The burst of trade events from one device, across accounts, in the same windows
Device indicators	BOT_AUTOMATION, EMULATED_ENVIRONMENT, BROWSER_SPOOFING and the network indicators

These readings are context for your analysts. They do not enter the score and are not returned by the API. The order readings of the v1 TRADE journey count only v1 orders; v1.1 orders are counted by tag.

Usage

The usage unit is a completed browser collection, not an order. Orders that reuse the same collection add no usage, so usage follows the time your users actively trade divided by the evidence window, not the number of orders. Usage figures on the console are estimates, not invoices (production status).