Forums  > Trading  > FX trading system : build vs buy  
     
Page 1 of 1
Display using:  

gammaphreak01


Total Posts: 17
Joined: May 2007
 
Posted: 2019-01-14 19:31
it seems that FX systems have become so commoditized these days that the incremental benefit of a system built in-house versus what is available from a vendor might only make sense if you are a significant flow-monster.

The common wisdom of the above statement is contradicted by the rise of a player such as XTX who have done amazing things with a relatively small team by all accounts.

It is always tempting (and fun for anyone with that bent) to build something - but if your flow is less than [x]bn per day and you are not massively latency sensitive should "common sense" prevail and the game be more about 3rd party system configuration and client service rather than build?

If so, any thoughts on any "common sense" choices: flextrade etc?






prikolno


Total Posts: 40
Joined: Jul 2018
 
Posted: 2019-01-17 07:37
I'll take a shot at your question.

Sure, FX and pretty much all exchange-traded D1 is commoditized when it comes to vendor connectivity.

But there's two major differences when you're considering a vendor for FX as compared to other D1 asset classes. One is that FX is extremely fragmented, even if you're comparing to, as an example, U.S. equities. Another issue is that FX platforms are much poorer documented and more heterogenous.

Vendors have always not had the right pricing incentives for connectivity. To a vendor, the cost of writing a CME, CBOE or LMAX feed parser is nearly the same, and the reachable market segment is driven by popularity and not by alpha. So it costs nearly the same to license connectivity to any venue through a vendor. Why pay $5,000 per month to license a LMAX feed handler when you can pay the same for an EBS feed handler and access a lot more flow? Answer: if you have more revenue capture on LMAX than EBS to compensate for the lower volume. But then likewise, why should you pay $5k MRC to license EBS after you've exhausted the lower hanging fruit at LMAX?

This is much less of a problem if you're trading a consolidated venue like CME and don't need to pool many different sources of flow to scale, but problematic in a fragmented setting where scaling involves adding more liquidity pools. So the amount of capacity or revenue you can extract per dollar spend on vendor connectivity is a lot less efficient in FX than other asset classes.

If you're building your own, you can triage the time spent and developer costs according to the revenue capture.

The second problem is that a vendor generally doesn't trade with their own products, so the stability of their products mostly depends on the quality of documentation and the usefulness of the UAT environment. There's a lot of edge cases in FX ECNs and liquidity pools that you don't encounter until you've traded on them. Examples which you may be less familiar with coming from an equities or futures background, and that may only trigger edge cases in production: situations where you need to write to 2 separate APIs to make and take at the same time, asymmetric speed bumps, unicast UDP, multiple sessions for different counterparty requirements.

If you're not going to build it yourself, your best bet for mitigating these 2 issues is to partner up with a trading firm that wants to license out their connectivity to reduce their own infrastructure costs.

Not sure what you mean with XTX as an exception? HC Tech, GTS, Jump, Virtu, Citadel have all done it with relatively small FX teams.

On the flip side, FX can well be more of a relationship-driven business depending on what strategy style you're going after, so you have leeway with tech quality, not something you'll see in lit equities or exchange-traded futures.

gammaphreak01


Total Posts: 17
Joined: May 2007
 
Posted: 2019-01-17 09:27
Thanks for the valuable insights

In respect of my XTX point:

It seems that the full cost of a trading system in FX that incorporates connectivity, aggregation, pricing, execution management and client distribution is probably the same as running a 30 person dev team (very loose heuristics).

So a simple business case might question the cost-benefit between the following types of options for implementing a client e-FX franchise (with respect to tech):
(a) fully outsourced with zero devs (of course BA type support required)
(b) fully in-house build
(c) modular hybrid with some in-house dev and some 3rd party vendor

The current "low-cost, outsourced service world" that we are in would suggest (a) or maybe (c) whereas my understanding is that XTX is an example of where (b) can really be a game-changer.

(c) above is probably the most expensive and time consuming strategy, but provides the most business agility and optionality.

All this being said, your observations on the relationship-driven business aspect of FX is a crucial point which possibly far outweighs any optimisation between (a), (b) or (c) above

thanks again for your comments

prikolno


Total Posts: 40
Joined: Jul 2018
 
Posted: 2019-01-17 20:44
No problem. Actually my firm did adopt approach (c) at first. The idea was that we'd have a tick-tock cycle like Intel where we'd be able to enter any market faster through a single vendor API that we're coded against ("tick"), and then we'd optimize later by replacing it with our own ("tock"). Sounded idealistic at the time.

The reason we dropped it was that we found that the vendor APIs have so many issues, often idiosyncratic to each venue, that it took us longer to debug than it took to just write our own feed handler and order router each time we added a new venue.

YMMV.

Tyrannosaurus


Total Posts: 4
Joined: Jan 2019
 
Posted: 2019-01-26 07:16
XTX is crushing you on pricing, not infra. Until you're fast/smart enough to consistently undercut them, moving to slightly faster systems won't help you much.
Previous Thread :: Next Thread 
Page 1 of 1