Bringing Sexy Back...to FIX

[oversea]

Who are you clearing with? Are you trading only futures? Which fcm/broker do you use?

And yes I think you stating its for Frankfurt /eurex clears up a few things because there definitely are way better choices in Chicago. I would have to ask colleagues who cover eurex. I will pm you when I hear back.

Thanks, I sent you a PM.

 

[Drew Shields]

Agree with most of what you said in your last post. I just guess hft, as used by TT is misleading and should never be used by TT whatsoever because they simply cannot compete in this space. We are talking max 40 micro seconds to stay competitive. Most hft groups even pre-create orders they send to the market. TT simply cannot compete in this space at all.

Of course is there a measurable difference between a connection via internet vs right on premises. But I do not see where the edge here is that TT seems to claim over many other, much more specialized and less pricey players. They do not have experience in this space (algorithmic trading) and why would you choose them over other competitors that have plenty more experience, cleaner interfaces, better connectivity at price points at or below TT's?

I'm sorry I'm late getting back to this thread! Hopefully I can clarify a few things.

First, I'm not sure where I talked about 'HFT' in the context of this post on our new FIX service. I wasn't arguing that our FIX adapter on the new platform competes with HFT algos directly. I was only pointing out that as far as FIX services go, I believe it is one of the, if not 'the', fastest one of those. If you can point out which statement I made that claimed this FIX solution competes with HFT, please let me know so I can clarify.

Second, our automated trading solutions on our new platform are more competitive than ever before. For example, our Autospreader has been clocked in production re-quoting (wire to wire time inside our network) well below 30 mics and auto-hedging well below 50 mics. So, to say we are not in the space is simply incorrect. We also know that we are competitive because of the many users we have around the world using our automated trading tools. We have more engineers than you may realize, and certainly more than we did in the past, who have come out of HFT prop firms and so many of the strategies used (including pre-creating orders as you mentioned) are known to us and will certainly make their way into the product in the coming months.

It's important to note that all our recent talk about performance is not referring to X_TRADER but to our new platform which has slowly been gaining traction over the last 18 months. It grew significantly in terms of volume and number of users in the second half of 2016, largely on the back of the performance improvements we've made in TT over X_TRADER.

 

[Drew Shields]

It could be that you missed what I said in my first post that I'm connecting via the TT FIX adapter - I'm merely using TT as a connectivity solution for my own system, so their interfaces, aren't such a concern for me.

There are a few main outfits that do this:
TT
CQG - which I tried and was a disaster. They also don't have a gateway in FR2.
Stellar - which may be bettter than TT, certainly in the service area. But at least as expensive as them.
Rithmic - would have been a solid solution, but they don't have any client-facing servers in Europe (let alone FR2).
PATS - not sure if they'd actually compete performance wise. Also, I couldn't get any answers regarding where they have servers, etc.

I just realized that my previous post didn't indicate that this setup was specifically for Frankfurt. So, true, if this was for CME, there'd be a quite a few other/better solutions.

It's a bit late now...but who am I missing?





Oh, and btw...I'm contending that there's a very measurable difference between connecting via the internet (from within the premises!) vs. connecting via x-connect.

Oversea, I'm sorry to hear you've had such trouble. I'm not sure the specifics so if you could PM me the details I'll gladly follow up. If you are looking to get connectivity via FIX on the TTNET infrastructure, I would recommend we chat either way so you understand the benefits of the new platform, especially when it comes to FIX. Before you pursue other options, I hope you'll give us a chance to get your connectivity issues resolved and explain the differences between the two offerings.

 

[Drew Shields]

Oversea, I'm sorry to hear you've had such trouble. I'm not sure the specifics so if you could PM me the details I'll gladly follow up. If you are looking to get connectivity via FIX on the TTNET infrastructure, I would recommend we chat either way so you understand the benefits of the new platform, especially when it comes to FIX. Before you pursue other options, I hope you'll give us a chance to get your connectivity issues resolved and explain the differences between the two offerings.

