Liquidity tracker

From Bookmap
Revision as of 19:12, 1 February 2019 by Serg (talk | contribs) (Created page with "Liquidity tracker is a new indicator developed by Bookmap. It was developed using Bookmap API, which means it could have been developed by anyone else. The indicator display e...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Liquidity tracker is a new indicator developed by Bookmap. It was developed using Bookmap API, which means it could have been developed by anyone else. The indicator display either sum or average of liquidity on bid order book, ask order book, and their difference, which represents the imbalance between buyers and sellers. Traders can configure how much / deep of the market depth should be accounted up to the entire full market depth. It's also possible apply higher weights for price the levels near the market and lower weights for the price levels far from the market.

Simplest case of 10 price levels

If we set the following configuration, the displayed values are:

  • Bid Liquidity is the sum of sizes of all Buy orders at first 10 levels of the Bid book
  • Ask Liquidity is the sum of sizes of all Sell orders at first 10 levels of the Ask book
  • Liquidity Diff is Bid Liquidity minus Ask Liquidity, i.e. the imbalance

Average versus Sum

Suppose that we frequently change the number of price levels to be accounted, for instance from 10 to 50, then to 30, and so on. Using the sum as the output doesn't give us an easy measurement of whether the order book is more dense near the market of farther from it. This can be solved by choosing the output to be displayed as the average per accounted price levels. Now, if, for instance, Bid Liquidity of 10 levels is higher than Bid Liquidity of 30 levels, we know that the bid book is denser near the market. In case of uniform computation mode of N price levels, the average is division of the sum by N. In more complicated computation modes the division factor is computed differently, but the principle is the same.

Avoiding illusionary imbalance

Traders should be careful with interpretation of imbalance when computation mode selected output is sum, here is why. Consider the following hypothetical example: Exchange allows orders to be placed only between prices 2600 and 2700. Imagine that it just so happen that the size at each price level is precisely 100, so by definition there is no any bid/ask imbalance. Still, when price moves up, the imbalance will show order book imbalance in the same direction. This happens simply because there would be less ask levels. In fact, the imbalance would show 100% correlation with the price, but it's obviously a useless signal. The situation of a fixed range of permitted prices isn't purely hypothetical. It's a common practice for most of the exchanges (including CME) to set price limits, therefore this illusion will manifest itself when the sum is computed over full market depth. If market depth data contains only N price levels, then the fixed price limits will be created by the extended order book.

Exponential weights

TODO: justification of exponential weights to compensate on the impact of edges

Sigmoid weights

TODO: justification to limit the number of price levels that has any effect