Liquidity Tracker
Short description
Liquidity tracker (LT) shows the current state and historical view of the Bid and Ask liquidity in the entire market depth (limit orders), allows to filter the orders by their size, can instantly recompute the data and more...
Installation
Technical details: download the add-on's jar file either from the download section in your marketplace dashboard or using the direct links of LT-Pro and LT-Free. In Bookmap click Settings -> Addons -> Add, and add the jar file.
Description
Liquidity tracker (LT) is a tool for traders to adjust their strategy with the market liquidity and its evolution over time. Its main features are:
- Smooth representation of the Bid and Ask liquidity in the entire market depth with higher weights assigned to closer price levels (it computes the entire market depth weighted with configurable exponentially decaying weights) Liquidity imbalance
- Filter the market depth orders by their size. This allows to distinguish (presumably) "smarter" larger orders which belong to more informed traders from the rest of the liquidity that consists of smaller orders (see more details below)
- No lag. Instant computation and display of each update whenever it happens (no bars, etc) Quick historical re-computation. When settings are changed by the user, it will displays the results on all the data collected since instrument subscription
- High performance . LT processes millions of market data events per second on a regular laptop. This allows to recompute the indicator instantly whenever user changes its settings
Math
We have received requests to show the formula of liquidity computed by LT (thanks, Jayme).
- Let's denote price levels of market depth pi, and the sum order sizes on it: qi. Note that the following 'halflife' parameter appears in the add-on's UI as 'market depth' (for simplicity). The best bid and best ask are considered zero price level and appear in the formulas as p0. The liquidity computed by LT on each side of the order book (the two lines called LT-Bid and LT-Ask) is:
- If the checkbox "compute in money units" is selected, LT multiplies the quantities by their price depending on price level. This may be useful when looking at a very wide range of prices because it neutralizes the distortion caused by the fact that [almost] anyone can place a Buy order of size 1M BTC at price 0.001, but few can place such large Sell order.
- If the checkbox "average per price level" is selected, LT normalize the result by the sum of weights (as if all price levels have size exactly 1). Note that in this case it's important that such the denominator runs only over non-empty price levels.
- If both checkboxes above are selected, the formula is:
Remarks
Half-life parameter is the exponential decay rate. The weights assigned to price levels is always 1 for the best price (because exp(0)=1), and gradually drops by half every half-life price levels.
Note that the distance between prices is in units of minimum price increment, thus it's always an integer. But decimal decay rates are valid, e.g. 3.5 or 1e7 (effectively, the latter would sum up uniformly the sizes of all price levels)
In practice, the number of price levels on each side isn't infinite. It may be thousands, or billions (on some digital currency exchanges) or even limited to 10-20 levels by a data vendor (which is more typical for futures). Also, in practice, LT computes the formula dynamically (thanks to a couple of math tricks and much bigger effort to make it work in real-life conditions), i.e. just one computation per each data update anywhere in the order book. Otherwise, iterations over high number of price levels would degrade performance.
Exponentially weighted liquidity also solves a typical problem with uniform sum of N price levels. Imagine a large order on the last Nth price level and the best price starts flickering by advancing and retreating just by 1 level (this happens all the time and at high rate). The large order doesn't move, but the impact of it being added and removed (as it leaves and enters the scope of N levels) is identical to such order being frequently added / removed at the best price or in front of it. But for an observing trader these two situations are very different.
Tips
In many cases while the general liquidity imbalance is flat, the imbalance between large orders is very well noticable and may indicate a kind of 'alignment' of intentions of larger traders. Images LT-03 vs LT-04 and LT-05 demonstrate such a case around the time 15:00. Without the order size filter the bid size reaches x2 times of ask size. But after filtering out orders below size 5 or 10, this ratio becomes x10. This indicator doesn't imply that the price will always bounce from larger liquidity. It's a tool that presents essential information, not a decision maker. There are many other ways to use it not covered in this description, for instance:
You can use both min and max order size filter to account only the orders of specific order size (e.g., perhaps these are your orders of a particular size 42)
You can set a high value to the market depth parameter, e.g. "1e6" (1 million) so that effectively all levels will be summed with uniform weight 1 and see the total size of the entire market depth. Notice, however, that the result may mislead because of two factors:
Most non-crypto exchanges set price range limits per instrument that determines where the orders are allowed to be sent, for instance, between 2000 and 4000. Therefore, naturally, when price moves up, the sum of all Sell (Ask) orders is expected to decrease and the sum of all Buy (Bid) orders — to increase. This is expected if the order book on both sides is completely uniform, identical. In reality, it's not, but this effect adds up to the resulting view
The USD worth of orders at lower prices is lower that of those at higher prices
Without order size filter
With order size filter at minimum 5 contracts
With order size filter at minimum 10 contracts
Limitations
Both LT Pro and LT Free support any instrument with MBP -- market-by-price depth data. Today, all connections including stocks and crypto provide MBP data. But the order size filtering feature (which is the only difference of LT Pro) works only with CME Futures with Rithmic connection. To clarify, this feature will NOT work with:
- Non-CME data by Rithmic, e.g. Eurex futures
- CME data not by Rithmic, e.g. CME futures by CQG
- Anything else except CME futures by Rithmic
Direct download links
Note: LT Pro allows to apply computation only on orders of specific size or range of sizes. Notice the limitations above.
Versions changelog
3.2.1
Note: Some of previous updates were dropping the previous settings, and we were alerted about the huge effort required to reconfigure it on all instruments. We will minimize such cases as much as possible in future. However, in this case, dropping previous settings was unavoidable in order to fix the problem
Published on 30-Oct-2020.
- Fix: a crash when loading add-on version 3.2.1 after using 3.1+.
3.1.0
- TBA
2.2
Published on 26-May-2020.
- Fix: a false alarm about non-MBO data
- Fix: Negative values of Bid or Ask (due to computation error in special cases)
- Improvement: updates notification mechanism (see status in the settings panel)
2.3
Published on 01-Jun-2020.
- Fix numerical errors causing negative sizes when order book is cleaned
- Performance improvement
2.5
Published on 04-Jun-2020.
- Fix: Another, solid fix for negative sizes
- Fix: Proper detection of presence of MBO data. It caused false alarms about absence of MBO data
- Minor improvements and refactoring
- A known bug: the state of the checkboxes near order size filters isn't preserved