How to Integrate APQ variable from APQ.cs into my strategy

[iantg]

Greetings,

I have been playing around with the idea of integrating the APQ.cs class into my strategy to be able to track my queue position from my strategy. I am not 100% sure but I think the variable currentApqValue is the one I need.

I am specifically looking into the following code base: Ninjatrader8 > bin > custom > SuperDomColumns > APQ.

My question specifically is this:

1. Is there any way to call this class and the containing variables directly from my strategy via a reference of some kind? This would be ideal, I just don't know the syntax to use. For example if I just try to call currentApqValue from my strategy with nothing else, this will not work. If you could provide me with a working code snipit of calling this APQ.cs class via a class, or function reference I would appreciate it.

2. Alternatively, if calling this from a class reference is not possible would I have to reverse engineer the entire APQ.cs code and more or less just copy all of this into my strategy.

I have not found any documentation whatsoever regarding this in the online help section, so any insight here would be greatly appreciated.

Thanks,

Ian

[NinjaTrader_AlanP]

Hello iantg,

Thank you for your note.

The logic for Approximate Position in Queue is proprietary or protected source code.

I will submit a feature request that his be available.

In the meantime you could consider writing your own, which would require you save the quantity before your order was placed at that price then subtract for the volume traded at that price. The following sample may be helpful for pulling book quantity.

https://ninjatrader.com/support/forum/showthread.php?t=5965

If the contract you were applying the study to was ProRata, the logic to estimate your place in the queue would be more difficult.

Please let us know if you need further assistance.

[iantg]

Alan,

Thanks for reaching out and providing the explanation below. I suppose I will work on reverse engineering the logic. The only follow up question I have is this.

When marking the starting bid or ask volume what should be used exactly. I am enclosing a file where I have printed from both the OnBarUpdate method as well as the OnMarketDepth and it appears that the OnBarUpdate method is front running, and the single value that is collected for the bid volume and ask volume can be found within a larger data set from the OnMarketDepth data. In the attachment I show that the OnBarUpdate data shows a bid volume of 113 and ask volume of 364 when the ask price moves down from 2801.75 to 20801.5.

Now to capture when this price change occurs exactly within the OnMarketDepth population you would need to look down to row 47. This is where the ask price level changes and starting ask volume is 35.

If you continue looking down to row 187 you will find the exact matching Bid / ask price and volume that was picked up from the OnBarUpdate on row 19.

So here are the possible options and the obvious conclusions that I am drawing.

1. If I mark the starting volume based on the OnBarUpdate I would perhaps be getting an accurate starting point that is not lagging, however to measure any volumes that have transacted after this, or canceled after this, it would be tricky. For example at the time that the bar update occurs the corresponding rows from the OnMarketDepth, and OnMarket data are still on old price levels so any data picked up here would be incorrect.

2. If I start marking the starting volume based on the OnMarketUpdate where would I start from? I ask this considering that often times there is a lag between the OnBarUpdate method running first and the OnMarketData method running second, so if I picked a starting volume from this side, I might actually be on the wrong price level, or assuming I got in line at the very start of the of the line right after the price changed. For example row 47.

3. What I am thinking is the right approach is to run all of these three events separately and not try to synchronize them because they are not even going to be in sync. I would take the starting volume from the OnBarUpdate, and then using Market Data I can start collecting transactions that occurred on the applicable price level, but I have no way to determine when I was entered into the queue, because some of the transactions will have occurred before I entered. I could attempt to match my volume from the OnBarUpdate method to the OnMarketData method and consider applicable volume as only volume beyond this match. (For example row 47 = row 187).

As you can imagine none of this sounds like good options, or even in some cases logical. Although I realize you can't provide me with anything proprietary that would revile your SIM engine logic, or queue positioning logic, I do need some direction integrating these methods because they are not in sync.

In my mind, the OnMarketData being the most granular should be the first event to capture a price change and the OnBarUpdate should occur as just a snapshot in time that can be instantly synchronized with the OnMarketData feed. But this is not the case.

Maybe this is something that I can request as a feature request. I think being out of sync makes this very challenging to track.

