# Difference between revisions of "Liquidity tracker"

m (→What is liquidity) |
m (→What is Exponentially weighted mode and why to use it) |
||

Line 43: | Line 43: | ||

[[File:Exponential_decay.png|right|380px]] | [[File:Exponential_decay.png|right|380px]] | ||

− | 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 [https://en.wikipedia.org/wiki/Exponential_decay 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, | + | 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 [https://en.wikipedia.org/wiki/Exponential_decay 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, a nice property of exponential function allows to compute efficiently without degrading the performance. In fact, it's faster than, for instance computing the liquidity of just 10 price levels uniformly. |

== What is Sigmoid weights == | == What is Sigmoid weights == |

## Revision as of 10:05, 29 April 2019

Liquidity tracker (LT) is a new indicator developed by Bookmap. It was developed using Bookmap API, which means similar indicators can be 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

## What is liquidity

When traders say, for instance, "There is a high liquidity at price 52.45 on Ask (aka Offer)", it simply means this: The total size of Limit Sell orders at 52.45 is large. With reference to the image above, we can see that the total size at 52.45 is 112 and it's significantly larger than average size at price levels.

In finance, the synonym of liquidity is mobility, and shouldn't be confused with liquidity as a physical property of a substance (e.g. fluidity). This originates from the ability to quickly buy and sell an asset at nearly the same price, i.e. with low risk and loss during this process. This also means the ability to liquidate / flatten the position. Such ability improves when:

- There is a quick and easy access to the market to buy and sell the asset
- Low commissions
- Low Bid/Ask spread
- Large enough quantity at Bid and Ask (the asset may be considered liquid by one trader, but not liquid by another who trades with much larger amounts)

Typically, the first two conditions automatically lead for the other two due to competition between Market Makers who aim to profit by placing limit Buy and Sell orders simultaneously.

In the context of Liquidity Tracker, we use the simplest definition of liquidity, which is the size of Bid and Ask limit order book. Because the order book consists of limit orders, it tells about the changing intention of traders to buy and sell at particular price levels and in general.

## 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, a nice property of exponential function allows to compute efficiently without degrading the performance. In fact, it's faster than, 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.