Detect above ask / below bid trades in 1 tick bars

[BraisedInBlue]

I am struggling to properly detect trades that result in slippage via trading through the best bid/ask. To be clear, I want to only use the 1 tick bar series to accomplish this.

There is also the issue of aggregating trades that occurred at the exact same time (to the precision given by the data feed) in conjunction with trying to properly detecting this slippage.

Please advise NT. Is it possible to accomplish using only the 1 Tick data series?

I was attempting to do this via getting the previous tick's bid/ask and comparing to the current, but this not correct as it will not detect the cases where in bids/offers are removed thus changing the best bid / ask.

[NinjaTrader_Kate]

Hello BraisedInBlue,

Thank you for your post.

If you're trying to detect slippage in your own trades, it would be comparing the stop price (or price at the time the entry is submitted, in the case of market orders) to the fill price of the order - if different, you've got slippage on that order.

If you're looking to detect buys and sells with a 1 tick series, I'm attaching an example script that may be helpful. This builds the bars for each based on an added 1 tick series and adds them to the proper bar.

Please let us know if we may be of further assistance to you.

[BraisedInBlue]

I am trying to detect trades via 1 tick bars that occur below bid/above ask (exclusively), and want to be able to calculate that slippage. If you try to just look for 1 tick close prices that are > Ask, or < bid, you will find 0 instances of this occuring because the value returned by BarsArray[1].GetAsk(AtBar) gives the ask/bid after the trade occurred, and not before.

If you simply look at the previous bars Ask, you will start including trades that occured solely due to offers being lifted or bids being dropped. (These are not below the bid / above the ask either!)

[NinjaTrader_Kate]

Hello BraisedInBlue,

Thank you for your reply.

Who is your data provider? If your provider does not provide bid/ask stamped tick data, you could be running into incorrect values returned from .GetBid() and .GetAsk().

I think I should clarify that with Bid/Ask stamped tick data, the bid/ask is associated with the tick, not after it. When we're working with your BarsArray[1], BarsArray[1].GetBid(AtBar) is giving you the ask and bid associated with that particular completed trade.

If you want to know if the tick was a buy/sell, you need to get the bid/ask associated with that tick, and that's exactly what the script provided above does:

 // This is how we get the right tick values
double volume = BarsArray[1].GetVolume(whatBar);
double price = BarsArray[1].GetClose(whatBar);

// Accumulate volume
if (price >= BarsArray[1].GetAsk(whatBar))
buys += volume;
else if (price <= BarsArray[1].GetBid(whatBar))
sells += volume;

If it is a 1 tick data series the OHLC will all be the same, but you would essentially want to compare the bid/ask associated with that tick to the Close price of the tick.

Please let us know if we may be of further assistance to you.

[BraisedInBlue]

CQG is my data feed. The GetAsk/GetBid will only return the final Ask/Bid when the trade executed. It will not show what it was prior to the trade and thus cannot detect trades that go through the best bid/ask. With the Time & Sales you are able to mark trades that occur at the ask, and trades at occurred above the ask. They are two distinct and seperate types of trades, at least it is deduced to be that way.

[hedgeplay]

If I recall correctly

1) NT8's Time and Sales produce "Above the Ask" conclusion from same information available originally via the 1 tick data series...
2) Kate's post above with the sample zip and code like ( if (price >= BarsArray[1].GetAsk(whatBar)) ) somewhere were mentioned as the underlying source of data for the T&S Above and Below conclusions.


A similar thread https://ninjatrader.com/support/foru...e-bid-from-t-s

And a quote from habibalex
"In case anyone stumbled upon this, the e.Ask and e.Bid prices will always be at whatever trade price occurred last or (which is good to see what side the trade occurred on for delta). If you want to get the last level 1 bid or ask update, use the if(marketDataType == MarketDataType.Bid) or Ask. These updates occur after the trades have finished.
The NT8 T&S uses this to get trades above / below the bid/ask for highlighting "


After that the next level deeper might be to start watching the Level 2 at the millisecond level and tying changes that just occurred in Level 2 with the specific tick transactions .. yes the ticks can sometimes number in the hundreds stamped with the same really big high-level Millisecond bucket.

There might be a newer Level 2 example posted here in the forum somewhere, but this one is very popular https://ninjatraderecosystem.com/use...indicator-nt8/

Just FYIs I thought you might have interest in..

HedgePlay

[BraisedInBlue]

Hedgeplay,

I was trying to avoid using OnMarketData, as it adds overhead and forces you to use TickReplay in any historical data / backtesting. Is it possible to monitor market depth data without OnMarketDepth() similar to how it functions in the DOM components?

Something like:
Via

lock(SuperDom.MarketDepth)
{

}

I believe the T&S uses OnMarketData to make the determination of above ask/below bid. I am guessing it is because under the last event update, the given ask/bid are the values as they were when the trade came in, then after the last event, you will get the ask/bid update events. I simply know that during the 1 tick bar, there were 0 cases of the trade price ever being above ask / below bid in 10 days of data on /ES which isn't correct.

I would prefer an asynchronous polling method over an event driven callback. Because then I can control when to check for updates and dont have to worry about gurantees on order of operations. Even monitoring the L2 data, you could run into the edge case where bids/offers are pulled prior to the trade going through. This is where having frame updates divided into pre - during - post is incredibly powerful for modeling & simulation.

It may be that the only way to do this is with OnMarketData, but then that makes it very difficult / slow to back test, and also exacerbates issues where tick alignment in historical data doesnt match real-time. And thus a historical back-test produces different results then replaying the data pseudo live via market replay in a V&V comparison. And if I cant perform any verification analysis its hard to trust the results.

