What an AI Trading Order Preflight Must Verify
A detailed guide to the essential preflight checks an AI trading order must perform, covering market‑data freshness, owner‑signed limits, key scopes, error
Produced with automation, then checked by deterministic quality rules and an independent source-grounded review before publication.
- 01The order must confirm market data freshness, source, and timestamp.
- 02Owner‑signed limits on size, notional, and loss must be enforced before signing.
- 03Agent keys are scoped; they never replace the owner’s withdrawal authority.
- 04Explicit error states and timeout handling are required for reliable reconciliation.
- 05An emergency stop revokes the agent key but does not automatically close positions.
An AI trading order preflight should verify that market data is current, that the order respects all owner‑signed limits, and that the agent’s key scope is appropriate. It also needs to handle errors and timeouts explicitly, and to respect emergency stop semantics. These checks together reduce operational risk before any signature is created.
Why is market‑data verification the first step?
Accurate pricing is the foundation of any trade. The preflight must ensure the data feed includes a reliable source identifier, a recent timestamp, and coverage for the intended instrument. If any of these elements are missing or flagged with a warning, the order should be rejected rather than silently treated as zero.
- Source: confirm the feed originates from a trusted provider.
- Timestamp: verify the data is within an acceptable freshness window.
- Coverage: ensure the instrument is listed and tradable.
- Warnings: treat any data‑quality alerts as a hard stop.
How to assess data freshness
A freshness window of a few seconds is typical for equities, while crypto markets may tolerate slightly longer delays. The preflight should compare the feed timestamp against the system clock and reject data older than the configured threshold.
What owner‑signed limits should be enforced?
Limits are defined by the owner and encoded in the agent’s authorization scope. Before an order is signed, the preflight checks that the request does not exceed any configured caps such as maximum order size, daily notional exposure, or daily loss thresholds. These limits are immutable without a new owner signature, providing a clear safety barrier.
- Maximum order size per instrument.
- Daily notional exposure across all venues.
- Maximum allowable loss for the day.
- Order expiry time aligned with policy.
Combining multiple limits
When several limits apply, the preflight evaluates them in order of strictness. If any single limit would be breached, the order is rejected. This approach prevents a scenario where a small breach of one limit is masked by compliance with another.
How does key scope affect order safety?
Agent keys are deliberately narrow. They can place orders within their authorized limits but cannot initiate withdrawals. This separation ensures that even if an agent is compromised, the attacker cannot move funds without the owner’s separate signature.
An AI trading agent should never hold the owner’s withdrawal key. [Why an AI Trading Agent Should Never Hold the Owner’s Withdrawal Key](/blog/ai-agent-withdrawal-key-safety)
What should happen when an order request times out?
A timeout does not prove failure. The preflight must record the exact error state and retain the order’s intent for later reconciliation. This durable mutation identity allows the system to query the venue later and determine whether the order was executed, rejected, or never received.
Proper timeout handling avoids false assumptions about order status. [How an AI Agent Should Respond When an Order Request Times Out](/blog/ai-agent-response-order-timeout)
Reconciliation workflow
After a timeout, the system should schedule a follow‑up check within a short interval. If the venue confirms execution, the order is marked completed; if it reports rejection, the preflight logs the reason for owner review.
When should an AI trading agent pause after repeated errors?
Repeated error conditions indicate a systemic issue-perhaps data degradation or a mis‑configured limit. The preflight logic should count consecutive failures and trigger a pause once a threshold is reached, requiring owner review before resuming.
Strategic pauses protect capital while issues are investigated. [When Should an AI Trading Agent Pause After Repeated Errors?](/blog/ai-trading-agent-pause-after-errors)
Configurable pause thresholds
Owners can set the number of allowed consecutive errors and the minimum pause duration. Typical defaults might be three errors and a five‑minute pause, but high‑risk strategies may use stricter settings.
Frequently asked questions
An emergency stop revokes the calling agent key, preventing further order submissions. It does not automatically close existing positions or cancel token allowances; those actions require separate owner review.
No. Backtests are read‑only and do not deploy agents or sign transactions. Preflight verification operates on live intent and must be performed each time an order is generated.
Risk limits should be revisited whenever market conditions change, after significant portfolio moves, or on a regular schedule defined by the owner. Frequent reviews help keep limits aligned with risk appetite.
Any warning about stale timestamps, missing source attribution, or incomplete instrument coverage should cause the preflight to reject the order until the issue is resolved.
Relying on a single source increases vulnerability to outages or errors. The preflight should be able to detect source failures and either switch to a backup feed or halt trading.
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 full trading app launches September 17.
An AI trading agent must handle order cancellations and replacements with clear controls, error handling, and verification. This guide explains the safe workflow, required checks, and how to manage uncertainty.
When a trading agent reports an ambiguous order status, it signals uncertainty about whether the order succeeded, failed, or is still pending. This article explains the meaning, underlying causes, and practical steps to resolve the ambiguity.