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 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 (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.
|
