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 NewOrderSingle <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 SecurityDefinitionRequest <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 SecurityDefinition <d> for multileg security with identification identical to that of the request |
| 2b | Create the order | ← | Reply with SecurityDefinition <d> for multileg security with identification different from that of the request |
| 2c | Exception Handling for failed SecurityDefinitionRequest <c> | ← | Reply with SecurityDefinition <d> rejecting the security request |
| 3 | Send NewOrderMultileg <AB> for security identification provide in SecurityDefinitionRequest <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 ExecutionReport <8> for the overall multileg security (MultilegReportType=2) |
|
| 4b | ← |
If MultliegReportTypeRequest =1 or =2 or if market rules require reporting by multileg security
Send ExecutionReport <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 SecurityDefinition <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 SecurityDefinitionRequest <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 SecurityDefinition <d> for multileg security with identification identical to that of the request |
| 2b | Create the order | ← | Reply with SecurityDefinition <d> for multileg security with identification different from that of the request |
| 2c | Exception Handling for failed SecurityDefinitionRequest <c> | ← | Reply with SecurityDefinition <d> rejecting the security request |
| 3 | Send NewOrderMultileg <AB> for security identification provide in SecurityDefinitionRequest <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 ExecutionReport <8> for the overall multileg security (MultilegReportType=2) |
|
| 4b | ← |
If MultliegReportTypeRequest =1 or =2 or if market rules require reporting by multileg security
Send ExecutionReport <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 NewOrderMultileg <AB>.
| Counterparty 1 – Interested in trading a multileg instrument | Counterparty 2 or Market | ||
|---|---|---|---|
| 1 | Send NewOrderMultileg <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 ExecutionReport <8> – indicating an invalid product was encountered. |
| 2a | ← |
If MultilegReportTypeRequest =0 or =1 or if market rules require reporting by multileg security:
Send ExecutionReport <8> for the overall multileg security (MultilegReportType=2) |
|
| 2b | ← |
If MultliegReportTypeRequest =1 or =2 or if market rules require reporting by multileg security
Send ExecutionReport <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 NewOrderMultileg <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 ExecutionReport <8> – indicating an invalid product was encountered. |
| 2a | ← |
If MultilegReportTypeRequest =0 or =1 or if market rules require reporting by multileg security:
Send ExecutionReport <8> for the overall multileg security (MultilegReportType=2) |
|
| 2b | ← |
If MultliegReportTypeRequest =1 or =2 or if market rules require reporting by multileg security Send ExecutionReport <8> for each instrument leg defined previously for the multileg security (MultilegReportType=3) |
Messages Used for Multileg Trading
Order Entry
Use the NewOrderMultileg <AB> message to submit a multileg order to a market place.
Execution Reports for Multileg Orders
The ExecutionReport <8> has been modified to report the order status of Multileg Orders.
Modification of a Multileg Order
Use the MultilegOrderCancelReplace <AC> to modify a Multileg Order.
Cancellation of a Multileg Order
Multileg orders are canceled using the OrderCancelRequest <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.
- 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.
- .... [FIXME: need more content describing the use of MultilegPriceMethod <1378> field and what relation Price <44> field has to all this also]