Appendix I: Security Definition, Security Status, and Trading Session Message Scenarios – FIX 4.4 – FIX Dictionary

Overview

A set of messages has been defined for the definition and dissemination of securities information traded between two parties. These messages allow for the ability to define complex, multi-leg financial securities, such as options strategies, futures spreads, underlying-derivative combinations, indexes, and baskets. Security Definition Request <c> message is used to define a security to the counterparty for trading and to retrieve definitions for securities available for trading with the counterparty.

The Security Definition <d> message can also be used to query a list of securities offered by a trading party. This message is useful for obtaining lists of products that are traded on a market. Although intended to support exchange style trading – this capability should also be of use in trading between any two trading partners.

Two additional messages have been added for status purposes: The Security Status <f> message and the Trading Session Status message. The Security Status message is based upon the Trade Related message proposal from IAC.

The Security Status message provides solicited or unsolicited status information on securities. An exchange can use this message to transmit change in trading state of a product. Security Status Request <e> message can be used to query the state of a product or to subscribe for security state changes.

The Trading Session Status <h> message has been added to provide status on a market. An exchange can use this to indicate status on the overall market and to provide a list of securities traded during that trading session. Two trading parties can also use this message to communicate information on two-party trading. The Trading Session Status Request <g> message is used to query the state of a product.

Both the Security Status message and Trading Session Status message include a SubscriptionRequestType <263> field, which is used to tell the counterparty application if the requesting application wants to receive a snapshot of status or wants to subscribe for unsolicited messages as the status of the security (or trading session) changes.

Background

The motivation behind these messages was to identify a method to be able to trade derivative strategies (butterfly spread, vertical spread, calendar spread, covered write, etc.) and to provide a mechanism to define FLEX Options using the FIX protocol. Most exchange trading systems have some type of product definition service. Although the motivation for the new messages was to support the communication between trading party and exchange, it was important to make any message flexible enough to support a variety of applications, including the ability to retrieve information about securities available for trading with a counterparty. The ability to query for a list of securities is very important in an exchange environment – where the retrieval of “standing data” from the exchange is needed by many trading systems.

Definitions

• Strategy - A group of related securities that are traded atomically at a net price.

  Examples:

  • Vertical Spread
  • Butterfly Spread
  • Calendar Spread
  • Covered Write
  
  
• Strategy Leg - One Security within a strategy
• Spread - combination of derivative securities whose maturity date or strike price is spread, creating a synthetic Security.
• Synthetic - A financial security that is the result of holding positions in multiple securities.
• Combination - alias for spread or strategy.

Approach

A Security Definition Request <c> message can be used to define and/or request a specific Security to be traded with a counterparty.

The Security Definition <d> message is used to:

• Indicate acceptance of a Security defined in a previous Security Definition Request message.
• Indicate acceptance of a Security defined in a previous Security Definition Request message with changes to the definition and/or symbol or security ID.
• Reject the request for security.

Extensions to other messages

One additional field, MultiLegReportingType <442>, is to be used on the Execution Report to indicate if the Execution Report is for the multileg security itself or an individual leg of the multileg security. Absence of this field in the Execution Report implies that the report pertains to the entire security – not an individual leg.

The agreement on how parties report multileg security execution is left to individual trading parties and is to be configured out of band. The FIX protocol will not provide a mechanism to specify how multileg execution reporting should be done.

For an example:

A straddle is an option strategy that consists of simultaneously buying a call option and a put option at the same strike price and maturity date. The straddle is defined for trading using the Security Definition Request <c> Message. Once the straddle is defined, via receipt of the Security Definition <d> Message from the counterparty (in this case an options exchange), a New Order Single <D> is used to submit the order to trade this newly defined multileg security. If the parties agree to report multileg execution by individual legs– then an execution report will be generated for each leg of the option strategy. If the parties agree to report multileg execution by multileg security only, then only one Execution Report <8> will be issued for the fill.

Reporting by leg is required for equity options as clearing houses will only understand the individual option series legs. Reporting by legs permits the trading parties to accurately maintain positions.

Rules

• The Security identification negotiated during the session is, by default, assumed valid only during the session. This eliminates the requirement for, but does not prevent the use, of a service to define and keep Securities persistent.
• Once a Security is defined, it will be traded as a regular Security
• Once a Security is defined, it will be traded at a single net price
• Once a Security is defined, it can be traded by FIX 4.1 compatible systems (This provides for backward compatibility and the ability to maintain Security information outside of FIX so that FIX 4.1 engines can participate).

Specifying Derivative Trading Strategies using the Security Definition message

The Security Definition message can be used to specify multiple legs of a derivative trading strategy. The first set of security related fields are used to name and identify the proposed strategy. This is followed by the NoRelatedSym <146> field, which indicates the number of legs in the proposed security. After the NoRelatedSym field, security related fields are repeated for each leg in the proposed security.

Two additional pieces are needed specify the strategy.

