Evidence for broker review
What execution data can and cannot show about your broker
You have had a run of fills you did not expect and you want to raise it. Most pages on this subject either refuse the question or answer it with outrage. This one draws the line where it actually sits: what a per-trade record can establish, what it cannot, and what makes the difference between a message that gets a real answer and one that gets a template.
What a support desk actually engages with
A broker's support desk handles a large volume of complaints that contain no checkable claim. Yours is read against that background, so the thing that changes the reply is not tone - it is whether someone on their side can look up what you are describing.
Usually goes nowhere
- A screenshot of one bad fill.
- An equity curve, or a month of results.
- "My fills are always worse than the price I see."
- A chart with a circle drawn on it.
- A claim about intent, with no ticket attached.
Usually gets a real reply
- Order and deal tickets they can look up.
- Exact timestamps, to the millisecond, with the timezone stated.
- A defined window and a stated number of trades.
- One specific question, not a list of grievances.
- Figures reconstructable from their own server-side records.
That last point carries most of the weight. Almost everything worth citing already exists on the broker's side: order tickets, deal tickets, server-clock timestamps, filled prices, volumes, commission and return codes. When your message is built from those fields, you are not asking them to accept your version of events - you are pointing at their own record and asking a question about it.
Nothing on this page promises an outcome. A broker is not obliged to reply, to explain, or to change anything. What a good record changes is whether the conversation is about checkable facts, and whether you can tell for yourself if the situation is unusual before you start it.
What a per-trade record needs to contain
A record is only useful if a stranger can reconstruct each trade from it without asking you a follow-up question. In practice that means these fields, per trade, and not a summary of them:
| Field | Why it is needed |
|---|---|
| Order ticket and deal ticket | The only identifiers that let the broker find the same trade in their own system. |
| Symbol, volume, order type, filling policy | A market order and a pending order are different events; partial fills produce several deals. |
| Requested price and filled price | The difference, in points, is the thing being discussed. Without both, there is no claim. |
| Server timestamps to the millisecond | ORDER_TIME_SETUP_MSC, ORDER_TIME_DONE_MSC, DEAL_TIME_MSC - the broker's own clock. |
| Bid and ask at the moment of the result | Establishes the spread you actually paid, rather than the spread the chart shows now. |
| Return code | Separates fills from requotes, off quotes and rejections, which have their own pattern. |
| Commission, fee and swap | Cost changes are a separate question from price and often the real one. |
| Sample size and observation window | Turns a set of trades into a measurement someone can check or repeat. |
One field deserves a warning. The bid and ask at the moment of the result exist only inside the trade event itself - they are not written into MT5's order or deal history. If nothing captured them while the trade happened, the spread you actually paid is not recoverable afterwards from your own terminal. That single gap is why a record has to be collected continuously rather than assembled after something goes wrong.
Why one bad fill is not evidence and a distribution is
A fill three points worse than requested is not remarkable on its own. Prices move between the moment a request leaves and the moment it is executed, spreads widen around news and session boundaries, and any account will produce outliers in both directions. A single trade is consistent with completely ordinary conditions, which is exactly why it persuades nobody.
What carries information is the shape across hundreds of trades:
- The centre. Median difference between requested and filled price, in points, per symbol. Medians rather than averages, so one extreme trade does not set the number.
- The tail. The 95th percentile, and how far it sits from the median. Two accounts can share a median and differ entirely in what a bad day looks like.
- The symmetry. The share of fills better than requested against the share worse. Price movement between send and execution should land on both sides. A persistent lean is the observation worth asking about.
- The rejections. Requote and off-quote rates over the same window, since those are the attempts that produced no fill at all.
- The comparison point. All of it against your own earlier window on the same account. Your own history is the most defensible baseline you have.
Stated that way, a claim becomes checkable: not "my fills are bad", but "across 412 market orders on one symbol in the London session, the median difference moved from 0.2 points to 0.9 points against me between one month and the next, and the requote rate tripled." That is a question a support desk can actually take somewhere.
What a broker slippage comparison can establish
The strongest test available to a retail trader is not a comparison against published figures, which nobody publishes in comparable form. It is a comparison you run yourself: the same EA, on the same symbol, over the same period, on two accounts.
Run properly, that establishes something real - that two execution environments produced measurably different results for identical instructions. It is the one design that separates a strategy problem from an environment problem, because the strategy is held constant by construction.
Running it properly means holding the confounds still, and there are more of them than people expect:
- Account type - a raw-spread account with commission is not comparable to a spread-only one.
- Symbol specification - contract size, tick value and symbol suffix can differ between servers.
- Session coverage and the exact date range, including which news events fell inside it.
- Order type and filling policy, and the execution mode each account runs.
- Where each terminal runs, since network distance affects one leg of every round trip.
- Sample balance - two accounts with very different trade counts are not yet a comparison.
Where the limits actually are
It is worth being blunt about this, because the honest boundary is also the useful one.
- Execution data does not establish intent. A record shows what happened to your orders. Why it happened, and whether anyone chose it, is not a quantity that appears in a fill log.
- It does not isolate a cause. A wider spread at your fill could come from the broker's pricing, from a liquidity provider behind them, from genuine market conditions, or from your own connection. The record narrows the question; it does not answer it.
- It does not generalise beyond your account. What your account experienced is evidence about your account. Other traders on the same broker may see something different.
- It is not legal or regulatory advice. Whether a situation is worth escalating, and to whom, is outside anything a measurement can tell you.
ExecGuard names no brokers, publishes no rankings and takes no money from brokers. The reason is practical rather than principled: the moment a tool has a commercial interest in which broker you choose, its comparisons stop being worth anything. The record describes your account, and the conclusion stays yours.
Questions traders ask
Will a broker accept execution data from a third-party tool?
They are not obliged to accept anything. What helps is that the fields that matter - tickets, server timestamps, filled prices, return codes - come from their own server-side records, so the figures can be checked against their system rather than taken on trust. A record built from reconstructable fields is much harder to set aside than a screenshot.
How many trades before a comparison means anything?
There is no fixed number, because it depends on how variable your fills are on that symbol and session. The practical test is stability: if adding another few weeks of trades still moves your median and 95th percentile noticeably, you do not yet have a measurement, you have a sample.
Can execution data show that my broker treated me unfairly?
No. It can show what your fills did - the size and direction of the difference from requested price, how the spread behaved at the moment of execution, how often sends were rejected, and how all of that compares with your own earlier record or a second account. Intent and cause sit outside what any fill log contains, and a tool claiming otherwise is overreaching.
Is comparing two brokers a fair test?
Only if the confounds above are held still. Two accounts running the same EA on the same symbol over the same window, matched on account type and symbol specification, is a fair comparison of those two setups. Two accounts that differ in several of those respects is a comparison of setups, not of brokers, and should be described that way.
Related pages
Waitlist
Collecting this by hand is the hard part
Every field in the table above exists in MT5 at the moment a trade happens, and some of it stops being recoverable shortly afterwards. ExecGuard records it per trade, summarises it at the account level, and exports the record so it can be reviewed or attached to a message. The tracking EA will be published in full, so how each figure is derived can be inspected rather than taken on trust.
It is not open to everyone yet, and the waitlist is genuinely a waitlist - we are trying to understand which version of this problem people actually have. If you join, tell us what you saw: which symbol, which window, what changed, and what you have already ruled out.