An order rejection comes from your broker's risk system, not from the platform that sent it. The broker's own error text is the authoritative clue, and it almost always points at one of six causes.
The six that cover nearly everything
| Cause | What the error usually says | Fix |
|---|---|---|
| Not enough margin | Insufficient funds, margin shortfall, RMS rejection | Add funds or reduce lots |
| Expired daily session | Invalid session, token expired, login required | Complete the broker login for the day |
| Unregistered IP | Unauthorised, forbidden, invalid credentials | Re-whitelist your address and validate |
| Quantity above freeze limit | Freeze quantity exceeded, quantity too large | Split into smaller orders |
| Market order not permitted | Market orders blocked, order type not allowed | Use a limit order |
| Instrument not tradeable | Symbol blocked, contract expired, not permitted | Check the contract is live and not in a ban period |
Reading a rejection properly
The useful discipline is to treat the broker message as evidence rather than noise. Three questions, in order, resolve almost every case.
- Does the message name a specific cause? Margin, session, quantity and order type are usually stated outright. If so, you are done.
- If it is only an authorisation error, did today start fine? If earlier orders worked today, it is not the session and not the IP.
- Did anything change on your side? A new network, a regenerated key or a reallocated address each point somewhere specific.
Most rejections are resolved by question one. The ones that are not are almost always session or address problems, and question two separates them without guessing.
Margin is the most common
Option selling needs far more margin than option buying, and the requirement moves with volatility. A strategy that was comfortably funded last month can be short today without anything about the strategy changing.
Why a strategy you can afford still fails
This produces a failure that looks bizarre until you understand it: a strategy whose final margin requirement you can comfortably afford gets rejected partway through, because the intermediate state needed more than the end state. The fix is keeping headroom above the final requirement, not matching it exactly.
Session and IP rejections look alike
Both produce an authorisation-flavoured error, and both appear suddenly on a setup that worked yesterday. An expired token normally names the session or login. A wrong IP normally reads as unauthorised or forbidden without mentioning a session.
When the error does not say
If the text is ambiguous, check the token first — it expires every day, so it is the likelier of the two, and renewing it is faster than re-whitelisting.
Margin on a multi-leg strategy, step by step
The margin behaviour of a multi-leg position confuses people more than any other part of this, so it is worth walking through what the broker is doing.
- Leg one arrives. A naked short option. The broker blocks the full margin for an unhedged position, which is the largest requirement in the sequence.
- Leg two arrives. Now there is a second position. If it hedges the first, the combined requirement drops — but only once the broker recognises the pair.
- Legs three and four arrive. On a defined-risk structure the requirement can drop substantially again, because the maximum loss is now capped.
- The final state can require far less margin than the intermediate states did.
Why you can afford the position and still fail
The consequence is counter-intuitive: you can have enough funds for the finished position and still be rejected partway through assembling it. The peak requirement is in the middle, not at the end.
What reduces the problem
Some brokers reduce this by accepting the legs as a basket. Where that is available it helps, and where it is not the ordering of your legs can matter — placing the hedging leg earlier reduces how long the unhedged state exists.
Freeze quantity
Exchanges cap how many lots can go in a single order. Beyond that cap the order is rejected rather than queued, and the cap differs by instrument and changes periodically.
A strategy sized for a large account can hit this without warning after a lot-size revision. Lot size changes alter how many lots a given exposure needs, which can push an order over a limit it previously sat under.
What splitting costs you
The fix is splitting the order. The thing to watch is that splitting changes your fill profile — several smaller orders arriving in sequence will not all fill at the same price, and on a fast-moving strike that difference is real.
Blocked order types
Some brokers restrict market orders for automated flows. The reasoning is sound: a market order from a misbehaving algo can execute at a price nobody intended, and the broker carries some of that risk.
Using limit orders is the normal answer, and for most strategies it is also the better one. A limit order that does not fill is usually a better outcome than a market order that fills terribly.
Where to look on Arthalab
1
Open the execution logs
Live Trading, then Logs. Each attempt is recorded with what the strategy decided and what the broker replied.
2
Read the broker's own message
The raw broker response is kept rather than replaced with a generic message, because the exact wording is what identifies the cause.
3
Check the order book
An order that was accepted and then rejected behaves differently from one that never left — the order book tells you which happened.
4
Check positions last
Particularly on a multi-leg strategy, where a partial fill leaves a structure you did not design.
Rejections you should expect occasionally
Not every rejection is a fault to fix. Some are the system working as intended, and treating them as emergencies leads to changes that make things worse.
| Rejection | Is it a problem? | What to do |
|---|---|---|
| Margin, on a volatile day | No — the risk model did its job | Reduce size or accept you sit that day out |
| Freeze quantity on a large order | No — a known exchange cap | Split the order |
| Market order blocked | No — a broker policy | Use limit orders |
| Session expired | Operational, not a fault | Log in earlier tomorrow |
| Unregistered IP | Yes — fix it properly | Re-whitelist and validate |
| Contract not tradeable | Depends | Check the contract is live and not in a ban period |
The only row that demands immediate structural attention is the IP one, because it will recur silently until the address is fixed. The others either resolve themselves or have a known workaround.
The rejection that matters most
A single rejected order on a single-leg strategy is an inconvenience. A rejected leg on a multi-leg structure is a different problem entirely, because the position you are left holding is not the position you designed.
A short straddle that loses one leg becomes a naked short with unlimited risk on one side. That is not a degraded version of your strategy — it is a trade with a completely different worst case, and it can sit there for hours if you are not watching.
The short version
Almost every rejection is one of six causes, and the broker's own wording identifies which.
- Margin is the most common, and the requirement moves with volatility
- A multi-leg structure can need more margin mid-assembly than when finished
- Session and IP errors look alike; check the session first, it expires daily
- Freeze quantity is an exchange cap, fixed by splitting the order
- A rejected leg on a multi-leg strategy leaves a position you did not design
That last point is the one worth configuring for in advance. Decide whether a leg failure should close the rest before you deploy, not while you are watching it happen.
Frequently asked questions
Usually margin. The intermediate state of a multi-leg structure can require more margin than the finished position, so assembly fails partway even when you can afford the final result.
Not directly — a rejected order is not executed. The cost is the missed trade, and on a multi-leg strategy, the risk of being left with a partial position.
Be careful. Retrying a margin rejection will usually just fail again, and retrying into a fast-moving market can fill at a price the strategy never intended.
Almost always one of: insufficient margin, an expired daily broker session, an unregistered IP, quantity above the exchange freeze limit, a blocked order type, or an untradeable contract. The broker's error text identifies which.
A rejection from your broker's risk management system. In practice it most often means the margin available did not cover the order.
Some brokers restrict market orders for automated flows to limit slippage and runaway execution. Using limit orders is the normal answer, and usually the better one.
Most likely the daily broker token expired, or a dynamic IP rotated overnight. Neither requires you to have changed anything.
It can, which is the real risk with multi-leg strategies. A short straddle missing a leg is a naked short with a different worst case. Check positions immediately, and configure the square-off-all-legs rule in advance.
A multi-leg structure may get margin benefit only once every leg is in place. Partway through execution the requirement can exceed the final state, so keep headroom above the final figure rather than matching it.
An exchange cap on how many lots can go in one order. Above it the order is rejected, and the usual answer is splitting into smaller orders — which changes your fill profile.
Start with a free 3-day trial
Build a strategy, backtest it and run it on paper — no broker, no IP and no money needed to try it.
