11 patterns for this issue
When a Pre-Trade Risk-Check Tool Call Times Out or Returns a Transport-Level Error Instead of a Structured Response, the Agent's Next Reasoning Step Generates a Schema-Conforming Risk-Check Result From Its Own Expectations of What the Tool Usually Returns, and Proceeds as if the Call Had Succeeded
After a Trading Venue Renames a Field in Its Order-Routing API Response (e.g., `available_qty` to `remaining_quantity`), an Agent Consuming the Response Maps the New Field to the Old Expected Key by Semantic/Fuzzy Similarity Rather Than Failing Loudly, Silently Misreading a Different Field as the Quantity Value
An Agent Resolving a Margin Call Through a Multi-Step Tool-Calling Sequence Continues Reasoning About Remaining Liquidation Needs Using the Account Equity and Margin-Usage Figures It Read Before Its Own Preceding Sell Order Executed, Rather Than Re-Fetching Current State After Its Own Action Changed It
A Transaction-Cost-Analysis Agent Benchmarking a Trade's Execution Quality Against Historical Comparable Orders Selects the "Most Similar" Past Order Using Embedding Similarity Over Free-Text Order Notes, Rather Than Matching on Instrument, Order Size, and Time-of-Day Liquidity Regime, Producing a Benchmark That Was Never Executed Under Comparable Conditions
An Execution Agent Receives a "Filled" or "Success" Status From an Order-Management/Broker Tool and Narrates the Trade as Correctly Executed Based on That Status Alone, Without Comparing the Confirmation Payload's Own Symbol, Quantity, Side, and Price Fields Against the Order It Actually Submitted
Agent Sizes and Times Orders Without Accounting for Its Own Price Impact, Especially Across Correlated Positions or Repeated Trades
A Pre-Trade Risk Agent Notes in Free Text That an Order, Combined With Existing Positions, Would Push a Concentration or Leverage Limit Into a Marginal Breach Under a Plausible Adverse Price Move, but the Structured Pre-Trade Check Result Handed Off to the Execution Agent Has Only a Pass/Fail Field on Static Current-State Limits, So the Execution Agent Routes the Order as Clear
Execution Agent's Pre-Trade Cost Model Systematically Understates Realized Slippage, Especially for Larger or Illiquid Orders
A Post-Trade Analytics Agent Generating a Free-Text Explanation for Elevated Execution Slippage Constructs a Plausible Causal Story Linking a Temporally Co-Occurring but Unrelated News Event to the Slippage, When the Actual Driver Was the Execution Algorithm's Own Order-Slicing or Venue-Selection Behavior
Agent Routes Orders to the Venue With the Best Quoted Price Without Accounting for Realistic Fill Probability, Rebate Structure, or Information Leakage Risk at That Venue
Agent Executing Orders Across Multiple Related Accounts or Strategies Inadvertently Creates Wash-Trade-Like Patterns by Crossing Its Own Buy and Sell Orders Without a Cross-Order Check
Trading execution failures occur when agents size, time, or route orders without modeling the actual cost and feasibility of execution, or when they misdiagnose what actually filled versus what was intended, leading to unintended positions, regulatory exposure (wash trades), and slippage that erodes or reverses the intended alpha. Execution failures are often asymmetric in detection: an order fills at a worse price than estimated and the loss is diffuse (1-2 basis points times thousands of shares), while a major execution error (wrong instrument filled, wash-trade pattern, venue routing to a thin book) surfaces only in post-trade reconciliation hours later. Execution agents frequently optimize for a single dimension (best quoted price, lowest fees) without considering the full cost surface (fill probability, information leakage, slippage under realistic book depth, tax impact of forced liquidation).
All 8 trading-execution patterns share a common root mechanism: execution agents are optimized for a single observable dimension (quoted price, status response, narrative plausibility) while remaining blind to the full cost surface or actual execution outcome. Slippage models use historical ADV but ignore current order-book depth and time-of-day liquidity seasonality. Market-impact models assume single-order isolation without visibility into platform-wide aggregate flow. Venue selection ranks by quote quality without measuring realized fill probability or information leakage. Fill validation checks status without diffing actual fields. TCA narratives are generated fluently without grounding in the execution log’s actual decision factors. The reliable fix is architectural: (1) replace static cost models with real-time, order-book-aware impact estimation, (2) implement platform-level flow aggregation and netting before routing, (3) require field-by-field reconciliation of confirmations against orders before any completion narration, (4) ground TCA narratives in execution logs, not free-form market-event correlation, (5) block execution on any pre-trade risk scenario flag with mandatory escalation rather than treating scenarios as advisory.
Partially. Better models (order-book-aware, time-of-day aware, size-sensitive) reduce underestimation from 2-4x down toward 1.5-2x. But the fundamental issue is that slippage is nonlinear: a 2% order experiences disproportionately higher impact than two 1% orders spread over time. No model fixes this without changing behavior: implement dynamic order slicing (size child orders based on live book depth), stagger orders across time windows, and consider dark pools or internal crossing for large trades.
Compute platform-wide aggregate order flow per instrument before approving any individual order. Alert if the aggregate flow for a single instrument exceeds defined thresholds (5% of ADV, or 1 million shares in 15 minutes). For flow exceeding threshold, implement: (1) order netting (cancel offsetting orders), (2) staggered execution scheduling (spread orders over hours), (3) venue diversification (do not concentrate on single venue). Track realized aggregate impact vs. model’s single-order estimate and feed back into sizing logic.
Implement mandatory field-level diff: before narrating an order as “executed successfully,” verify that every material field in the confirmation payload (symbol, quantity, side, price) matches the originally submitted request. Use a canonical security master (not string equality) for symbol matching to catch venue-side reused tickers. If any field diverges, route to manual review and do not update position records until the divergence is resolved.
Not without structural change. The issue is not data coverage but the fundamental mismatch between TCA narrative generation (a free-form language model task) and execution-log grounding (a deterministic lookup task). Require TCA narratives to: (1) cite only factors present in the execution algorithm’s own logged decision factors, (2) label any market-context claim with independent evidence (did the instrument’s spread/volume actually move during the event?), (3) present the execution log’s structured factors as the primary explanation, not as supporting detail.
| Pattern | Mechanism |
|---|---|
| Slippage Underestimation (GitHub) | Cost models linear/static; realized slippage 2-4x estimate for orders >1% ADV |
| Market-Impact Blindness (GitHub) | Multi-account platform aggregate flow 15% of ADV; execution agents unaware; self-inflicted impact compounds |
| Venue-Selection Blindness (GitHub) | Routing selects best-quoted venue; ignores realized fill probability and information leakage |
| Fill-Confirmation Status Trusted Without Diffing (GitHub) | Confirmation status “filled” trusted; actual instrument/quantity/side differs; position system corrupted |
| Embedding Retrieval Selects Wrong Historical Benchmark (GitHub) | TCA historical comparable via text similarity; differs in size/liquidity regime; benchmark cost wrong |
| Spurious Causal Narrative in Slippage Explanation (GitHub) | TCA narrative attributes slippage to news event; news unrelated to actual instrument movement; narrative artifact |
| Multi-Agent Handoff Drops Risk-Limit-Breach Flag (GitHub) | Pre-trade risk flags marginal-breach scenario; execution agent receives only pass/fail, routes order |
| Wash-Trade Detection Gap (GitHub) | Multi-strategy execution; offsetting buy/sell orders cross without pre-trade detection; regulatory exposure |
Total: 8 patterns