21
This is determined through order precedence rules. In most markets, these are
Price priority: precedence goes to the best ask or bid offers.
Time precedence: precedence goes to who improves the current ask or bid offers. In computer-speak that's FIFO. It encourages the market participants to improve prices aggressively.
Public order precedence: public ...
21
Since Quant Cup 1's objective was an efficient price/time matching engine, the data structure of the winning implementation might partly be what you are looking for.
Else the setup of LOBSTER is supposed to be quick.
16
The specifics depend on if you're implementing for equities (order-based) or futures (level-based). I recommend https://web.archive.org/web/20110219163448/http://howtohft.wordpress.com/2011/02/15/how-to-build-a-fast-limit-order-book/ for a general overview of a good architecture for the former.
Building off of that, though, I have found that using array-...
14
Why not just use the weighted mid-market price, quoted as (Bsize * Aprc + Asize * Bprc) / (Asize + Bsize)? This measure doesn't suffer a bounce per se and allows you to directly take moving or exponential moving averages.
14
I don't know why it was removed, but the R package "orderbook" was available:
http://journal.r-project.org/archive/2011-1/RJournal_2011-1_Kane~et~al.pdf
http://cran.r-project.org/web/packages/orderbook/index.html
In the IBrokers package, the function "reqMktDepth" is used for streaming order book data.
http://cran.r-project.org/web/packages/IBrokers/...
13
All exchanges allocate to best price. This is by law in the US, and it's unimaginable that an exchange would do otherwise in other jurisdictions. As for tie-breaks, there are two possibilities for public orders:
Time: first-come first-served; used for most equities exchanges
Pro-rata: larger quote sizes get more of an incoming market order; common for ...
11
As RYogi indicated, this depends on the exchange and product type.
e.g. here is a summary of the matching algorithms at the CME
The answer to the second part of your question is yes. Even in a market like the Eurodollar futures -- which is mostly pro-rata, but has a FIFO component -- a common strategy is to "stack the book." So that you will be first in ...
10
Repeating groups are a way for FIX to represent arrays. A "number of" field prepends the repeating group to alert the recipient how many elements to expect.
For example, Arca uses TradingSessionID (tag 336) to identify pre-open (P1), primary (P2), and post-close (P3) market hours. This group is prepended by NoTradingSessions (tag 386). So, I would use the ...
9
The flickered orders are postonly bid at 15.16. The exchange slides it back to 15.15 to avoid a locked market. Submitting firm sees the slideback and cancels. Then tries again. When the 15.16 offer is executed or cancelled out, the offer moves to 15.17 then the postonly bid at 15.16 goes through at the targeted price and gains good queue position.
9
You don't just simply grab some random open source order book implementation and expect it to work. Every market is different. For example, markets have different rules for how you should handle priority in the order book (some are price-time, some are price-size-time, etc). Grabbing Joe Blow's code and expecting it to just work is only going to lead to pain ...
8
So one such visualization package is demonstrated in http://www.tradeworx.com/movie/booklet_demo/temp/booklet_demo2.mov. AFAICT it looks like a tk script.
Trading Technologies (TT) sells another visualization tool. But TBH writing your own tool takes a few hours and allows you to focus on what information you are interested in finding.
8
There is a paper of mine answering To this question: Dealing with the Inventory Risk. A solution to the market making problem by Olivier Guéant, Charles-Albert Lehalle, Joaquin Fernandez Tapia.
8
I can think of 3 reasons:
1) Queue position
2) To be on the other side when an alogrithm has a disastrous error, which happens quite often on singular stocks and doesn't get reported (but someone will get fined) . I've seen cases where the price will drop over 99% almost instantaneously. For this to occur a backfiring algo will clear out the entire bid ...
8
My Answer
You should set your limit order to: $s (v+1)^{-0.0314192 \sqrt{t}}$
where $s$ is the current price, $t$ is the time in years you're
willing to wait, and $v$ is the annual volatility as a percentage.
If you want to be $p$ percent sure (instead of 0.98), set your limit
order to:
$s (v+1)^{-\sqrt{\pi } \sqrt{t} \text{erf}^{-1}(1-p)}$
Of course, ...
7
Validating tops against the consolidated is a good method. Obviously the time stamps won't match up, but the event stream should. Bear in mind that this won't tell you much about whether you're getting the inner dynamics of the book correct (for example, did the newly inserted order go into the right spot within a given price level).
You should build ...
7
Your first definition is wrong; I'm not sure where you got that from. Your second definition is correct: the ISO alerts the exchange that the submitting party has taken responsibility for RegNMS and requests a fill at only that venue's price; there is no routing away. Obviously, there is a huge red-tape burden to get permission to do this.
7
The Queue Reactive Model (by Huang, L and Rosenbaum) is an improvement of what Cont and de Larrard (CL) did.
This model is capturing
the inflows and outflows in each queue given the current state of the orderbook (it is one of your remark)
but more importantly, once one queue depletes, the discovered quantity is not taken at random (like in the CL model)
...
6
If you're writing a "highly-optimized" book then you should be tailoring that book to the venues from which you will be receiving data. Max price, for example, is published in NASDAQ's Itch spec: 200,000.0000.
If you plan on trading US equities you better go read each of the venues depth of book specs very carefully. You'll find all sorts of ways to ...
6
You have two ways to estimate your position in an order book:
first if you have access to an ITCH feed, you can recognize your order into the ITCH updates, and know exactly where you are, but you will have to build an engine to translate an order-by-order ITCH feed to a limit order book;
or you have to use estimates; the easiest way to build one is to ...
6
I am not aware on any rules preventing a too high number of entries at a limit price. Nevertheless you usually have controls for each trader id. A trader cannot have too many orders in the book or send them at a too high frequency.
[EDIT] Moreover, on most trading platforms you cannot have orders too far away from the mid (or a reference price like the ...
6
As Alex C. notes, OHLC bars are meant to be calculated using transaction ticks. However, you could try to make bars from bid/ask individually (or perhaps even the mean of the two as an approximation), but bear in mind that they are not the 'real thing'.
But assuming you acquire transaction data, there are a number of possible methods for forming OHLC bars (...
6
In my opinion, instead of developing an analytical model, it's better to evaluate this probability directly from the data. Place your simulated orders at different price levels, and check whether and when they would be executed. Then use this probability model to simulate your trading strategy.
However, assuming that you want to simulate a trading strategy,...
5
I do not know in which context you want to implement a matching engine (ME). But according to me the two nice challenges in this context are:
implement one in an FPGA
for simulation / fast replay purpose, design the most efficient in/out bus to put synthetic traders in front of the ME.
The last point is about simulating one day in few seconds.
To answer ...
5
I recently stumbled upon this question after needing to do this to do some real-time microstructure analysis and have taken a look at the various possible implementations. Here are some of the pros/cons of each implementation (I'll use C/C++ terminology):
Array:
You have an array of structs ordered from top of book (index 0) to worst (index N). You have to ...
5
Each venue will allow diferent order types, and will have different matching rules (the queue positions you mentioned), so this is not general to the whole market, but this is a paper from Nyse that is pretty much explains most of the order types I have heard of:
http://www.nyse.com/pdfs/fact_sheet_nyse_orders.pdf
Also, one factsheet/regulation from the ...
5
Assuming that:
limit prices of Long and Short orders are equally pre-calculated in all 3 strategies;
there is no risk-free return;
strategies 1 and 2 have equal quality, and strategy 3 is slightly better.
However, the only advantage that strategy 3 takes over 1,and 2, is better location of the orders in the price level queue. In case of FIFO (price-time ...
5
You might find the paper "Low-Latency Trading" by Hasbrouck and Saar useful. In it they discuss the episodic nature of some high-frequency flow and construct some useful measures of this flow.
Generally, I would think some model that relates the cancel rate with the quote rate is most useful.
5
http://lobster.wiwi.hu-berlin.de/forum/viewtopic.php?f=4&t=30
R code, pictures and discussion, it's easy to modify it
5
Don't discount the fact that it could be a fund testing a strategy or order type.
I do this all the time. I'll take an algo that should penny on say, VWAP, and make it penny on VWAP - $10 to ensure that it works but if it does go a bit crazy then atleast I have a buffer before it starts going active.
Same thing with order types, if I'm testing a new fix ...
5
I have heard of several allegations in the recent days, but they are mostly baseless.
However, there are a rare, few trading venues whose matching rules are most often accused of giving unfair order execution advantages to certain firms. These usually arise from violations of the standard price-time priority:
IEX's broker priority rule. "All orders will be ...
Only top voted, non community-wiki answers of a minimum length are eligible
