Fri, 28/09/2007 - 09:31
It is clear from conversations with a broad range of market participants that inherent latency is a problem for active market participants on current FX trading systems. These systems may be slowed down because of consequences of architectural decisions they are locked into such as regional synchronization, time slicing, or inefficient trading protocols.
Regionally-synchronized systems were designed for markets where the bulk of activity was being transacted in one location at a time, and response times needed to meet the needs of manual traders who were insensitive to price/time priority. Venues that run geographically distributed 'books' are typically designed to look at the book closest to the user first to fill the order and then submit it to other centres if it cannot be filled locally. This design may produce a latency characteristic with a fat tail as it necessitates a timeconsuming synchronization process to make sure the books do not get out of step with each other. It is also more difficult for regionally-synchronized systems to honor price/time priority and ensure orders are filled at the best available rates, particularly in cases where the price maker and taker are not in the same region. As an increasing amount of flow is now transacted between centres via algorithmic trading tools, the inefficiencies of this design are increasingly evident.
Limitations of regional synchronization may be:
(See fig 1 & 2)
Best practice is moving to centralized architectures which perform better because they fairly honor price/time priority, are more predictable because of a thinner latency tail and are less costly to operate.
Timeslicing architectures wait a pre-set time between matching cycles and match all orders received during that interval rather than matching them on a continuous basis. If an order arrives at the beginning of the cycle, it will take the maximum timeslice time to match, during which period the market may have moved. Timeslicing architectures will have higher fill on take out (FOTO) times as a result. In addition, timeslicing architectures have higher and less predictable market data distribution times because they cannot publish information until the timeslice has been completed. A preferable solution is where orders and market data are handled in real time, which reduces latency and provides a more accurate representation of the current state of the market. Timeslicing has the potential to create gaming opportunities for those market participants who understand that they can submit orders at the end of the timeslice, cancel them quickly, yet have them persist in the market data feed until the next timeslice. In order to combat this, it may be necessary to build preventative measures into these systems to make them less predictable, at the expense of further fattening the latency tail.
Efficiency of Trading Protocol
The design of the trading protocol itself varies from venue to venue and can have a profound impact on latency. The parties communicating need to agree what language they are speaking, what information they need to exchange, and the order in which it is communicated. Market participants generally have a variety of options to consider such as proprietary APIs, XML, or FIX messaging, which result in trade-offs between speed, cost of implementation, reliability and flexibility. In addition to differences inherent between the various technologies, there can also be big differences between implementations in the amount of data they need to transfer and the number of times they need to communicate to effect a transaction. Regardless of whether the connections
are made directly, or with the help of a vendor, the underlying protocol can significantly impact trading latency. As an example, consider the simple requirement of cancelling an order. Some protocols are architected where the trader uses a unique order-ID generated by the venue to cancel an order, whereas other protocols are architected to use the trader's own order-ID to process the cancel. The former scenario adds both the processing time to generate the unique order ID and a round trip communication time to the time to cancel (TTC), which meaningfully adds to the risk of placing passive orders in those venues.
Credit checking reduces credit and operational risk for counterparties at the expense of additional processing time. In a low frequency trading world, it was sufficient to monitor credit a few times during the day with a manual process. However with the growing popularity of high frequency algorithmic trading, the market now requires that venues ensure they only produce trades which are appropriately credit approved. The good news is that participants can now get the inherent benefits that credit checking provides, by reducing operational risk with a minimal impact on latency when the credit checking is managed efficiently by the venue. Credit intermediaries that choose these platforms can avoid the awkward position of having to break trades if credit is later found to be insufficient. Market participants should be cognizant of the credit-checking mechanism of the venues they choose and understand that differences can exist between them. They should evaluate the operational risk of using a platform that does not perform a credit check at all or performs one only after counterparties are notified that they have dealt.
In addition to the underlying software architecture, the age and robustness of the trading infrastructure may play a part in latency. Trading platforms need to maintain up-to-date infrastructures to continuously reduce latency and should have the organizational capability to maintain their investments in technology to improve performance. Likewise, market participants should also make sure they have sufficient capacity to take advantage of industry advances and ensure sufficient performance to handle the trading strategies they are deploying.
Tue 16/06/2015 - 10:44
Tue 16/06/2015 - 10:39
Tue 16/06/2015 - 10:35
Tue 16/06/2015 - 10:29
Tue, 07/Jul/2015 - 07:46
Tue, 07/Jul/2015 - 07:43
Tue, 07/Jul/2015 - 07:36
Mon, 06/Jul/2015 - 15:05
Mon, 06/Jul/2015 - 15:03
Mon, 06/Jul/2015 - 14:55