Proving an AI Trade Was Executed: A Practical Checklist
A practical guide that outlines the data, signed receipts, account snapshots and market‑data checks needed to verify an AI trading agent’s executed trade.
Produced with automation, then checked by deterministic quality rules and an independent source-grounded review before publication.
- 01The venue’s order acknowledgment is the core proof that an order entered the market.
- 02Signed receipts stored in an immutable log create tamper‑evident evidence of receipt.
- 03Comparing pre‑ and post‑trade account snapshots validates the expected balance change.
- 04Market‑data timestamps must be matched to the venue timestamp to confirm price freshness.
- 05Timeouts require explicit status checks and documented error handling to avoid false conclusions.
When an AI trading agent reports that it placed a trade, the only reliable way to confirm the action is to collect a set of verifiable artifacts. These include the venue’s order acknowledgment, a signed receipt stored in an immutable log, a reconciled account snapshot, and a market‑data record that aligns with the trade timestamp. Together they form a complete evidence chain. For related context, see What Evidence Confirms an AI Agent Trade Was Actually Executed?. For related context, see How an AI Trading Agent Should Use Exit Plans.
What primary data confirms that an order was accepted?
The venue returns an order acknowledgment that contains a unique order identifier, the exact quantity, price, side and a timestamp from the venue’s clock. Because this message is generated by the matching engine, it serves as the authoritative record that the order entered the market.
- The order identifier assigned by the venue.
- The submitted price, size and side.
- The venue‑provided timestamp.
- The status field indicating accepted or rejected.
How do signed receipts and immutable logs add confidence?
After receiving the acknowledgment, the agent’s key signs a receipt that references the order identifier and the venue timestamp. The signed receipt is written to an immutable store such as a write‑once database or a blockchain ledger. The signature can be verified against the agent’s public key, ensuring the receipt was not altered after creation.
- Signed receipt linking order identifier to venue timestamp.
- Immutable storage that prevents post‑hoc modification.
- Verification of the signature using the agent’s public key.
What account‑state changes must be reconciled?
A successful fill changes both holdings and cash balance. Operators should capture a pre‑trade snapshot from the normalized account interface, then compare it to the post‑trade snapshot after the fill. The expected delta is calculated as filled quantity multiplied by price plus any fees. Any variance triggers a reconciliation log.
- Pre‑trade balance and position snapshot.
- Post‑trade snapshot from the authoritative account view.
- Calculated expected delta based on fill details.
- Reconciliation log documenting any variance.
How can market‑data timestamps verify the trade context?
Market data used for pricing must include a source identifier, a timestamp and a freshness indicator. By matching the venue timestamp on the acknowledgment with the market‑data timestamp, operators can confirm that the price was current at execution time. Missing or stale data should be flagged rather than treated as zero.
- Source identifier (exchange or data vendor).
- Timestamp aligned with venue acknowledgment.
- Freshness flag or warning from the data feed.
What steps are required when an order request times out?
A timeout does not prove failure. The agent must query the venue using the previously received order identifier. If the venue reports a fill, the normal evidence chain proceeds. If the venue reports no order, the agent records a timeout error and may retry according to its risk limits.
- 01Query the venue for order status using the order identifier.
- 02Record the timeout event and the venue’s response.
- 03If no order exists, log the attempt as unexecuted.
- 04If a fill exists, capture acknowledgment and signed receipt as usual.
A timeout is a signal to investigate, not a verdict on execution.
Frequently asked questions
The venue’s order acknowledgment containing a unique identifier, price, size, side and timestamp.
It creates tamper‑evident proof that the agent received the acknowledgment and did not alter the details.
Reconciliation should occur immediately after each trade and be logged for periodic review.
Treat the data as unverified, flag it for review and do not use it for execution decisions.
See the article [How an AI Agent Should Handle Partial Fills](/blog/ai-agent-handle-partial-fills).
Sources and verification
Product claims in this article were checked against these first-party references. Runtime status remains authoritative for current availability.
- Felix documentationfirst party
- Felix machine referencefirst party
Build with Felix now.
Felix infrastructure is live through MCP and the API. The Felix V1 retail quant-desk private beta is planned for September 22.
An AI trading agent can limit exposure to price swings without assuming that an order will fill, using conditional logic, explicit status checks, and owner‑signed limits.
Running a capability check at the start of every automated trade workflow protects against stale data, unavailable venues, and limit breaches, keeping operations safe and auditable.