Rithmic, LLC is pleased to announce that version 10.0.0.0 of R | API+™ is now available for download by its end users. “The standout feature of version 10.0.0.0 is support for Depth by Order™. Programmers now have the ability to determine the position in the order queue of orders for instruments that trade on exchanges that publish order priority information,” said Gene Sato, chief developer of Rithmic’s API libraries. “We also provide information on the size of the implicit order book.” Jonathan Walden, CEO of Rithmic, continued, “We are very pleased to make such information available to our developer community. It has been more than 8 months since the CME began publishing the order priority of all its products via its MBO messages. During this time, through our desktop trading screen, R | Trader Pro™, we have demonstrated that position in queue information can be provided to a desktop application and displayed well, without taxing the trader’s CPU. We are confident that our programmatic interface to such information will enable algorithmic trading programs as well as other desktop trading screens to benefit likewise.”
I can back @IAS_LLC’s assessment of R | API+. Very good product. Gene is very knowledgeable and although I haven’t used the API in live trading I can tell you that the design of his API is better than the vast majority of mktdata APIs I’ve seen since entering the working world. Not sure I understood the decision to us an interface or abstract class (forget, was a while ago) vs. events and delegates as listeners in C#, but that’s so minor. I have a couple follow ups which may allow @jjw to quickly deanonymize me: 1. What’s the state of your efforts to implement SPAN? 2. You guys have clearly made a high level decision to offer some of MDP 3.0’s features on top of the intersection of what all the other exchanges offer in terms of market data. Why not take it a step further and give access to the raw messages? Doing so may be a bit touchy as an ISV but it would distinguish your offering greatly because it would allow people to model the distribution of fills in a way other platforms don’t. 3. On the TCP fill feed from CME, do you guys microsecond timestamp this data server side? 4. Did you guys ever pursue the other timestamp fields such as Jump Off Point? It would be really nice to have transact time and server side timestamps on book updates as well as trades.
Responses below: 1. What’s the state of your efforts to implement SPAN? Our algorithm that calculates margin based upon the inter-relationships between contracts, taking into account positions that form spreads, has been running live for several months with a limited distribution. It calculates margin for contracts traded on the CME's exchanges and on the ICE's exchanges. In addition to identifying positions that comprise spreads, it handles the relationship between outright contracts, TAS contracts, TAM contracts and their spreads. We expect to finish the TAM-TAS spread calculations in the next week or two. We are also finishing our work on option margin calculations, which are based upon the exchanges' calculated deltas. There is too much testing to perform for me to provide a release date at this time but my guess is that we will release this Sophisticated Margin Account Calculation (SMAC™) some time in Q2.2. You guys have clearly made a high level decision to offer some of MDP 3.0’s features on top of the intersection of what all the other exchanges offer in terms of market data. Why not take it a step further and give access to the raw messages? Doing so may be a bit touchy as an ISV but it would distinguish your offering greatly because it would allow people to model the distribution of fills in a way other platforms don’t. If we provided the raw messages from the exchange to end users through our software then, among other issues, the value of our feed would decrease greatly. For someone who is willing to deal with the various issues that present themselves when dealing with a raw data feed, especially data processing issues, we do offer DMA to the CME's exchanges, through our hosting company, TheOmne.net.3. On the TCP fill feed from CME, do you guys microsecond timestamp this data server side? Yes. See the answer to the next question.4. Did you guys ever pursue the other timestamp fields such as Jump Off Point? It would be really nice to have transact time and server side timestamps on book updates as well as trades. When provided to us by the exchange, we stamp our messages with the time as indicated by the exchange (which tends to indicate the time of the action - fill, cancel, modify) as well as the time just before the exchange sent the message to us (the jumping off point). The granularity of these timestamps is the granularity set by the exchanges padded to nanoseconds as required.