• RatioQty <319> is a quantity field that indicates the ratio of the leg to other legs in the strategy.
• Side <54> indicates if that particular leg will be bought or sold as part of the strategy.

  Example using RatioQty <319> and Side <54>:

  A Butterfly strategy consists of simultaneously:

  Buying 1 Call at Strike Price #1

  Selling 2 Calls at the next higher strike price (Strike Price #2)

  Buying 1 call at the next higher strike price (Strike Price #3)

  The Legs that would describe this strategy are as follows:

Scenarios

Scenario 1 - Typical use of Security Definition message in placing an Order

This scenario has the first party defining a strategy order using a Security Definition message.

First Party Second Party Security Definition Request <c> message SecurityRequest = 1 Propose an identity for the Security or Request an identity for the Security from second party Interprets Security request If second party accepted Security then the first party is free to use the Security in a trade Security Definition <d> message SecurityResponse=0 New Order Single <D> message Product = Security information from the Security Definition message Order is handled by exchange Execution Report <8> Order received (Most likely will need to add Security information to the Execution report) Execution Report <8> Fill Information on Order

Scenario 2 - Inquire Securities Types Available

This scenario has the first party requesting a list of Security types supported by the second party

First Party Second Party Security Definition Request <c> message SecurityRequest = 2 Processes Security Definition message First party can use this to select a list of messages Security Definition <d> message In this scenario, the trading party only trades three types of securities SecurityResponseType= 2 NoRelatedSym=3 UnderlyingSecuritySymbol=SecurityType#1 UnderlyingSecuritySymbol=SecurityType#2 UnderlyingSecuritySymbol=SecurityType#3

Scenario 3 – Inquire Common Stocks Available for Trading with Counterparty

This example shows how the Security Definition Request Message and Security Definition Messages can be used to return a list of common stocks available for trading with a counterparty. The first party specifies the SecurityRequest equal to 3 and specifies the SecurityType of common stock. The second party returns a list of common stocks available on its market. Note: This is intended to return standing data (static data) or a list of products available for trading – it is not intended to return an order book (see Market Data messages for this purpose). This is most applicable but not limited, to the case when the second party is an exchange.

First Party Second Party Security Definition Request <c> message In this scenario the initiator wants to obtain a list of common stock available for trading with the counterparty. SecurityRequest = 3 SecurityType = "CS" Processes Security request Create a list of common stocks that are available for trading. First party can use this to select a list of messages Security Definition <d> message Contains list of common stocks available for trading with the second party SecurityResponse = 3 NoRelatedSym = 25 UnderlyingSecuritySymbol = "AOL" …Other tags for this security UnderlyingSecuritySymbol = "GM" …Other tags for this security UnderlyingSecuritySymbol = "IBM" …Other tags for this security

Scenario 4 - Inquire all securities traded by a trading party

This scenario has the first party requesting a list of Security types supported by the second party.

First Party Second Party Security Definition Request <c> message SecurityRequest = 3 Processes Security request Create a list of the Securities available for the specified SecurityType First party can use this to select a list of messages Security Definition <d> message Contains list of Securities available for the specified the Security Types supported by second party SecurityResponse = 3 NoRelatedSym = XX Security information for each security is provided for each of the XX securities.

Scenario 5 – Inquire Option Classes Available for Trading with Counterparty

This example shows how the Security Definition Request <c> Message and Security Definition <d> Messages can be used to return a list of option classes available for trading with a counterparty. The first party specifies a Security Request Type equal to 3 (Request List of Securities) and the SecurityType of options. The second party returns a list of option classes available on its markets. Note: This is intended to return standing data (static data) or a list of products available for trading – it is not intended to return an order book (see Market Data messages).

First Party Second Party Security Definition Request <c> message In this scenario the initiator wants to see a list of option series for IBM that are traded by the counterparty (that may be an exchange) SecurityRequest = 3 SecurityType = "OPT" Processes Security request Create a list of common stocks that are available for trading. First party can use this to select a list of messages Security Definition <d> message Contains list of common stocks available for trading with the second party SecurityResponse = 3 NoRelatedSym = 25 UnderlyingSecuritySymbol = "AOL" UnderlyingSecuritySymbol = "GM" UnderlyingSecuritySymbol = "IBM"

Scenario 6 - Inquire list of option series for a class

This scenario has the first party requesting a list of option classes by setting the SecurityRequest equal to 3, the SecurityType to "OPT", and a security symbol = "IBM". Because a symbol is given, the second party sends back a list of option series for the class specified with a symbol or securityID.

First Party Second Party Security Definition Request <c> message SecurityRequest = 3 SecurityType = "OPT" Symbol = "IBM" Any of the security identification fields can be populated for this query Processes Security request Because a symbol is provided the second party sends back a list of option series. First party can use this to select a list of messages Security Definition <d> message Contains list of option series available for the specified the class specified in the request. SecurityResponse = 3 NoRelatedSym = XX Security information for each security is provided for each of the XX securities.