- Dalian Commodity Exchange
- SGX Securities Market Direct Feed
- CanDeal (http://www.candeal.com) mostly Canadian dollar debt securities
I have evidence (not my imagination) to believe that these exchange data feeds don’t use vanilla TCP or multicast but some proprietary API (based on them presumably).
I was told other China feeds (probably Shenzhen feed) is also API-based.
ESpeed would ship a client-side library. Downstream would statically link or dynamically link it into parser. The parser then communicates to the server in some proprietary protocol.
IDC is not an exchange but we go one level deeper, requiring our downstream to provide rack space for our own blackbox “clientSiteProcessor” machine. I think this machine may or may not be part of a typical client/server set-up, but it communicates with our central server in a proprietary protocol.
There was a requirement that within 90 seconds, any execution on any online or traditional broker system need to be reported to the “official” exchange. For each listed security, there’s probably a single “official” listing exchange.
Take IBM for example.
- On NYSE, executions only take place after 9.30am, usually after an opening auction.
- On-line electronic brokers operate 24/7 so an execution could happen and get reported any time. However, NYSE data feed only publishes it after 4am by right. I don’t know how strict this timing is. If your feed shows it before 4am I guess you are free to discard it. Who knows it might be a test message.
I could imagine that u.s. exchanges are more advanced in terms of trading rules, operational complexity, matching engine, order types … because presumably u.s. exchanges have more volume and more variations in securities. It’s like a bigger, older hospital is more sophisticated since it has treated many more patients.
On the other hand, I read more than once (over the last 7 years) that in terms of pure latency the bigger exchanges in the U.S. are often slower, but only moderately, so everything still works fine. I don’t know any capacity concerns on the horizon. Some of the smaller exchanges in Asia were aggressive to beat the bigger exchanges on latency. World #1 fastest exchange is now Bombay.
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
https://www.opradata.com/specs/48_Line_Notification_Common_IP_Multicast_Specification.pdf shows 48 multicast groups each for a subset of the option symbols. When there were 24 groups, the symbols starting with RU to SMZZZ were too heavy too voluminous for one multicast group, more so than the other 23 groups.
Our OPRA parser instance is simple and efficient (probably stateless) so presumably capable of handling multiple OPRA multicast groups per instance. We still use one parser per MC group for simplicity and ease of management.
From: Chen, Tao
Sent: Tuesday, May 30, 2017 8:24 AM
To: Tan, Victor
Subject: RE: OPRA feed volume
Opra data is provided by SIAC(securities industry automation corporation). The data is disseminated on 53 multicast channels. TP runs 53 instances of parser and 48 instances of rebus across 7 servers to handle it.
There are various order types usable before the 9.30 opening auction (and also before a halted security comes back). We might receive these orders in the Level 2 feed. I guess the traders use those orders to test the market before trading starts. Most of these orders can be cancelled, since there’s no execution.
The Imbalance data is a key feature by the exchange auction engine, and possibly very valuable to traders. It has
- indicative match price, which at 9.30 becomes final match price
- imbalance at that match price
The auction engine looks at all the orders placed and works out an optimal match price to maximize execution volume. Traders would monitor that value published by exchange, and adjust their orders. This adjustment would be implemented in an execution algorithm.
In one major market data provider, there are 20 to 30 million “instruments”, mostly derivatives. Globally there are more than 300,000 stocks on various trading venues, as of 2017.
This site aggregates 300 to 400 “sources”. Each source could be a data feed or a distinct trading venue. For example, Nyse has at least 3 independent trading venues — nyse classic, Arca and Amex.
A Market (a particular exchange or an instrument) shows its true liquidity upon a Client-market-order. The other types of order are typically market-maker orders, which are (always?) limit orders.
#1 obvious sign of every illiquid product — wide bid/ask.
#2 obvious sign — tiny sizes of quotes (i.e. limit orders)
Now the defining features of a Liquid instrument. Look at EUR/USD…
1) Immediacy — client order is immediately filled. It’s necessary but not sufficient to have a tight bid/ask spread.
2) Resiliency — low-impact. Minimal impact on equilibrium price even in the face of a large trade. Depth of market. If there are relatively large bid/ask volumes close to the best bid/ask, then impact will be low.
2a) strong demand — large bids around mid-price
2b) firm and adequate supply — large offers around mid-price
Even the largest instrument in the world — EUR/USD can show a (temporary) drop in mid-price after a 100mio trade.