But any advice, thoughts or feedback would be greatly appreciated. I am happy to share the code I used to create the attachment if you would like to see it as well.

Thanks,

Ian

Hello iantg,

Thank you for your note.

The logic for Approximate Position in Queue is proprietary or protected source code.

I will submit a feature request that his be available.

In the meantime you could consider writing your own, which would require you save the quantity before your order was placed at that price then subtract for the volume traded at that price. The following sample may be helpful for pulling book quantity.

https://ninjatrader.com/support/forum/showthread.php?t=5965

If the contract you were applying the study to was ProRata, the logic to estimate your place in the queue would be more difficult.

Please let us know if you need further assistance.

[NinjaTrader_AlanP]

Hello iantg,

OnBarUpdate would not be the place to do it, as the book can change without a new bar, regardless of what the Strategy/Indicators Calculate settings are set to. A new tick is required to trigger OBU with Calculate set to OnEachTick.

In my opinion you would want to save the quantity working at X price to a variable the moment your order is submitted, and shift your implied place in the queue down for each trade at that price, all within OnMarketDepth.

You could pull this value from OnBarUpdate and it would be in sync at that moment.
If you’d like I can have someone reach out with a list of third parties that would be interested in working with you on this.

Please let us know if you need further assistance.

[iantg]

Alan,

Thanks for the update and I appreciate you providing feedback on this. I have no issues doing the coding myself, I just need some clarification on the point you made below.

Which event handler am I calling this from.

OnBarUpdate: Leading, and possibly real time but missing granularity.
OnMarketDepth: Lagging, when I submit my order, I might still be getting updates from an old price level.
OnMarketData: This covers transaction volumes not resting volumes.
OnOrderUpdate / OnExecutionUpdate: (Within these methods I could call GetCurrentBidVolume() or GetCurrentAskVolume() or I could call volume from the level 2 data via OnMarketDepth.

In my opinion there are problems with all of these because of the timing and lag, but suspect that the OnBarUpdate Variables of GetCurrentBidVolume() and GetCurrentAskVoume() are the only real time snapshots, MarketDepth can be lagging and on prior price levels even. So maybe calling the volumes when my order goes into a state working via one of the order related event handlers and getting the volume via the bar methods would be the best approach.

Could you give me some direction on this.

Ian

Hello iantg,

In my opinion you would want to save the quantity working at X price to a variable the moment your order is submitted,

[NinjaTrader_AlanP]

Hello iantg,

You would want to pull the order book information from OnMarketDepth.

Please see the following section of our helpguide for information on this method,

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

I also provided a link to a sample in my second post which demonstrates how you can pull and print order book information.

Please let us know if you need further information.

[iantg]

Alan,

Thanks for following up with me. I am likely covering a more complex scenario. I think what you are advising about just going to the OnMarketDepth and tracking volume.... will work fine and be an easy to implement solution for any pending orders that are on resting price levels N number of levels out from the current price level which is being transacted. I figure I can implement this in a day or so just working with OnMarketDepth and building some assumptions around which cancellations I get credit for to move me up in line vs. which cancellations may have came after I joined the line... This part is all fairly easy.

What is far more complex is when I join the queue on a level that is in the middle of being transacted. I was hoping for some help in this particular scenario. If I jump into a price level that has already had x amount of transactions and considering that the OnMarketDepth is lagging behind the BarUpdate GetCurrentBidVolume() and GetCurrentAskVolume() where should I mark my starting volume. Is this going to just be CurrentBid, CurrentAsk using the Get methods? I could use the volumes from OnMarketUpdate but they are often lagging behind and in many cases can actually be on an old price level, so any help with this special scenario is really all I still need clarification on.

Thanks,

Ian

[NinjaTrader_AlanP]

Hello iantg,

OnMarketDepth is called for every change in level one data, on OnBarUpdate is called on every new tick assuming Calculate is set to OnEachTick. Lets assume at a moment in time, no trades are made, nothing is changed in the order book except a 1 lot 3 off the best offer is canceled. OnMarketDepth will pick up this change where OnBarUpdate will not. This is why I suggest working in OnMarketDepth, and not doing anything in OnBarUpdate.

Please let us know if you need further assistance.