Hot answers tagged limit-order-book
7
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.
7
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.
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 ...
3
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 ...
3
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.
2
From the Turquoise features document:
6.3. Away Market Best Bid and Offer (ABBO)
6.3.1. The ABBO is defined as the Best Bid and Offer prices as represented by an aggregation of relevant European Order Books as
defined by Turquoise. An external market’s Best Bid and Offer will
only be part of the ABBO when that market is in Continuous Trading.
...
1
Assuming your question is about using the FX 'volume' you see in a broker's DOM or T&S window, you probably can't infer much about order flow in the way you can with other instrument types. FX volume and tick data are not equivalent to what you will see for other instruments. That is, unless the feed is coming from a FX ECN like HotSpot or ...
1
One way to think about this is as a missing data problem. You observe the order book constantly, but trades only occur infrequently. One way to resolve this is to perform full information maximum likelihood (other techniques, such as multiple imputation, may be too slow for your needs but it might be useful to look into them), which has analytical formula ...
1
Despite the rather unconventional terminology used I would say you are pretty much spot on with what you are doing and what you try to achieve. I would, however use log returns in order to get an identical percentage no matter whether you measure the distance from 100 -> 90 or 90 -> 100, for example. You can also standardize the value you capture by ...
1
I would actually not bother with F# data structures for this - many of them are actually slower than ordinary .NET collections. My approach is to use SortedDictionary<price,volume> for bids and asks. That way, you always know the best prices on the market.
Of course, the above assumes that you're not concerned with thread safety and are building the ...
Only top voted, non community-wiki answers of a minimum length are eligible
