Feature Request: Realistic Queue Positioning for limit order fills.

[iantg]

Patrick,

I am enclosing a script I wrote to try to reconcile the differences between the prices and volumes obtained by the GetCurrent() methods which I now understand run on the bar event and are sized accordingly regardless of which event handler was used.

From the looks of it here is what I see:

Part 1: Volumes:

1. Resting Volumes: GetCurrentBidVolume() and GetCurrentAskVolume() show the resting volumes as a snapshot in time and would be in line with what users see on a tool like the DOM. The limitation I see is that these values don't get refreshed every time there is an added contract, or a transacted contracted. It appears that these get updated kind of randomly every so often. So this alone will not show you the entire picture. Do you have any insight into the frequency of the updates to this?
   
2. Volume[0]: This would be backwards looking and show the transacted volume that occurred during a period of time, specifically the bar being used 1 tick, 25 ticks, 50 ticks, etc.
   
3. Market Update Volumes: If you run these on a 1 tick chart and do not enable tick replay, then the bid side or ask side will = the Volume[0] exactly. This will give you visibility into which side had the transaction on that specific trade. So this is backward looking and not forward looking.

Part 2: Prices

1. Active Price Levels: I always assumed that GetCurrentBid() and GetCurrentAsk() would provide the most up to date price level in play. I suppose the limitation of this would be that this is only going to update and therefore be as granular as the bar size used. So 1 tick for example would be the most granular, but 100 tick for example would have a serious lag.
   
2. Market Data Price Levels: I interpret this as backward looking at the most recent transacted price at the bid or ask level. From the documentation: "If used with TickReplay, please keep in mind Tick Replay ONLY replays the Last market data event, and only stores the best inside bid/ask price at the time of the last trade event. You can think of this as the equivalent of the bid/ask price at the time a trade was reported."

So in my mind, GetCurrentAsk() or GetCurrentBid() would be leading whereas anything derived from marketdata would be historic and therefore lagging. My testing confirms this at least for volumes and the prices appear to move first on the GetCurrent events and the OnMarketData prices lag. Please confirm that I did not miss anything, and that I have this right.


Overall, from this simple script I see that the market data volumes are transactional in nature and do not represent the forward looking resting volumes, and I believe the same is true for the prices.

So as my goal here is to see the resting volumes with the most granularity possible, I suppose in order to deconstruct this the best possible method would be the following:

1. Start with the bid or ask volume present when an order is submitted.
2. From this point forward run the market data volumes to see any new transacted volume since the entry. Subtract the starting volume - the total subtracted volume to get the current remaining volume.
3. On any new subsequent updates to GetCurrentBidVolume() or GetCurrentAskVolume() you would have to take the the total from 2 above which would be your queue position and then back out any incremental new volume that was added during this next update. The goal is really not so much to measure any incremental update to the bid or ask volumes from the GetCurrent method so much as keep a running total of all transacted volume since you marked your entry volume. When your queue position = 0 you should get filled.

In the past I was measuring only from the GetCurrent() volume methods and I was running a 50 -100 tick size so I likely missed some of the granularity. I believe I now have the approach to this.

Let me know your thoughts, as I want to make sure I have everything correct. If so, I will retest and report back in a few days.

Thanks,

Ian

[NinjaTrader_PatrickH]

Hello iantg,

Thank you for your response.

GetCurrentBidVolume(), GetCurrentBid(), GetCurrentAskVolume(), and GetCurrentAsk() will pull the Bid or Ask for the bar series at the last update that occurred in real-time. This means as the primary bar series is likely the Last price then you are only seeing the Bid or Ask at the Last event. Thus you would instead pull up Ask and Bid when they actually update in OnMarketData.

You are correct on Volume[0] as it is pulling the volume of the bar series. You are also correct that Tick Replay is running off the Last price as well.

OnMarketData() will update in real time for each event the data provider provides for Market Data. Thus it is where you want to pull or assign any Bid or Ask values that need to be updated as they update in real-time and not based on when the Last price series has updated.

Your PrintLevel1Output is printing the values when OnBarUpdate() is called. OnMarketData() will be called after OnBarUpdate(). So if you want to get the real-time Bid or Ask in OnBarUpdate() then you would in fact call GetCurrentAsk(), GetCurrentAskVolume(), GetCurrentBid(), or GetCurrentBidVolume().

However, if you plan to access the Bid or Ask outside OnBarUpdate() such as in OnExecutionUpdate() then you need to be pulling from OnMarketData() which is guaranteed to have updated since the last Ask or Bid update where as the "GetCurrent" methods will have only updated on the last Last bar series update (the last tick for the Last price).

Please let me know if you have any questions.

[iantg]

Hi Patrick,

I think I have everything I need to build my testing simulation. But I just want to confirm the following:

If I want to see the resting volumes (I.E the volumes that show up on the DOM as waiting in the queue) I am aware of how to get this with the GetCurrentBidVolume() / GetCurrentAskVolume() methods. Which I now understand will print relative to the bar size selected. So the more granular your size, the more often you would see an update. But even at 1 tick size there are still going to be gaps in between each update. So In order to see the most accurate picture possible I would need to run the transacted volumes from the OnMarketData event handler and deduct these from the last GetCurrent update.

For queue positioning I just take the starting volume and then start deducting any transacted volume from OnMarketData and run this down until the cumulative transacted volume is greater than the starting volume.

I haven't played with this much, but is there any benefit to working with MarketDepth?

https://ninjatrader.com/support/helpGuides/nt8/en-us/?marketdepth.htm

Would this provide me with more granularity in updates vs. calling GetCurrentBidVolume() on a 1 tick time-frame for example?

Thanks,

Ian

[NinjaTrader_PatrickH]

Hello iantg,

Thank you for your response.

OnMarketDepth() can provide further detail at levels beyond just the Last, Bid, and Ask. This could be used to see the volume updates at different price levels.

For more information please visit the following link: https://ninjatrader.com/support/help...arketdepth.htm

We also have two examples available at the following links:

• https://ninjatrader.com/support/foru...ead.php?t=5965
• https://ninjatrader.com/support/foru...ead.php?t=3478

Please let me know if you have any questions.

[iantg]

Quick update, I am in the process of doing a side by side analysis for a few of the orders that looked strange when I tested recently. I am running the OnMarketDepth volumes and OnMarketData volumes to see the exact volumes in play when the order is initially submitted and when a fill occurs. I will likely have this done in the next week, and report back.

But in the mean time I was curious if there is a way to access the APQ variable in a strategy. This is something that I found only in the documentation relating to adding an extra column to the DOM, but I did not find any documentation relating to calling this variable from a strategy. If you could provide me some information or point me to some documentation I would appreciate it.

Thanks,

Ian

[NinjaTrader_PatrickH]

Hello iantg,

Thank you for your post.

You can review the APQ SuperDomColumn under the SuperDomColumns in the NinjaScript Editor. This utilizes OnMarketData and you can view the calculation used here for APQ.

Please let me know if you have any questions.

[iantg]

Hi Patrick,

Thank you for this update. I was able to take a peak at the @APQ.cs code and I can see a few variables that more of less get me what I need.

For example currentApqValue would be ideal to call and track from within my code, but I was not quite sure how to call this from within my strategy. Any insight you have on this would be greatly appreciated.

Thanks

Ian

[NinjaTrader_PatrickH]

Hello iantg,

Thank you for your patience.

The "currentApqValue" is calculated in the OnMarketData() function in the @APQ.cs SuperDOMColumn NinjaScript file. You can emulate the same logic in your strategy by using the OnMarketData() function.

Please let me know if you have any questions.