Slippage settings: Wrong behaviour

Hi,

Currently the slippage setting will only impact market and stopmarket orders.

But not stoplimit or marketable limit orders. This setting should be added to any fill that is the result of an aggressor fill.

I don't use it because of this and instead use an average estimate of execution costs to the commission rule. The problem with my workaround is that pre-optimisation, it can be difficult to estimate the proportion of fills generated by passive vs aggressive orders (as a result of varying target/stop distances). This inherent inaccuracy will then steer the optimisation to exploit the mis-simulation. Therefore having a correctly behaving slippage function would be very useful (essential)!

Multicharts: can you simply check if a fill was the result of an agressor order and then apply slippage costs accordingly.

Thanks!



An even better solution would be to have one slippage cost for stop orders and a seperate one for event triggered market orders (e.g. "market next bar").

I find that in general a triggered stop order will have significantly lower slippage than a script generated market order.

But even the simple solution I mentioned first would be a significant improvement.

Hello, wilkinsw,

You can enable slippage for Limit and Stop Limit orders in the Registry:

Please follow these instructions:
Close all MultiCharts processes.
Go to Windows Start menu and launch Regedit.exe (type in Regedit.exe and press Enter).
Please go to this path:
HKEY_CURRENT_USER\Software\TS Support\your MultiCharts version\StrategyProp
Double click on “UseSlippageForAllTypes” key and change the value to 1.
(If then you want to switch back - set 0).

Please test this solution and let us know if it suits your needs.

Hi Svetlana,

You've misunderstood the problem I think.

Slippage is a function of aggressor vs passive.... not limit/market/stop per se.

Trust me, it simply needs fixing.

Thanks,

Will

wilkinsw,

Please give a specific example of what you’d like to achieve.

For example, in backtesting, a Buy Limit order is sent for 100 contracts @ 1000.00 on MSFT instrument;
slippage = 2 Per Share.
In this case,
- what shall be specified in Strategy Performance Report?
- at what price shall the order be executed?

Hi Svetlana,

If any new order instruction is instantly fillable (executable); aggressor slippage needs to be assigned.

If "Buy at 1000 limit next bar" results in a fill being placed on the chart at the open data point, next bar..... it's an aggressor order and should have slippage assigned. Ie if the next data point (in this case, the open) <1000 then assign slippage. However, if open>=1000 then no aggressor slippage to be assigned.

Stop orders (stop market and stop limit) are best assumed to be instantly fillable upon trigger and therefore should always have aggressor slippage assigned.

Fill placement doesn't relate to this, per se. However, to specifically answer your question:

Place a fill at the opening data point (next bar), IF open<1000, and make sure that $200 is subtracted from the trades profit.

Hello, Will,

If a marketable limit order is placed, we should impose the commission equal to slippage.
If a limit order, which is not going to be immediately executed, is placed, we should not impose additional commission.
We should always impose the commission equal to slippage on other order types (market, stop, stop-limit).

Is our understanding correct?

Spot on!

What would be even better would be the ability to define 2 different types of slippage:

1) Market/marketable limit/instantly triggerable stops

2) Triggered resting stops (stopmarket and stoplimit)

i find “1” to typically be significantly more expensive than “2” to execute. Being able to define respective slippages would be great.

Call “1” “aggressor slippage” and “2” “stop slippage”.

Failing that, the simple fix, as you described: attach slippage to all executions, but not resting limits, would be good.

Will,

As far as we understood, instantly triggerable stop – is a marketable stop; triggered resting stops – are stops and stop limits that are not executed as soon as placed, but live for some time, until the price meets a stop condition.
If that is correct, then it’s unclear why slippage in case of “Triggered resting stop market” shall be lower, as this order is executed according to the market (the same way as a regular market order).
As for the stop limit, everything depends on the limit price of a stop limit order. If the limit price of a stop limit order is marketable at the moment when the stop condition is triggered, then slippage should be the same as for the marketable limit order. If the limit price cannot be met at the moment when the stop condition is triggered, then the slippage shouldn’t be assigned, because the order will be executed strictly at the limit price. Therefore, we don’t see the point in introducing different slippages for marketable and resting orders.

Hi Svetlana,

I suspect MCs understanding of how orders work in live markets explains why they've made the design decisions that they have. "Unkown unknowns" ,if you will.

There's lots of technical details to explain in support of my previous post. I'll do my best to be concise:

1) A triggered resting stop will typically attract less slippage vs a script generated aggressor order because your aggressor order (sent once stop is triggered) is following the aggressor order that triggered your stop. What does that mean, you're thinking? It means that more frequently a triggered buy stop is being filled at the "last traded" price, ie the price we have in our OHLC dataset, because the aggressor order that triggered our stop took place at the ask (aka the "offer"). IF the triggering aggressor order (or maybe a whole cascade of higher priority triggering aggressor orders) took out several resting offers, then our resulting triggered stop's corresponding aggressor order will suffer slippage. So typically we see slippage being rare in very thick slow markets but higher in thin and faster markets. I hope that makes sense.

2) When we send an aggressor order triggered by other events other than following an aggressor order that's touched a price of interest (akin to an emulated stop order) we will see higher slippage:
a) "Market next bar": we don't know if the opening tick of the next bar is the bid/offer. And have no strong clues or biases, as we do with a stop trigger event. This attracts more slippage than a resting stop being triggered.
b) "Market if touched": This is the opposite situation to our resting stop scenario: we are going against the aggressor order that triggered our subsequent aggressor order. We therefore expect this to attract much higher slippage than all other examples.


Just to address the remaining points you raised:

Instantly marketable stop orders don't exist on any of the futures markets I trade as they are rejected. When I mentioned the concept of an instantly marketable stop (for the sake of simplicitly; as the backtest engine assumes correct handling) it is really simply a market or marketable limit order (ie we send a plain and simple aggressor order).

You are correct: an unfilled but triggered stoplimit should attract no slippage as there was no trade in the first place. If the limit component was resting before being filled; then slippage=0. All other situations it will attract slippage as a stopmarket order would.

Being able to define these details allows the user to generate more reliable optimisations. MC comes with a punchy GAO. A user can't properly lean on the power of GAO unless simulations are spot on. If MC's portfolio trader got simulation accuracy nailed (added bar magnifier and granular execution costs, to name a few) then you guys would have an industry leading piece of software. I would happily pay much more if MC PT's simulation accuracy was sorted out.

Simulation accuracy should be one of the biggest priorities for MC IMHO.

Thanks,

Will

Hello, Will,

Thank you for the explanation, we understood it. We have forwarded this information to the developers for further analysis and estimation of improvement possibility in one of the future MultiCharts versions.