Low-latency data feed and execution APIs

[loopquantumgirl]

Quote from MRBRETTONWOODS:

QH's QF is in C# BTW. Another one that you might want to look at is 'Object Trading', they simply offer an API (including FIX) for both market data and execution directly interfaced to a variety of exchanges. They also have some limited risk management solutions and they also have co-location. Although, I believe they are positioned more at the high-end.

Ullink is another one, although for data, they're using IDC's consolidated feed (not recommended).

Quote from hoppla:

That's also what I recall. Not sure what their target market is as anyone with low-ish latency requirements and appropriate setups has the capacities to do that themselves. It's not that hard and intensive a project. I would never want to rely on a 3rd party product for that part of the business. That being said, I have no direct personal experience with the product so it may be fantastic.

Thanks for the color on QH and ULLINK.

My experience is that it isn't difficult from a software development perspective to write feed handlers for (or an API for the protocols used at) every additional venue. But:

- The variable costs increase nonlinearly with each and this factored in, it's still an order of magnitude costlier to rely completely on an inhouse stack.
- The main issue has to do with the opportunity cost-benefit analysis: a 7 digit expense on 3rd party software may seem better spent elsewhere, but a 6 month development time with a 7 digit expense is very expensive too.
- As you've said, we have 'low-ish latency requirements', but low latency really isn't our competitive edge.

For these reasons, there's justification for relying on a 3rd party normalized feed or connection.

 

[hoppla]

I didn't mean feedhandlers with my comment. I agree that if you don't have ultra low latency requirements then there's no need to write them yourself (and pretty boring too). I was referring to QH's product which seems to be geared towards backtesting where I just don't see any benefits from not building this in-house. Actually negatives only.

 

[nitro]

Quote from hoppla:

I didn't mean feedhandlers with my comment. I agree that if you don't have ultra low latency requirements then there's no need to write them yourself (and pretty boring too). I was referring to QH's product which seems to be geared towards backtesting where I just don't see any benefits from not building this in-house. Actually negatives only.

They are nowhere near boring. Writing ultra-low latency feed [and corresponding systems to take advantage] touches on al most every aspect of computer science.

I have seen 100 programmers try to write something that can scale at this level and 95 of them fail flat on their face.

 

[hoppla]

Quote from nitro:

They are nowhere near boring. Writing ultra-low latency feed [and corresponding systems to take advantage] touches on al most every aspect of computer science.

Didn't mean to come across offensive. It's just not the area I am particularly interested in and also readily admit no expert knowledge especially when it comes to kernel level and hardware interfacing type stuff. But I can appreciate why some love it.

 

[ofthomas]

fair enough...

I went by this statement from you: "I haven't read too deep into the link you've provided but it doesn't seem to be what I'm looking for" ....

either way, I personally got stuck on the above bc I do deal with people like that in your position, that do not bother to review a solution or proposal properly and end up shutting down things because they lack understanding and knowledge...

as I read your prior statement again, I should have noticed this part: "My role with the budget is to reduce counter party risk, expand and improve on the existing infrastructure" ... that contained what you explained below...

and I don't use them for their back testing, or even data, but rather for their execution and proximity... for an individual like myself, much lower cost than if I had to co-locate at the venues I care about considering what i do for my personal account.

Quote from loopquantumgirl:

I'm not dense-headed. If a proposition works well, I can say "OK great I'll call them up" and chip in a few lines if I have additional information for the mutual benefit of the person who made the proposition. If it doesn't work well, I'm not going to spend 100 lines elaborating why it doesn't just to show that I've taken your suggestion seriously and assessed its features. I play a sufficient part in the software development to understand the end requirements, but it doesn't require a specialized developer to see these:

1. Embium doesn't integrate well with any of our existing infrastructure: We don't need a cloud-based historical data solution; we're not a .NET shop; we're not going to rewrite our existing libraries to work with them; we have our own execution hardware; we don't have clearing relations with any of their partners and don't intend to. (Although we've been considering Newedge recently.)

2. The description of the agent-based market simulation with 10,000 iterations per second suggests that this firm does not really have the level of sophistication we're seeking to outsource a crucial part of our infrastructure to.

3. I was unimpressed by the claim of processing "1 year of data under a minute" as that doesn't really say anything (1 year of OTM Albanian yak options?), and it's not something I'd advertise unless I'm really grasping for straws.

 

[MRBRETTONWOODS]

Quote from loopquantumgirl:

Which low-latency data feeds and execution APIs would you guys recommend for a 6 to 7 digit annual budget for infrastructure? I'm just being short of the capital to write feed handlers for every exchange directly although I'm open to compelling arguments to do so.

1. I hope to cover these markets in decreasing priority:
- Execution and data in all U.S., Eurex, SGX, KRX, HKEx, ASX (SFE) futures.
- Execution and data in Tokyo, HKEx, KRX, SGX, MYX equities.
- Data in all U.S. and LSE equities.
- Data in above-listed markets' futures and equity options.
- Data in OPRA feed.

2. I'm looking for DMA; if it's a broker-specific solution, the broker should not be receiving any payments for order flow.

3. Lowest latency is not my priority. Max 120 microsecond RTT in U.S. markets is the service level requirement. (Adjust appropriately for the other markets.)

I've heard TT via Newedge, ORC and QuantHouse so far. What about data?

So, Did you end up picking RTS or ORC?