hyperscalper 

OK, I'll try to explain this without going into code. So you are retaining a record of ALL trades which cross the Time and Sales, and you are of course able to categorize them from some original sequential trade list, into 2 lists, the MM-Buy list (Retail sales to the BID) and the MM-Sell list. All of these items are, of couse, timestamped but in calculating Buy/Sell volume pairings, the time order is not important since you can clearly Buy, then Sell; or Sell, then Buy and so Inventory Evaluation is not done in time sequence. However, it is ALWAYS done with a particular Timeframe subset of the action, for example, all Trades for the past hour. Once you have these 2 lists for the past Hour, all within the same time range, you'll need to make a determination whether there is more MM-Buy activity than Sell activity; and decide to call the Inventory "Net Long" or whether the opposite is true, so you call the Inventory "Net Short". Having made this determination, then... ...if "Net Long", then Sort both lists lowest to highest price; and if "Net Short", then Sort the lists highest to lowest price. Then we have to do "matching" of any MM-Buy volume, and eliminate it, by finding MM-Sell volume at a higher Price. From the MM-Sell entries, most of the time, we'll be able to find enough Volume to match each MM-Buy volume entry, with 1 or more MM-Sell entries at the higher Price levels. The current MM-Buy entry then has its volume set to zero (meaning it is eliminated from open Inventory) and the MM-Sell entries which gave up all or portions of their volumes are also reduced in volume, or set to zero volume by giving up all of their Matching volume in compensating for the MM-Buy entry. Thus, for "Long" inventory, we work from Lowest to Highest Price, matching EVERY MM-Buy volume unit, with corresponding MM-Sell volume at the next higher price. So, simplistically, an MM-Buy of 1 unit is compensated for by an MM-Sell entry of 2 units. The MM-Buy entry is eliminated from active Inventory (profit is taken) and the MM-Sell entry has 1 unit subtracted from its volume entry. We work on every MM-Buy, matching MM-Sell volume until we have no more MM-Buy entries, or we run out of matching MM-Sell entries, of course. WHAT REMAINS are "pure" MM-Buy transactions which DO NOT YET HAVE matching MM-Sell volume at a higher price. This is PURE LONG INVENTORY, which has been bought from Retail Sellers, but which remains to be sold off at a higher price. The Volume Weighted Average price of this "pure" MM-Buy inventory is the Cost Basis or "Price Break Even" for Open Inventory. (The inventory which disappeared during the matching process is Closed Inventory or profit-taking, and so it must be taken out of the remaining Open Inventory). So the Current Market price, as compared with the Cost Basis for LONG Inventory positions, determines whether MM is making a profit or a loss on her current Open Inventory of "pure" Long Inventory items after this process of evaluation has taken place, over the specified timeframe we said 1 hour. Obviously, you can evaluate this for ANY timeframe, and you'll find different results; or you can do them for a number of representative timeframes, at the same time, in order to have a "multi timeframe Inventory Status" which shows the Open Interest (Open Inventory), its Price Break Even (Cost Basis) and then calculates an estimate of what I call "Risk" which is Current Price versus Cost Basis. That, multiplied by Net Open Inventory volume, can give you a $$$ measure of just how much "Risk" is being experienced by Market Maker, on this timeframe, at this current time. Tedious, yes. But this is roughly the way in which Inventory can be analyzed to yield useful results, over specific Timeframes, based on actual Trades over the Time and Sales. Let's say MM has 10,000 contracts Long and would love to sell them off. Will MM then raise the Price in order to stimulate Retail Buyers, to whom she can sell these contracts??? Not necessarily. She has a Long position, sure, and it seems like a lot of contracts !!! But Market Maker operates at scale. WHAT REALLY MATTERS is when those 10,000 net Long contracts' Cost Basis is 10 Ticks above the Current Market Price, so she is "losing money on paper" temporarily. Now, we know this is all "part of the game" and that these "Risks" are not really risky, provided that Market Maker can simply raise Price and get out of "Risk" and into "Profit" quite easily. But RISK (losses on paper) are not a situation which MM prefers, so there is a strong motivation to reduce that RISK level or control it. This is a DYNAMIC situation, as you can appreciate. There are several ways MM may be able to shift Cost Basis and control Risk, in addition to modifying the Inventory mix. This is why any simplistic Analysis is inadequate. Hope this gives some idea of the calculations which could be done to evaluate Inventory and "Risk" meaningfully, so that we could use this "situational awareness" and factor it into our trade decisions. So, if we are at a "Support" level (is that a real concept?) then if we are strongly into "Long Risk" we predict that the Support may appear to break, but it is far more likely to hold. I'm sure you can work out the Short Inventory evaluation methodology, since it is just the opposite of Long inventory. [EDIT] Imagine if you find that MM is in $100,000 Risk (small, unrealistic, but for example) so, dang, but consider that in your matching process (every Buy/Sell volume match generates revenue) and maybe that Revenue is $150,000 that has gone into her ample pocket !! So this "dynamic" situation can be seen to be even slightly more dynamic, since Revenue has compensated for Risk losses on paper, at least at this point in time. She's making high Revenues, so maybe the Risks are not immediately a big deal... LOL Revenue could be characterized as $$ per minute of the entire Timeframe Interval, for example. $150k/60= rev. per minute? Rate of getting Rich for aggregated MM in this situation ! lol of course these are estimates... [EDIT] So, I ask "Why are support and resistance price levels so important?" one reason is that they generate a trading battle, and generate... wait for it... MORE REVENUE to MM. She loves to linger there for a while ! LOL [EDIT] At this time, it looks like ES is trading at around $25,000 per minute Revenue, but I didn't see how to post the image. hyperscalper

