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


7

The Eurodollar market is partially pro-rata. And there is a lot of HFT on it. Getting out of the book when conditions are not right is very much HFT.


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


4

I have heard of several allegations in the recent days, but they are mostly baseless. However, there are a rare, few trading venues whose matching rules are most often accused of giving unfair order execution advantages to certain firms. These usually arise from violations of the standard price-time priority: IEX's broker priority rule. "All orders will ...


3

You need to track your current position for each stock in the software. You need a process to find out when an order is executed, and update your position for the appropriate stock. This process is separate from sending orders to the market.


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

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

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


2

In addition to @madilyn's answer, there is one point that needs to be addressed and that is often called an unfair advantage although it is merely a competitive advantage. Take the US Equities market. There are now several venues on which the same symbols are traded. If one HFT acquires information about one symbol in one venue - e.g. due to a limit order ...


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