# Why do my forex orders get rejected?
> A rejection is not an error. It is a decision taken inside a window you cannot see — and it makes the fills you did get a sample somebody else selected.
- Canonical: https://hadalinstruments.com/research/why-do-my-forex-orders-get-rejected/
- Published: 2026-08-07
- Author: Hadal Research
- Answers the question: "why do my forex orders get rejected"
- Coins the term: **The Survivor's Fill** — A fill that exists because a counterparty chose to accept it, in a market structure where it could have declined. Execution statistics computed on fills alone describe the accepted half of an order flow and inherit whatever selected it, which is why a fill-only record cannot price its own rejections.
---
## The short answer
Because your counterparty was allowed to say no. Across much of over-the-counter FX an order does not become a trade on arrival: it enters a short decision window — [last look](/glossary/last-look/), covered in full in the glossary — and comes out the other side as a fill, a rejection, or a [requote](/glossary/requote/). A rejection is that window's ordinary output, not a malfunction, and the window itself is a disclosed practice with a defensible history the glossary entry walks through.
What the glossary cannot do is read your log. The useful question about your own record is not *why was this one declined* — it is **whether the declines fall evenly**, because every one of them was a decision taken by an interested party, on every order, out of your sight, and even-handedness is precisely the property a decision like that cannot be assumed to have.
## The Observable Mechanism
From your own platform export, provided it retains rejected orders: the send timestamp, the price you acted on, the outcome, the interval between send and decision, and a reference price for the market across that interval. Most retail exports keep fills and discard everything else — establishing which kind you have is the first finding, and often the only one available.
## Why a rejection rate on its own tells you nothing
The number almost everyone reaches for is the share of orders that were declined. On its own it is close to uninformative.
Consider two counterparties, each declining two orders in a hundred. The first declines them without reference to what the market did during the hold. The second declines only where the interim move went against it, and fills every order where the move went its way. Both publish the same rejection rate. They are not the same instrument, and the difference is the entire subject.
What separates them is **conditioning**. Not *how often* were you declined, but *what was true when you were*. A rejection rate is a marginal statistic in a question that is conditional all the way down, which is why a [fill ratio](/glossary/fill-ratio/) quoted without its conditioning is a brochure figure rather than a measurement.
## The measurement, step by step
Every step below runs on records you already hold, or reveals that you do not hold them.
1. **Establish whether your export retains rejections.** Filled-only is the common case. If that is what you have, stop and note it: the question is unanswerable from your data, which is a real finding about your instrumentation rather than a failure of the method.
2. **Recover the hold interval.** Send timestamp to decision timestamp, per order. The distribution matters more than the mean — a tail of long holds is a different behaviour from a uniform short one.
3. **Attach a reference price at both ends of each hold.** This is the step that decides whether the exercise is worth anything, and it is the hard part: the comparison needs an independent record of the market across the window, not the same feed whose behaviour is in question.
4. **Classify each order by interim drift.** Did the reference market move in your favour, against you, or not materially, between send and decision?
5. **Compute the decline rate within each class, and print n on every one.** Three conditional rates with their sample sizes, not one headline number. Where your platform records requotes as their own outcome, count them beside the declines in each class — a requote is a third answer, not a subspecies of fill.
6. **Do the same for hold duration.** Compare the distribution for accepted orders against declined ones.
**The tell is symmetry.** If the three conditional rates from step five sit close together, the window is doing what its disclosure says it does. If the against-your-counterparty class carries most of the declines while the favourable class fills, you now hold a description of one-directional behaviour — three numbers with their sample sizes, stated without any claim about why.
## The Survivor's Fill
Here is the part that survives even if every rejection in your record turns out to be even-handed, and it is the reason this matters beyond one disputed order.
**Your fills are a sample somebody else selected.** Every trade in your history is there because a counterparty chose to let it be there, in a structure where it could have declined. That makes the filled set a survivor population, and every statistic you compute on it inherits whatever did the selecting.
This is [survivorship bias](/glossary/survivorship-bias/) pointed at your own order flow, and it is more awkward than the usual kind, because the selection is not an accident of record-keeping. Where declines fall on one side of the interim drift, the orders removed from your flow are precisely the ones that had already moved your way. What is left — what becomes your fills, your average [slippage](/glossary/slippage/), your measured [execution cost](/glossary/execution-cost/) — is the remainder after the good ones were taken out.
None of this shows up in a slippage report. An order that never became a trade contributes no row; its replacement fills at whatever the market has since become; and the difference between the two is booked by nobody, because it is filed under market conditions. That is the defect I am naming **the survivor's fill**: not that a fill is wrong, but that a record made only of fills cannot price its own rejections, and will report a cost that is too low by exactly the amount it cannot see.
## What This Does Not Establish (The Limits)
This article is method. **I have measured and published no rejection data** — no rates, no hold-time distributions, no counterparty comparison — and no figure of that kind appears on this page. It names no firm and describes no firm's arrangements.
It does not establish intent. A one-sided decline pattern is a description of behaviour, not evidence of a decision to behave that way, and nothing in a client-side record can carry that distinction. Nor does it establish that anything improper occurred — last look is disclosed and permitted across much of over-the-counter FX, and the [glossary entry](/glossary/last-look/) covers how the FX Global Code treats it. What a one-sided pattern gives you is a precise question to put to your counterparty's disclosures, not a verdict.
It also cannot be run at all on a fills-only export, and that is the common case. Status of my own measurements: **NOT YET COMPUTED**. Hadal carries no affiliate links and takes no commission from any venue.
## Where the measured version publishes
Steps one through six are a spreadsheet and an afternoon, and step three is where the afternoon stops being enough. Setting each hold against the market that was actually running during it needs an independent, time-aligned record of that market — and that record, not the arithmetic, is the part no spreadsheet supplies.
No published instrument yet claims the rejection half of this measurement, and I would rather say that plainly than stretch a page to imply otherwise. What is published divides the problem in two. The fills half — signed slippage as a distribution, cost against the quote of record — is the [Execution Cost Auditor](/instruments/execution-cost-auditor/), whose scope is bounded by what your statements contain: exactly the fills-only boundary this article is about. The reference-record half — an independent, time-aligned journal of what the market was doing during a hold — is the [Broker Feed Auditor](/instruments/broker-feed-auditor/)'s territory, and the subject of [is my broker's feed honest](/research/is-my-brokers-feed-honest/). And the single-event version — one disputed window reconstructed with requote and rejection context where your logs carry it — is the Single-Trade Investigation on [the assay desk](/assays/#single-trade-investigation). Both instruments are pre-launch and carry outputs marked `NOT YET PUBLISHED`; pattern-level rejection analysis joins the published set when it can carry its receipts, and not before.
If the question you actually have is about one order rather than a pattern, the narrower version is [what can a trading statement prove](/research/what-can-a-trading-statement-prove/), which is about what a record establishes and what it cannot.
**If you want the analysis rather than the spreadsheet:** read what the Execution Cost Auditor measures, and the block stating what it does not establish. It is pre-launch and nothing is for sale.
---
## Claims examined
### Claim 01 — canonical: https://hadalinstruments.com/refutations/#claim-913d2d5f
> "My order was rejected because my connection is slow." — our reading: Misleading
A slow connection makes the quote you acted on older by the time it lands, and an older quote is more likely to be declined. So latency is genuinely a factor. What the claim gets wrong is where the decision happens. The order arrived; something at the other end evaluated it and returned a rejection. That is not a dropped packet, and treating it as one sends you to buy a faster line rather than to the record that would tell you how the decision is being made.
**What is true:** Latency changes how stale your quote is by the time it arrives, which changes how likely a rejection becomes — but the rejection itself is a decision taken by the counterparty during a hold window, not a transmission failure, and your own connection speed is only one of its inputs.
Evidence: https://hadalinstruments.com/research/why-do-my-forex-orders-get-rejected/#claim-913d2d5f
### Claim 02 — canonical: https://hadalinstruments.com/refutations/#claim-2acd15de
> "My fill rate is high, so my execution is fine." — our reading: Misleading
An unconditional fill rate answers how often you were accepted, not whether acceptance depended on anything. Both a symmetric process and a strongly one-sided one can produce the same headline percentage — the difference lives in which orders were declined, not how many. Ninety-eight per cent acceptance with the missing two per cent falling entirely on the side where the interim move went against your counterparty is a different instrument from ninety-eight per cent spread evenly, and no single figure distinguishes them.
**What is true:** A fill rate is a single unconditional number and the question is conditional: a high rate can still conceal rejections concentrated entirely in the moments the market moved in your favour, which is the only pattern worth detecting.
Evidence: https://hadalinstruments.com/research/why-do-my-forex-orders-get-rejected/#claim-2acd15de
### Claim 03 — canonical: https://hadalinstruments.com/refutations/#claim-1b32f99f
> "A rejected order costs me nothing, because no trade happened." — our reading: False
The trade did not happen, so no loss appears in the account. That is exactly what makes it expensive: the cost is real and lands nowhere your statement will show it. You re-send, and the second order fills at whatever the market has since become. If declines fall disproportionately where the interim move ran against the party holding the decision, then the orders removed from your flow are the ones that had already moved your way — and the ones that survive to become fills are the remainder.
**What is true:** The cost of a rejection is the trade you would have had, priced against what you got instead — and where rejections fall on one side of the market's interim drift, the orders you lose are systematically the ones that were about to be good.
Evidence: https://hadalinstruments.com/research/why-do-my-forex-orders-get-rejected/#claim-1b32f99f
## Cite This Article
APA BibTeX HTML
Hadal Research. (2026). Why do my forex orders get rejected?. Hadal Research. https://hadalinstruments.com/research/why-do-my-forex-orders-get-rejected/ Version 5762f56, 2026-08-29.
@misc{hadal_2026_why-do-my-forex-orders-get-rejected,
author = {Hadal Research},
title = {Why do my forex orders get rejected?},
year = {2026},
url = {https://hadalinstruments.com/research/why-do-my-forex-orders-get-rejected/},
howpublished = {Hadal Research},
version = {5762f56},
note = {Published: 2026-08-07; version dated 2026-08-29}
}
Source: Hadal Research, Why do my forex orders get rejected?. Original Research
Copy Citation
**Version 5762f56** identifies the commit that last changed this page in Hadal's content repository. That repository is not public, so the identifier does not resolve externally — it is published so a citation pins one specific state rather than a moving page. To obtain the exact version cited, use the [press and research route](https://hadalinstruments.com/press/).
## Explore further
### Instruments
- [Broker Feed Auditor](https://hadalinstruments.com/instruments/broker-feed-auditor/)
- [Execution Cost Auditor](https://hadalinstruments.com/instruments/execution-cost-auditor/)
### Concepts
- [Adverse Selection](https://hadalinstruments.com/glossary/adverse-selection/)
- [Execution Cost](https://hadalinstruments.com/glossary/execution-cost/)
- [Fill Ratio](https://hadalinstruments.com/glossary/fill-ratio/)
- [Last Look](https://hadalinstruments.com/glossary/last-look/)
- [Quote Fade](https://hadalinstruments.com/glossary/quote-fade/)
- [Requote](https://hadalinstruments.com/glossary/requote/)
- [Slippage](https://hadalinstruments.com/glossary/slippage/)
### Research
- [What can a trading statement prove?](https://hadalinstruments.com/research/what-can-a-trading-statement-prove/) Asked as: what can a trading statement prove
- [Is my broker's feed honest? How to test it](https://hadalinstruments.com/research/is-my-brokers-feed-honest/) Asked as: is my broker's feed honest
- [Do brokers hunt your stop losses?](https://hadalinstruments.com/research/do-brokers-hunt-your-stop-losses/) Asked as: do brokers hunt stop losses by widening the spread
[All Hadal research](https://hadalinstruments.com/research/)[This article as plain markdown](https://hadalinstruments.com/research/why-do-my-forex-orders-get-rejected.md)
---
## Raw artifact — NOT PUBLISHED FOR THIS PAGE
No downloadable artifact ships with this page. Eight published measurements do, each content-hashed so a reader can verify the figures independently. Where a measurement is published here without one, that is a gap rather than a policy, and it is stated rather than left to be noticed.
[Measurements that ship their data](https://hadalinstruments.com/research/)