it is crucial to make nt calculate slippage f every execution when trading automated.

[rtwave]

people with nt,



it took me a very long time. it was all the way back in september of last year that i started to convert some indicators and strategies i have developed into ninjascript and after having to fix numerous malfunctions with the platform and having to jump through the numerous hoops nt brokerage forces clients to go through it was only this weekend that i finally was able to begin trading automated with nt with real funds.


however, even after months of coding and evaluating on simulator i have no idea how bad slippage can be with nt brokerage for the two contracts i'm interested in (m2k and mnq). and there is no reason why this should not be the case at all, nt is a very advanced platform that already has all the capabilities and components it needs to calculate slippage for every automated entry and exit with absolute precision.



slippage when trading strategies automated (specially when trading with real money) consists of the difference between the price at which an order was executed - filled and the price for the instrument (close of bar or last) at the moment the strategy made the decision to make this entry or exit.


the biggest part of slippage costs results from jumping the bid - ask spread every time with a market order as this is necessary to ensure instantaneous executions and for most strategies to function appropriately. additional slippage ticks will also result from the delay in data being sent from the exchange, to the data provider, to the strategy and then orders from the strategy to the broker and to the exchange. significant latency can result in some slippage ticks against a strategy but the slippage generated from jumping the spread is always larger and more relevant.


nt has several capabilities that should be more than enough so that the platform can automatically monitor and calculate slippage for every entry and exit. right no nt can identify every individual order it generates, can trace them, it perfectly knows which strategy generated every single order, it can identify every individual position in the platform and associate them to the strategy and order that created every position. and it is possible that nt could have even more capabilities that could make the automatic measurement of slippage the easiest thing, i couldn't know as i'm not a programmer and just began using the platform very recently.





it is absolutely indispensable to measure slippage costs accurately when trading automated because the lower the slippage incurred per execution per instrument, the faster a profitable strategy can be configured to trade and the larger profits it can accumulate. conversely, elevated slippage means that systems must be significantly throttled so that they can still generate profits. if nt automatically measured observed slippage for every execution and provided reports for these events this would be a feature that would help this product differentiate itself from other far less robust and developed commercially available trading platforms. as far as i can tell, nt already contains all the components it would need to calculate slippage automatically, so it could take mere hours for the people who work with the nt platform to incorporate this enhancement to the product.


very well, thanks, regards.

[NinjaTrader_Jim]

Hello rtwave,

Thanks for your post.

NinjaTrader currently estimates slippage within the bar that is used to fill the order.

Slippage

Slippage can be added to your order fills to help mimic real market conditions. The value is expressed in "ticks", the minimum value of fluctuation for an instrument, and is only applied to market, stop-market and Market-if-touched orders. NinjaTrader will add the slippage to each order however you cannot have more slippage then the high/low price of the next bar.

https://ninjatrader.com/support/helpGuides/nt8/index.html?understanding_historical_fill_.htm#UnderstandingTheHistoricalFillAlgorithm

I have submitted a feature request on your behalf so that NinjaTrader can monitor order latency and provide a more robust way to automatically calculate slippage. I will reply back with an internal ticket number when it is available.

This will be an internal number, but for anyone else wishing to have their interest tracked, please let our support staff know that you would like a vote added for this request.

We receive many requests and cannot reasonably implement all requested features or changes. Interest is tracked internally and if enough interest is tracked, it would be weighed against how feasible it would be to make those changes to consider implementing.

I look forward to assisting.

[rtwave]

thanks.


i'm talking about slippage for every execution and also average slippage per instrument.


nt already generates strategy performance reports which include exhaustive trades lists. it would be the easiest thing to add a column to these reports for the observed slippage for every execution as i defined previously. the platform already has all the information it requires for this calculation.


and the average observed slippage for each instrument would be even more important to calculate as this is a necessary input for any optimization - backtest process. it would be very easy to create a slippage report per instrument or incorporate this average into other existing reports.


