Yes, you are correct when you suggest that the Depth of Market is a "dumpster fire with intent to deceive" or something like that. Spoofing is one of the Major techniques used, which prevents anyone from "eyeballing the DOM" and getting any useful information out of it.

So when you Analyze Quote Sizes on a specific Price; the very first thing you want to do is to defeat most of the Spoofing. Here's a Hint: If MM really wants to transact with the Retail population of traders; then MM will not "pull" quotes, but will maintain them in order to gain the "FIFO matching engine advantage". So, watching the MINIMUM sizes advertised (perhaps for only a few milliseconds) versus the AVERAGE or MAXIMUM values; is the key to getting a Proxy for the concept which estimates MM's "eagerness" to transact with the Retail Market.

By using these "size minima" you can then begin to look at the DISTRIBUTION of Quoted Size near the Market. You'll find that the Distribution of Volume Weighted Price, expressed in a snapshot as "delta ticks (tiers) from the inside market" will be CLOSER to the Market on the SIDE WHERE YOU WILL PREDICT THAT PRICE IS MOVING.

iN SIMPLISTIC TERMS: "When they really want to 'pull the inside market' to their Quote, then they will hold the Quote stable; and will Distribute their Quoted Sizes nearer to the Market". ...or something like that...

This stuff really works, but "the Devil is in the excruciating Details", as always.

hyperscalper

If I told you, I might be asked to kill you... Just kidding.

So, the basics apply here. MM-Buy transactions are (by my definition) Trades which take place at the BID;
and MM-Sell transactions at the ASK/OFFER Price.

Any time MM can Buy from a Retail Seller at the BID price, and then Sell that same quantity higher up
in price (even if it's only 1 minimum Tick) then that is MM profit, and that Size is eliminated from the "open inventory".

So, to answer your question, when being evaluated for LONG Inventory,
if MM Buys 10 and then ANY MM Sell at A HIGHER PRICE, like your 2 Trades of 5 each occurs,
then that Inventory is neutralized, profit is taken and it is no longer MM Open Inventory.

Let's say MM buys 10, and there's a higher price trade with size 15; then the 10 contracts are
eliminated (neutralized) and that higher Priced Trade (for purposes of the analysis scan)
is set to 5 remaining, since 10 was used to match the MM-Buy.

For a LONG Inventory scan; using the term "Long" loosely, but meaning MM has more BUY
transactions in Inventory than Sell transactions, remembering that we SORT/ORDER the Buy
list and the Sell lists. So these lists would be sorted in ASCENDING order; and then you might
think we could start with the LOWEST BUY Transaction, and then "borrow volume" from any
just higher SELL transactions (eliminating that BUY from Inventory, as closed profit)
proceeding up the BUY Orders, and eliminating them, when their Size can be "borrowed"
from higher Priced Sell Orders.

You might think that would be the way to do the Matching. HOWEVER, I prefer to start with
the HIGHEST BUY transaction and proceed downwards in Price, finding any higher priced SELL
transaction whose volume can be "borrowed or matched" with the BUY transaction, in order
to eliminate it from inventory. BUT WHY?

In this way, I will attempt to eliminate HIGHEST priced BUY orders (remember, we are evaluating
here for a "LONG" MM Net Position) and then LOWER priced BUY orders may remain
unmatched. THIS ALLOWS ME TO UNDER-ESTIMATE MM'S COST BASIS.

I WANT TO UNDER-ESTIMATE MM'S COST BASIS because if Market Price is below that
under-estimation; it is MORE LIKELY that MM is "in risk" or "losing money" on the
Net Open Inventory estimate. So I am more confident when I say "MM is in Long Risk"
and is less likely to want to lower the price further. If I had a higher estimate of
MM's Cost Basis, then I'd be less confident that MM was "in Risk" than if I use an
algorithm which under-estimates (estimates a lower price) for MM's Cost Basis. Savvy?

hyperscalper

"delta ticks (tiers) from the inside market" - not sure what this is - is it the difference in ticks in the spread?

You can get MBO data with Bookmap. I looked at it, didn't spend a lot of time on it so not sure what the true value is. Might be interesting to start a thread where traders who are using MBO can contribute.

I think I could write it in bookmap. I'm just not really in a spot to invest in a new platform, and there's some execution based edges that I don't think I can get over there. If there's a way to get around that I'd be interested in helping write it in Bookmap. Maybe though I'm just enamoured with the idea of writing something that touches the API directly? We're talking about some things that are fairly calculation and memory intense. It would probably be better to have such analysis in a different application from the application you are using to execute from. The Ninjatrader 8 - Jigsaw combination is perfect for it. Too bad ninjatrader doesn't have MBO data.

Can't you get it from Rithmic and funnel it through Ninja 8? I thought there were options for different datafeeds.

Unfortunately, I learned "the hard way" that Ninja does not have a setup for a Rithmic Data Feed. You must take the entire Rithmic Order Routing and Data Feed package, and that invalidates your usage of their CQG broker.

Of course, nothing stops you from coding your own C# to the Rithmic API and feeding that data into your Indicator(s) but it would not be "natural" through the Ninja Framework for datafeed only.

Yes, they market their Kinetick feed as a "feed only" option. But that's a "business decision" and they have no such feed only arrangement with Rithmic.

By using the Rithmic API, no doubt you could get "deeper" into things like MBO (whatever that is...) but unfortunately that could not be integrated as an "officially supported" NinjaTrader Connection adapter; as they simply do not support such a thing; and you'd have to Beg, Borrow, Bribe or Steal the code which could be used to write a proper Connection "snap in" to NinjaTrader 8... <speculation>

hyperscalper

Do not want to pollute the thread but for the sake of explanation of MBO, you can find it here:

Historical market depth and MBO data: Assess your latency, data and execution quality I decided to start a thread to provide some samples of historical market depth and MBO data to consolidate a solution for different questions on execution quality, data integrity and latency. My main goal is to encourage more latency transparency and …

Time for a new platform!