Tag Info

Hot answers tagged

6

The "correct" way is the way best suited to your trading. Regardless as to your data structure of choice, you have to maintain a list of all orders active on your book. That's because subsequent messages reference Order ID and you have to look up the corresponding order to determine the price level being acted upon. Given that you have to maintain a ...


6

Approaches like FIFO and LIFO are most useful for tax accounting. If you don't have a tax accounting reason to do them, I'd recommend avoiding them, as they don't reflect actual realized gains (it's very rare for a position accounting system to move cash in and out of your account based on FIFO or LIFO). I'm going to discuss everything here in Gross of ...


4

I'll add my own experience here based on what we do at our firm, simply to provide more support for what Brian said in his answer. Fills that move a position further away from 0 contribute to the average price of the position. Fills that move a position closer to 0 "book profits" against the average price of the position to that point in time. Any fill ...


4

With respect to what you need, you have to consider different aspects of optimal trading: the Almgren-Chriss framework (cited by Anna, since Jim and Alex -amongst others- extended it) focus on obtaining an optimal trading rate, it is nice but not really what you need. You can nevertheless use it to plan / schedule your trading during the day. but what you ...


4

Louis's answer hints at the problem. Most market-data feed formats only use the order's reference ID for cancel, replace, or execute; they do not list the symbol or side. So you'll need a way to look-up the particular order by ID alone just to make adjustments. You can aggregate by price if your application requires it, but just know that the "level book" ...


3

Regardless of frequency, every firm should track its own fills to ensure that the exchange's drop copy is accurate. Now it is true that the positions can be stored in a simple database for later retrieval if real-time execution isn't a goal. But it is extremely dangerous (and fiduciary irresponsible) to just "take the counter-party's word for it".


3

It is possible to think of a strategy for splitting orders for one large sell over time as a function $x_t$ which describes how much to sell at each timestep $t$. If the instantaneous trading rate $\dot{x_t}$ is too large, i.e. too much is sold at once you get immediate impact which is bad. If selling takes too much time, there is the risk of negative price ...


1

I can speak from experience that options with next to no volume and ridiculously large spreads have market makers that accept nothing short of 5% effective spreads, right below liquidation value for deep in the money, and quickly nothing for out of the money. Also, the parameters should be expected to move against your fund flows very quickly. I've found ...


1

Some execution platforms or markets have a policy to execute order in full volume at one price (fill-or-kill). You would use it on thin market to ensure low slippage. For example, in your case a buy order for 1000 would be filled by 70% at 14.10, which is 30 cents away from best bid, 25 cents (1.7%) away from midquote, and could be considered as too costly ...


1

you forgot to mention what broker or api you are using. AFAIK every broker/exchange provides a execution id, wich is unique for every trade on the trade session, with the execution id and your order id you can group the trades for the order sent. You could check the execution report of the FIX Protocol its based on the industry standard and the majority of ...


1

I have never implemented an order book, but I don't see immediate benefits from this aggregation. If you merge the volumes, then during the actual execution you'll have additionally to take into account that these orders came from different market participants. This seems to add additional complexity to your implementation. From the point of view of market ...


1

1) The uhf/hf approach is to run dedicated order management modules, position managers, and risk checks in dedicated processes in-house and NEVER rely for any of this on outside applications. For uhf some or all of those processes may run on hardware chips, but most on the hf side and lower frequency side runs within software modules that are dedicated to ...



Only top voted, non community-wiki answers of a minimum length are eligible