for example, from my extensive experimentation with interactive brokers' simulator and other platforms i have determined that the average slippage for every execution for the m2k contract is around 8 ticks, while it is 16 ticks for mnq. these are the values that i'm using at the moment on the nt platform but i don't know if slippage with nt brokerage could be higher or lower and it would be crucial for me to adjust my strategies accordingly if this value was actually significantly different.


as i wrote previously, calculating historical slippage has the highest importance for any trader with profitable automated strategies, this enhancement should be very easy for the people at nt who work on the platform and it would be of great help for nt to differentiate their product from the competition.

[NinjaTrader_Jim]

Hello rtwave,

Thanks for your feedback.

The ticket ID for calculating/estimating slippage has the ticket ID SFT-3089. Your comments are linked within that ticket so they are tracked.

Let us know if there is anything else we can do to help.

[axistrader]

As rtwave points out, real slippage during live trading against the bid/ask spread is not the same as the intrabar backtest performed using "Fill Resolution: High" which I believe simply looks at the tick price with some delay from the market order request. While this is significantly better than the "Standard, Fast" algorithm (less than worthless), the problem with "High Resolution" is that the current bid/ask is going to be different from the last tick from which the back test is calculated. Allowing slippage in the "High Resolution" mode would be a first step (why does it even say slippage for High Resolution when it doesn't even work - just grey out the box). BTW, I have strategies that go from 1.7 PF in the "Standard, Fast" mode (with 8 tick slippage) to 1.05 PF in "High Resolution". What would it be with real slippage??? Probably 0.9, but I'd rather test to see, than waste my money. "Standard, Fast" is a marketing gimmick IMHO to get impatient traders blowing their money thinking they have a good strategy. If you want to keep those clients and trade profitably, it would be in your best interest to dramatically improve the "High Resolution" mode. Make NT the go to resource for truly accurate back-testing.

[NinjaTrader_Jim]

Welcome to the forums axistrader!

The intention of using Standard Fill Resolution is to get quick results with the data that is already available. An alternative would be to simply use the Close price, but since we already have OHLC values in the data series, a more intuitive approach can be taken.

Improving backtesting results comes down to a decision of how much data would be required and how much computation time should be spent on the backtest? Using High Order Fill Resolution or adding a single tick data series within the script and submitting orders to that data series makes results closer to actual market dynamics, but at the cost of additional tick data and backtesting time. With long backtests, single tick data can be quite cumbersome. Improving this further with bid/ask data is certainly possible, but we would want to keep in mind that using bid/ask can at least double the amount of data needed to fill the orders.

As you are expressing interest with using Bid/Ask in backtesting, I have submitted a vote for exposing the fill engine so it can be customized and I noted your interest in using Bid/Ask.

Customizing Fill Engine - SFT-1137 (your feedback for wanting Bid/Ask based historical fill processing is noted.

The behavior with the single tick data series limiting slippage is known. NinjaTrader is designed to keep slippage within the the bar that fills the order. Since High Order Fill Resolution/submitting orders to a single tick data series changes the fill series so each bar is 1 tick, additional slippage will not be seen here. I have tracked your impact in our enhancement request ticket for improving that situation.

Allow out-of-bar slippage - SFT-1464

We look forward to assisting.

[xTrader1]

As RTWAVE said, I cannot emphasize how important is both - ask/bid spread and slippage - both of them may be different on entry and on exits from a trade. This is the reason I had no choice,but to develop my own framework for tick by tick (or higher intervals) testing of historical data. Of course, it means you must have bid and ask historical data . Regarding the slippage - on historical I could only simulate it, so I disregarded it as for now.
I believe Ninja can compute quite easily both bid/ask spread and slippage for real time trading. Regarding historical - we must be on our own.

[NinjaTrader_Jim]

Hello xTrader1,

We have tracked your interest in the above feature requests.