By Irfan Syed, Managing Director, Fixnox
The FIX protocol, like many other computer protocols, has always been a domain of techies. They are the ones to set up new FIX connections and ‘certify’ them by complying with FIX rules of engagements of counterparties before the users – traders in the case of FIX connections – start to trade over them after minimal testing.
And for any changes or enhancements, traders communicate requirements to their connectivity team, and in turn these techies enhance FIX connectivity software to support the changes and ‘certify’ the FIX connection again. Or if the connectivity team didn’t fully understand the business and/or the protocol, they would just reject the requirements with an excuse that requirements are not supported in FIX, in a particular version of it, or their FIX engine software.
In most organisations, connectivity teams’ understanding of the FIX protocol is often incomplete due to the very fact that many of the terms used in FIX specifications, white-papers and guides will only make complete sense to someone who understands the business of trading well. It should not be expected that technical people will understand “order capacity”, “price improvement” and “participation rate” without reasonable knowledge of the business and industry. But these very terms are used all over the FIX documentation.
In an ideal world, all traders should be well-versed with FIX protocol specifications and adopt a habit of using these as a reference during conversations about trading connections. But most traders, who are already overwhelmed with information in today’s fast moving markets, do not realise the value and competitive edge which can be gained by acquiring knowledge of FIX protocol and using it to set their trading connections ‘right’.
However change is in the air. In the highly competitive world of buy-side trading, where trading technology and infrastructure has a direct impact on performance of buy-side trading desks, traders have started to take ownership of their tools. They are starting to have deep conversations with their technical teams so that they have correct and properly implemented tools to make precise trading decisions.
They have also started to realise that a complete understanding of a broker’s FIX capabilities – and shortcomings – must be an important factor in selecting a new execution provider.
And that is why we think a simplified FIX protocol guide for buy-side traders, with the most important stuff, should exist.
In collaboration with GlobalTrading magazine, we have created a first version of this guide which can be found at https://fixglobal.com/home/trader-fix-tags-reading/. This version is geared for buy-side traders who are active in equities and use FIX versions 4.2 and 4.4. In the near future and after collecting feedback from the community we aim to update this guide to include other asset classes and functionality specific to FIX 5.0. This guide covers the following business areas:
1. Security identification
FIX field 55 (Symbol) in FIX is still a very common method for security identification but this may not always be the best choice. A preferred alternative is to use a combination of fields 22 (SecurityIDSource) and 48 (SecurityID) which allow using any of a number of global security identification databases. ISIN, CUSIP, SEDOL, Bloomberg, RIC, all of them are supported.
Field 107 (SecurityDesc) can also be used to describe the security for manual trades, and field 207 (SecurityExchange) allows for indicating the market from where security identification was taken. Field 167 (SecurityType) in FIX can carry the type of stock (i.e. preferred stock) or CFICode for a futures product.
2. Order and venue identification
Buy-side firms identify their orders using Client Order ID field 11 (ClOrdID) but brokers use field 37 (OrderID). When requesting amendments or cancellations of an order, Original Client Order ID field 41 (OrigClOrdID) comes into play and chains ClOrdID of new trading instruction with the existing one being amended or cancelled.
In multi-market environments, buy-side institutions can indicate the market where order should be executed by providing its Market Identifier Code (MIC) in Execution Destination field 100 (ExDestination). In execution reports provided by sell-side firms, field 30 (LastMkt) is used to indicate the market where the order, or part of it, was filled.
Sell-side firms may also use field 851 (LastLiquidityIndicator) to indicate whether current fill was result of a liquidity provider providing or liquidity taker taking the liquidity.
Field 39 (OrdStatus) exists in all execution report messages so that sell-side firms can indicate the latest status of the order in their system.
3. Quantities
Buy-side institutions use Order Quantity field 38 (OrdQty) to specify the number of units of a security they wish to buy or sell. Quantity can also be provided as cash value – e.g. for FX trades – in field 152 (CashOrdQty). For CIVs, quantity is provided in field 516 (OrderPercent).
FIX protocol also contains fields for brokers to provide changing quantity information to the buy-side during order execution. Field 32 (LastQty) carries quantity executed in current fill, 151 (LeavesQty) contains quantity open for execution, and 14 (CumQty) has the quantity executed in current order so far.
For multi-day orders FIX has additional fields to carry intra-day quantity information. 424 (DayOrdQty) contains quantity open for execution and 425 (DayCumQty) carries executed quantity during current day. Both of these fields are applicable from 2nd day onward.
4. Prices
In FIX, price for a limit order is provided in field 44 (Price) and associated currency can be indicated in 15 (Currency) field. There is also tag 99 (StopPx) which is used to provide stop price of appropriate order types. In execution reports, sell-side firms use field 31 (LastPx) to indicate the price at which quantity in current fill executed, and field 6 (AvgPx) to provide average price of total executed quantity in current order. Then there is field 140 (PrevClosePx) which can be used to indicate the instrument’s previous day’s closing price. This field is sometimes used as an aid in security identification when symbology in use does not guarantee a unique instrument.
For multi-day orders, the sell-side may use field 426 (DayAvgPx) to indicate average price of quantity filled during current day. And if they have made any price improvement, they can send its value in field 639 (PriceImprovement).
For trades which are executed in one currency and settled in another, field 120 (SettlCurrency) indicates the currency in which those should be settled.
5. Execution management
FIX protocol supports various order types, and buy-side institutions can use field 40 (OrdType) to indicate the appropriate one for their orders. Order side is provided in field 54 (Side).
Buy-side institutions can also instruct their brokers how they should work on the order by using fields 21 (HandInst) and 18 (ExecInst). Field 21 carries general handling instruction of the order (automatic vs manual) while field 18 allows for provision of one or more specific execution instructions – for example “All or none”, “Stay on bid-side”, “Go along” or “Cancel on trading halt” etc.
FIX also allows the buy-side to control how their order should be displayed in the order books of the trading floor. Field 111 (MaxFloor) is used to indicate the quantity which will be visible on the trading floor at any given time, and 210 (MaxShow) indicates the maximum quantity which a broker can show to their other customers. The latter is useful in IOI flows as it restricts brokers not to fully disclose an order’s quantity in the IOIs they may send to their other customers.
Other useful tags for execution management are 110 (MinQty) – minimum quantity in the order which must be executed, 114 (LocateReqd) – if a broker is required to locate the stock for short sell orders, 847 (TargetStrategy) – name of strategy if order is for one e.g. VWAP, 848 (TargetStrategyParameters), 849 (ParticpationRate) – if target strategy is “Participate”, and 636 (WorkingIndicator) – a flag sent by a broker to indicate they are currently working on the order.
6. Date and time
FIX protocol has the following fields for carrying different date/time information in orders and execution reports. Note that most date/time fields in FIX use UTC/GMT times.
- 60 (TransactTime): Time when a trading instruction, e.g. an order was created in the trading system.
- 52 (SendingTime): Time when a FIX message was sent out by the FIX engine.
- 59 (TimeInForce): Effective time of an order. This can be Day, Good Till Date (GTD), Good Till Cancel (GTC), Immediate or Cancel (IOC), or Fill Or Kill (FOK) etc.
- 168 (EffectiveTime): Time when instruction provided in the FIX message takes effect. For example start time for an order instruction to become active.
- 432 (ExpireTime): Time when an order expires. This is always local time, instead of UTC.
- 75 (TradeDate): Date when a trade happened. Useful when a broker is reporting trades of non-current day.
7. Parties in trade
FIX also provide means to identify various parties involved in the trade, both from buy-side and a broker’s perspective. For example the buy-side institutions may use field 528 (OrderCapacity) to indicate their agency, proprietary, individual or principal capacity and 529 (OrderRestrictions) to specify restrictions on an order (e.g. foreign entity, market maker).
Brokers use 29 (LastCapacity) to indicate the capacity in which they executed the order – e.g. as an agent, principal or crossing as either. If they executed the order via a third-party, they may identify it in field 76 (ExecBroker).
FIX 4.4 and later versions also support repeating groups which can carry information about all parties involved in the trade. The information which can be exchanged may comprise of party ID, source of this identification, party’s role and party information like address, phone number and email address.
We believe that this guide will be useful for buy-side traders who are starting to take ownership of their trading connections. This will answer at least some of those FIX questions you always had but never asked.
At the very least, knowledge gained from this guide will lead to some ‘interesting’ conversations with your brokers, execution venues and internal connectivity teams.
Those conversations should in turn lead to more questions and a desire for even better understanding of FIX. We hope that you will send those questions to us so that we can address them in next update of this guide.
