Page 1 of 2
IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 8:30 am
by FXS London Scalper
Being signed up through a partner or IB doesn't change one basic fact: if there's an execution dispute, the broker will look at server logs, and the trader needs their own evidence.
What counts as useful proof:
- Trade ticket number.
- Exact time of the order, ideally to the second, with timezone.
- Requested price and fill price.
- A screenshot of the chart at that moment, showing bid/ask.
- The platform journal entries (MT4/MT5 "Journal" tab), which record order requests and server responses.
What doesn't help:
- "It happened yesterday on GBPUSD, the fill was bad."
- Screenshots without time axis or spread.
- Comparisons with a different broker's chart at a vaguely similar time.
A partner relationship might help get a faster response from support, but it shouldn't replace documentation. Brokers handle disputes based on records, and the more precise the claim, the more likely a fair outcome.
Has anyone successfully won an execution dispute? What evidence made the difference?
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 9:56 am
by PTScalper
Hi traders,
Winning an execution dispute against an ECN or STP broker is essentially a forensic audit of network handshakes. Brokers operate on the default premise that the client terminal is fallible—usually blaming ISP latency, local hardware lag, or standard market volatility. Shifting the burden of proof requires demonstrating that the failure occurred at the broker's pricing engine, their liquidity bridge, or the trading server itself.
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 9:57 am
by PTScalper
Advanced Evidence Required to Overturn a Trade
Beyond the basic requirements of ticket numbers and standard screenshots, dealing desks require irrefutable, timestamped technical data to justify absorbing a loss or reversing a trade.
Millisecond Journal Sequencing: The MT4/MT5 Journal and Experts tabs must be perfectly correlated. If a custom EA or script sends an OrderSend request at 14:30:00.015, the server acknowledges it at 14:30:00.035 (20ms latency), but the actual fill returns at 14:30:02.500 (2.5 seconds later) during normal M15 or H4 market conditions, the data proves the broker's bridge is bottlenecked.
Unfiltered Tick Data (Exported): A simple chart screenshot is easily dismissed as a visual rendering glitch. Exporting the raw tick data (Time, Bid, Ask, Volume) directly from the MT5 or cTrader terminal proves exactly what the platform registered at the microsecond level.
VPS / Network Latency Logs: Brokers routinely use "client internet instability" as a defense for extreme slippage. Providing a continuous ping log from a localized trading VPS (e.g., Equinix LD4 or NY4) showing a stable, unbroken <2ms connection completely eliminates the client-side delay defense.
Aggregated Feed Comparisons: While comparing random retail broker charts is unhelpful, comparing a disputed price spike against institutional aggregated feeds (like LMAX, EBS, or Bloomberg) proves an "off-market" quote. If a broker's quote deviated significantly from the aggregate Top of Book, it was a localized pricing feed error, not a genuine market event.
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 9:57 am
by PTScalper
Real-World Scenarios: How Disputes are Won
1. The Phantom Spike (Bad Tick / Synthetic Stop Hunt)
The Incident: Price spikes instantly, triggers a Stop Loss, and immediately reverses, often visible on only one timeframe or terminal.
The Winning Evidence: The trader provides terminal-exported tick data showing a single anomalous quote with near-zero corresponding volume, alongside historical tick data from two independent institutional feeds showing no such price action.
The Broker's Action: The dealing desk identifies a "bad tick" passed through by a single Liquidity Provider (LP). Because the trade could not have been matched in the real market, the broker cancels the execution, restores the balance, and settles the discrepancy with their LP on the backend.
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 9:58 am
by PTScalper
2. Asymmetric Slippage on Pending Orders
The Incident: Limit orders routinely experience negative slippage or exact fills, but never positive slippage, indicating the broker's B-book plugin or bridge is configured to absorb price improvements (asymmetric slippage).
The Winning Evidence: A trader running automated scalping algorithms provides an exported database of 500+ trades, logging the exact requested price versus the execution price. Statistical evidence showing 100% negative slippage on limits—which should mathematically offer positive or zero slippage in a true Raw ECN environment—proves algorithmic interference.
The Broker's Action: To avoid regulatory escalation regarding "best execution" policies, the broker compensates the discrepancies and moves the account to an unfiltered, true A-book routing group.
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 9:58 am
by PTScalper
3. The "Trade Context is Busy" Freeze
The Incident: During high-volume trading, the terminal freezes, rejecting manual closure orders while the market moves aggressively against the position.
The Winning Evidence: Terminal logs show multiple request taken messages without corresponding server rejections, combined with VPS ping logs showing an active, unbroken connection to the broker's IP. This proves the terminal was communicating perfectly, but the broker's internal trade server queue was overwhelmed and dropping packets.
The Broker's Action: The broker compensates the trader for the financial difference between the first timestamped request taken log and the eventual manual fill.
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 9:58 am
by PTScalper
The True Leverage of the Partner/IB
Operating under a high-volume Introducing Broker or Partner does not change the broker's Terms of Service, but it radically alters the routing of the complaint. Standard support tickets go to Tier 1 desk agents, whose primary directive is to deflect claims using boilerplate templates about "market volatility" and "lack of liquidity."
A strong IB directly bypasses this deflection layer. They escalate the compiled technical evidence straight to the Head of Dealing or a VIP Account Manager, forcing an actual technical review of the FIX logs rather than a copy-pasted dismissal.
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 10:00 am
by PTScalper
To build an indisputable database for execution disputes, your trading algorithms must capture the exact millisecond timestamps and price deltas between the client terminal's request and the broker server's final execution. This requires logging the terminal state immediately before sending the order and capturing the server's final callback.
MetaTrader 5 (MQL5) Implementation
In MT5, execution logging requires pairing the initial OrderSend() request with the asynchronous OnTradeTransaction() event handler. Slippage is the difference between the requested price and the final deal price, while latency is the microsecond delta from the request to the deal confirmation.
1. Define Global Tracking Variables
Store the exact time and price when the order is sent.
Code: Select all
ulong last_order_ticket = 0;
ulong request_time_micro = 0;
double requested_price = 0.0;
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 10:00 am
by PTScalper
2. Capture State Before Order Execution
Record the microsecond timestamp immediately before transmitting the order to the broker's bridge.
Code: Select all
void SendMarketOrder(string symbol, ENUM_ORDER_TYPE type, double volume) {
MqlTradeRequest request = {};
MqlTradeResult result = {};
request.action = TRADE_ACTION_DEAL;
request.symbol = symbol;
request.volume = volume;
request.type = type;
request.price = (type == ORDER_TYPE_BUY) ? SymbolInfoDouble(symbol, SYMBOL_ASK) : SymbolInfoDouble(symbol, SYMBOL_BID);
request.deviation = 0; // Capture actual slippage
// Log the exact moment before sending
requested_price = request.price;
request_time_micro = GetMicrosecondCount();
if (OrderSend(request, result)) {
last_order_ticket = result.order;
}
}
Re: IB-friendly brokers still need fill proof from traders
Posted: Mon Oct 19, 2026 10:00 am
by PTScalper
3. Process the Server Response in OnTradeTransaction
The broker server returns several transaction stages. Isolate TRADE_TRANSACTION_DEAL_ADD to capture the final fill.
Code: Select all
void OnTradeTransaction(const MqlTradeTransaction &trans, const MqlTradeRequest &request, const MqlTradeResult &result) {
// Only process completed deals matching our order
if (trans.type == TRADE_TRANSACTION_DEAL_ADD && trans.order == last_order_ticket) {
ulong execution_time_micro = GetMicrosecondCount();
double execution_latency_ms = (execution_time_micro - request_time_micro) / 1000.0;
double executed_price = trans.price;
double slippage_points = MathAbs(requested_price - executed_price) / SymbolInfoDouble(trans.symbol, SYMBOL_POINT);
// Write to CSV file for the dispute database
string log_entry = StringFormat("%I64u,%s,%f,%f,%.2f,%.2f",
trans.deal, TimeToString(TimeCurrent(), TIME_SECONDS),
requested_price, executed_price, slippage_points, execution_latency_ms);
WriteToCSV(log_entry);
}
}