Hi,
Haven’t used Collective2, but considering making my system available here. But it requires fast execution of orders. So, anyone know what “typical” lags would be from an order (using the API) is given till a subscriber (using AutoTrade) receives it?
Connection speeds/lags are difficult to guess on average I assume, but what about the Collective2 back-end? How efficient is that?
– Chris…
The short answer to your question is no, a resounding NO. The typical lag on C2 is >4 seconds. (That’s right, SECONDS.)
I need to disagree with Iris. Iris is annoyed because he had a fill he didn’t like, and when he examined his logs, he saw a 4-second lag between the time his NinjaTrader submitted an order and the time that C2 responded to his HTTP request with a fill confirmation. He has complained to me about this fill (and a number of other issues) through a series of emails.
But the reality is a bit more complicated. While 4 seconds isn’t unheard of, it’s not common; and - besides - the round-trip HTTP request-to-confirmation-time is not really the material issue, anyway. When you issue a signal at C2, the fill in the internal C2 engine takes (typically) less than a second. The harder part to control and measure (and more important, actually) is the time the signal takes to get from C2 to all the various brokerage accounts, at multiple brokers, who are AutoTrading the signal.
This time varies. A lot depends on each broker and the kind of API they provide. Straight-through FIX connections are fast. Other architectures are slower, but even that latency depends on time of day and other factors.
Now, the reason this delay time is important, and the reason Iris is upset, is that C2 has a very strict policy: we use the average fill price of real brokerage accounts when we display the fill price on C2. This means, in effect, that the fill price C2 displays can be degraded by the slowest of our AutoTrade broker partners.
The simplistic response I often get from people like Iris after I explain this fact is that C2 ought not display the real-life broker fills as the fill price. “After all,” these people typically say, "when I traded on my screen at home, I got filled at X. It’s not fair that C2 shows me as filled at X+1 (or whatever)."
Well, okay. Except, the thing is, in real life, real traders got filled at X+1. And the fact that C2 uses real-world fills (whenever available, that is; some systems don’t have any real-broker-account trading) actually helps system developers. How? By making the C2 platform more transparent and honest, subscribers can feel a little comfortable about the slippage they will get in real-world trading. This attracts more subscribers to the platform, and to good systems.
And - while I wish all our broker partners had extremely fast API connections - the fact that we try to work with as many brokers as possible (yes, even the ones with slightly slower connections) means your system is AutoTradable at more places, and thus will attract more subscribers. I believe that this increased transparency, and the greater ability to autotrade at more places and more brokers, outweighs the negative of some incremental AutoTrade latency being factored into fill prices.
Now, all that being said, the truth is that C2 isn’t an good place for high-frequency trading. The reasons I describe above (latency at the broker-connection level), not to mention the inherent latency in an HTTP polling architecture at the C2 API level, degrades these strategies.
But for most strategies, I think you’ll find C2 does a reasonably good job at keeping latency down. We’ve spent a lot of money behind the scenes to beef up our infrastructure, and will continue to do so as the C2 platform grows.
- Matthew
* P.S. I made a point of saying C2 uses real-life fill prices (when available) as the basis for the executions it displays in the trading system results. This does not change the fact that all results on C2 must be regarded as hypothetical, since (among other reasons) no single real-world account looks like the C2 Model Account. The standard hypothetical results warning, visible on every page of this site, still therefore applies.
Matthew and Christian,
Do you mind putting a definition around what constitutes “high frequency?” I’m just curious.
Christina
Since Mathhew was so kind to focus on my trade in particular, in fainess, he should have also mentioned that there was an additional 4 second lag from the time NinjaTrader sent the signal to C2’s server and that server acknowledged it. Then, there was an additional 4 seconds for C2’s engine to transmit the trade as he mentioned. This resulted in 15 ticks of slippage in subscribers accounts. Is that considered to be “real world.” I hardly doubt it. I have subscribed to other developer’s systems with non C2 related brokers and the most slippage was 3 ticks in a illiquid instrument.
So, if C2 is taking this much time in sending signals to subscribers’ brokers for trade execution, of course there are going to be fills in real world accounts that are far removed for the developer’s trade signal. But let’s not loose fact those trades are late due to C2. After all, a subscriber’s auto-trade order can take place no faster than C2 send the signal to his broker. What good is transparency if the fills are, indeed, not close to real world with a reasonable and customary amount of slippage?
Mathew also acknowledged after reviewing the logs that the issue is not with NinjaTrader’s servers in sending the signals to C2,
Hi Christina,
High-frequency trading means you are using a computer program and super fast computers to hold a trading position for an extremely brief period of time, sometimes seconds or milliseconds. High-frequency trading programs usually attempt to profit from market inefficiencies, with nearly zero risk.
Currency triangular arbitrage for example relies heavily on high-frequency trading (those interested can read the now famous "Triangular arbitrage in the foreign exchange market : inefficiencies, technology and investment opportunities" by Marios Mavrides).
Yes, there are sometimes lags. And yes, sometimes AutoTrade subcribers or their systems screw up and C2 logs their crappy trades as actual fills.
It often isn’t fun for developers, but full disclosure, and treating actual fills as those that should be reported, is really the only fair thing to do for subscribers.
IMHO, if a system isn’t robust enough to take a few hits on system lags from time-to-time, then it probably isn’t worth following.
Thanks, Igor… I had no idea that sort of trading existed, but now that you describe it, I see that it would be, of course, inevitable.
You are welcome Christina.
Here is an example of a high frequency trade : your computer program discovers that you can buy Coca Cola shares for $20 a share in New York while in Philadelphia the same stock is being sold for $20.50 a share, at the same moment. You super fast computers then buy 2000 shares in New York and a second later they sell them in Philadelphia, leaving you with a nice $1000 profit only seconds later, minus commissions.
High frequency trading programs are looking for these market inefficiencies 24 hours a day, all over the biggest financial centers on the planet, from New York to Sydney, in the stock market, the futures market, currencies, bonds, interest rates, ETF you name it.
Now back to the charts and let’s see what the Yen is doing…
Thanks Matthew, just the type of information I was after.
Based on that and other info in the thread my system might still be relevant. But I might also need to do some adjustments.
Anyway, no big harm in trying it out anyway for a period and see what happens.
Ask ten different people and you’ll get ten different variations. Igor is definitely describing one aspect of it, removing obvious arbitrage opportunities and hence making the market move towards a more efficient one.
There’s also high frequency speculation, where you could go for (say) a trend following system. But rather than following a (potentially) X day long trend, you follow a (potentially) X minute long trend (intraday in other words). This isn’t arbitrage as it’s not risk free, since you might get the trend wrong.
But no matter what variation of a description you might get, I would say quick execution of orders are key to any high frequency system success. And that is were you get all the (sometimes craziness) of attention to where your servers are located relative to the exchange servers, or HF funds hiring hard core programmers to optimize the Linux kernel for higher network throughput, and on and on… It’s all about that 1 ms (or lower) latency edge, I would say especially if you’re trying to exploit short lived risk free arbitrage opportunities… That also part of the reason LSE just replaced their software systems, as they were unable to competete with other competitors regarding execution speeds. You might find this interesting: http://blogs.computerworld.com/14876/london_stock_exchange_dumps_windows_for_linux
Hi Christina,
what is high frequency
here an answer from the opposite side of the (frequency) spectrum 
I talk to various funds about my trading systems. When we reach a point in the conversation where I axplain that my holding period averages somewhere around three days some use to scream "Oh my god that is high frequency!"
These boys usually trade once in three months…
If C2 is going to try to sell its customers that “real world” slippage is 4-12 ticks in futures due to a 4 second front end and 4 second back end lag (8 seconds) from time a report is sent from NinjaTrader, than I don’t think any auto-trade system is worth trading here. I know that isn’t very self-serving, but truth trumps personal gain.
I think you need to ask yourself if it’s acceptable if your broker, in effect, took 8 seconds from the time you sent an electronic order, to report your fill. In the days when brokers used telephones, 8 seconds wasn’t acceptable, but here we are told it’s reasonable.
Given the numerous third party services that offer trading server colocation and ultra low latency data transmission at a very reasonable cost, one has to wonder why C2 can’t offer an acceptable solution.,
Iris:
You keep talking about “4-12 ticks” of slippage and “8 seconds” of latency as typical. I continue to insist that these numbers are not typical.
But I don’t have time or desire to get in a public pissing match.
I’ll just simply say that we’ll continue to do our best to improve the C2 platform and make it as responsive as possible.
Matthew
Matthew I don’t desire to have a confrontation and I’m sorry if this annoys you, but I think it’s important for the community to be aware of this issue and your position on it instead of trying to make me look like a malcontent who is misrepresenting the facts.
To wit: Last Friday, you sent an email when we had our exchange on this matter and you wrote the following: "We’ll keep aiming for response in milliseconds. For now, we are delivering response in 4 seconds."
Today, C2 reported 5 ticks of slippage in an @EU trade when the market was far from moving fast.
ACTUAL MARKET DATA >> DATA PROVIDER >> TRADER/DEVELOPER >> (POSSIBLY THIRD PARTY SOFTWARE >> COLLECTIVE2 >> (POSSIBLY THIRD PARTY SOFTWARE) >> (POSSIBLY SUBSCRIBER) >> (POSSIBLY THIRD PARTY SOFTWARE) >> SUBSCRIBER BROKER
Now, is it at all surprising that somewhere in that chain of events is a lag?
The lag I’m speaking of starts when C2’s server acknowledges a signal from a frontend such as NinjaTrader to the time C2 sends that signal to the subscriber. You see, an autotrader is beholden to C2 in its role of trade information clearinghouse provider.
It’s all about C2’s timestamps, not those other parties. So if C2 is lagging in seconds (as opposed to the industry benchmark, milliseconds) that just compounds any lag from other sources (which is a seperate discussion).
I hope that clears things up for you. 
