You know what really drives me crazy: Brokers think they understand the term âLow Latencyâ. I have been trading algorithmic strategies now for over 5 years. We were doing this before it became âhotâ on the street. Through that experience, we have learned so many things that have helped us survive all of these years and make money consistently.
What bothers me so much is that every damn broker we end up trading with has the same speech and pitch. It usually goes: We have the best this and that, best collocations, feed lines, apiâs customer service blah blah blah blah. They obviously want your business, so they are going to do whatever it takes to get it. The funny thing is: Most of them believe what they say because it is all that they know. Some brokers are large and because of this, think they are the best. They have the money to buy the technology and hire the programmers to build the âlighting fastâ APIâs. The trouble is that they have no way of identifying what is TRULY considered âfastâ. They assume they have it and thatâs good enough. In their world: âItâs the bestâ. That goes for feeds as well: âWe have direct fiber pipesâ and we are at Harborside..blah blah blah. (Do I sound frustrated?)
The truth is that none of these guys look deeper into real latencies. Sorry, but a ping time doesnât cut it. Most high speed customers do not complain if they feel the executions and service are adequate. Because of that, the brokers âdonât fix what isnât brokenâ. Well, what about the few that do complain? What does it take to prove them wrong? And if you do prove them wrong, what does it take to make a difference and have them take action? My experience has almost always been that even once proven, they rarely take action.
Five and a half years ago, we were with a âbrokerâ and co-located at their facilities. Back then, we were just learning about latencies. We found some outside of our own systems and pointed it out. The broker took no action. Later, they were bought out by another firm. We later found latencies within that firms api/network/hardware. They were unwilling to even look at any issues. We ended up leaving and going to a bigger firm: Had the same issues there. After a year and a half with that âfirmâ we left out of frustration to another broker. For the first time, this new broker started listening. We were happy. Through that experience, they became a much better shop with regards to execution, low latency and all of that. Well, that firm is now a new firm. This ânewâ firm which has so much âexperienceâ basically has us in the same position as we have been for years and years. They talk about how good they are, they throw numbers at us and based on what our options are, we go with it. Well, the end result is always as it is: They are slower than what their full potential could be. The problem is that the people who run all of these firms think their version of âfastâ is fast enough. I am now at the point where I have pointed out latencies we uncovered on their end, but they seem gun shy to even consider any as an issue. Bottom line: The faster a broker is head to tail, the more money their clients will make the more volume the broker will do and new clients will migrate to whoever is fastest. Itâs simple.
So out of frustration of not being âheardâ at my broker, I started the search once again to find a new âbrokerâ to suit my needs. And here we are in 2005: The same speech, the same stories, the same claims. Hereâs an example: I have been talking to a large well known broker (which I will not name, nor will I name any in this story) on the street. They basically made all of the same claims. They bet that they could beat anything I had on my end as far as speed and all of that. I asked them to run tools that we have built which measure true latency. These tools basically have kept us in business for all of these years. They ran them on their main servers and gave me the results. I wanted to go with this approach rather than spend months of development time fusing to their api and finding out first hand they were wrong. Well, BINGO I proved them wrong again. My systems were about 900% faster than anything they had from execution servers to feed distribution servers with regards to latency. What this means in my world: They are the automatic bottleneck. All it is here is the same story over and over. And the beauty of all of this is that NONE of them know how to fix that issue. They never thought of digging that deep! Same old story, âWe are the best and fastestâ.
You know what I wish? I wish I was big enough to help build a real automated trading brokerage firm. With all of the first hand knowledge we have from the years of experience and not overlooking the smallest of variables, it would be the fastest anyone has ever seen. It would change the landscape. Whatâs funny is that if any of these brokers actually listened and implemented some ideas pointed out, they would be there now. I never claimed to know everything, but I do understand true latency. Sorry guys, I had to vent for the first time.
What bothers me so much is that every damn broker we end up trading with has the same speech and pitch. It usually goes: We have the best this and that, best collocations, feed lines, apiâs customer service blah blah blah blah. They obviously want your business, so they are going to do whatever it takes to get it. The funny thing is: Most of them believe what they say because it is all that they know. Some brokers are large and because of this, think they are the best. They have the money to buy the technology and hire the programmers to build the âlighting fastâ APIâs. The trouble is that they have no way of identifying what is TRULY considered âfastâ. They assume they have it and thatâs good enough. In their world: âItâs the bestâ. That goes for feeds as well: âWe have direct fiber pipesâ and we are at Harborside..blah blah blah. (Do I sound frustrated?)
The truth is that none of these guys look deeper into real latencies. Sorry, but a ping time doesnât cut it. Most high speed customers do not complain if they feel the executions and service are adequate. Because of that, the brokers âdonât fix what isnât brokenâ. Well, what about the few that do complain? What does it take to prove them wrong? And if you do prove them wrong, what does it take to make a difference and have them take action? My experience has almost always been that even once proven, they rarely take action.
Five and a half years ago, we were with a âbrokerâ and co-located at their facilities. Back then, we were just learning about latencies. We found some outside of our own systems and pointed it out. The broker took no action. Later, they were bought out by another firm. We later found latencies within that firms api/network/hardware. They were unwilling to even look at any issues. We ended up leaving and going to a bigger firm: Had the same issues there. After a year and a half with that âfirmâ we left out of frustration to another broker. For the first time, this new broker started listening. We were happy. Through that experience, they became a much better shop with regards to execution, low latency and all of that. Well, that firm is now a new firm. This ânewâ firm which has so much âexperienceâ basically has us in the same position as we have been for years and years. They talk about how good they are, they throw numbers at us and based on what our options are, we go with it. Well, the end result is always as it is: They are slower than what their full potential could be. The problem is that the people who run all of these firms think their version of âfastâ is fast enough. I am now at the point where I have pointed out latencies we uncovered on their end, but they seem gun shy to even consider any as an issue. Bottom line: The faster a broker is head to tail, the more money their clients will make the more volume the broker will do and new clients will migrate to whoever is fastest. Itâs simple.
So out of frustration of not being âheardâ at my broker, I started the search once again to find a new âbrokerâ to suit my needs. And here we are in 2005: The same speech, the same stories, the same claims. Hereâs an example: I have been talking to a large well known broker (which I will not name, nor will I name any in this story) on the street. They basically made all of the same claims. They bet that they could beat anything I had on my end as far as speed and all of that. I asked them to run tools that we have built which measure true latency. These tools basically have kept us in business for all of these years. They ran them on their main servers and gave me the results. I wanted to go with this approach rather than spend months of development time fusing to their api and finding out first hand they were wrong. Well, BINGO I proved them wrong again. My systems were about 900% faster than anything they had from execution servers to feed distribution servers with regards to latency. What this means in my world: They are the automatic bottleneck. All it is here is the same story over and over. And the beauty of all of this is that NONE of them know how to fix that issue. They never thought of digging that deep! Same old story, âWe are the best and fastestâ.
You know what I wish? I wish I was big enough to help build a real automated trading brokerage firm. With all of the first hand knowledge we have from the years of experience and not overlooking the smallest of variables, it would be the fastest anyone has ever seen. It would change the landscape. Whatâs funny is that if any of these brokers actually listened and implemented some ideas pointed out, they would be there now. I never claimed to know everything, but I do understand true latency. Sorry guys, I had to vent for the first time.
