TimeMatch Examples

TimeMatch Examples

Sep 5, 2012. | By: Fil

Here are some examples of how the TimeMatch public order book would work. You may want review the premise of this design in the previous posts, as well as the terminology. The following key is used to interpret the status of various orders in the examples:

Order Status: Cancel Uncertain Improvement Notes
Quote Yes Yes Yes Uncommitted quote
Potential Yes Yes Yes Potentially matching against another order, if the market is stationary.
Hopeful (taker) No Yes Yes Taker is committed to the auction, could be removed if another taker offers price improvement.
Auction (maker) No No Yes Order will match against the opposing taker (Hopeful order) or at another improved price.
Trade No No No Order is executed and complete on both sides

A: Status quo

We'll start with a simple example that shows the way the public order book works today - ie. instant execution with no auction period:

The notation for bids: Party (Time) Price, asks: Price (Time) Party

  • Party: the counter-party owning the order
  • Time: the length of time that the party wishes to participate in auction, after price overlapping
  • Price: limit price of the order
Time Buy Sell Trade
0.000 10 (0) Z
1.000 X (0) 10 10 (0) Z Z X @ 10
1.000

The above table shows an order book a seller "Z" showing an order which is matched instantly by "X". Both parties are asking for instant execution - denoted by "(0)" in both cases which means the auction time period is zero. The "10" is the price in both cases, so we have the simplest of trade matches.

B: Slow liquidity provider

Time Buy Sell Trade
0.000 10 (1) Z
0.001 X (0) 10 10 (1) Z
1.001 X (0) 10 10 (1) Z Z X @ 10
1.001

Here we have a mismatch of time periods: the seller wants to trade on a 1 second auction, whereas the buyer wants to trade instantly. In this case, since the market is stationary, the order book will match them up as nothing has occurred in the intervening second. There is no 'auction' per-se in this situation, and someone could have jumped over the top of buyer "Z" at any time up to the match. This type of "stationary non-auction" scenario is present to merely provide natural liquidity between investor types when nothing is moving and there is no additional time period risk to the liquidity creator.

C: Fast liquidity provider

Time Buy Sell Trade
0.000 Z (0) 10
0.001 Z (0) 10 10 (1) X X Z @ 10
0.001

The liquidity creator Z has requested instant execution. Liquidity taker X then enters with an exposure period of up to 1 second. This match is done instantly since the taker's time period is greater than or equal to the liquidity creator's. Since there is no adverse selection of the slower order (since it arrived later), this is ruled to not expose them.

Of course there is some potential for latency arbitrage here if you know that X is about to hit the order book. This is an issue that can be addressed - and an area for further refinement.

D: Slow jumps in front of fast

Time Buy Sell Trade
0.000 10 (1) Z
0.001 X (0) 10 10 (1) Z
0.002 Y (1) 10
X (0) 10
10 (1) Z
1.002 Y (1) 10
X (0) 10
10 (1) Z Z Y @ 10
1.002 X (0) 10

In this example buyer X has come in to take Z's liquidity, but is not willing to bid in an auction - only willing to trade immediately. At this point Z does not know whether X is more informed. Immediately after this, Y jumps in front of X on the queue and is willing to submit to an auction of 1 second, which is good enough for Z. A 1-second auction is started, and since no-one out-bids Y with a higher price the trade is matched. X is left unfilled.

E: Price divergence on latency

Time Buy Sell Trade
0.000 10 (1) Z
0.001 X (0) 10 10 (1) Z
0.002 Y (1) 10
X (0) 10
10 (1) Z
0.003 X (0) 11
Y (1) 10
10 (1) Z
1.002 X (0) 11
Y (1) 10
10 (1) Z Z Y @ 10
1.002 X (0) 11

In this example there is a strange situation where the price divergence on the basis of latency. While a fast trader outbids a slower one on a price basis, they are not willing to commit to an auction. Price improvement cannot be passed on to Z in this case because doing so would encourage late and informed orders to arrive at the end of auctions - handing them the advantage of adversely selecting their opponents. In this scenario Y was granted the match at a lower price due to the fact they committed to the auction first, thereby rewarding them for their willingness to expose themselves to the auction.

F: Fast traders not held up by slow ones

Time Buy Sell Trade
0.000 10 (1) Z
0.001 X (0) 10 10 (1) Z
0.002 Y (1) 10
X (0) 10
10 (1) Z
0.500 Y (1) 10
X (0) 08
10 (1) Z
0.501 Y (1) 10
X (0) 08
09 (0) W
10 (1) Z
0.600 Y (1) 10
X (0) 08
08 (0) W
10 (1) Z
W X @ 8
0.600 Y (1) 10 10 (1) Z
1.002 Y (1) 10 10 (1) Z Z Y @ 10

The scenario shows where fast prices can move throughout auctions for slow trades. Here the price drops and executes while an auction is still in progress - with different prices. The trades come out in a different order to the order instructions that generated them. We can see here that traders are not held-up at all by slower traders, they all progress concurrently.

G: Price improvement

Time Buy Sell Trade
0.000 10 (1) Z
0.001 X (0) 10 10 (1) Z
0.500 Y (0) 11
X (0) 10
10 (1) Z
1.100 W (0) 12
Y (0) 11
X (0) 10
10 (1) Z
2.000 V (0) 14
W (0) 12
Y (0) 11
X (0) 10
10 (1) Z
2.500 W (0) 12
Y (0) 11
X (0) 10
10 (1) Z
3.000 U (1) 13
W (0) 12
Y (0) 11
X (0) 10
10 (1) Z
3.500 W (0) 14
U (1) 13
Y (0) 11
X (0) 10
10 (1) Z
3.600 W (0) 15
Y (1) 14
U (1) 13
X (0) 10
10 (1) Z
4.000 W (1) 15
Y (1) 14
U (1) 13
X (0) 10
10 (1) Z
4.500 W (1) 15
Y (1) 11
U (1) 10
X (0) 10
10 (1) Z
5.000 W (1) 15
U (1) 10
X (0) 10
Y (1) 09
10 (1) Z Z W @ 15
5.000 U (1) 10
X (0) 10
Y (1) 09

This is a fairly typical latency arbitrage scenario, where a liquidity creator Z is exposed by news creating bidding amongst liquidity takers. Instead of handing the order to the fastest trader, the order book requires takers to commit to a time period before allowing them to lock an auction in. Prior to the auction being called there are no executions, despite overlapping price since the market is not stationary.

Categories

Hft 21

Timematch 2

Tca 1

Haskell 1

Recent Posts

Popular Tags

Hft (21) Timematch (2) Tca (1) Haskell (1)

Social Links

Location

London, UK