Tag Info

Hot answers tagged

7

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 ...


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 ...


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

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" ...


4

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".


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 ...


3

This differs from exchange to exchange but in Toronto (TSX) the rule is that the unfilled amount becomes a limit order at the last sale price. A market priced order is an instruction to trade the order at prices currently established by the opposite side of the market. Such orders have no trader defined limit on the potential trade price but these orders ...


2

You will need an entry and then a "Grouped" stop loss and take profit (one cancels other). An implementation of this exists in quantstrat in R called ordersets. Documentation and source code can be found here: https://r-forge.r-project.org/scm/viewvc.php/pkg/quantstrat/R/orders.R?view=markup&root=blotter You will unfortunately need to port this and ...


2

To slice up an order you can use several execution strategies. TWAP which will execute small slices of your order over a time period VWAP which will spread your order over time and try to minimize slippage against the vwap benchmark for a given instrument POV which will split your order up into smaller chunks and attempt to keep your order filled as a ...


1

Most of the big players offer a suite of execution algorithms for big orders, as seen in this listing from Credit Suisse. Very generally speaking, the algorithms will have a pedigree going back to volume weighted average pricing schedules, or perhaps to the famous paper by Almgren and Chriss. They have various modifications, including use of "unusual" ...


1

When an exchange (or ECN) receives an order, there is no identifier of the buyer or seller. Therefore the only place that this is available is at the broker themselves. No broker would be willing to provide this information even on an anonymized basis and it would be a violation of other laws and regulations (such as Regulation S-P). ...


1

On BATS, your market order would be rejected back to you with an error "No Liquidity".


1

If it was on Nyse or NASDAQ, could be a special order type (only if on first limit: some participants can send orders that are activated only to prevent a "trade through", i.e. if there is no other order at this price on other venues). It may also be your broker did not succeeded into counting the orders on this limit (bug, datafeed, etc), especially if it ...


1

I think you are focusing on lots when you should focus on having the API return the original orderID, that is what really matters, not LotIDs (though every API of average quality should generate a unique ID for each individual fill as well). Chrisaycock is right in saying that each fill you receive should automatically be unique. So you are by definition ...


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