Tag Info

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

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

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

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