Appendix E
Category: Multileg Orders (Swaps, Option Strategies, etc)
Background
A multileg security is made up of multiple securities that are traded atomically. Swaps, option strategies, futures spreads, are a few examples of multileg securities. This requirement that all legs be traded in the quantities that they make up the multlileg security is the important distinction between a multileg order and a list order.
Two generalized approaches to trading multileg securities are supported by FIX. The first approach involves a market maintaining multileg securities as separate products for which markets can be created. This "product approach"
is often used in electronic trading systems. The second approach is to trade the multileg security as a group of separate securities – as is commonly done today in open outcry markets.
The multileg order can be traded using one of the following trading models using FIX. The first three models are variations on the multileg security as a separate tradeable product. The last models permits trading of multileg
securities in environments where the multileg securities are not productized.
Predefined Multileg Security Model (FIX 4.2) (Model 1)
In this model a Security Definition Request for the security is sent to the counterparty that defines the multileg security and the legs. The counterparty accepts the security definition with an acknowledging Security
Definition message. The initiating counterparty can then send a New Order – Single <D> message that specifies just the multileg instrument without the legs.
| |
Counterparty 1 – Interested in trading a multileg instrument |
|
Counterparty 2 or Market |
| 1 |
Sends Security Definition Request <c> that defined Multileg Security |
→ |
Receives Security Definition Request – determines if multileg security has already been defined. If so – return identification of the multileg security – otherwise create the multileg security and return its
identification. |
| 2a |
Create the order |
← |
Reply with Security Definition <d> for multileg security with identification identical to that of the request |
| 2b |
Create the order |
← |
Reply with Security Definition <d> for multileg security with identification different from that of the request |
| 2c |
Exception Handling for failed Security Definition Request <c> |
← |
Reply with Security Definition <d> rejecting the security request |
| 3 |
Send New Order – Multileg <AB> for security identification provide in Security Definition Request <c> (The Instrument Leg component block is not provided) |
→ |
Accepts order for processing |
| 4a |
|
← |
If MultilegReportTypeRequest =0 or =1 or if market rules require reporting by multileg security:
Send Execution Report <8> for the overall multileg security (MultilegReportType=2) |
| 4b |
|
← |
If MultliegReportTypeRequest =1 or =2 or if market rules require reporting by multileg security
Send Execution Report <8> for each instrument leg defined previously for the multileg security (MultilegReportType=3) |
Enhanced Predefined Security Model (Model 2)
In the enhanced model – the multileg security is still defined as a product using the Security Definition <d> message. However, the instrument legs are elaborated on the order to provide clearing information per leg, such as LegPositionEffect <564>, LegCoveredOrUncovered <565>, and within <NestedParties> information such as
ClearingFirm for the leg, etc.
| |
Counterparty 1 – Interested in trading a multileg instrument |
|
Counterparty 2 or Market |
| 1 |
Sends Security Definition Request <c> that defined Multileg Security |
→ |
Receives Security Definition Request – determines if multileg security has already been defined. If so – return identification of the multileg security – otherwise create the multileg security and return its
identification. |
| 2a |
Create the order |
← |
Reply with Security Definition <d> for multileg security with identification identical to that of the request |
| 2b |
Create the order |
← |
Reply with Security Definition <d> for multileg security with identification different from that of the request |
| 2c |
Exception Handling for failed Security Definition Request <c> |
← |
Reply with Security Definition <d> rejecting the security request |
| 3 |
Send New Order – Multileg <AB> for security identification provide in Security Definition Request <c> (The Instrument Leg component block is not provided) |
→ |
Accepts order for processing |
| 4a |
|
← |
If MultilegReportTypeRequest =0 or =1 or if market rules require reporting by multileg security:
Send Execution Report <8> for the overall multileg security (MultilegReportType=2) |
| 4b |
|
← |
If MultliegReportTypeRequest =1 or =2 or if market rules require reporting by multileg security
Send Execution Report <8> for each instrument leg defined previously for the multileg security (MultilegReportType=3) |
Product Definition Model using New Order - Multileg Message (Model 3)
In this approach the Multileg Security is defined using the New Order - Multileg message. However, the market or counterparty still creates or maintains a product definition for the multileg security upon receipt of the New Order – Multileg <AB>.
| |
Counterparty 1 –
Interested in trading a multileg instrument |
|
Counterparty 2 or Market |
| 1 |
Send New Order – Multileg <AB> that includes the multileg security definition in the Leg Instrument Block |
→ |
Accepts order for processing
A product is defined or identified for the multileg security.
If the multileg security is not a valid product in the market – the order is rejected. The order is rejected using an Execution Report <8> – indicating an invalid product was encountered.
|
| 2a |
|
← |
If MultilegReportTypeRequest =0 or =1 or if market rules require reporting by multileg security:
Send Execution Report <8> for the overall multileg security (MultilegReportType=2) |
| 2b |
|
← |
If MultliegReportTypeRequest =1 or =2 or if market rules require reporting by multileg security
Send Execution Report <8> for each instrument leg defined previously for the multileg security (MultilegReportType=3) |
Single Message Model (Model 4)
No product definition is used (Likely will be used by open outcry markets that do not have a product definition service). The message flow is the same as model 3 – the difference being that the counterparty or market receiving
the order does not create nor maintain product information for the multileg security – most likely the multileg security is simply distributed to the market.
| |
Counterparty 1 –
Interested in trading a multileg instrument |
|
Counterparty 2 or Market |
| 1 |
Send New Order – Multileg <AB> that includes the multileg security definition in the Leg Instrument Block |
→ |
Accepts order for processing
The multileg security information is distributed to the market. No product definition takes place.
If the multileg security is not a valid multileg strategy in the market – the order is rejected. The order is rejected using an Execution Report <8> – indicating an invalid product was
encountered.
|
| 2a |
|
← |
If MultilegReportTypeRequest =0 or =1 or if market rules require reporting by multileg security:
Send Execution Report <8> for the overall multileg security (MultilegReportType=2) |
| 2b |
|
← |
If MultliegReportTypeRequest =1 or =2 or if market rules require reporting by multileg security
Send Execution Report <8> for each instrument leg defined previously for the multileg security (MultilegReportType=3) |
Messages Used for Multileg Trading
Order Entry
Use the New Order – Multileg <AB> message to submit a multileg order to a market place.
Execution Reports for Multileg Orders
The Execution Report <8> has been modified to report the order status of Multileg Orders.
Modification of a Multileg Order
Use the Multileg Order Cancel Replace Request (a.k.a MultilegOrder Modification Request) <AC> to modify a Multileg Order.
Cancellation of a Multileg Order
Multileg orders are canceled using the Order Cancel Request <F>. The entire multileg order is cancelled by OrderID <37> or ClOrdID <11>. The ability to cancel one leg of a multileg order is not supported in FIX 4.3 and above.
Multileg Pricing Methods
Multileg orders may be submitted using different pricing schemes.
1. Prior to FIX 5.0 SP1 LegPrice <566> was used to specify an anchor price for a leg as part of the definition or creation of a multileg strategy. Price <44> would not be specified if LegPrice is specified.
2. In FIX 5.0 SP1 the MultilegPriceMethod <1378> field was introduced that allowed a multileg security order's price is to be interpreted when it is applied to the legs of the order.
Pricing methods include:
Net Price. The price is given as the sum of the Price * Ratio for all legs.
- If buying the strategy, the price of a bought leg (which is a buy-leg in the multileg definition) is added, and the price of a sold leg is subtracted.
- If selling the strategy, the price of a bought leg (which is a sell-leg in the multileg definition) is subtracted, and the price of a sold leg is added.
This is supported by the Price <44> tag and the PriceType <423> = "Spread". However, it is assumed that the underlying are quoted in “price” (including “percent of par” for fixed income).
Reversed Net Price. This pricing convention is often used in commodities markets. The price is given as the sum of the Price * Ratio for all legs.
- If selling the stategy, the price of a bought leg (which is a sell-leg in the multileg definition) is added, and the price of a sold leg is subtracted.
- If selling the strategy, the price of a bought leg (which is a sell-leg in the multileg definition) is subtracted, and the price of a sold leg is added.
Yield difference. The price of a strategy order is given as a yield difference between two legs.
This is supported by the Price <44> tag and the PriceType <423> = "Spread". However, it is assumed that the underlying legs are quoted in “yield” (fixed income).
Individual Prices. The price of the strategy is given using individual prices for the legs.
This is supported by not specifying the root level Price <44> tag and instead specifying the LegPrice <566> of each leg. The LegPrice is used solely to “anchor” the overall multi-leg to an individual leg price.
Contract Weighted Average Price (Energy Specific). The price of the strategy is given as an average price of all legs in the multileg, including adjustment for differences in contract sizes between the legs.
Multiplied Price (Cross Currency specific). The price is given as the product of the prices for all legs, independent if the leg is bought or sold.
The PriceType of multileg has two dimensions:
- PriceType <423> defines how the Price <44> is expressed (per unit, yield, percentage at par etc)
- MultilegPriceMethod defines how that overall multileg price is to be interpreted when applied to the legs (the methods mentioned above).
|
