How a Trading Agent Should Respond When Execution Is Unavailable

When execution is unavailable, a trading agent should pause new order submission, record the intended trade details, and monitor the venue status until it can safely resume. This approach protects capital, preserves audit trails, and ensures that later reconciliation can determine whether any orders were filled.

Why detecting execution unavailability is critical?

Execution venues can become unreachable due to network failures, scheduled maintenance, or internal throttling. If an agent continues to assume execution, it may create phantom exposure, double‑count positions, or violate owner‑defined limits. Early detection prevents these downstream risks and keeps the system aligned with the owner’s risk policy.

How an agent can reliably detect that execution is unavailable?

• ·Query the runtime status endpoint for venue health flags.
• ·Validate that market data timestamps are fresh and include source warnings.
• ·Handle explicit error codes such as timeouts or service‑unavailable responses.

What signals indicate a loss of connectivity

Typical signals include repeated HTTP 503 responses, missing heartbeat messages, or market data that is older than the configured freshness window. Each signal should be logged with a timestamp and the venue identifier so that the outage can be audited later.

Immediate actions after detection

1. 01Immediately stop sending new orders and invoke an emergency stop that revokes the active agent key.
2. 02Persist the intended order details-including side, size, price, and risk limits-in durable storage with a unique mutation identifier.
3. 03Log the exact error state and timestamp to aid later reconciliation.
4. 04Continue to monitor venue status without altering existing positions.

Why use a durable mutation identifier

A durable identifier allows the system to match persisted intents with later order confirmations. It prevents duplicate submissions if the agent retries after the outage and provides a clear audit trail for each intended trade.

Recovering once execution returns

Recovery involves a controlled replay of persisted intents. The agent should re‑query the venue to confirm that no partial fills occurred, then decide whether to resubmit, modify, or cancel each pending intent based on current market conditions and owner limits.

• ·Re‑fetch the latest order book and verify that the original price level is still relevant.
• ·Check that owner‑signed daily notional and loss limits have not been exceeded during the outage.
• ·Submit new orders using the same scoped agent key if it has been re‑authorized.

What if the market has moved significantly

If the price level has shifted beyond a predefined tolerance, the agent should treat the persisted intent as stale and either adjust the parameters or discard it, depending on the owner policy. This prevents unintended exposure to adverse price moves.

Safeguards to prevent accidental exposure during an outage

• ·Separate research and execution authority so that read‑only processes cannot trigger trades during downtime.
• ·Use trade‑scoped agent keys that lack withdrawal capability, ensuring that no funds can be moved without explicit owner consent.
• ·Implement regular reviews of permission scopes and expiry dates for all agent keys.

An outage is not a loss event, but it is a state that must be recorded with the same rigor as a filled trade.