If an answer gets to be very complicated, it is usually wrong. The simple answer is usually the correct one.

datahogg 

If an answer gets to be very complicated, it is usually wrong. The simple answer is usually the correct one.

All due respect, Sir; but that is very wrong, although it may be comforting for you to think that simplicity is the answer.

hyperscalper

Here's how I define and utilize "order flow"




>"Footy" with the profile on the left chart & bid vs ask on the right. (Shows volume at price)

This view I call my lower timeframe and its very helpful. (I use 3 timeframes: daily market profiles + "my trading time frame": renko bricks + "LTF")

>Nuggets:

*The white line is the point of control (most volume in that footprint).

*The black lines are the highest volume, lighter color = less volume.

*Sometimes you can see absorption which is sometimes a temporary top or bottom. Using numbers footy you see price moving up then plateauing, there's a 0X300 bid/ask at 3361.25 for example, and then price goes down a few ticks, comes back up for another test and then it changes to a higher value like 0x500, somebody just absorbed 200 contracts.
(its not a guarantee price would go down in that situation, it could be getting absorbed for another move up, do a fakeout, etc . it supports trade ideas)

*Imbalance is when you see something like 200x600 , 487x163, (I set the pink dots for 300% on the bid or ask, some people prefer 200%)

So if you're looking for accumulation or distribution at a certain level, footy confirms if a lot of volume is transacting which could support your current hypothesis for the next move. Low Volume Nodes also provide valuable info to me as they can often be a resistance area.

