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

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


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


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

Time and sales shows trades, not orders. You are most likely seeing off exchange block trades being matched in dark pools and other block crossing venues and reported to FINRAs TRF.


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

The adopting release of Reg NMS http://www.sec.gov/rules/final/34-51808.pdf discusses the problem(s) they were looking to solve. That will provide the SEC's thought process.


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

Three possible explanations, 1) From a recent PhD thesis, this could be part of an aggressive HFT strategy that tests how the market reacts to such large orders. See Adam Clark-Joseph's exploratory trading paper. 2) If the order is in a Large Cap Stock or liquid ETFs, it could be a large fund filling a block trade. Think about it if your a fund manager, if ...


1

It depends on the smart order router that you've chosen. Generally no. However in your example it appears that you are referring to passive execution on both ends, and there are smart order routers that preference the highest rebate, in which case you might find high correlation - note this doesn't mean that the venue where the entry leg is executed causes ...


1

Having locked markets is bad in the sense it freezes the price formation process. Ideally we would like to have a price on as much instruments as possible so that we know their value. it prevent investors to buy (or sell) it and thus adds frictions, transaction costs, etc. We would like to enable investors to buy or sell when they need/want, to let the ...


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