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.
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.
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:
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.
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.
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.
Scenario 2 - Inquire Securities Types Available
This scenario has the first party requesting a list of Security types supported by the second party
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.
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.
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).
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.