Imported from previous forum
Hi,
I have come across a situation where client requires us to support multi leg orders. This is specifically for derivatives orders.
My Query:
In New single order 35=D (Fix4.2), how can we identify the various contract description along with their respective QTy, Price and Side? There could be more than 2 contract order that can be received in a single new order.
Appreciate your help in detail Tag description.
Thanks,
Sachin
NewOrderSingle is not NewOrderMultiLeg, simple as that. FIX 4.2 does not offer a message for the entry of multi-leg orders, FIX 4.3 or later do. So I would use a user-defined message modeled after the NewOrderMultileg of a higher version. This is a lot better than applying structural changes to NewOrderSingle with user defined tags.
Do not try to put the multi-leg information into the standard fields of the NewOrderSingle somehow. The semantic of this message just does not offer it.
Regards,
Hanno.
Hi,
I have come across a situation where client requires us to support multi
leg orders. This is specifically for derivatives orders.My Query: In New single order 35=D (Fix4.2), how can we identify the
various contract description along with their respective QTy, Price and
Side? There could be more than 2 contract order that can be received in
a single new order.Appreciate your help in detail Tag description.
Thanks, Sachin
Another technique, used in pairs trades but can also be applied to options trading, is to send each side (or leg) of the order in a separate NewOrderSingle messages and associate them with a common ID via a user defined tag (or tag 583 if using FIX 4.4 or greater).
I’m rather cool to the idea, though, because it it requires the order recepiant to manage the timimng of the orders - probably by setting a timer when the 1st order arrives then rejecting both if the 2nd order arrives too late. Then there’s also the risk of non-tandem execution which the recipiant should assume. So while I really don’t agree with this approach I though I’d let you know that there are some brokers who accept orders this way.
Cheers.
-Greg
NewOrderSingle is not NewOrderMultiLeg, simple as that. FIX 4.2 does not
offer a message for the entry of multi-leg orders, FIX 4.3 or later do.
So I would use a user-defined message modeled after the NewOrderMultileg
of a higher version. This is a lot better than applying structural
changes to NewOrderSingle with user defined tags.Do not try to put the multi-leg information into the standard fields
of the NewOrderSingle somehow. The semantic of this message just does
not offer it.Regards, Hanno.
Hi,
I have come across a situation where client requires us to support
multi leg orders. This is specifically for derivatives orders.My Query: In New single order 35=D (Fix4.2), how can we identify the
various contract description along with their respective QTy, Price
and Side? There could be more than 2 contract order that can be
received in a single new order.Appreciate your help in detail Tag description.
Thanks, Sachin
As Greg says, a user defined Tag with NewOrderSingle, instead of that, if a user defined tag will be used in NewOrderList (35=E) and this tag will signify if it is a MULTI LEG order or not. In this case there is no need to manage the timing.
Will this solve the purpose??
Amiya.
Another technique, used in pairs trades but can also be applied to
options trading, is to send each side (or leg) of the order in a
separate NewOrderSingle messages and associate them with a common ID via
a user defined tag (or tag 583 if using FIX 4.4 or greater). I’m rather
cool to the idea, though, because it it requires the order recepiant to
manage the timimng of the orders - probably by setting a timer when the
1st order arrives then rejecting both if the 2nd order arrives too late.
Then there’s also the risk of non-tandem execution which the recipiant
should assume. So while I really don’t agree with this approach I though
I’d let you know that there are some brokers who accept orders this way.Cheers.
-Greg
NewOrderSingle is not NewOrderMultiLeg, simple as that. FIX 4.2 does
not offer a message for the entry of multi-leg orders, FIX 4.3 or
later do. So I would use a user-defined message modeled after the
NewOrderMultileg of a higher version. This is a lot better than
applying structural changes to NewOrderSingle with user defined tags.Do not try to put the multi-leg information into the standard fields
of the NewOrderSingle somehow. The semantic of this message just does
not offer it.Regards, Hanno.
Hi,
I have come across a situation where client requires us to support
multi leg orders. This is specifically for derivatives orders.My Query: In New single order 35=D (Fix4.2), how can we identify the
various contract description along with their respective QTy, Price
and Side? There could be more than 2 contract order that can be
received in a single new order.Appreciate your help in detail Tag description.
Thanks, Sachin
Technically yes, semantically no as NewOrderList (Order-List in FIX 4.2) contains orders than can be independently executed. FIX 5.0 SP1 introduced tag 1385 ContingencyType to convey dependency information between orders, e.g. one-cancels-the-other. It still means that one order is executed and then an action is taken on another order of the same list.
Multi-leg orders are different as you cannot execute only one of the legs. It is a single entity.
I do not see that you can really reduce effort by using NewOrderList as opposed to a user-defined message modeled after of the proper standard message of a higher version. In case of NewOrderList, the recipient would need special logic to make sure the pieces fit together and then collate them into a single entity. You would have order ids that are actually leg ids and other details to watch out for.
FIX 4.2 was released 9 years ago now (March 2000). How many software products do you have running where the latest update was that long ago? Your business needs have obviously evolved. I would try to look forward and reap the benefits from higher versions to ease a transition that will eventually happen anyway. FIX had about 450 tags to offer in FIX 4.2. The upcoming FIX 5.0 SP2 has four times that amount, i.e. over 1600 tags. All these additions came from new business needs and the current FIX “toolbox” is better than ever. FPL obviously wants people to take advantage of it.
Regards,
Hanno.
As Greg says, a user defined Tag with NewOrderSingle, instead of that,
if a user defined tag will be used in NewOrderList (35=E) and this tag
will signify if it is a MULTI LEG order or not. In this case there is no
need to manage the timing. Will this solve the purpose?? Amiya.
1 Like
Hi guys,
In FIX4.4, what is the standard way of handling MultiLeg fills?.
Should we look to have an execution report per 'Leg Fill', or just one execution report and the fills detailed via repeating groups in that one exec report?
many thanks
Graham
Hi Graham,
Below are the relevant specifications: (FIX44 specs, Volume4, June18, 2003)
Use of the Execution Report for Multileg Instruments:
The Execution Report has been expanded to include an optional repeating group of instruments legs. The instrument leg repeating group will not be used to track order status (LeavesQty, CumQty, etc.). The instrument leg repeating group can be used to report:
· Each leg of a multileg instrument – this provides a method for data enrichment for productized multileg instruments that can be identified on orders using only the Instrument block.
· The user supplied per leg information for Party block, PositionEffect, CoveredUncovered
· To report the price specified by the user on the order.
· Reporting of last sales price per leg, settlement type, and settlement date.
The multileg repeat group cannot be used to report the following:
· fill quantity per leg
· order status per leg
There are three different ways strategies can be traded on markets.
1. As a product identified by an Instrument block in which all legs of a multileg instrument are traded atomically in the ratio quantities specified for leg where contraparties to the trade are also apportioned per the ratio quantities defined per leg. (Note this method applies to strategies that are or will be productized in the securities definition table)
2. As a product identified by an Instrument block in which all legs of a multileg instrument are traded, but they are traded against individual legs - likely resulting in contraparty trading quantities not corresponding to the ratio quantities. (Note this method applies to strategies that are or will be productized in the securities definition table)
3. As individual legs (legging in). (Note this method applies to strategies that are not and will not be productized in the securities definition table)
Multileg Instruments that are traded atomically and contraparties to the trade being assigned by ratio quantity can be reported by strategy by setting the MultilegReportType (442) field to 3. The OrdQty, LeavesQty, CumQty, AvgPx apply to the overall strategy. Quantities of each individual leg are calculated by multiplying the quantity field for the strategy quantity * the LegRatioQty.
Multileg Instruments that are not traded atomically (because they execute against orders and quotes for individual leg securities or they are traded on an open outcry environment by leg) can:
· Report fills by overall strategy and legs in a single Execution report, where instrument identification is in the Instrument Block and the leg instrument identification is in the Instrument Leg Block. The MultilegReportType field is 3. The OrdQty, LeavesQty, CumQty, AvgPx always apply to the strategy. Reporting must be done within the context of the strategy (ie: fills and partial fills are reported within the ratio quantities defined by the legs) even though contraparties have traded against individual legs and perhaps not within the ratio quantities defined by the legs. The LegRefID and ContraLegRefID are used to associate specific contra trade quantities against a leg with a specific contra party; or
· Counterparties can choose to send a summary Execution Report for the overall multileg instrument (MultilegReportType of 3) once the multileg order has been filled or partially filled, and then separately report details of each leg in separate Execution Reports. (MultilegReportType of 2). The OrdQty, LeavesQty, CumQty, AvgPx always apply to the strategy. Reporting must be done within the context of the strategy (ie: fills and partial fills are reported within the ratio quantities defined by the legs) even though contraparties have traded against individual legs and perhaps not within the ratio quantities defined by the legs.
· The summary Execution Report is within the context of the strategy. Instrument identification is in the Instrument Block. This summary report does not contain leg information nor contraparty information. ForExecTypes = Pending New and New only the summary execution report should be sent.
· The separate Execution Report for each leg is within the context of a single leg of the strategy. Leg instrument identification is in the Instrument Leg Block. These reports contain the contraparty information for each leg.
· The ExecType of each separate leg report should be the same as the ExecType stated in the summary Execeution Report; or
· Counterparties can choose to report fills by leg (without a summary Execution Report for the overall strategy). The MultilegReportType field is 2. Reporting should be done within the context of the strategy (ie: fills and partial fills are reported within the ratio quantities defined by the legs) even though contraparties have traded against individual legs and perhaps not within the ratio quantities defined by the legs.
· The Execution Report for each leg is within the context of a single leg of the strategy. Leg instrument identification is in the Instrument Leg Block. These reports contain the contraparty information for each leg. The OrdQty, LeavesQty, CumQty, AvgPx always apply to the strategy. Because a summary Execeution Report is not being sent, ExecType = Pending New and New will also have to be reported by leg.
· If reporting of leg fills is not done within the context of the strategy, leg instrument identification and details should be promoted to the Instrument Block. Also, the OrdQty, LeavesQty, CumQty, AvgPx then apply to the individual leg. The MultilegReportType remains 2. … Always refer to the customs and practices of specific marketplaces to determine whether a specific marketplace permits reporting fills that are not within the context of the strategy and under what conditions such reporting is may be allowed.
That's great, thanks a lot Yuval! :-)
Hi guys,
I’ve got another query on Multi Leg Orders 
When placing an ‘AB’ message in FIX 4.4, what is the best way to identify the strategy/spread that you are trading?
We are looking at using SecurityID (Tag48) with a relevant value in IDSource (Tag22) but is there a standard string to identify spreads?
For example, in Tag48, is it acceptable to use ‘EURIBOR JUN14|SEP14|DEC14 FLY’ for a Butterfly or ‘BOBL JUN14DEC14’ for a Calendar Spread’?
We will specify the leg information in the instrument repeating groups, as standard.
many thanks for any help
Graham
Graham,
Tag 48 (security id) / Tag 55 (Symbol) with relevant value in tag 22 (Id source) is used to represent the Stock/Index. Repeating group tags such as 600 (LegSymbol),608 (LegCFICode), 609 (LegSecurity Type), 610 (LegExpiry) are also considered.
Sudhir
Strings such as ‘EURIBOR JUN14|SEP14|DEC14 FLY’ are typically provided for display purposes. Tag 207 SecurityDesc is intended for that. I would advise against trying to “standardise” string formats and require parsing of strings to extract multiple elements. That should be covered with explicit fields as explained by Sudhir (leg level). CFIcode is an exception to this rule on strings due to it being an ISO standard that FIX chose to support in its messages.
Thanks for this @hanno.klein. Very useful input this is.
I’m currently evaluating an option to build NewOrderList (35=E) to support non-securitised multi-leg order (i.e. two orders with separate standalone securities as opposed to spread securities created by a market with standard expiry dates. On a usual model could you think of any tags which could come into the picture here on this topic?
1 Like
The choice of message boils down to whether the separate standalone securities are to be traded individually (the order split apart and filled or cancelled at different times usually without affecting the outcome of the other security) or as an atomic unit (acknowledged and filled all-or-none). For the former use NewOrderList(35=E). For the latter use NewOrderMultileg(35=AB).
NewOrderList(35=E) is used to submit multiple individual orders to a broker or trading platform to be traded independently. E.g. if the list contains an order to buy or sell 3 corporate bonds individually there will be three instances of the <ListOrdGrp> component. Fills may be returned for the first, then sometime later for the third and the broker may ultimately cancel the second without affecting the results of the first and third. The only difference from submitting multiple NewOrderSingle(35=D) messages is that the orders in NewOrderList(35=E) are linked through ListID(66) on submission and the ExecutionReport(35=8) messages returned report ListID(66) on acknowledgement, reject, cancellation and fill. As Hanno points out ContingencyType(1385) and the <TriggeringInstruction> component may also be used to construct contingencies among the individual orders.
NewOrderMultileg(35=AB) is used to submit one order identifying buys and sells of multiple securities to be traded as a unit. E.g. a typical treasury butterfly involves a buy, a sell and a buy of three different bonds. For a multileg, the executing broker or trading platform will acknowledge receipt, reject or cancellation of all legs of the strategy all-or-none. Fills will also be all-or-none but may result in multiple messages depending on the venue - see MultiLegReportingType(442).
In the FIX standard the NewOrderList(35=E) message does not support multileg strategies but there are trading platforms out there that do support them in list trading. In that case each instance of the <ListOrdGrp> may either be an outright or a multileg and each instance of the <ListOrdGrp> will be reported independently within the restrictions of that item.
2 Likes