Forex Magnates reached out to Sassan Danesh, managing partner of Etrading Software for his perspective on FIX standardization and the genesis of the Trading Enablement Standardization Initiative (TESI) as it relates to FX. His interview can be read in full below.
1. What is the present landscape for FX platforms and how does the fragmentation of liquidity factor into this?
The background to this is the fragmentation of liquidity and the increasing number of FX platforms that we are seeing in the marketplace and it looks as that trend is not changing anytime soon.
Of course what this increasing fragmentation is doing is making it much more important for the sell side, that is to say liquidity providers, to be able to interact with a broader client base with much wider channels. A long time ago they might have just had a couple ECMs and so they would have just used connectivity to reach out to their respective client bases with multi-data platforms.
The reality today is that it is a much more complex market structure and that there are lots of different platforms, each innovating with slightly different models and so on. Thus we have a much greater dispersion of platforms, each specializing in some area.
2. What challenges of headwinds do you face and is there any evidence of standardized FIX measures to allay potential concerns?
The challenge we are trying to address here are less trading challenges, such as how you integrate the APIs for trading – of course most have always been based on FIX already and thus have a reasonable amount of standardization. And this has, in turn, made life a lot easier for the big sell side, to be able to manage the increase in the number of platforms.
From their perspective they have setup their FIX engines. Yes they need to customize it for each platform, but it’s only a customization effort rather than starting from scratch and starting the whole connectivity from there each time a new platform comes out.
The part we are talking about here is what I call the administration of clients’ relationships through a third-party platform. There are so many different types of trading relationships that the buy side may have with the sell side.
Bitcoin: Can it Hit 100k in 2021?Go to article >>
To give you a trivial example, some buy side may want to be able to send RFQs (request for quotes), among other things. The type of trading activity might be configured or configurable based on either the type of buy side clients or the specific asset classes dealt with.
Some of the NDFs, for example, or specific types of buy side cannot go short, they can only go long, so this needs to actually be built into the permission of multi-data platforms. The Indian rupee was one of such challenges a while ago.
4. Can you explain some things that need to be administered or bridged across the buy and sell side?
There are a whole bunch of things that need to be administered across the buy and sell side. There are lots of complex rules here. What we have done at TESI is to automate all of these so there is a standard way for a sell side to reach out and interact with any buy side organization through the multitude of channels out there.
This is quite important because, critically, buy side should be treated in the same way regardless of the channel they are going through. So imagine if a buy side asks for a quote from the sell side through FXall or Bloomberg, etc.
Actually the mode of interaction and permissioning should be based on the buy side, based on their trading relationships – it must be consistent. Historically, that’s not been the case because the information about what is the trading relationship is known by the sell side, known by the buy side, but how does the trading platform in the middle know what this relationship is. Of course they have to be notified but that notification has been manual or ad hoc via emails, faxes, and different types of error prone approaches.
4. What is the impetus behind TESI and how does it impact trading relationships?
TESI is all about automating the transfer of these trading relationships between the buy and sell side. Automating or standardizing this to allow the sell side on behalf of their buy-side clients to be able to “STP of enablement” this information and update this through a zero-touch on their platforms and notify the platforms of any changes in the relationship.
The entire marketplace can, critically, find this out so that the trading relationship between the buy side and sell side can be maintained and be guaranteed to be consistent regardless of the channel that the buy side is using.