>Other need to know -- This info works better for me on the ES and not as well in less liquid markets like NQ, YM, RTY, (less liquid because there isn't a high amount of orders at each price level). (Eurostoxx is also high liquidity). Perhaps my skill at reading the less liquidity markets will improve but for now I'll take the easier path.

I dont look at doms, no thankyou. Trading is my zen practice, I dont need all the flashing lights.

hyperscalper 

DOM ANALYSIS requires some fast processing Case in point, ES and some discussion of NQ futures Just to give you a rough idea of how difficult Depth of Market Analysis can be, from an implementation standpoint, on the ES contract, I'm seeing as high as 500 callback events PER SECOND coming in as Market Depth changes, in a C# Indicator callback routine. So you got a couple of milliseconds on some of the peak data rates to do something, anything to capture the data. This is with an ATAS platform, and Rithmic feed and Order Routing; sitting on a dedicated server in a data center. Just to give you an idea of the challenges you would face. Basically, it's not achievable by traders, and I'd advise not to even try; unless, of course, you are one of "those driven traders" who gets his/her kicks out of trying to "tame the Beast". Just sayin'... The Dynamic nature of the DOM should be apparent from just looking at it, but in NQ in particular, the Spoofing activity reaches its peak to completely confuse traders. I'd post a picture if I knew how... It's an eye-opener... Entire sides of the DOM consist of "mega spoofing", the minimum values of which are SINGLE CONTRACTS on the DOM. But, visually, you'd probably think there was balanced size on both sides... don't be naive; of course you're not naive... For me, the real prize as I've said before is to master NQ's "take no prisoners" approach to Price movement. Quite insane, but certain fundamental aspects of it are actually predictable. I just observed the "distant or far DOM bias" remain elevated for 10 minutes prior to a 160 TICK Rally in NQ. So, as I said, and I can't offer you software; but the concept involved maybe; if you can "tame the DOM Beast" then there would be riches to be had... There's Gold in them thar Hills, but to get it out may be near impossible, so don't take such a task lightly; and in fact, don't even try it. Just sayin'... once again. hyperscalper

I found your posts very interesting. I do a lot of research on the side. There's a lot of opportunity for a good developer to come up with a new platform that captures much of what you are talking about. I'm not nuts about Ninja but I use it along with Jigsaw, doing my own analytical work in Excel. Bookmap has some advantages but in the end, I preferred my own setups.

I don't trade the NQ but I've watched the order flow. I've never come to any other conclusion except that it's a complete fraud - spoofing, pulling/placing order, crap all over the DOM. Market profile not much better. I did find that Ninza's Volume Delta was helpful to identify impulse trades (actually you gave me a good idea to study - the 1 hour long or short using volume delta). Tried to do it in sim but in the end always gave it back.

Interesting stuff. Thanks for posting.

phantomtrader 

I found your posts very interesting. I do a lot of research on the side. There's a lot of opportunity for a good developer to come up with a new platform that captures much of what you are talking about. I'm not nuts about Ninja but I use it along with Jigsaw, doing my own analytical work in Excel. Bookmap has some advantages but in the end, I preferred my own setups.

I've been doing quite a bit of programming work, and I'm coming to a similar place. I think to really do what I'd like I will need to plug into the Rithmic API directly. A lot of what has been discussed in this thread would benefit from MBO data.

phantomtrader 

I found your posts very interesting. I do a lot of research on the side. There's a lot of opportunity for a good developer to come up with a new platform that captures much of what you are talking about. I'm not nuts about Ninja but I use it along with Jigsaw, doing my own analytical work in Excel. Bookmap has some advantages but in the end, I preferred my own setups. I don't trade the NQ but I've watched the order flow. I've never come to any other conclusion except that it's a complete fraud - spoofing, pulling/placing order, crap all over the DOM. Market profile not much better. I did find that Ninza's Volume Delta was helpful to identify impulse trades (actually you gave me a good idea to study - the 1 hour long or short using volume delta). Tried to do it in sim but in the end always gave it back. Interesting stuff. Thanks for posting.

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

TWDsje 

I've been doing quite a bit of programming work, and I'm coming to a similar place. I think to really do what I'd like I will need to plug into the Rithmic API directly. A lot of what has been discussed in this thread would benefit from MBO data.

Not sure what MBO means, but I think it means identifying the individual Market Makers which form the composite Size at each Market Depth Price level.

In my experience, YOU DO NOT NEED that level of DOM feed Analysis, in order to get Predictive information from the Depth of Market. At least, I've never had it; and haven't found it necessary.

I'm not denying that "more information could be better" but my guess is that such information would not improve prediction more than roughly 10% so it's a lot of work to do; with a low probability of significant utility.

Heck, with just a simple 10 wide DOM there's a huge amount of predictability; no need to get a super expensive feed, and try to extract even more information. I really doubt it would be fruitful... even if you could figure out how to interpret it.

[EDIT] I am using the Rithmic DOM which allows for 40 wide tiers on each side of the Market. But that's because I am also interested in "distant radar" which potentially exists in that data, having already mined just about all I can from the "near DOM" tiers. But I'm not going to be delving into the MBO information, even if it were available.

hyperscalper

hyperscalper 

Not sure what MBO means, but I think it means identifying the individual Market Makers which form the composite Size at each Market Depth Price level. In my experience, YOU DO NOT NEED that level of DOM feed Analysis, in order to get Predictive information from the Depth of Market. At least, I've never had it; and haven't found it necessary. I'm not denying that "more information could be better" but my guess is that such information would not improve prediction more than roughly 10% so it's a lot of work to do; with a low probability of significant utility. Heck, with just a simple 10 wide DOM there's a huge amount of predictability; no need to get a super expensive feed, and try to extract even more information. I really doubt it would be fruitful... even if you could figure out how to interpret it. [EDIT] I am using the Rithmic DOM which allows for 40 wide tiers on each side of the Market. But that's because I am also interested in "distant radar" which potentially exists in that data, having already mined just about all I can from the "near DOM" tiers. But I'm not going to be delving into the MBO information, even if it were available. hyperscalper

The big advantage I'm primarily concerned with is the ability to determine if a market order that has hit the market was generated from a stop or not. That can be factored into the calculations to determine when losses are being taken, and could give a more accurate reading of market maker positioning. I'm also trying to study the orders in the queues themselves to see if I can get indications from them of when a trend is attracting new participants to the market.

TWDsje 

Ok that makes sense and answers one part of my question. The second part had to deal with how do you match orders up. If you are just adding and subtracting all the orders that hit then you basically get cumulative delta. But it sounds like you're looking for the lot size to match up exactly? So if mm bought 10 at one level and sold two 5's at another level since the size didn't match up you'd still say there's 10 net long and 10 net short?

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

TWDsje 

I've been doing quite a bit of programming work, and I'm coming to a similar place. I think to really do what I'd like I will need to plug into the Rithmic API directly. A lot of what has been discussed in this thread would benefit from MBO data.

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.