Stop Guessing: A Practical Triage Flow for ‘Bad Execution’ Tickets in FX

Bad execution complaints rarely mean “the platform is broken.” Most tickets fall into three buckets—requotes, partial fills, or slippage—and each has a different root cause, evidence trail, and remediation.

Below is a broker-friendly decision tree you can hand to dealing, support, and ops so they stop debating opinions and start checking the same artifacts.

1) Start with a 60-second classification (the fastest decision tree)

Before you open logs, classify the complaint using the client’s order type and what they actually saw.

Ask for (or pull) these four fields first:

• Symbol, order type (Market / Limit / Stop / Stop-Limit)
• Order size (lots) and whether it was a single ticket or multiple
• Client-side timestamps (platform journal) and server-side timestamps
• What the client claims happened: “requote,” “filled worse,” “only partially filled,” “delayed,” or “rejected”

Then route it:

• Requote-like behavior: client got a “price changed” / “requote” message, or order wasn’t accepted at the requested price.
• Partial fill: one order resulted in multiple fills, or a remainder stayed open / got canceled.
• Slippage: order filled, but at a worse (or better) price than expected.

Why this matters operationally: each bucket maps to different systems. Requotes usually implicate platform execution settings / price validity; partial fills implicate available depth / max fill size / aggregation behavior; slippage implicates market movement + latency + last look / price protection rules.

2) If it’s a “requote”: prove whether it’s price validity, last look, or platform rules

In modern setups, “requote” is often shorthand for price no longer valid at the moment the order hit the execution venue.

Check these in order:

1. Execution mode & order type rules (especially on MT4/MT5):
   • Is the symbol configured for instant execution vs market execution?
   • Are there slippage/deviation limits that cause a reject/price refresh?
2. Quote age at execution time:
   • Compare the timestamp of the quote the client acted on vs the quote at the server when the order arrived.
   • If the client is on a high-latency path (home ISP, far VPS, mobile), “requotes” cluster during fast ticks.
3. Last look / reject codes from LP/bridge:
   • If you’re A-booking, pull the bridge/FIX execution report details: was it rejected due to price change, off-market, or timeout?

Common root causes (and what to do):

• Too-tight deviation / price protection settings → adjust per symbol and session (more tolerant during news/rollover).
• Stale quotes on the client path → recommend closer VPS / optimize hosting (e.g., LD4 for London liquidity), and ensure quote distribution is healthy.
• LP last look behavior → diversify LPs, review hold time, and monitor reject reasons by venue.

Operational tip: if requotes spike on one symbol or one session, it’s usually configuration or LP behavior—not “the whole platform.”

3) If it’s a partial fill: treat it as a depth and routing problem first

Partial fills are not automatically “bad execution.” They’re often the honest outcome of limited top-of-book liquidity—especially for larger tickets, thin symbols, or volatile moments.

Your checklist:

• Was the order eligible for partial fills?
  • On many bridges/aggregators, partial fill behavior depends on order instructions and venue capabilities.
• What was the available depth across LPs at that moment?
  • Pull aggregated order book snapshots (if available) or LP fill breakdown.
• Did the SOR split the order?
  • Smart order routing may slice across LPs to reduce market impact, resulting in multiple fills.
• Were there max order size / throttle limits?
  • Some LPs cap size per fill; the remainder may route to the next level or be rejected.

What “good” looks like (for your internal SLA):

• Fill sequence shows rational price levels (top of book → next levels) rather than random gaps.
• Partial fills correlate with known thin periods (rollover, session transitions) or known symbols (exotics, minors).

Fix levers:

• Add/reshape liquidity (more LPs, better mix of bank + non-bank, regional diversity).
• Tune SOR settings (priority by fill rate vs price; aggressiveness; timeouts).
• Set client expectations via execution policy (disclose partial fill possibility; check local regulations).

4) If it’s slippage: separate “market slippage” from “process slippage”

Slippage is the most emotional complaint because clients compare the fill to a price they saw earlier. Your job is to determine whether slippage came from the market moving, or from your execution path adding avoidable delay.

Step-by-step diagnosis:

1. Directionality check
   • Do you see both positive and negative slippage across the book? If it’s only negative, that’s a red flag for asymmetric execution rules or markups.
2. Latency decomposition
   • Break total time into: client→server, server→bridge, bridge→LP, LP response.
   • A “slow” segment points to the owner: hosting, platform load, bridge connectivity, or LP hold time.
3. Volatility context
   • Compare the fill time to tick frequency and spread expansion. In fast markets, even 50–200 ms can matter.

Typical causes of avoidable (process) slippage:

• Platform servers not co-located with liquidity (or overloaded during peaks)
• Bridge timeouts/retries, suboptimal routing, or single-LP dependency
• Misconfigured markup/spread rules that widen during volatility without clear disclosure

Mitigation options:

• Infrastructure: co-location/optimized hosting, tighter network path to bridge/LPs.
• Execution controls: symbol-specific settings, sensible timeouts, and monitoring of venue hold times.
• Transparency: publish an execution policy and dispute process; check local regulations for required disclosures.

5) The evidence pack: what to attach to every “bad execution” resolution

Most disputes drag on because teams don’t standardize the proof. Build a repeatable “evidence pack” so support can close tickets confidently and compliance can audit later.

Minimum artifacts (copy/paste into your SOP):

• Order details: ticket ID, symbol, size, order type, requested price (if applicable)
• Timestamps: client journal time, server receive time, bridge send time, LP ack/fill time
• Execution outcome: fill price(s), partial fill breakdown, reject reason codes (if any)
• Market context: spread at the time, top-of-book snapshot (if available), volatility notes (news/rollover)
• Routing context: A-book/B-book route for that order (or “hybrid rule triggered”), plus any internalization/C-book match info

KPIs worth tracking weekly (to spot systemic issues early):

• Rejection/requote rate by symbol/session/LP
• Fill ratio and average number of fills per ticket
• Slippage distribution (positive vs negative) by symbol/session/client segment
• End-to-end latency percentiles (p50/p95/p99) across each hop

6) Prevent repeat tickets: align execution settings, risk routing, and client messaging

Once you can diagnose correctly, the next step is reducing ticket volume without “loosening everything.” The best brokers treat execution as a joint system across dealing, risk, and client comms.

Practical prevention moves:

• Session-aware symbol profiles: different thresholds for majors vs exotics, and for rollover/news windows.
• LP diversification and health scoring: prioritize venues by fill quality, not only tight spreads.
• Hybrid routing governance: document when flow is A-booked vs internalized, and monitor for toxicity-driven changes that could affect execution quality.
• Client education that doesn’t sound defensive: explain partial fills and slippage mechanics in your execution policy, and ensure disclosures match your actual behavior (check local regulations).

If your stack includes a risk backoffice, use it to correlate execution complaints with routing decisions, exposure events, and LP performance—so you fix the cause, not just the ticket.

The Bottom Line

“Bad execution” is usually one of three things: requotes (price validity/rules), partial fills (depth/routing), or slippage (market movement vs latency). A simple decision tree plus a standardized evidence pack turns disputes into measurable operations.

When you track reject reasons, fill ratios, and latency percentiles by symbol and session, execution quality becomes something you can manage—not argue about.

If you want help instrumenting this workflow across your platform, bridge, and risk stack, start here: /get-started.