# Difference between revisions of "Liquidity tracker"

(→Installing Liquidity Tracker) |
(→Simplest case of 10 price levels taken uniformly) |
||

Line 19: | Line 19: | ||

In this mode the 3 outputs represent the following: | In this mode the 3 outputs represent the following: | ||

* The uniform sum of sizes at first 10 price levels of Bid. This is the Bid Liquidity | * The uniform sum of sizes at first 10 price levels of Bid. This is the Bid Liquidity | ||

− | * The uniform sum of sizes at first 10 price levels of Ask | + | * The uniform sum of sizes at first 10 price levels of Ask. This is the Ask Liquidity |

* Bid Liquidity minus Ask Liquidity. This is the Liquidity Imbalance. If the checkbox "Display imbalance as percentage" is selected, the imbalance is normalized (divided) by the sum of Bid and Ask liquidity and multiplied by 100, thus producing output in the range from -100% to +100%. | * Bid Liquidity minus Ask Liquidity. This is the Liquidity Imbalance. If the checkbox "Display imbalance as percentage" is selected, the imbalance is normalized (divided) by the sum of Bid and Ask liquidity and multiplied by 100, thus producing output in the range from -100% to +100%. | ||

## Revision as of 18:14, 15 February 2019

Liquidity tracker (LT) is a new indicator developed by Bookmap. It was developed using Bookmap API, which means similar indicators could have been developed by anyone else. It shows the current values and their evolution over time of liquidity at bid order book (consists of limit buy orders), ask order book (consists of limit sell orders), and liquidity imbalance which is simply the difference between the two: bid minus ask. The indicator is displayed on the sub-chart while its current values are displayed in the widgets panel. Liquidity tracker allows traders to configure how exactly the liquidity should be defined (including the ability to account entire full market depth), and to configure various display and post-processing options.

## Contents

## Installing Liquidity Tracker

Like any other add-on developed with Bookmap API, Liquidity Tracker is a jar file. Download the latest jar file here: https://bookmap.com/addons/LT. Make sure you have the latest Boookmap installed (7.0.0 build 66 or above). Click Settings->Api plugins..., then click "Add", and select the jar file. For a more detailed guide on how to install an add-on, click here. Once loaded and enabled, the indicator should appear on the sub-chart and the widgets panel, and its settings should look like in the image below.

By default, LT is configured to display the weighted average of sizes at all available bid and ask price levels. The price levels of Best Bid and Ask get the highest weights. The weights of price levels farther from the market decay exponentially. The default decay rate (i.e. the half-life distance where the weight drops to 50%) is 10.

In order to review all other available computation modes, let’s start with the simplest (not the default) case. in which the liquidity presented as a uniform sum of sizes at first 10 price levels.

## Simplest case of 10 price levels taken uniformly

In this mode the 3 outputs represent the following:

- The uniform sum of sizes at first 10 price levels of Bid. This is the Bid Liquidity
- The uniform sum of sizes at first 10 price levels of Ask. This is the Ask Liquidity
- Bid Liquidity minus Ask Liquidity. This is the Liquidity Imbalance. If the checkbox "Display imbalance as percentage" is selected, the imbalance is normalized (divided) by the sum of Bid and Ask liquidity and multiplied by 100, thus producing output in the range from -100% to +100%.

The corresponding configuration is shown on the right side.

## The sum vs average per price level

There are two potential flaws with computation of liquidity as a sum of sizes. 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. The sum of sizes at corresponding amount of price levels doesn't allow easily to compare (i.e. without additional manual computation) the liquidity near the market with that farther from the market. 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 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.

Another reason to display the output as average per price level is to avoid potential illusionary pattern, described later on this page.

## What is Exponentially weighted mode and why to use it

Suppose that our computation mode is 10 levels uniformly, and suppose that at certain moment the size of 11-th price level is significantly large. Now, if price fluctuates just 1 tick up and down, that large price level significantly affects the output by getting in and out from the computed range. Indeed, that price level is important, but it would appear as if a minor change in the current price is that much important. To solve this problem, we can assign higher weights for near the market price levels, and lower weights to farther levels. A natural way to achieve that is using the exponentially decaying weights. This makes the impact of that price level much smoother when price moves towards or away from it. The first level is always given the maximum weight=1 (100%), and the weights of price levels farther from the market will drop gradually. The parameter of exponential mode in Liquidity tracker corresponds to half life distance. For instance, if set to 10, then the weights will drop by half every 10 price levels. In this computation mode Liquidity Tracker always computes over all available price levels. But at the distance of, for instance, 10 half-life distances, the weights are 1/2^10 = 1/1024 = 0.1%, so the impact of those price levels is negligible. Although the computation takes into account full market depth, it's done efficiently and doesn't degrade the performance. In fact, it's faster that, for instance computing the liquidity of just 10 price levels uniformly.

## What is Sigmoid weights

Another way to make the impact of far from the market price levels more gradual is to use the so called sigmoid computation mode (here sigmoid is a nickname, not the mathematical sigmoid). It allows to set 2 nodes that define the shape of the weights:

- Uniform weights 100% until node #1
- Linearly decreasing weights from 100% to zero between node #1 and node #2.

This mode also allows to set weights precisely zero starting from the distance defined by node 2.

## Advanced tips and tricks

### Computation complexity

The indicator computation takes little CPU resources. The most efficient computation modes are exponential and uniform with full depth checkbox selected. In other computation modes (uniform N levels and 'sigmoid'), the CPU time is proportional to number of accounted price levels.

### Indicator's lag and temporary smoothing

By default, there is no lag. At each moment the indicator displays the liquidity and its imbalance based on the state of order book (market depth) at the same moment. To be precise, there are just two causes of temporary lag:

- Computation frequency settings. For instance, if set to 200 milliseconds, then the lag is between 0 to 200 milliseconds, plus the latency from the exchange.
- Smoothing the lines obviously adds a lag. In effect, like any other moving average indicator, it displays the average value for the moment T/2 ago where T is the selected smoothing parameter, i.e. sliding window.

### Filter by order size

The future version of Liquidity Tracker will include an ability to filter by order size. This filter allows to define which orders participate in computation. Because this feature requires precise market-by-order (MBO) data, it will be enabled only with CME data by Rithmic. The computation is applied on actual sizes of orders, but the filter is applied on maximum size of order during its lifetime. See more details here: Order size of passive orders.

### Avoiding illusionary imbalance

Traders should be careful with interpretation of imbalance when computation mode is full depth and selected output is sum, here is why. Imagine that orders are allowed to be placed only in a fixed price range, e.g. between 2600 and 2700. Imagine also 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 feature which keeps last known values outside the reported price range.

### Interpretation and trading techniques

The indicator provides true measurements of liquidity, but it isn't a buy / sell signal. Its interpretation is the art of trading. Let's assume a significant imbalance where the bid liquidity is much higher that ask liquidity. If new aggressive orders are equally distributed between buyers and sellers, the price is likely to move up, i.e. following the least resistance path. But if there are market participants who wish to sell and look for high bid liquidity, then the price may go down.

## Feedback

You are welcome to give your feedback on the forum: https://www.bookmap.com/forum/viewtopic.php?f=3&t=148

## Price

Liquidity tracker is free for all Bookmap users at least until 01-Apr-2019.