[NinjaTrader_Kate]

Hello BraisedInBlue,

Thank you for your reply.

For what you mentioned about previous bid/ask, you could add a historical bid/ask series, to get previous bid/ask ticks.

https://ninjatrader.com/support/helpGuides/nt8/using_historical_bid_ask_serie.htm

However, synchronization of the streams may be difficult if these bid/ask ticks have the same timestamp.

OnMarketData with Tick Replay wouldn't help for backtesting since it is just Last ticks, not not the bid/ask.

Please let us know if we may be of further assistance to you.

[hedgeplay]

Greetings!

First, I am still new to the platform and have not put tremendous depth into these topics so please view others inputs as more informed than mine. Kate please reply with corrections or coaching where anything I have written is not quite right.


Lets break this down.

Hedgeplay,

I was trying to avoid using OnMarketData, as it adds overhead and forces you to use TickReplay in any historical data / backtesting. Is it possible to monitor market depth data without OnMarketDepth() similar to how it functions in the DOM components?

Something like:
Via

lock(SuperDom.MarketDepth)
{

}

"Is it possible to monitor market depth data without OnMarketDepth() similar to how it functions in the DOM components?"

I don't see how. I have not seen that there is any possible way to take advantage of OnMarketDepth or OnMarketData without first subscribing to the event streams.

I simply know that during the 1 tick bar, there were 0 cases of the trade price ever being above ask / below bid in 10 days of data on /ES which isn't correct.

A fellow journeyman spending hours and hours executing analysis on low level tick charts. Bravo!


So are we chasing the wind? Maybe.

For example, in ES or NQ I have not personally seen visibility of two events commonly driving Above and Below transactions for NYSE and NASDAQ offerings: 1) Price inefficiencies across the MANY exchanges listing an issue and 2) Direct routing Above/Below the NBBO to snap up liquidity before the market moves past you and you will need to pay a far worse price.

From the limited time I have spent analyzing the T&S Above and Below I concluded that for me personally the terms "Above and Below" seem like a misnomer. I decided to stop using those terms for futures T&S and decided to view those blocks of rows of "Above and Below" events in the T&S window only as notice that a Market Impulse just took place.

I simply know that during the 1 tick bar, there were 0 cases of the trade price ever being above ask / below bid in 10 days of data on /ES which isn't correct.

I found this approach to be helpful to visualize these events.

My goal for you here. Use lots of ticks events to better see ES transactions 1) in relation to time 2) in relation to the market's movements and 3) how ES's "Above and Below" might most often really be from these three causes:

1) Fallout from large individual transactions that started at CurrentBid/Ask but pushed Above or Below as they consumed all available liquidity.

2) Simple catchup after a lag, after a stall in ES transactions. "Above and Below" is incorrect because the ES transaction is actually dead center boring right where the rest of the market has moved to.

3) Less often but still visible I was left with the sense that a milliseconds of lag in the broad ecosystem involved was the source of signals that would not exist if all the inputs had down to the millisecond accurate timestamps. This is industry-wide issue and not unique to NT and much of the scope is outside NT's control.

• Create a new chart, add 1 tick data series on MNQ, ES, MES, NQ, and RTY.
• As the series with the most ticks leave MNQ as the top and primary chart to help gain more granularity of the number of ticks displayed
• Switch ES & MES data series from Candlesticks to "Line on Close" and make the different colors Overlay them in the same panel.
• In Chart properties switch "Equidistant" off and on to highlight when ES has stalled and the ES reported Last is now way off in relation to how the rest of the market has moved.
• Use this chart to compare against "Above and Below" in the T&S window to see what is really happening in the market.

If you still want to see more clarity

• Now make ES the primary data series and do the list above again to see when view is better
• Add a smoothed ROC indicator in a different color for each of those series above to the same panel and move that panel to just under the panel where you have the ES & MES "Line on Close" series overlaying each other. This collection of ROCs helps to show ES's movements (or not) in relation to the broader markets.
• Again with switching "Equidistant" off and on and scaling the time zoom in and out

What I have written above comes from micro-market analysis on the NQ. I have not done this for ES and would love to hear back on what you learn.

HedgePlay

[BraisedInBlue]

From your list, I am most interested in #1. Which I think is the point surrounding why one would highlight these transactions differently on the tape. Either bids/offers were pulled by HFTs before the order cleared and thus it spilled, or the order was simply larger enough to sweep multiple rows.

While I can sort of catch these events I know I am taking in noise/dirty data with it because of the way in which I have to implement it.

I was trying to line it up wth tape events as a validation step. And as a comparison they dont line up perfectly, which is what caused me to pose the question to begin with.

[hedgeplay]

Either bids/offers were pulled by HFTs before the order cleared and thus it spilled, or the order was simply larger enough to sweep multiple rows.

On the NQ

• "Either bids/offers were pulled by HFTs before the order cleared and thus it spilled" - I don't see this often.
• "or the order was simply larger enough to sweep multiple rows." -- this is extremely common

ES & NQ trade differently so your mileage may vary.

I was trying to line it up with tape events as a validation step.

"or the order was simply larger enough to sweep multiple rows."

My gut reaction to for a simplest path to answer this question is to use something like (from the 1 tick chart)

On big volume within one second, what was the transaction efficiency ratio ..

Highest efficiency ( a big sweep) being the largest number contracts closed without even a small reversal

in the fewest total Milliseconds

HedgePlay