Sorry, one other thing I forgot to mention, oversea, while historically the brokers were always 'resellers' or 're-distributers' of our software, that has changed in many ways on the new platform. No one at TT should be encouraging the broker to get between you and us and we've specifically designed the administration and configuration toolsets in the new platform to allow you more control than ever before. Where you desire to outsource some control to your broker, we facilitate that, but we can certainly facilitate the opposite including having a commercial relationship directly with TT. Again, happy to elaborate further if you could share a little more context via PM.

 

[Zzzz1]

30/50 milliseconds or microseconds?

I'm sorry I'm late getting back to this thread! Hopefully I can clarify a few things.

First, I'm not sure where I talked about 'HFT' in the context of this post on our new FIX service. I wasn't arguing that our FIX adapter on the new platform competes with HFT algos directly. I was only pointing out that as far as FIX services go, I believe it is one of the, if not 'the', fastest one of those. If you can point out which statement I made that claimed this FIX solution competes with HFT, please let me know so I can clarify.

Second, our automated trading solutions on our new platform are more competitive than ever before. For example, our Autospreader has been clocked in production re-quoting (wire to wire time inside our network) well below 30 mics and auto-hedging well below 50 mics. So, to say we are not in the space is simply incorrect. We also know that we are competitive because of the many users we have around the world using our automated trading tools. We have more engineers than you may realize, and certainly more than we did in the past, who have come out of HFT prop firms and so many of the strategies used (including pre-creating orders as you mentioned) are known to us and will certainly make their way into the product in the coming months.

It's important to note that all our recent talk about performance is not referring to X_TRADER but to our new platform which has slowly been gaining traction over the last 18 months. It grew significantly in terms of volume and number of users in the second half of 2016, largely on the back of the performance improvements we've made in TT over X_TRADER.

 

[Drew Shields]

30/50 milliseconds or microseconds?

Microseconds

For Autospreader in particular, we actually show these latencies in the audit trail in the UI in real time.

 

[oversea]

Oversea, I'm sorry to hear you've had such trouble. I'm not sure the specifics so if you could PM me the details I'll gladly follow up. If you are looking to get connectivity via FIX on the TTNET infrastructure, I would recommend we chat either way so you understand the benefits of the new platform, especially when it comes to FIX. Before you pursue other options, I hope you'll give us a chance to get your connectivity issues resolved and explain the differences between the two offerings.

Thanks a lot for the message - I sent you a PM.

 

[Zzzz1]

What do you mean inside your network? A trader cares about the latency from order submission off his engine till it reaches the matching engine.

Microseconds

For Autospreader in particular, we actually show these latencies in the audit trail in the UI in real time.

 

[Drew Shields]

What do you mean inside your network? A trader cares about the latency from order submission off his engine till it reaches the matching engine.

I mean the time under our control.

For requotes, this measures from the moment a price/book update hits our network from the price feed to when the order leaves our network.

For a hedge, this measures from the moment a fill message hits our network from the exchange to when the hedge order leaves our network.

We are measuring this the same way any automated trading shop would measure their latency. We capture a value in the audit trail for real time consumption by users based on when it hits the application layer but are also monitoring/evaluating the same metrics via packet capture on every market.

 

[Zzzz1]

Sorry but this is getting incredibly confusing. I thought you are in the business of providing connectivity. All of a sudden we are not talking about Fix and load balancers and non static IP addresses (something I think is hugely inferior to direct routes) any longer but we are talking about trading software applications and logic. If I understand your whole pitch correctly then you are in the process of retooling from a pure frontend application developer into a connectivity partner, moving your efforts upstream so to speak.
What I am confused about is where you exactly fit in the space you are claiming you are capable of managing? Anyone in micro and millisecond space will run a headless execution logic in software or hardware form and highly proprietary and customized colocated with exchange or alternative venue matching engines. The connect will either be directly with exchanges or ecns or else via a PB for pretrade risk. Where exactly are you in that pipeline?

I mean the time under our control.

For requotes, this measures from the moment a price/book update hits our network from the price feed to when the order leaves our network.

For a hedge, this measures from the moment a fill message hits our network from the exchange to when the hedge order leaves our network.

We are measuring this the same way any automated trading shop would measure their latency. We capture a value in the audit trail for real time consumption by users based on when it hits the application layer but are also monitoring/evaluating the same metrics via packet capture on every market.