Tag Info

Hot answers tagged

11

Regarding your order management issue, every order should have a unique identifier that the user can reference; in FIX, this is the ClOrdID. The parameters of every order the user requests should be stored in a table keyed by this identifier. If your goal is to prevent duplicate orders from going out, consider having a trade volume limit per each symbol. ...


8

The "price protection" refers to RegNMS in the US. A stock exchange that does not have the best price must route all order flow to the exchange that does. The SIP in the figure is a consolidated feed that lists the best price among all exchanges. Consider this example: a broker sends a market order to buy JNJ to NYSE where the best offer is \$86.97. ...


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

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

What I've done in the past is create an OnOrderSubmit event/method that fires when an order is placed. Use set a semaphore in that method so that your tick/analytical method ignores order placement instructions until an execution occurs or a timer expires. Then flip the semaphore. (If you're using multiple threads you want to make sure to serialize access ...


3

Instead of sending orders each time condition is met, try to set "wanted holding" in the trade logic thread. Trade execution will then make sure (issue sufficient number of orders) to achieve your wanted holding.... For example, the first time signal happens, you sent wanted holding to 100 shares the next time it happens you only confirm that you want 100 ...


3

If I understand correctly the TCP roundtrip time can be used as a posteriori proxi for the order entry gateway delay. So assuming the roundtrip time is composed of gate delay and independent other delays $RTT_g(t) = dT_g(t) + d_g(t)$ with assumed $Cov(dT_g,d_g)=0$ and $Cov(d_i,d_j)=0$. Minimizing the this combination of gate delay and other delays is ...


1

Optimal value of n should be calculated based on how much amount you want to invest in that decision, that can be for example 200 000 of base currency, and minimum order size is 10 000 of base currency then you should have 200 000 / 10 000 = 20 orders in my opinion that are targeted at hotspots where is most single price points inside interval. EDIT: When ...


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

Yes. You're right that queue position is less important in a pure pro-rata market. But in a market that is very deep, such as Eurodollars, the cost of getting adversely selected ("catching a falling dagger") is huge (very large bid/ask spread). So it is critical to cancel any open orders quickly when the price is about to move.


1

Market markers still have to consume market data. The techniques required to scale a live order book in real-time will be the same regardless of the intended use case. So while the strategies will be different from what we know as HFT (and even the participants different), the systems in use will be very similar.



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