Incorrect Fill Price even when using tickreplay and having bid/ask.

[rspine]

In the OnMarkedData() event the MarketDataType field is always set to "Last"

In the OnMarkedData() event the MarketDataType field is always set to "Last"
when it should be "Ask" or "Bid"

protected override void OnMarketData(MarketDataEventArgs marketDataUpdate)
{
if (marketDataUpdate.MarketDataType != MarketDataType.Last)
{
// is never reached
throw Exception("Bid or ask updated");
}
}

subscriptions code:

AddDataSeries("AAPL", Data.BarsPeriodType.Tick, 1, Data.MarketDataType.Last);
AddDataSeries("AAPL", Data.BarsPeriodType.Tick, 1, Data.MarketDataType.Ask);
AddDataSeries("AAPL", Data.BarsPeriodType.Tick, 1, Data.MarketDataType.Bid);

[rspine]

The FillPrice needs to be transparent and customizable

Hi Brett

Thank you for taking the time to read and answer to my post, however I must kindly but firmly say that at the moment, the answer describes a situation that is highly unsatisfactory.
This was a massive issue of Ninjatrader7, there is the chance now to reduce/solve the issue in NT8, I hope this will not get actually worse in quality or transparency.

All these points are related to the same key issue/bug that is how to control and trust the (hypothetical) fill price.
Just to make it clear that this is a deal breaker and top priority for any backtester consider the following.
If you do 10 trades a day (buy+sells+20) on something like oil (CL) the bid/ask is equivalent to 0.01, that makes 0.01 x 20 x 1000 USD = 200 USD per day, that is 50'000 USD per year per contract.
It is 100% annualized return on notional value of the current Oil future. Or 500% just using a 5to1 leverage. This is not a detail. On other less volatile assets it would be even worse.
I have worked as market maker, tested many different platforms (Deltix,TT, CQG, Stellar, Multichart and few other custom built backtesters).
If you can't control the fill assumptions (or worse if they are wrong) any back test result is irrelevant or at best you can interpret it as just way to "optimize how to cheat the fill assumption".
This is in your interest as a software developer as well as a broker, your client would go into trading suicide if they assume a back test with more than 10 trades a day has any correspondence with what happened in the past data (let alone the future).


Indeed in your list of NT8 enhancements

http://ninjatrader.com/Downloads/MajorEnhancements_NinjaTrader8.pdf

There are clearly two points where I believed this somehow was improved:
"Enhanced Backtesting Engine"
"New TickReplay Engine"
"Expanded NinjaScript® Access"

Moreover in the NT8 help:

http://ninjatrader.com/support/helpGuides/nt8/en-us/

"Developing for Tick Replay"
"OnMarketData()"
You are describing the OnMarketData() event as a way to access and back test with bid/ask and tick replay.

This was a move in the right direction however all would be wasted if you do not use the bid ask in the fills when available or as a minimum you have to tell how the FillPrice is calculated and open it to customization.


1) Can you point me or explain exactly how the fill price is calculated. With formulas and snippets etc.
2) Please escalate this to the highest level.
3) Check the next post where I explain better what I believe it is a bug/unexpected behavior on the marketDataUpdate.MarketDataType not being updated correctly.

Kind Regards
R.

[NinjaTrader_Brett]

rSpine,

Thanks for posting appreciate you taking the time to post your experience.

On the first point the fill engine is not setup to use bid or ask prices at all. We did not design the fill engine with tick replay in mind unfortunately on this aspect. Its good feedback and is something we should look at in the future if we wanted to support tick replay back testing. SFT-982

On the second point labeled "ALSO RELATED" I'm sorry but I do not understand what you mean. If you get an OnMarketData call with MarketDataType == MarketDataType.Last I expect that to be a trade occurring and to have its .Bid/ and .Ask properties set correctly to reflect the bid/ask at the time the trade occurred. What issue are you running into?

On the third point on no longer being able to adjust the fill type anymore, I will record this feedback. We originally removed the fill type due to lack of interest and we ultimately developed a fill type we felt would meet the majority of use cases needed. SFT-983

[rspine]

Hi

I have uploaded correctly Last, Bid, Ask ticks, with 10th of microsecond precision as per instructions for one instrument (e.g. FGBL 06-12 ).

Then from the Strategy analyzer I run the "Sample MA crossover" strategy with tick replay on a 1 tick. See figure below.
As you know this strategy uses the Enterlong() Entershort() methods that are market orders. However, I see that the fill price are not using the correct bid and ask they are (incorrectly trading at whatever is the last tick price).
In the example it sells market order at 140.90 around timestamp is 17:01:34 seconds
Indeed this is the ask price, Since the bid is never higher than 140.89 betweeen 17:01 and 17:02

The ability to do tickreplay and have max granularity is good (although one would like to be able to choose the latency) but that is only a minor improvement. The key point is to be able to trust that bid ask are used correctly and in controllable/transparent way in historical back tests. I understood this was now supported in NT8. I read in the help on the OnMarketData() event that NT8 "stores the best bid ask at each tick" ..but from my tests it appears this is a bit obscure or wrong.


ALSO RELATED
From other test during the OMarketData() event the marketDataUpdate.MarketDataType it is NOT updated it seems always set at "marketDataUpdate.MarketDataType==MarketDataType.L ast".


In general : Indeed the important point is that I would like to have total control on the Fillprice assumption (as it was somehow possible with NT7). Simply Allowing the user to customize it, e.g. exposing some data (e.g. the next high low of a timeseries... or anything like that). Or even just prices (last, bid ask) in the past ..(one can put a lag in the input signals anyway). I believe that the inability to control exactly the assumption on fill price makes any backtest, even for lower freq strategy, worthless.


Kind Regards
R.