Fix-5.0 SP1 Vol-7
Fix-5.0 SP1 Vol-7
Fix-5.0 SP1 Vol-7
EXCHANGE PROTOCOL
(FIX)
March 2008
DISCLAIMER
NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR
DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY
USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT,
INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA,
LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC
LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR
OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR
OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES.
No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein),
except as expressly set out in FIX Protocol Limited's Copyright and Acceptable Use Policy.
REPRODUCTION
FIX Protocol Limited grants permission to print in hard copy form or reproduce the FIX Protocol specification in
its entirety provided that the duplicated pages retain the “Copyright FIX Protocol Limited” statement at the
bottom of the page.
Portions of the FIX Protocol specification may be extracted or cited in other documents (such as a document
which describes one’s implementation of the FIX Protocol) provided that one reference the origin of the FIX
Protocol specification (http://www.fixprotocol.org) and that the specification itself is “Copyright FIX Protocol
Limited”.
FIX Protocol Limited claims no intellectual property over one’s implementation (programming code) of an
application which implements the behavior and details from the FIX Protocol specification.
Contents – Volume 7
DISCLAIMER...............................................................................................................................................................2
REPRODUCTION........................................................................................................................................................2
VOLUME INTRODUCTION.....................................................................................................................................8
CIV Example 13. Exchange/switch order quantities – OrderPercent, Rounding, Sell Driven..........................27
CIV Example 14. CIV Bulk order – purchase of funds for multiple investors into a designated nominee........28
CIV Example 15. Registration Instruction – Joint Investors..............................................................................29
CIV Example 16 Registration Instruction – Tenants in Common, .....................................................................31
PRODUCT: LISTED DERIVATIVES (FUTURES & OPTIONS)......................................................................32
USE OF CFICODE TO IDENTIFY DERIVATIVES SECURITY................................................................................................32
Single Leg Instruments.........................................................................................................................................32
Multileg Instrument Specification........................................................................................................................32
US LISTED OPTIONS ORDER CAPACITY VALUES........................................................................................................33
Proposed option order capacity codes and their FIX 4.3 equivalents...............................................................34
CUSTOMER ORDER CAPACITY(TAG 582) MAPPINGS FOR FUTURES CTICODE....................................................................36
NEGATIVE PRICES PERMITTED FOR FUTURES AND OPTIONS STRATEGIES.............................................................................37
DERIVATIVES MARKETS ORDER STATE TRANSITION....................................................................................................37
PARTY ROLES USED FOR DERIVATIVES MARKETS.......................................................................................................38
MAPPING FIX 4.2 TO FIX 4.3 USAGE FOR OPTIONS MARKETS..............................................................................39
GENERAL USAGE INFORMATION – US FUTURES MARKETS...........................................................................................40
EXECUTION TIME BRACKET REPORTING FOR US FUTURES MARKETS.............................................................................40
EXAMPLE NEW ORDER – SINGLE FOR LISTED FUTURES MARKET..................................................................................41
EXAMPLE NEW ORDER – SINGLE FOR LISTED OPTIONS MARKET..................................................................................45
EXAMPLE NEW ORDER - MULTILEG FOR LISTED FUTURES MARKET (BUTTERFLY STRATEGY)............................................54
EXAMPLE MULTLILEG EXECUTION REPORT FOR LISTED FUTURES MARKET.....................................................................61
Multlileg Execution Report Example for Futures Markets.................................................................................61
OPTIONS BACK OFFICE PROCESSING........................................................................................................................68
Background...........................................................................................................................................................68
Position Maintenance Report..............................................................................................................................68
Position Report.....................................................................................................................................................68
Trade Capture Report Ack...................................................................................................................................68
Trade Capture Report..........................................................................................................................................68
Security Definition...............................................................................................................................................69
Security List..........................................................................................................................................................69
Parties component block......................................................................................................................................69
Contrary Intention Report....................................................................................................................................69
Security Definition Update Report......................................................................................................................69
Security List Update Report.................................................................................................................................69
FIA TRADE IDENTIFICATION STANDARDS..................................................................................................................70
Background...........................................................................................................................................................70
Trade Identification Fields..................................................................................................................................70
Additional Identifier Definitions..........................................................................................................................70
Trade Identification Usage Table........................................................................................................................74
COLLATERAL MESSAGES FOR MARGIN MANAGEMENT.................................................................................................75
Background...........................................................................................................................................................75
Business Workflow...............................................................................................................................................75
Message flow with a clearinghouse.....................................................................................................................75
Use of Instrument and UnderlyingInstrument component blocks.......................................................................77
Marginable vs. Valued Collateral.......................................................................................................................77
COVERED SPREADS AND OTHER USER DEFINED SPREADS USING SECURITY DEFINITION MESSAGES.......................................77
Usage examples....................................................................................................................................................78
PRODUCT REFERENCE USAGE.................................................................................................................................80
Introduction..........................................................................................................................................................80
Business Workflow...............................................................................................................................................80
Product Reference Model....................................................................................................................................82
Market Segment and Venue.................................................................................................................................88
Message Flows.....................................................................................................................................................88
Usage exmples......................................................................................................................................................89
PRODUCT: EQUITIES............................................................................................................................................94
STEP-OUTS AND GIVE-UPS....................................................................................................................................94
CFDS................................................................................................................................................................95
CFD with cash equity hedge executed by same broker as writing the CFD......................................................95
CFD with cash equity hedge executed by different broker from that writing the CFD.....................................95
COMMISSION SHARING ARRANGEMENTS....................................................................................................................97
Soft Dollars...........................................................................................................................................................97
Directed Brokerage..............................................................................................................................................97
MULTI-DAY AVERAGE PRICING..............................................................................................................................98
Introduction..........................................................................................................................................................98
Flow Summary......................................................................................................................................................98
Example Warehouse Flows..................................................................................................................................99
Decision Flows...................................................................................................................................................103
REGULATION SHO - SHORT-SELL SECURITY LOCATE...............................................................................................105
STRATEGY PARAMETERS FOR ALGORITHMIC TRADING................................................................................................105
REGULATION NMS............................................................................................................................................106
Background.........................................................................................................................................................106
Order Protection Rule Compliance...................................................................................................................106
Sub-penny Rule Compliance..............................................................................................................................109
OATS PHASE 3 REQUIREMENTS...........................................................................................................................109
Background.........................................................................................................................................................109
Meeting OATS 3 Requirements using FIX.........................................................................................................109
TrdRegTimestamp Usage Example for OATS 3................................................................................................111
EXTERNAL ORDER ROUTING CONTROL...................................................................................................................113
PRODUCT: FIXED INCOME (FI).......................................................................................................................114
INTRODUCTION...................................................................................................................................................114
MESSAGE DIALOG..............................................................................................................................................114
Indication of Interest (Offerings).......................................................................................................................115
Negotiated Trade /Inquiry/Bid or Offer Request...............................................................................................116
Out-of-Band Negotiated Order..........................................................................................................................120
Allocation Instructions.......................................................................................................................................122
Post Trade Reporting to a 3rd Party or Virtual Matching Utility....................................................................126
MESSAGE USAGE DETAILS...................................................................................................................................128
General Usage Rules..........................................................................................................................................128
Indication Of Interest.........................................................................................................................................128
Quote Request.....................................................................................................................................................128
Quote Response..................................................................................................................................................129
Quote..................................................................................................................................................................129
New Order - Single.............................................................................................................................................129
New Order - Multileg.........................................................................................................................................129
Execution Report................................................................................................................................................130
Allocation Instruction.........................................................................................................................................130
Allocation Report...............................................................................................................................................130
Trade Capture Report........................................................................................................................................131
Instrument component block..............................................................................................................................131
OrderQtyData component block........................................................................................................................131
REPURCHASE AGREEMENTS (REPO) AND COLLATERAL MANAGEMENT..........................................................................131
Repo Terminology..............................................................................................................................................131
Collateral Management.....................................................................................................................................138
IDENTIFYING EURO ISSUERS ..................................................................................................................................145
Euro CountryOfIssue Codes:.............................................................................................................................145
Euro Issuer Values:............................................................................................................................................145
EXAMPLE USAGE OF FI SPECIFIC COMPONENT BLOCKS................................................................................................148
Example usage of BenchmarkCurve fields........................................................................................................148
Example usage of Stipulation fields...................................................................................................................149
PRODUCT: FOREIGN EXCHANGE..................................................................................................................150
INTRODUCTION...................................................................................................................................................150
MESSAGE DIALOG..............................................................................................................................................150
Price Discovery..................................................................................................................................................150
General Order and Execution Handling...........................................................................................................157
FX Settlement Obligation...................................................................................................................................160
USAGE NOTES...................................................................................................................................................162
General Usage Notes.........................................................................................................................................162
Quote Request.....................................................................................................................................................163
Quote Response..................................................................................................................................................164
Quote..................................................................................................................................................................164
Quote Request Reject.........................................................................................................................................165
Quote Cancel......................................................................................................................................................165
Market Data Request..........................................................................................................................................166
Market Data Snapshot/Full Refresh..................................................................................................................166
Market Data Incremental Refresh.....................................................................................................................167
Market Data Request Reject..............................................................................................................................168
New Order - Single.............................................................................................................................................168
New Order - Multileg.........................................................................................................................................168
Execution Report................................................................................................................................................169
FX OTC Spot Option..........................................................................................................................................170
SettlDate and SettlType Required Usage Exception.........................................................................................172
MESSAGE SAMPLES.............................................................................................................................................173
Quote Request for FX Swap using NoLegs repeating group.............................................................................173
Quote for FX Swap using NoLegs repeating group..........................................................................................174
Single Bank Market Data Request.....................................................................................................................175
"Exchange" Market Data Request.....................................................................................................................177
FX Swap Multi-legged Order.............................................................................................................................178
Execution Report for FX Swap Multi-legged Order.........................................................................................179
Settlement Obligation Report.............................................................................................................................181
USER GROUP: EXCHANGES AND MARKETS..............................................................................................183
INTRODUCTION...................................................................................................................................................183
ORDER STATE CHANGE MATRICES FOR EXCHANGES.................................................................................................183
A Vanilla.............................................................................................................................................................186
I TimeInForce.....................................................................................................................................................188
CONTINUOUS MARKET MAKER QUOTING................................................................................................................189
Quote Identifiers.................................................................................................................................................189
Quote Acknowledgement and Status..................................................................................................................191
Reporting a Mass Cancel...................................................................................................................................193
Quote Cancel Scope...........................................................................................................................................194
Workflows...........................................................................................................................................................194
QUOTE NEGOTIATION..........................................................................................................................................211
Introduction........................................................................................................................................................211
Usage Notes........................................................................................................................................................211
QUOTE NEGOTIATION SCENARIOS..........................................................................................................................213
Public Tradable Quote.......................................................................................................................................213
Private Tradeable Quote - Three-Party Matching Model................................................................................213
MULTILEG ORDERS.............................................................................................................................................219
User-defined, Non-securitised Strategies..........................................................................................................219
Multileg Price Method.......................................................................................................................................220
Delta Neutral Multileg Orders...........................................................................................................................221
MARKET DATA..................................................................................................................................................222
Books View Complexities...................................................................................................................................222
Varying Book Depths.........................................................................................................................................228
Trade Statistics...................................................................................................................................................228
APPLICATION SEQUENCING AND RECOVERY.............................................................................................................228
Business Workflow.............................................................................................................................................228
Business Cases....................................................................................................................................................229
Application Indentification................................................................................................................................230
Application Sequencing integration..................................................................................................................230
VOLUME INTRODUCTION
Volume 7 of the FIX Protocol Specification aims to provide the FIX user community with notes and guidelines on
the usage of FIX for specific areas, namely by security product or by user groups. Sections that are security
product related has a section title that begins with "PRODUCT" while user group sections begin with "USER
GROUP". A product is the broad security categorisation. A user group represents a particular type of user, for
example exchanges, investment managers.
The "PRODUCT" sections are usage notes specific to a product. The "USER GROUP" sections are ussge notes
specific to that type of user - this mostly covers FIX message flows and interpretation of key fields within FIX
messages used by the user group.
Market environment
Units in funds are typically sold to Retail Investors on the recommendation of an Intermediary advisor (whose
firm may not be authorised to hold client assets or settle transactions), or purchased at the Investors’ initiative via
a broker or funds supermarket (which may outsource settlement to a third party) or purchased by the Investor
directly from the fund manager (who again may outsource fund administration to a third party ).
Retail intermediaries (eg. Intermediary advisors) who don’t hold client funds or settle transactions are rewarded
by commission from the fund manager out of charges collected from the Investor. Commission and charges may
be paid at the time of investment (“front-end load funds”) and/or during the life of the investment (“no-load
funds”). The latter may be called “renewal” or “trail” commission, and is typically paid directly to the
intermediary at the end of each period.
Intermediaries such as brokers and funds supermarkets may charge their own commission etc. directly to the
Investor and instruct the fund manager not to deduct commission from the sum invested.
Institutional Investors typically purchase funds directly from the fund manager and no commission is payable.
In some regulatory environments the fund manager is responsible for making compliance and money laundering
checks before a CIV order is executed, hence for new investors full details must be supplied with the order.
In some markets Hubs, Exchanges or Funds Supermarkets provide messaging, order matching/crossing, clearing
and settlement services between Intermediaries/brokers, Fund managers etc.
FIX messages may be used between any of the participants. The fund manager may also use FIX messages to buy
and sell fund assets with other participants in the relevant market(s) (eg. Equities):
Note that in a CIV scenario brokers, intermediaries etc. may be on the “buy side” and institutions may be on the
“sell” side, i.e. a reversal of the situation in equity/fixed interest/FX transactions.
A Collective Investment Vehicle security type is designated by a CFICode field (ISO 10962 standards-based)
value which starts with “EU”. Note that if the Product field is specified, the value should be set to “Equity” to
correspond with the “E” in the CFICode “EU” prefixed value, as presently defined. See “Volume 6 – Appendix
6D” for CFICode details.
Allocation messages are not required for CIV trading with Fund managers, but other FIX messages are unchanged
and can be used as required, e.g. Market Data, Security Status Request, Quote, Order Status, Order Cancel /
Replace, Don’t Know, Business Reject etc.
(See CIV Examples 1 – 7 below for examples of the use of these message types.)
Order Quantities
Income on units may be credited as additional units on the Investor’s account with the Fund manager, leading to
uncertainty about the exact number of units when a holding is to be sold. Similarly when an exchange or switch is
requested the cash value of investments realised and to be re-invested is not known. Hence it can be more
convenient for Unit quantities to be expressed as a percentage of total holding, e.g. sell 50% or 100% of the
existing holding, and reinvest 50% of the cash proceeds in Fund A, 25% in Fund B and 25% in Fund C.
“Percentage” amounts are indicated in the OrderPercent field.
Where an order is for investment of a money amount (CashOrderQty) or percentage (OrderPercent) the
Intermediary may request that the resultant quantity is rounded up or down to a specific fraction or multiple of
units by setting RoundingDirection and RoundingModulus.
(See CIV Example 13 below for an example of the use of OrderPercent & Rounding to specify order quantity.)
Intermediary identification
Where messages are sent to or from a Fund manager via a Hub or Funds Supermarket on behalf of the
Intermediary the IntroBroker field may be used to identify the Intermediary who is interfacing with the Investor.
This information is used by the Fund manager used to validate the Investor / Intermediary relationship on his
records and to credit Commission to the correct Intermediary.
Investor details
If an Intermediary places a CIV Order for a new Investor (to the Fund manager) then the Registration instructions
message can be used to transmit the details as required by the Fund manager:
• RegistAcctType – identifying which of the fund manager’s account types should be opened
• TaxExemptType – identifying which of the (nationally defined) tax-exempt accounts or “plans” is
required
• OwnershipType – indicates relationship between owners where there is more than one, e.g. tenants in
common (i.e. equal interests), joint tenants with rights of survivorship.
• RegistDtls & RegistEmail – name and address into which purchases for this Investor should be registered,
plus e-mail address where applicable.
• InvestorCountryOfResidence – identifying the country of residence of the investor, e.g. for compliance
and/or tax purposes
• OwnerType – identifying whether the registered investor is an individual, corporation, nominee/street
name, trustee etc. (This information may be required for regulatory purposes and/or to indicate which
format of Registration name and address information is required)
• InvestorID and InvestorIDSource – containing identifiers issued by official organisations such as tax
authorities, company registrar, regulators or national numbering agencies, together with an identifier for
the source of the identifier
• MailingDtls – the name and address to which general correspondence should be sent (if different from the
Registration address), semi-annual reports, marketing literature.
• MailingInst – e.g. instructions indicating what the mailing address is to be used for, whether marketing
literature is acceptable etc.
(See CIV Examples 15-16 below for examples of the use of registration instruction for new investors, accounts
etc.)
Having received this information the Fund manager responds with a Registration Instructions Response– which in
addition to the RegistID of the Registration request should also contain the Account and/or ClientIDs allocated to
the Investor.
(See CIV Examples 3, 4 & 6 below for examples of the use of Registration instruction response message.)
Investor identification
A Fund manager may allocate an Account id and/or Client id to each Investor – depending on the architecture of
his account database. These can be returned on the Registration status or Execution report message or by some
other means (e.g. printed confirm or contract note), and should be quoted on subsequent New Order etc. messages.
(See CIV Examples 8-10 below for examples of the use of identification fields for new and existing investors,
accounts etc.)
(See CIV Examples 6 & 14-16 for examples of registration instructions and the designation field.)
“sell” order can be matched or crossed by an intermediary, funds supermarket, broker/dealer etc. or
forwarded to the fund manager. On the other hand a “subscribe” or “redeem” order must be forwarded to
the fund manager, e.g. where the originator requires specific tax treatment and/or dealing charges.
• OrdType – Previous Fund Valuation Point (Historic pricing) or Next Fund Valuation Point –(Forward
pricing)
• Order quantity expressed as one of:
o OrderQty – number of units,
o CashOrdQty– cash amount to be invested, or
o OrderPercent – percentage of existing holding (for a sell) or percentage of available cash amount
to be invested (for an exchange / switch)
• RoundDirection & RoundModulus – for cash amount or percentage, allows the investor or intermediary
to request rounding up or down to the nearest 5, 10, 100 etc. or fractional units
• Currency & ForexReqd – e.g. for an off-shore fund settled in domestic currency
• Designation – supplementary registration information specific to this Order
(See CIV Examples 13 & 14 below for an example of the use of New Order – List.)
Commission Instructions
The Intermediary can indicate specific commission requirements using:
• Commission & CommType – e.g. a specific commission rate or a waiver of the standard commission rate
for the fund, the saving on standard commission being credited as for additional units or as a cash
discount
• CommCurrency – to specify that commission on an overseas or offshore fund should be paid in domestic
currency
• FundBasedRenewalWaived – to indicate whether or not the Intermediary accepts renewal/trail
commission
Compliance
Depending on terms of business and the regulatory environment either or both of the Intermediary and Fund
manager may be required to support money laundering status checking and/or right-to-cancel. The New Order
message supports these with:
• MoneyLaundering – indicating whether or not checks are required and have already been carried out by
the Intermediary
• CancellationRights - indicating whether or not a “right-to-cancel” applies
Settlement instructions
For CIV Orders retail settlement instructions may be transmitted using Settlement instruction features including:
• SettlInstMode – indicating that settlement instructions relate to a specific (retail) Order
• SettlInstSource –indicating the Investor as the source of settlement instructions
• PaymentMethod & SettCurrency – indicating cheque, bank transfer, payment card, cash account at
depository etc.
• CardHolderName, CardNumber, CardStartDate, CardExpDate, CardIssNo, PaymentDate and
PaymentRemitterID – details required for cash settlement by payment card
• SettlBrkrCode, SettlDepositoryCode – for cash settlement via central depositories
• CashSettlAgentName, CashSettlAgentCode, CashSettlAgentAcctNum, CashSettlAgentAcctName - for
cash settlement by bank transfer
• PaymentRef – cross-reference or narrative information for bank transfers etc. to appear on bank
statements, SWIFT MT950’s etc. to assist reconciliation
Distribution instructions
The Registration instruction message can also carry Distribution instructions, including:
• NoDistribDetls & DistribSeqNo – the number of beneficiaries
• DistribPercent –the split of each distribution (by value) between several beneficiaries
• DistribPaymentMethod & CashDistribCurr – payment method and currency for a specific beneficiary
• CashDistribAgentName, AgentCode, AgentAcctName and AgentAcctNum – bank and account details for
a specific beneficiary
• CashDistribPayRef - cross-reference or narrative information for bank statements
(See CIV Examples 15 & 16 below for examples of the use of distribution instructions.)
Unit Prices
Fund managers calculate a net asset value for each fund – typically at a fixed time each day, the “valuation point”.
They then quote either a single Unit price (“single pricing”) or separate buying and selling prices (“dual pricing”)
– depending on the fund’s constitution and regulatory environment.
Valuation point
The unit price applicable to a CIV trade depends on when the Order was received by the fund manager relative to
a Valuation point, whether the Fund is normally dealt on a Historic or Forward basis, and possibly also on recent
volatility on underlying fund assets and any specific instructions from the Investor.
Some of this information is indicated by fields on the New Order:
• TransactTime – the time at which the Investor placed the CIV Order directly, or at which Intermediary
placed the Order on behalf of the Investor
• OrdType – whether Investor requires a Forward or (where available) a Historic price
Other times establishing the relevant valuation point are shown on the Execution Report:
• OrderBookedTime – the time at which the Fund manager provisionally accepted the order for execution
(having completed any preliminaries, e.g. setting up an account, money laundering checks)
• ExecValuationPoint - the fund valuation point with respect to which a order was priced by the fund
manager (may be before or after the OrderBookedTime).
Single pricing
The Unit price for single-priced funds is determined from the net asset value, based on the mid-price of the
underlying assets of the fund, divided by the applicable number of units. For these funds ExecPriceType on the
Execution Report should be set to “S” = Single.
The manager’s Initial charge (if any) is then charged out separately. In addition a Dilution levy may be charged on
large buy or sell transactions, e.g. to compensate for the difference between the mid- and buy/sell- price of the
underlying investments. These charges can be notified on the Execution Report in the Contract amounts repeat
group.
Dual pricing
For dual priced funds the manager calculates:
• Creation price – based on the “buy” price of the underlying assets (net of transaction taxes etc.)
• Cancellation price – based on the “sell” price of the underlying assets (net of transaction taxes etc.)
If the net cash flow is into the fund new units will be created:
• Offer or Buy price – will be no higher than the Creation price plus the manager’s Initial charge
• Bid, Sell or Redemption price – will be the Offer price minus the manager’s Dealing spread
If the net cash flow is out of the fund existing units will be cancelled:
• Bid, Sell or Redemption price – will be no lower than the Cancellation price
• Offer or Buy price – will be the Bid price plus the manager’s Dealing spread, up to a limit of the
Creation price plus the manager’s Initial charge
The manager may sell to buyers units he has re-purchased from sellers (rather than cancelling and re-creating
units), thus profiting from the Dealing spread.
The Initial charge covers any commission paid to Intermediaries as well as advertising, administration, dealing
costs etc. It can be a money amount or percentage and may be waived on large investments, e.g. by institutional
investors. Where the Initial charge is waived for a private investor an Exit charge (money amount or percentage)
may be levied if an investment is sold within the first few years. (This is sometimes known as a Deferred
contingent sales charge.) These charges can be notified on the Execution Report in the Contract amounts repeat
group.
The manager may offer an improved buying price by discounting the initial charge or reducing his dealing spread
– the improved price is expressed as “Creation price plus” an amount or percentage, or “Offer price minus” an
amount or percentage.
ExecPriceType and (where applicable) ExecPriceAdjustment on the Execution Report indicate how the actual
buying or selling price was calculated from the fund valuation price(s).
Execution Reports
The Fund manager should send Execution Report messages to confirm receipt (OrdStatus=“New”) and execution
(OrdStatus= “Filled” and/or “Calculated”) of CIV Orders, plus other Order Status from the list below as agreed
between the parties – individual Execution Reports being sent for each line of an New Order – List.
In markets where tax treatment and/or dealing charges depend on whether execution was by crossing / matching
by an intermediary, or by subscription / redemption at the fund manager the LastMkt field should be used to
indicate either the Exchange or 11 for an OTC trade, or omitted if execution was by the fund manager.
The CIV Fields included for each value of OrdStatus in Execution Report are listed below:
Rejected
Pending Cancel ClOrdID, ListID & TransactTime – Intermediary’s Order (and List)
references and time of submission
Pending Replace
Pending New ClOrdID, ListID & TransactTime – Intermediary’s Order (and List)
references and time of submission
All fields populated on the CIV Order (apart from Order fields not available
in Execution Report)
(See CIV Examples 1 – 7 below for examples of the use of Execution Report messages.)
CIV EXAMPLES
The following examples illustrate how FIX messages can be used to process CIV fund orders and provide
settlement and registration instructions to the fund manager.
NOTE that in the examples:
• “Buyside” refers to an institution or private investor investing in a CIV fund via broker, intermediary – or
a hub and/or exchange transmitting messages to/from other buyside parties
• “Sellside” refers to a CIV fund manager or intermediary – or a hub and/or exchange transmitting
messages to/from other sellside parties
A typical flow for an order for a CIV fund dealt on Historic price for an investor or nominee known to the fund
manager – is as follows:
BUYSIDE SELLSIDE
Fund
Valuation
Point
New Order-Single
(IntroBroker, ClOrdID, Account & ClientID specified)
Execution Report (ExecType = “F”) [Trade]
(IntroBroker, ClOrdID, Account & ClientID echoed)
Commission/
Fee Calc
Execution Report (ExecType = “B”) [Calculated]
(IntroBroker, ClOrdID, Account & ClientID echoed)
A typical flow for an order for a CIV fund for an investor/nominee known to the fund manager that wishes to deal
on a Forward price basis – is as follows:
BUYSIDE SELLSIDE
New Order-Single
(IntroBroker, ClOrdID, Account & ClientID specified)
(OrdType="M") [Forward]
Execution Report (ExecType = “0” [New]
(IntroBroker, ClOrdID, Account & ClientID echoed)
Fund
Valuation
Point
Execution Report (ExecType = “F”) [Trade]
(IntroBroker, ClOrdID, Account & ClientID echoed)
Commission/
Fee Calc
Execution Report (ExecType = “B”) [Calculated]
(IntroBroker, ClOrdID, Account & ClientID specified)
A typical flow for an order for a CIV fund for an investor/nominee not known to the fund manager where the fund
manager does not require settlement or registration instructions in advance – is as follows:
BUYSIDE SELLSIDE
New Order – Single (IntroBroker & ClOrdID specified,
Account, ClientID & RegistID not specified)
Execution Report (ExecType = “0” [New]
(IntroBroker & ClOrdID echoed)
Fund
Valuation
Point
Execution Report (ExecType = “F”) [Trade]
(IntroBroker & ClOrdID echoed)
Commission/
Fee Calc
Execution Report (ExecType = “B”) [Calculated]
(IntroBroker & ClOrdID echoed)
Registration Instruction Response (RegistStatus = “N”)
[Reminder]
(IntroBroker & ClOrdID echoed)
Settlement Instruction (SettInstTransType = “N”) [New]
(SettlInstMode=”4”) [Specific Order]
(IntroBroker & ClOrdID specified)
Registration Instruction (RegistTransType = “0” ) [New]
(IntroBroker, ClOrdID & RegistID specified)
Validate
Registration
Instruction
Registration Instruction Response (RegistStatus = “A”)
[Accepted]
(IntroBroker, ClOrdID & RegistID echoed,
Account and/or ClientID returned)
A typical flow for an order for a CIV fund for an investor/nominee not known to the fund manager where the fund
manager requires settlement and registration instructions in advance – is as follows:
BUYSIDE SELLSIDE
Registration Instruction (RegistTransType = “0” ) [New]
(RegistID, IntroBroker & ClOrdID specified)
BUYSIDE SELLSIDE
Registration Instruction Response (RegistStatus = “H”) [Held]
A possible flow for an order for a CIV fund for an investor/nominee known to the fund manager, on which the
CashOrdQty is modified before execution – is as follows:
BUYSIDE SELLSIDE
New Order-Single
(IntroBroker, ClOrdID, Account & ClientID specified)
CashOrdQty = “6,000”
Execution Report (ExecType = “0” [New]
(IntroBroker, ClOrdID, Account & ClientID echoed)
Order Cancel/Replace Request
(IntroBroker, ClOrdID, Account & ClientID specified)
CashOrdQty = “7,000”
BUYSIDE SELLSIDE
Execution Report (ExecType = “5” [Replaced]
(IntroBroker, ClOrdID, Account & ClientID echoed)
Fund
Valuation
Point
Execution Report (ExecType = “F”) [Trade]
(IntroBroker, ClOrdID, Account & ClientID echoed)
Commission/
Fee Calc
Execution Report (ExecType = “B”) [Calculated]
(IntroBroker, ClOrdID, Account & ClientID specified)
A possible flow for an order for a CIV fund for an investor/nominee not already known to the fund manager where
settlement and registration instructions are supplied, rejected and then corrected after the trade – is as follows:
BUYSIDE SELLSIDE
New Order – Single (IntroBroker & ClOrdID specified,
Account, ClientID & RegistID not specified)
Fund
Valuation
Point
Commission/
Fee Calc
Execution Report (ExecType = “B”) [Calculated]
(IntroBroker & ClOrdID echoed)
Settlement Instruction (SettInstTransType = “N”) [New]
(SettlInstMode=”4”) [Specific Order]
(IntroBroker & ClOrdID specified)
Registration Instruction (RegistTransType = “0” ) [New]
(IntroBroker, ClOrdID & RegistID specified)
Validate
Registration
Instruction
Registration Instruction Response (RegistStatus = “H”) [Held]
BUYSIDE SELLSIDE
Registration Instruction Response (RegistStatus = “R”)
[Rejected]
(IntroBroker, ClOrdID & RegistID echoed,
Account and/or ClientID not returned)
Registration Instruction (RegistTransType = “2” ) [Replace]
(IntroBroker, ClOrdID & RegistID specified)
Validate
Registration
Instruction
Registration Instruction Response (RegistStatus = “A”)
[Accepted]
(IntroBroker, ClOrdID echoed,
Account and/or ClientID returned)
Settlement Instruction (SettInstTransType = “R”) [Replace]
(SettlInstMode=”4”) [Specific Order]
(IntroBroker & ClOrdID specified)
BUYSIDE SELLSIDE
New Order-List
(ListId & ListExecInstType specified, e.g.
ListExecInstType=”3” [Exch/switch - Sell Driven]
For each component of exchange/switch:
(IntroBroker, ClOrdID, ClientID, Account,
Symbol/SecurityId, OrderPercent, Side)
BUYSIDE SELLSIDE
For each component of exchange/switch:
Execution Report (ExecType = “B” [Calculated]
(IntroBroker, ClOrdID, Account & ClientID echoed)
CIV Example 10. Order for CIV fund by new investor via non-client
money/asset holding intermediary to fund manager
CIV Example 11. Order for CIV fund by new investor, routed via
non-client money/asset holding intermediary via a non-
aggregating hub/exchange to fund manager
CIV Example 12. Order for CIV fund by new investor routed via
intermediary to a funds supermarket – which places bulk/net
orders to the fund manager
Typical usage of fields on Order and/or Post-Trade messages between intermediary and funds supermarket would
be as follows:
Typical usage of fields on Order and/or Post-Trade messages between funds supermarket and fund manager for
bulk/net orders would be as follows:
Quantity example
Typical use of OrderPercent and Rounding fields on Order and Execution Report messages to and from fund
manager or funds supermarket would be as follows:
Symbol/SecurityI Quantity
d held
Fund A 5281
Fund B 2296
Fund C 1833
After the Fund Valuation Point the quantities and cash amounts (assuming no commissions, initial or exit charges)
are reported on “calculated” Execution Reports are as follows:
Settlement amount (ContAmtValue) = £6.72 (credit, i.e. excess cash will be paid to Investor)
CIV Example 14. CIV Bulk order – purchase of funds for multiple
investors into a designated nominee
Typical use of New Order – List by a broker for purchase of funds for multiple investors into a designated
nominee would be to specify ListExecInstType=“1” [Immediate], with other fields as follows:
Typical use of the Registration instruction Joint Investors, e.g. husband & wife, with cash distribution split equally
between them would be:
Possible use of the Registration instruction for Tenants in Common, e.g. a club of private investors that reinvest
all their income could be:
1 A security type enumeration for an Option on a Future does not currently exist.
The following use of SecurityType and CFICode are proposed for specifying multileg derivative instruments
– such as options strategies or futures spreads.
SecurityType[167] CFICode[461] Description
FMXXS Multileg Instrument with futures contract legs
MLEG CFICode refers to Future – Miscellaneous
OMXXXN
MLEG Multileg Instrument with option contract legs
CFICode refers to Option – Miscellaneous (This would
include multileg instruments that include the underlying
security).
M
MLEG Multileg Instrument with legs made up of various types of
securities (not primarily a futures or options multileg
instrument that contains one or more derivative legs).
CFICode refers to M-Miscellaneous
2 A foreign broker/dealer is defined as any person or entity that is registered, authorized, or licensed by a foreign governmental agency or foreign
regulatory organization ( or is required to be registered, authorized, or licensed) to perform the function of a broker or dealer in securities, or
both. For purposes of this definition, a broker or dealer may also be a bank.
Proposed option order capacity codes and their FIX 4.3 equivalents
The following are additional codes that are proposed for the listed options markets and how they
would map to FIX 4.3.
Proposed Listed Option Market Order OrderCapacity OrderRestrictions Other
Capacity Values (tag 528) (tag 529)
“I” Proposed Code used to designate a Agency AccountType(
JBO account which clears Customer tag 581)=8
at OCC: any joint back office (“JBO”) Joint Back
account of a broker/dealer that has a Office
nominal ownership interest in a clearing
broker/dealer and receives good faith margin
treatment whereby such trade clears in the
customer range at OCC. This ownership
position allows the JBO clearing firm to
finance securities transactions of the JBO
participant on a good faith margin basis.
“J” Proposed Code used to designate a Proprietary AccountType(
JBO account which clears Firm at tag 581)=8
OCC: any joint back office (“JBO”) Joint Back
account of a broker/dealer that has a Office
nominal ownership interest in a clearing
broker/dealer and receives good faith
margin treatment whereby such trade
clears in the firm range at OCC. This
ownership position allows the JBO
clearing firm to finance securities
transactions of the JBO participant on a
good faith margin basis.
9 – External
Interconnected
Market
“S”Linkage – Principal satisfaction Riskless 5-Acting As a
order (i.e. an order for the principal Principal specialist or market
account of an eligible market maker sent maker in the
through the Linkage to satisfy the security
liability arising from a trade through that
was initiated by that market-maker).
9 – External
Interconnected
Market
B ro k e r
C lie n t API O RS H a n d h e ld
I n c o m in g W o r k in g
D eck D eck
N e w O rd e r
1
E x e c u tio n R e p o r t
O r d S ta t= P e n d in g N e w
N e w O rd e r
1
E x e c u tio n R e p o r t
O rd S ta t= N e w
1 A cce pt
E x e c u tio n R e p o r t 1
O r d S ta t= N e w
o p tio n a l W o r k in g = Y
E x e c u t io n R e p o r t F ille d
O r d S t a t = F ille d
1
NOTES:
• The broker is not required to move the order from the incoming deck to the working deck before
filling the Order. Therefore, the “Working=Y” might not be received by the client. The Execution
Report can be sent by the broker handheld from either the Incoming Deck or the Working Deck.
• The Order can take one or more Fills before the Order is completed, or the Order might only be
partially completed by the end of the day.
Replaces ClientID[109]
ExecutingTrader The trader or broker that Opt Reqd Opt Cond
actually executes a trade. If no
InitiatingTrader role exists on
the trade – then the
ExecutingTrader is assumed to
be associated with the
ExecutingFirm
GiveupClearingFirm Firm that carries the position Opt Cond Opt Cond
that results from a trade against
the order. This is the firm to
which the trade is given up.
80 2 AllocQty N
79 9876 AllocAccount N
467 n/a IndividualAllocID N
80 15 AllocQty N
79 546789 AllocAccount N
467 n/a IndividualAllocID N
545 n/a NestedPartySubID N
End </NestedParties>
80 2 AllocQty N
63 SettlmntTyp N
64 FutSettDate N
635 C ClearingFeeIndicator N
21 3 HandlInst Y Floor execution for futures markets
should always be a 3
18 n/a ExecInst N
110 n/a MinQty N
111 n/a MaxFloor N
100 XCBT ExDestination N
386 n/a NoTradingSessions N
336 n/a TradingSessionID N
625 n/a TradingSessionSubID N
140 PrevClosePx N
54 1 Side Y
60 20010806-13:34:29 TransactTime Y
1 AAA Account N
581 n/a AccountType N
591 n/a PreallocMethod N
78 n/a NoAllocs N
79 n/a AllocAccount N
467 n/a IndividualAllocID N
80 n/a AllocQty N
63 SettlmntTyp N
64 FutSettDate N
21 2 HandlInst Y
18 n/a ExecInst N
110 n/a MinQty N
111 n/a MaxFloor N
100 XCBO ExDestination N
386 n/a NoTradingSessions N
336 n/a TradingSessionID N
625 n/a TradingSessionSubID N
54 1 Side Y Buying the options.
167 SecurityType N
200 200109 MaturityMonthYear N
541 n/a MaturityDate N
470 CountryOfIssue N
471 StateOrProvinceOfIssue N
472 LocaleOfIssue N
202 100.0 StrikePrice N
206 n/a OptAttribute N
231 ContractMultiplier N
207 n/a SecurityExchange N
107 n/a SecurityDesc N
350 n/a EncodedSecurityDescLen N
351 n/a EncodedSecurityDesc N
End </Instrument>
Example New Order - Multileg for Listed Futures Market (Spread Order)The following addresses sending a
New Order – Multileg message into a futures market.
Tags that are not used in the futures and options industries are not included in the example.
Tags with strike-through text are not currently used by the industries but may be used in the future.
Tags that have an example value of not applicable (n/a) are used in the futures industry. Herein, however, the
value n/a was assigned for one of two reasons. First, specific futures and options markets may or may not
utilize certain tags and, if utilized, their use and valid values would need to be addressed by participants in the
particular market. (Examples of such tags are MultiLegRptTypeReq [563] and TradingSessionID [336].)
Second, the order created here is to buy 15 May 2002 - July 2002 Corn spreads at a price of –12. Some
specifics concerning the order, such as it is not being allocated, result in some tag values being n/a.
The direction of the strategy is indicated by the Side (54) taken. When a strategy is pre-defined by a futures or
options market and an inconsistency arises between:
the strategy indicated and the Side, LegSide (624), and/or LegRatioQty (623), or
the Side indicated and any LegSide indicated
the sell-side may either reject the order or accept the order. If the sell-side accepts the order it will be based
on the strategy and Side indicated with any inconsistencies in LegSide and/or LegRatioQty being ignored.
The example also has any trade resulting from this order being given up to another firm. The firm being given
up to will carry the trade on its books.
538 n/a NestedPartyRole N
545 n/a NestedPartySubID N
End </NestedParties>
80 n/a AllocQty N
63 SettlmntTyp N
64 FutSettDate N
635 C ClearingFeeIndicator N
21 3 HandlInst Y Floor executions for futures markets
should always be "3".
18 n/a ExecInst N
110 n/a MinQty N
111 n/a MaxFloor N
100 XCBT ExDestination N
386 n/a NoTradingSessions N
336 n/a TradingSessionID N
625 n/a TradingSessionSubID N
54 1 Side Y Buying the strategy.
60 20010509-09:20:15 TransactTime Y
Example New Order - Multileg for Listed Futures Market (Butterfly Strategy)
The following addresses sending a New Order – Multileg message into a futures market.
Tags that are not used in the futures and options industries are not included in the example.
Tags with strike-through text are not currently used by the industries but may be used in the future.
Tags that have an example value of not applicable (n/a) are used in the industries. Herein, however, the value n/a
was assigned for one of two reasons. First, specific futures and options markets may or may not utilize certain tags
and, if utilized, their use and valid values would need to be addressed by participants in the particular market.
(Examples of such tags are MultiLegRptTypeReq [563] and TradingSessionID [336].)
Second, the order created here is to buy 10 EuroDollar butterfly spreads at a price of -3.0, and is assumed that it
will be productized by the sell-side on its electronic order matching system (ie: trade engine). This and other
assumptions concerning the order, such as it is not being allocated, result in some tag values being n/a. (An
example is the SecurityID [48] which the buy-side would not know until the sell-side has productized the
butterfly.)
The direction of the strategy is indicated by the Side (54) taken. When a strategy is pre-defined by a futures
market and an inconsistency arises between:
• the strategy indicated and the Side, LegSide (624), and/or LegRatioQty (623), or
• the Side indicated and any LegSide indicated
the sell-side may either reject the order or accept the order. If the sell-side accepts the order it will be based on the
strategy and Side indicated with any inconsistencies in LegSide and/or LegRatioQty being ignored.
1 Z9871272 Account N
581 1 AccountType N
591 n/a PreallocMethod N
78 n/a NoAllocs N
79 n/a AllocAccount N
467 n/a IndividualAllocID N
80 n/a AllocQty N
63 SettlmntTyp N
64 FutSettDate N
635 C ClearingFeeIndicator N
21 1 HandlInst Y
18 n/a ExecInst N
110 n/a MinQty N
111 n/a MaxFloor N
100 XCME ExDestination N
386 n/a NoTradingSessions N
336 n/a TradingSessionID N
625 n/a TradingSessionSubID N
54 1 Side Y
140 PrevClosePx N
555 3 NoLegs Y
End </NestedParties>
538 n/a NestedPartyRole N
545 n/a NestedPartySubID N
End </NestedParties>
60 20010509-09:20:15 TransactTime Y
40 2 OrdType Y
44 -3.0 Price N
99 n/a StopPx N
15 Currency N
376 ComplianceID N
377 SolicitedFlag N
117 n/a QuoteID N
59 0 TimeInForce N
168 n/a EffectiveTime N
432 n/a ExpireDate N
126 n/a ExpireTime N
528 OrderCapacity N
529 OrderRestrictions N
582 4 CustOrderCapacity N
120 n/a SettlCurrency N
58 n/a Text N
354 n/a EncodedTextLen N
355 n/a EncodedText N
77 n/a PositionEffect N
Tags that are not used in the futures and options industries are not included in the example.
Tags with strike-through text are not currently used by the industries but may be used in the future.
Tags that have an example value of not applicable (n/a) are used in the industries. Herein, however, the value
n/a was assigned for one of two reasons. First, individual futures and options markets may or may not utilize
certain tags and, if utilized, their use and valid values would need to be addressed by participants in the
particular market.
The execution report references an order to buy 15 July 2001/September 2001 Corn Spreads. The order is a
give-up trade being executed and cleared by firm 560 and carried on the books of firm 500. This is the first
execution of the order and it is for a total of 5 spreads. The order was executed on the trading floor as
atomically and is being reported to the customer atomically via this execution report. The order will also be
cleared atomically.
382
1 NoContraBrokers N
N
375 455 ContraBroker
337 ABC ContraTrader N
437 5 ContraTradeQty N
438 20010509-09:22:40 ContraTradeTime N
655 n/a ContraLegRefID N
66
n/a ListID N
548 n/a CrossID N
551 n/a OrigCrossID N
549 n/a CrossType N
17 X6789 ExecID Y
19 n/a ExecRefID N
150 F ExecType Y
39 1 OrdStatus Y
WorkingIndicator
636 Y N
103 n/a OrdRejReason N
378 n/a ExecRestatementReason N
1 abcdef Account N
581 1 AccountType N
591
n/a PreallocMethod N
63 SettlmntTyp N
64 FutSettDate N
C
635 ClearingFeeIndicator N
54 1 Side Y
NoLegs Number of legs. Can be zero – must
555 2 Y be provided even if zero
606 LegSecurityAltIDSource N
608 F LegCFICode N
609 LegSecurityType N
LegMaturityMonthYear
610 200105 N
611 n/a LegMaturityDate N
596 LegCountryOfIssue N
597 LegStateOrProvinceOfIssue N
598 LegLocaleOfIssue N
n/a
612 LegStrikePrice N
613 n/a LegOptAttribute N
614 LegContractMultiplier N
616 n/a LegSecurityExchange N
Corn Future
620 LegSecurityDesc N
621 n/a EncodedLegSecurityDescLen N
622 n/a EncodedLegSecurityDesc N
623 1 LegRatioQty N
624 1 LegSide N
N Provide if the PositionEffect for the
564 n/a LegPositionEffect leg is different from that specified for
the overall multileg security
N Provide if the CoveredOrUncovered
565 n/a LegCoveredOrUncovered
for the leg is different from that
specified for the overall multileg
security.
587 LegSettlmntTyp
Required when SettlmntTyp = 6
588 LegFutSettDate (Future) or SettlmntTyp = 8 (Sellers
Option)
600 C LegSymbol ***
601 LegSymbolSfx N
n/a
602 LegSecurityID N
603 n/a LegSecurityIDSource N
604 NoLegSecurityAltID N
605 LegSecurityAltID N
606 LegSecurityAltIDSource N
608 F LegCFICode N
609 LegSecurityType N
200107
610 LegMaturityMonthYear N
611 n/a LegMaturityDate N
596 LegCountryOfIssue N
597 LegStateOrProvinceOfIssue N
598 LegLocaleOfIssue N
n/a
612 LegStrikePrice N
613 n/a LegOptAttribute N
614 LegContractMultiplier N
616 n/a LegSecurityExchange N
Corn Future
620 LegSecurityDesc N
621 n/a EncodedLegSecurityDescLen N
622 n/a EncodedLegSecurityDesc N
623 1 LegRatioQty N
624 2 LegSide N
N Provide if the PositionEffect for the
564 n/a LegPositionEffect leg is different from that specified for
the overall multileg security
N Provide if the CoveredOrUncovered
565 n/a LegCoveredOrUncovered
for the leg is different from that
specified forthe overall multileg
security.
545 n/a NestedPartySubID N
End </NestedParties>
40 2 OrdType N
44 -12 Price N Required if specified on the order
99 n/a StopPx N Required if specified on the order
n/a
388 DiscretionInst N Code to identify the price a
DiscretionOffset is related to and
should be mathematically added to.
Required if DiscretionOffset is
specified.
389 n/a DiscretionOffset N Amount (signed) added to the
“related to” price specified via
DiscretionInst.
15 Currency N
376 ComplianceID N
377 SolicitedFlag N
0
59 TimeInForce N Absence of this field indicates Day
order
168 n/a EffectiveTime N Time specified on the order at which
the order should be considered valid
432 n/a ExpireDate N Conditionally required if
TimeInForce = GTD and ExpireTime
is not specified.
A new enumeration value called "Defaulted" was added. A "Defaulted" Trade Report is one that was
originally specified to be given up to another party but due to a violation of a give-up condition the
transaction was placed into a ‘Default’ account and not the specified Give-Up account.
OrderID (37):
Should be conditionally required when Trade Capture Report is used for back office processing.
Security Definition
SecurityReportID (964):
This is the identifier for the Security Definition message in a bulk transfer environment that does not
support the request/response model.
It should be noted that in a request/response model the following fields are required: SecurityReqID
(320), SecurityResponseID (322), and SecurityResponseType (323).
Security List
SecurityReportID (964):
This is the identifier for the Security List message in a bulk transfer environment that does not support
the request/response model.
It should be noted that in a request/response model the following fields are required: SecurityReqID
(320), SecurityResponseID (322), and SecurityRequestResult (560).
Parties component block
PartyIDSource (447):
If not specified, the default is the counterparty agreed upon source.
PartySubIDType (803):
If not specified, the default is the counterparty agreed upon type.
Contrary Intention Report
Contrary Intention Report is used to support the reporting of contrary expiration quantities for Saturday
expiring options
Security Definition Update Report
Security Definition Update Report is to support the reporting of updates (Add, Modify, Delete) to a Product
Security Masterfile due to Corporate Actions or other business requirements.
SecurityReportID (964):
This is the identifier for the Security Definition Update Report message in a bulk transfer environment
that does not support the request/response model.
It should be noted that in a request/response model the following fields are required: SecurityReqID
(320), SecurityResponseID (322), and SecurityRequestResult (560).
Security List Update Report
Security List Update Report is to support the reporting of updates (Add, Modify, Delete) to a Contract
Security Masterfile due to Corporate actions or other business requirements.
SecurityReportID (964):
This is the identifier for the Security List Update Report message in a bulk transfer environment that does
not support the request/response model.
It should be noted that in a request/response model the following fields are required: SecurityReqID
(320), SecurityResponseID (322), and SecurityRequestResult (560).
Exhibit 1
Buy Sell
Order Order
Trader 1
Trader 2
OrderID OrderID
Match Event
ExecID
TradeMatchID
Fill 1 Fill 2
___________ ___________
ExecID ExecID
TradeMatchID TradeMatchID
TradeReport TradeReport
Trade ___________ ___________ Trade
ReportID ExecID ExecID ReportID
TradeMatchID TradeMatchID
Clearing Event
LegRefID LegRefID
TradeID TradeID
LegRefID LegRefID
AllocID AllocID
TradeReport TradeReport
___________ _________
Trade Trade
TradeID TradeID
ReportID ReportID
FirmBack Office
Firm Firm
TradeID TradeID
1. ExecID – used to identify the fill event that created the trade. There may be multiple fills per trade and
therefore multiple fills with the same exec id. In other words, ExecID has a one-to-many relationship
with the resulting fills. Since each fill becomes a cleared trade, ExecID also has a one-to-many
relationship with TradeCaptureReport.
2. TradeMatchID – all purpose internal identifier assigned to fills by the match engine. The TradeMatchID
may either be unique to each fill in a match event or common across all fills in a match. In the event that
this is the primary ID used to uniquely identify a fill, then ExecID should be used in stead.
3. TradeReportID – used to uniquely identify the transaction being used to add, update, or cancel a trade.
As required by the specification, TradeReportID is required on the Trade Capture Report and must be
unique per message. The Trade Capture Report Ack must echo back the TradeReportID and will not
necessarily have a unique ID assigned to it. TradeReportID is optional on Trade Capture Report Request
and Trade Capture Report Request Ack.
4. TradeReportRefID – used to refer to an original TradeReportID for purposes of update or cancellation.
A TradeCaptureReport will specify a TradeReportRefID when it is being used to perform a subsequent
update or cancellation.
5. AllocID – used to identify the Allocation Group ID to which a trade is being added. A trade may carry
allocation information which includes both the Allocation Group as well as the Allocation Instruction for
that trade. AllocID is used for both Average Price and Basic Allocations.
6. IndividualAllocID – occurs in the Allocation block of the trade and is used to specify the Allocation ID
of the allocation to which the trade is being directed.
7. TradeLinkID – used to link together a group of trades that make up an average price allocation.
TradeLinkID can be used in place of AllocID for average pricing purposes if so desired
8. TradeLegRefID – Used when reporting an individual leg of a multi leg trade. TradeLegRefID references
the leg of a multileg instrument (LegRefID) to which this trade refers. Used when
MultiLegReportingType = 2 (Single Leg of a Multileg security).
9. LegRefID – Used to uniquely identify the leg of a trade when reporting a spread with its associated legs.
Note that LegRefID may be unique when paired with TradeID or unique on its own. If the leg is reported
separately LegRefID would no longer be used but would be reported in Trade ID. Generally, not used in
Clearing as legs are reported individually.
Exhibit 2 illustartes trade identification in the context of electronic trade and order routing flow, and trade
reporting flow.
Exhibit 2
OrderID
ExecID
ExecID May carry the following:
Assigned TradeID
May carry the following : FirmTradeID
TradeReportID
ExecID TradeID Assigned
ExecID
TradeMatchID TrdMatchID Assigned TrdMatchID
Assigned TradeReportID
LegRefID
CopyMsgInd
NEW TradeCapture
Report
Clearing Trade Firm
Processor Back Office FirmTradeID
Updated TradeCapture Assigned
Report
Description Message Type Trade Sender Receiver Trans Copy ExecID Trade Trade TradeID3 LegRef TrdLeg Firm AllocID
Source Type Message Match ID Report ID4 RefID5 Trade
Ind ID ID
1 Electronic Trade Trade Capture Electroni Match Clearing New No Assigned Assigned Assigned N/A N/A N/A N/A N/A
reported from Report c Engine or Org In in Engine by Engine
match engine To VMU Engine
Clearing
2 Cleared Electronic Trade Capture Electroni Clearing Clearing New Yes Assigned Assigned Assigned Assigned Assigned Assigned Assigne N/A
Trade reported from Report c System Firm in Engine in Engine By in in in d in Firm
Clearing System to Clearing Clearing Clearing Clearing Back
Firm Back Office System System System System Office
3 Trade Update sent Trade Capture Electroni Clearing Clearing Replac No N/A N/A Assigned Returned Returned Assigned Assigne Assigned
from Firm Back Report c Firm System e by Firm by Firm by Firm in d in Firm in Firm
Office to Clearing Clearing Back Back
System System. Office Office
4 New Trade sent Trade Capture Pit Firm Clearing New No N/A N/A Assigned N/A N/A N/A Assigne Assigned
from Firm Back Report System by Firm d in Firm in Firm
Office to Clearing Back Back
System Office Office
5 New Trade from Trade Capture Pit Clearing Firm New No N/A N/A Assigned Assigned N/A N/A Returned Returned
Firm is Ack’d back Report Ack System by by by by
by Clearing System Clearing Clearing Clearing Clearing
System System6 System System
6 Firm enters a trade Trade Capture Pit Clearing Firm New Yes N/A N/A Assigned Assigned Assigned Assigned Assigne N/A
through Clearing Report System by by by by d in Firm
System User Clearing Clearing Clearing Clearing Back
Interface System System System System Office
7 Clearing System Trade Capture Pit Clearing Firm Replac Yes N/A N/A Assigned Assigned Assigned Assigned Assigne N/A
matches trade and Report System e by by by by d in Firm
sends report to Firm Clearing Clearing Clearing Clearing Back
System System System System Office
3 Clearing Trade ID
4 Used for multi-leg trade reporting. Refers to the ID of a Trade Leg as specified in a multi-leg TradeCaptureReport. Not used if trade legs are reported individually
5 Used for single leg trade reporting. Refers to the LegRefID as specified in the original multi-leg TradeCaptureReport
6 Clearing System may use FirmTradeID provided by the Firm as the TradeID
Business Workflow
The Clearinghouses assesses clearing margins based upon clearing member’s positions. This evaluation
produces a margin requirement which the members must meet using accepted forms of margin collateral.
Typical forms of margin collateral include cash, letters of credit, government securities, and equity securities.
If a clearing member has a margin shortfall the clearinghouse will immediately draft their settlement cash
account. The member may then choose to substitute this cash position with another form of collateral such as
a government security. The clearing member would contact their custodian/depository and instruct them to
transfer a sufficient quantity of securities to the clearinghouse. The depository would do this via out of band
means (non-FIXML). Upon acceptance of the collateral pledge the clearinghouse will deposit the collateral
and produce a Collateral Response message for the clearing member documenting the pledge. The clearing
member’s margin account would then carry an excess balance which the member could reduce by requesting
a cash withdrawal. This transaction would also trigger a FIXML Collateral Response message and a transfer
of assets, (again out of band).
This margin collateral rebalancing occurs frequently and dynamically through out each business day. At the
end of the day the clearinghouse will produce Collateral Report messages detailing the closing collateral
inventory positions.
FCM or Broker
Dealer
Covered Spreads and other User Defined Spreads using Security Definition Messages
Covered Spreads are an important subset of User Defined Spreads. At execution, Covered Spreads allow the
risk of an option strategy to be offset by taking a position in the underlying instrument. These strategies are
referred to as being “delta neutral”. A Covered Spread consists of a listed or non-listed option strategy such as
a calendar spread with one or more pre-defined underlying instruments specified. For Listed Derivatives, one
or more Futures instruments will be used to “cover” the option strategy. The Option Ratio is carried in the
option leg to which it applies.
The business rules governing the use of Covered Spreads in Listed Derivatives are as follows:
• An option strategy can only be covered with two futures if there are at least two different option
maturities
• No option leg can be specified more than once
• No covering future can be specified more than once
• For covered spreads, the inbound Security Definition ratio can only be between -99.99 to +99.99
• For covered call outright, the inbound Security Definition ratio can only be between 0.01 and
+1.00
• For covered put outright, the inbound Security Definition ratio can only be between -1.00 and -
0.01
Usage examples
Covered Spread Request
A Covered Spread Request consists of a listed or non-listed option strategy such as a calendar spread with one
or more pre-defined covering futures specified. The option strategy being covered in this example is a
straddle which can be expressed as ST: GEZ5 C9625 P9625. The straddle itself is not explicitly designated –
just the legs. Option legs and covering futures are specified in the Instrument Leg repeating group. The Ratio
is carried in the option leg to which it applies.
Security Definition Request
Tag Field Name Req'd Value
Standard Header Y MsgType = c (lowercase)
320 SecurityReqID Y Unique value assigned by client
321 SecurityRequestType Y “1” = Request Security identity for
specifications provided – name of security is not
provided
component block <Instrument> N User Defined Covered Spread specified here
55 Symbol Y “GE”
762 SecuritySubType Y Indicates if instrument being defined is a
Covered Spread
“COV” = Covered Spread
555 NoLegs Y Set to “3”
component block N Straddle Option Leg1
<InstrumentLeg>
1017 LegOptionRatio Y Assume that Leg1 Ratio = .75 and Leg2 Ratio =
-.5
LegOptionRatio = Ratio1 and Ratio2 = .25
Total quantity of Futures to buy is: (.25 x Option
Strategy Order Qty)
602 LegSecurityID Y CME333333
620 SecurityDesc Y “GEZ5”
623 LegRatioQty N “1”
637 LegLastPx* Y “962500” = Futures Price
827 ExpirationCycle N “0” = Expire on trading session close
263 SubscriptionRequestType N Not Used
Standard Trailer Y
Business Workflow
Product reference information is generally refreshed on a daily basis in order to convey changes to any properties
of an instrument. Users of an exchange or clearing entity service must obtain and load the Product Reference
Data. The data can be made available in a variety of ways - static file downloads, request/response mechanism,
subscription, or constant circulation over a broadcast feed.
Underlying Future-A
Class is based on Future
Option Class1
Reference to Future Definition
OPTION STRIKES-Class1
Derivatives Security List
OPTION STRIKES-Class2
Derivatives Security List
It is worth noting that options may also be modeled on an individual basis using the Security Definition message
or as a part of a list using the Security List message.
The diagrams below illustrate the how strategy instruments are defined. In the Futures Strategy diagram Futures
Strategy1 is comprised of Future-A and Future-B. An Option Strategy would be similarly constructed. In the
Complex Strategy diagram the Complex Combination Strategy is comprised of Futures Strategy1 and Futures
Strategy2. A Complex Option Strategy would be similarly constructed.
Futures Strategy
FUTURE STRATEGY1
Security Definition
FUTURE-A FUTURE-B
Security Definition Security Definition
Reference to Future
Futures-A Leg Reference to Future
Complex Strategy
COMPLEX
FUTURE STRATEGY1 COMBINATION STRATEGY FUTURE STRATEGY2
Security Definition Security Definition Security Definition
Reference to Future
Futures Strategy1 Leg Reference to Future
Futures-A Leg Futures-C Leg
Strike Specification
In general, strikes (option instruments) should be specifically enumerated. This is due to the fact that option
strategies are based on specific strikes and need to contain a reference to the strikes that make up the strategy.
Otherwise, the strategy itself is defined in a nondeterministic manner.
Security Definition
The Security Definition message is used to define an individual security or set of securities.
Security Definition Usage Guidelines
Recommended Uses:
• Allows a set of individual securities to be requested for a single Market Segment. The Security
Definition must be returned for the specified Market Segment
• Allows a request to be made independent of Market Segment. The Security Definition may carry all
relevant Market Segments and their corresponding trading rules.
• Allows stand-alone use in which a comprehensive Security Definition is generated for all Market
Segments in which that security participates
• If the Market Segment message is in use, Trading rules are to be included only if different than default
rules. Otherwise, only the relevant Market Segment identifiers are included
Explanation of Message Structure:
• Security Definition Request carries MarketID + MarketSegmentID at the main level as optional fields.
• Security Definition has a repeating Market Segment Group which allows all Market Segments in which
a security participates to be specified in the definition of that security.
• Only a single instance of the group will be used if a specific Market Segment has been specified on a
request. Multiple instances will be used if multiple Market Segments have been requested (by not
specifying Market Segment on request).
• If Market Segment is not applicable then MarketSegmentID = "[N/A]" (without the quotes) will be used
and trading rules will be provided.
• If Market Segment message is to be referenced for the trading rules only the Market Segment identifiers
should be provided
• Only a single instance of the group will be used if a specific Market Segment has been requested.
Multiple instances will be used if multiple Market Segments have been requested (by not specifying
Market Segment on request).
• If Market Segment is not applicable then MarketSegmentID = "[N/A]" (without the quotes) will be used
and trading rules will be provided.
• If Market Segment message is to be referenced for the trading rules only the Market Segment identifiers
should be provided
Security List
The Security List message is used to send a related list of securities in which each security is individually defined
within the list
Security List and Security List Request Usage Rules
Recommended Uses:
• Allows a list of securities to be requested and reported for a single Market Segment.
• Allows trading rules to be specified if different from the trading rules specified on the Market Segment
message.
Explanation of Message Structure –
• Security List Request and Security List will carry MarketID + MarketSegmentID at the main level as
optional fields.
• Security List will carry the SecurityTradingRules (trading rules) and StrikeRules in the instrument
repeating group.
Message Flows
Request for Instrument Definition
The DerivativeSecurityListRequest can be used to request a snapshot or snapshot supplemented with updates. In
static models it is not necessary to subscribe to instrument definitions as the data is made available on a retrieval
basis.
An Update Action Code will be provided at the option class level to indicate if the class is being added, modified,
or deleted. If deleted, all strikes in that series should be considered deleted. Further an List Update Action Code
will be provided at the Derivatives Security level to indicate if an options strike (or other instrument type) is being
added, modified, or deleted.
Usage exmples
This example shows a Derivative Security List message being used to specify a set of related option instruments.
The message structure begins by specifying the underlying. The DerivSecDef includes the option class
information which are the common properties shared by the option instruments. DerivSecDef also includes the
MktSegGrp block which specifies all the trading rules for the set of options. Finally, the specific options are
individually listed using the Instrmt block. Each option must specify the venue on which it is listed historical
strikes do not conform to the strike rules.
Option Class
<FIXML>
<DerivSecList=”1234567” Ccy=”USD” BizDt=”2007-06-01”>
<Undly ID=”ED” Src=”H” //Underlying for the Series
MMY=”200706”
Exch=”CME”
SecTyp=”FUT”
CFI=”FFDCSO” >
<SecAlt ID=”800103” Src=”8”/> //Underlying Instrument ID (IXM Num)
</Undly>
<DerivSecDef> //Group containing all Series info
<Deriv ID=”E0” Src=”H” //series product group
Sfx=”E0 W1” //series identifier
Exch=”CME”
Desc=”E0 June 2007 W1” //series name
MMY=”200706” //series period code
SecTyp=”OOF”
StrkCcy=”USD”
MatDt=”20070617” //series expiration
StrkLstMeth=”2” //prelisted and user requested
AsgnMeth=”R” //random assignment
ExerStyle=”A” //American style
UOM=”Int”
UOMQty=”1000000”
Mult=”250”
PxUOM=”USD” PxUOMQty=”1” PxQteMeth=”Int” //Price Quote props
SettlMeth=”C”
ValueTypCode=”PREM”>
<SecAlt ID=”E0 W1” Src=”N”/> //Globex Ticker
<SecAlt ID=”E0 W1” Src=”O”/> //Floor Ticker
<Evnt EventTyp=”5” Dt=”20061013” Tm=”202500000” /> //First day of
trading
<Evnt EventTyp=”7” Dt=”20070616” Tm=”202500000” /> //Last day of trading
<Evnt EventTyp=”16” Dt=”20070616” Tm=”202500000” /> //Position removal
date
</Deriv>
<DerivAttrib>
<Attrib Typ=”23” Val=””04”/> //Globex Tick Table
<Attrib Typ=”27” Val=”3” /> //Fractional Price precision
<Attrib Typ=”25” Val=”32” /> //Price Denominator
<Attrib Typ=”26” Val=”4” /> //Price Numerator fraction
<Attrib Typ=”28” Val=”3” /> //StrikePx Display precision
<Attrib Typ=”29” Val=”T” /> //Tradable,Non-tradable ind
</DerivAttrib>
<MktSegGrp
MktID=”CME” MktSegID=”Electronic”>
<StrkRules
StartStrkPxRng=”90.0” //starting strike price range
EndStrkPxRng=”92.5” //ending strike price range
StrkIncr=”.010” /> //Strike increment
<StrkRules
StartStrkPxRng=”92.505” //starting strike price range
EndStrkPxRng=”95.0” //ending strike price range
StrkIncr=”.025” /> //strike increment
<SecTrdgRules
MaxTrdVol=”1000” //Maximum order quantity
MinTrdVol=”1” //Minimum order quantity
ImpMktInd=”1” //Implied market indicator
<TickRules
StartTickPxRng=”90.0” //starting tick price range
EndTickPxRng=”92.5” //ending tick price range
TickIncr=”.005” //Tick increment
TickRuleTyp=”0” /> //Tick Rule Type
<TickRules
StartTickPxRng=”92.505” //starting tick price range
</Instrmt>
<Instrmt Sym=”GEH7P94675” Desc=”E0 Jun07 P 94675””
PutOrCall=”0” //Put
StrkPx=”94.675”
<Pty ID=”Globex” R=”73”> //Venue for which strike is eligible
<SecAlt ID=”700105” Src=”8”/> //Instrument ID (IXM Number)
</Instrmt>
<Instrmt Sym=”GEH7P94700” Desc=”E0 Jun07 P 94700””
PutOrCall=”0” //Put
StrkPx=”94.700”
<Pty ID=”Globex” R=”73”> //Venue for which strike is eligible
<SecAlt ID=”700106” Src=”8”/> //Instrument ID (IXM Number)
</Instrmt>
</DerivSecList>
<FIXML>
Outright Future
<FIXML>
<SecDef RptID=”1234567” Ccy=”USD” BizDt=”2007-06-01”>
<Instrmt ID=”ED” Src=”H” //product code
MMY=”200706” //period code
Exch=”CME”
SecTyp=”FUT”
CFI=”FFDCSO” //CFI code – standard/outright
Desc=”ED Jun 2007” //Clearing alias
MatDt=”20070615” //settlement date
Sym=”GEHZ” //Globex symbol
SecGrp=”GE” //Globex product group
UOM=”Int” UOMQty=”1000000” //unit of measure
Mult=”250” //price multiplier
PxUOM=”USD” PxUOMQty=”1” PxQteMeth=”Int” //Price unit of measure
SettlMeth=”C” ValueTypCode=”FUT”>
<SecAlt ID=”800103” Src=”8”/> //Instrument ID (IXM Number)
<SecAlt ID=”GE” Src=”N”/> //Globex Ticker
<SecAlt ID=”ED” Src=”O”/> //FloorTicker
<Evnt EventTyp=”5” Dt=”20061013” Tm=”202500000” /> //First day of trading
<Evnt EventTyp=”7” Dt=”20070316” Tm=”202500000” /> //Last day of trading
<Evnt EventTyp=”14” Dt=”20070316” Tm=”202500000” /> //First Intent Date
<Evnt EventTyp=”15” Dt=”20070316” Tm=”202500000” /> //Last Intent Date
<Evnt EventTyp=”10” Dt=”20070316” Tm=”202500000” /> //First Delivery Date
<Evnt EventTyp=”11” Dt=”20070316” Tm=”202500000” /> //Last Delivery Date
date
<Evnt EventTyp=”12” Dt=”20070316” Tm=”202500000” /> //Initial inventory due
date
<Evnt EventTyp=”13” Dt=”20070316” Tm=”202500000” /> //Final inventory due
date
<Evnt EventTyp=”16” Dt=”20070316” Tm=”202500000” /> //Position removal date
</Instrmt>
<InstrmtExt>
<Attrib Typ=”23” Val=””04”/> //Globex Tick Table
<Attrib Typ=”27” Val=”3” /> //Fractional Price precision
<Attrib Typ=”25” Val=”32” /> //Price Denominator
<Attrib Typ=”26” Val=”4” /> //Price Numerator fraction
PRODUCT: EQUITIES
Investment
manager 4 (optional)
1
New order message. Allocation Instruction
Clearing broker 3 (optional) message, status ‘ New’ , type
referenced in P arties Allocation Instruction ‘P reliminary’ or ‘ Calculated’ .
component block. message, status ‘ New’, type Executing broker(s) identified
Execution reports sent ‘ Ready to book’ in NestedP arties2 component
back to investment block in the NoOrders
manager . repeating group)
Executing Clearing
broker 2 (optional) broker
Drop copy execution
reports to clearing broker
This flow also supports the scenario where the investment manager has a block order which is then sent out (in
parts) to a number of executing brokers, all to be settled by the same clearing broker. In this case, each executing
broker receives a 'ready to book' allocation from the investment manager for their order(s) and the clearing broker
receives a single allocation message for the entire block. This latter message will reference the client order ids on
each order (which can be used to match up to the execution reports from the executing brokers) and the executing
broker id.
CFDs
CFD with cash equity hedge executed by same broker as writing
the CFD
Investment
manager
Executing
broker
The BookingType field is used on the new order messages to transmit the notification that the order is for a CFD.
This information is required at the time of execution as a) the broker may need to invoke separate credit or
compliance checks (e.g. different RTL) and b) the broker will need to know to execute a principal cash hedge.
Note the example here could be extended to cover any OTC derivative product where one or more of its cashflows
is derived from a cash equity position.
CFD with cash equity hedge executed by different broker from that
writing the CFD
Here the clearing broker is writing the CFD and the executing broker is simply executing a cash equity hedge for
(and settling with) the clearing broker. The allocation instruction from the investment manager to the clearing
broker contains the BookingType field to provide notification that the order is to be booked out as a CFD.
BookingType can also optionally be provided on the new order message to the executing broker.
Investment
4 (optional)
manager
1 Allocation Instruction message,
status ‘ New’ , type ‘P reliminary’
New order message.
3 (optional) or ‘ Calculated’ .
Clearing broker
referenced in P arties Allocation Instruction Executing broker(s) identified in
component block. message, status ‘ New’ , type NestedP arties2 component
‘ Ready to book’ block in the NoOrders repeating
Execution reports sent
group). BookingType = 1 (CFD)
back to investment
used to identify this as being
manager .
settled as a CFD.
Executing Clearing
broker 2 (optional) broker
Drop copy execution
reports to clearing broker
Directed Brokerage
Directed brokerage (commission recapture) programmes are arrangements whereby a proportion of commission
on certain trades is not retained by the broker, but set aside to be paid ultimately to the underlying funds on whose
behalf the trades were executed; this may or may not involve an intermediary (e.g. Frank Russell, State Street,
Lynch Jones Ryan) who collects payments from the brokers and manages the payment to the end funds.
As with soft dollars, the ProcessCode field (value '6=plan sponsor') is used. In addition, the identity of the scheme
administrator must also be identified. Use of the post-trade allocation instruction message is recommended over
use of ProcessCode on the new order messages for the same reasons as given for soft dollars above. The
NestedParties component block in the NoAllocs repeating group in the allocation instruction message (for post-
trade allocation) or new order message (for pre-trade allocation) should be used for identifying the scheme
administrator.
The confirmation message contains an optional field SharedCommission which can be used to communicate the
amount of commission actually being split out to the intermediary.
The flows outlined below and supported in FIX 4.4 are subject to the following constraints:
• Only equities will be warehoused.
• Multi-leg instruments will not be warehoused.
• No special functionality will be provided to cover corporate actions occurring during a warehouse period.
• Only GT orders will carry warehousing instructions on the order message itself (wrong – this covers day
orders as well). If the sellside decide to warehouse a day order they will use the FIX allocation message.
• Sellside firms will be responsible for deciding whether or not to accept a warehouse request.
Flow Summary
The following four flows are supported:
Good Till Order – Warehouse Until Filled Using Pre-Trade Booking Instruction
Day 1 – entire part-filled quantity is warehoused
BuySide SellSide
1. Buyside sends new GT order with instruction
New order single to warehouse any part-filled quantity until the
GTBookingInst = 1 order fills or expires (i.e. GTBookingInst is
1).
Execution reports 2. Sellside accepts the order, then sends 1 or
(new...partial fills) more partial fill execution reports.
Allocation instruction
AllocTransType 'new'
4. Buyside provides allocations for entire order
AllocType either 'Buyside
quantity
preliminary' (if without
MiscFees) or 'Buyside
calculated' (if with)
Allocation Instruction ACK 5. Sellside acknowledges receipt of the
(AllocStatus 'received') allocation details.
Good Till Order – Partial Warehousing - Day 1 (some of the part-filled quantity
is warehoused; the rest is allocated)
Day 1 – part of the part-filled quantity is warehoused
BuySide SellSide
1. Buyside sends new GT order with instruction
to warehouse any part-filled quantity (i.e.
GTBookingInst is 1 or 2).
New order single
Should clarify that use of GTBookingInst
GTBookingInst = 1 or 2
implies warehouse instructions not required.
Should add an example of 'normal' GT (i.e. no
GTBookingInst), i.e. post trade instructions
Execution reports 2. Sellside accepts the order, then sends 1 or
(new...partial fills) more partial fill execution reports.
(AllocReportType = 5)
Subsequent days' flows are as in 'Warehouse till filled' scenario above.
Note the flow is similar when the entire order is warehoused – in this case, messages 4a, 5a and 6a are missing.
Decision Flows
The NoStrategyParameters repeating group is to be used instead of the deprecate fields TargetStrategyParameters
(848) and ParticipationRate (849). This repeating group allows the ability to conveny multiple parameters in an
unrestricted manner between the Initiator and Respondent, as long as the StrategyParameterName,
StrategyParameterType and StrategyParameterValue ranges are recognized by the Respondent.
For example, a ‘VWAP’ strategy with specified start time and end time and two additional parameters,
participation rate (40%) and aggressiveness (Y) can be represented as follows:
It should be noted that StrategyParameterType is an enumerated field which may contain the following values
(See also Volume 6, Data Dictionary).
1 = Int 9 = PriceOffset
2 = Length 10 = Amt
3 = NumInGroup 11 = Percentage
4 = SeqNum 12 = Char
5 = TagNum 13 = Boolean
6 = Float 14 = String
7 = Qty 15 = MultipleValueString
8 = Price 16 = Currency
17 = Exchange 21 = LocalMktTime
18 = Month-Year 22 = UTCDate
19 = UTCTimeStamp 23 = Data
20 = UTCTimeOnly
Regulation NMS
Background
The Security and Exchange Commission (SEC) of the US has issued Regulation NMS (Reg NMS) in its final
form on June 9, 2005, which is available at http://www.sec.gov/rules/final/shtml . As it relates to the FIX
Protocol this section discusses the support provided by the protocol to be compliant with Reg NMS. The
focus will be on identifiers required to assist broker-dealers and trading centers in complying with the Order
Protection Rule (Rule 611) and the Sub-Penny Rule (Rule 612, also known as the Minimum Pricing
Increment Rule).
7 The exemptions listed are taken directly from the SEC filing with the FIF interpretation of the exemption given in brackets and italics below.
5. The transaction that constituted the trade-through was the execution of an order identified as an
intermarket sweep order.
[Referred to as the intermarket sweep exemption]
6. The transaction that constituted the trade-through was effected by a trading center that
simultaneously routed an intermarket sweep order to execute against the full displayed size of any
protected quotation in the NMS stock that was traded through.
[Exception for a transaction that executes at an inferior from the NBBO because other intermarket
sweep orders simultaneously hit protected quotes.]
7. The transaction that constituted the trade-through was the execution of an order at a price that was
not based, directly or indirectly, on the quoted price of the NMS stock at the time of execution and
for which the material terms were not reasonably determinable at the time the commitment to
execute the order was made.
[Exemption covering executions at a negotiated price, e.g., VWAP orders]
8. The trading center displaying the protected quotation that was traded through had displayed, within
one second prior to execution of the transaction that constituted the trade-through, a best bid or best
offer, as applicable, for the NMS stock with a price that was equal or inferior to the price of the
trade-through transaction.
[Referred to as the 1 second rule, intended to address flickering quotes.]
9. The transaction that constituted the trade-through was the execution by a trading center of an order
for which, at the time of receipt of the order, the trading center had guaranteed an execution at no
worse than a specified price (a “stopped order”), where:
a. The stopped order was for the account of a customer;
b. The customer agreed to the specified price on an order-by-order basis; and
c. The price of the trade-through transaction was, for a stopped buy order, lower than the
national best bid in the NMS stock at the time of execution or, for a stopped sell order,
higher than the national best offer in the NMS stock at the time of execution.
[Stopped orders are given on the consolidated tape.]
As it related to Reg NMS, FIX support for order protection compliance focuses on the following identifiers:
• Order Identifiers (for electronic trade communication)
o Intermarket Sweep Order Identifiers (for orders and execution reports)
o Single Execution Requested for block trade
• Quote Identifiers (for market data feeds)
o Manual Quote Identifiers
• Trade Identifiers (for market data feeds)
o Manual Trade Identifiers
o Intermarket Sweep Trade Identifiers
At this time FIX does not address the other Order Protection Rule exemptions.
Intermarket Sweep Order Identifier
According to the SEC filing: Intermarket sweep order means a limit order for an NMS stock that meets the
following requirements: (i) When routed to a trading center, the limit order is identified as an intermarket
sweep order; and (ii) Simultaneously with the routing of the limit order identified as an intermarket sweep
order, one or more additional limit orders, as necessary, are routed to execute against the full displayed size
of any protected bid, in the case of a limit order to sell, or the full displayed size of any protected offer, in the
case of a limit order to buy, for the NMS stock with a price that is superior to the limit price of the limit order
identified as an intermarket sweep order. These additional routed orders also must be marked as intermarket
sweep orders.
An intermarket sweep order functions like an Immediate or Cancel limit order (or other order type and time in
force), but it indicates that the firm sending the order has taken responsibility for price protection, and the
firm receiving the order should execute it immediately, if possible, without concern for price protection of
other markets.
As such the ExecInst field (tag 18) now includes a new value which would be used for order handling and
could be echoed on the execution report for this order.
ExecInst (tag 18)
• value "f" (lowercase F) to designate an "intermarket sweep" order
The Execution Reports do not need to identify intermarket sweep trades in the scenario where an incoming
order was executed against an intermarket sweep order since the original incoming order had not been
designated as an intermarket sweep order.
Quote & Trade Identifiers
Reg NMS differentiates between fast quotes, which are executed automatically, and slow quotes which are
executed manually. Reg NMS affords certain price protections to fast quotes that are not available to slow
quotes.
To differentiate between slow quotes, trades resulting from slow quotes, and trades resulting from intermarket
sweep orders in market data feeds the following fields and the associated new values can be used for this
purpose:
QuoteCondition (tag 276)
• value "L" (captial L) to designate a manual or slow quote
TradeCondition (tag 277)
• value "Y" (capital y) to designate a trade resulting from a manual or slow quote
• value "Z" (capital z) to designate a trade resulting from an intermarket sweep
Interoperability with Other Standards
Currently the CTA8 and UTP9 Plans have outlined flags ‘A’, ‘B’, and ‘H’ as follows:
The basic data element in the CTA and UTP Plans is a two-sided quote, while the FIX Protocol represents a
bid and ask pair as two distinct one-sided data elements. So these three values can map to
QuoteCondition(276) = L on the respective bid or ask Market Data Entries.
Additionally, the CTA Plan has redefined sales condition ‘F’ to reflect that an order was executed as an
intermarket sweep order. 10 This can map to a Market Data Entry representing the trade and having
TradeCondition(277) = Z
instruction
OrderHandlingInstSource(1032)=1 //NASD OATS is handling instruction
source
NoTrdRegTimestamps(768)=2
TrdRegTimestamp(769)=20061209-19:00:07 //Broker Receipt time in UTC
TrdRegTimestampType(770)=4 //Broker Receipt
TrdRegTimestamp(769)=20061209-19:00:42 //Desk Receipt time in UTC
TrdRegTimestampType(770)=6 //Desk Receipt
TrdRegTimestampOrigin(771)=NYINST //Desk ID
DeskType(1033)=IS //Instutional desk
DeskTypeSource(1034)=1 //NASD OATS source code
DeskOrderHandlingInst(1035)=NH AON //Desk's order handling inst, "not
held" and "AON"
Introduction
This section and the enhancements to the protocol has been the result of the joint effort between the BMA and
FPL’s Global Fixed Income Committee (formerly Fixed Income Working Group). This Appendix summarizes
how FIX messages can be used to support FI trading activities – offerings, negotiated trade/bid or offer request,
my bid/offer order, order initiation and execution, and allocation – for the following fixed income asset classes:
• US Treasury Bonds
• US Corporate Bonds
• Municipal Securities
• Agency Securities
• To-Be-Announced (TBA) Mortgage Backed Securities
• Euro Sovereign Bonds
• Euro Corporate Bonds
• US and European Commercial Paper
• Repurchase Agreements (Repos) and Related Securities Lending Activities
The usage models are described as between two counterparties, an Initiator and a Respondent – see the Glossary
in Volume 1 for definitions of these roles.
Note that this documentation should be used as a starting point and serves merely to provide guidance in the
reader’s FIX for FI implementation.
Message Dialog
In FI the trading dialog typically starts in one of two ways: 1) one party sending out offerings to their clients and
their clients responding to the offerings, or 2) an interested party initiating an inquiry or a bid/offer request. Once
the dialog is initiated a trade could be consummated. The allocation of the trade could be conducted “pre-trade”
or “post-trade” directly with the trading counterparty. Third party post-trade reporting using FIX messages is also
illustrated.
The diagrams below attempts to illustrate the various dialogs that can happen to facilitate an FI trade and the
message flows to use depending on the initiation point of the dialog. Note that the diagrams will also show, via
the green colored circles, the next step in the message dialog and do not show error conditions (i.e. one party
receiving an unknown CUSIP) that can occur during the dialog.
Figure 2: My Bid/Offer
Allocation Instructions
Allocation instructions can be communicated by the Initiator via three different options:
1. Pre-allocated Order – in this option the Initiator would communicate the allocation instructions
within the New Order message when the order is placed with the Respondent.
2. Pre-trade allocation – in this option the Initiator would communicate the allocation instructions
to the Respondent in a separate message using the Allocation message. The Allocation message is
sent after the order is placed with the Respondent but before the trade is completed by the
Respondent.
3. Post-trade allocation – in this option the Initiator would communicate the allocation instructions
to the Respondent in a separate message using the Allocation message after the trade has been
completed by the Respondent.
For the Initiator options 2 and 3 represents the same message flow. The main difference is when the Allocation
message is sent – in option 2 it is sent prior to the trade being completed and in option 3 it is sent after the trade
has been completed.
Once the trade is completed and the Respondent is ready to act on the allocation instructions, assuming no errors
in the allocation instructions from the Initiator, the message flow for the Respondent is the same regardless of
which option is used by the Initiator to communicate those allocation instructions.
Note that these options work for Fixed Income because of FI’s simple trading practices – there is no concept of
“done for day”, one set of allocations is applied to a single order usually filled in a single execution.
In the Pre-allocated Order scenario the Initiator would send a New Order message that includes the allocation
information needed by the Respondent to allocate the trade once the trade is completed. Note, however, that if
even one account cannot be identified, or the quantity of one allocation instance does not meet minimum
quantity/minimum increment rules for the instrument, or the sum of allocated quantities does not equal the block
trade quantity, the entire request must be rejected. If erroneous allocations are sent via the New Order message,
the entire New Order message is rejected using the Execution Report message with the appropriate reject code.
If the pre-allocated Order is accepted and filled, the Respondent communicates that information to the Initiator
using the Execution Report message type, setting all the appropriate status values per standard protocol usage.
At this point in the message flow the Respondent would begin to allocate the trade according to the allocation
instructions already provided in the New Order message and communicating that information back to the
Respondent according to the message flow shown in Figure 5, starting with the AllocationReport.
Figure 5: Allocations
In the Pre-trade allocation scenario the Initiator would send the allocation instructions, after placing the order but
before the Execution Report message indicated that the trade is completed, to the Respondent using the
AllocationInstruction message type. On the other hand, in the Post-trade allocation scenario the Initiator would
send the allocation instructions to the Respondent after receiving the Execution Report message indicated that the
trade is completed – again using the AllocationInstruction message type.
Before accepting the request the Respondent should determine that all accounts are known, the quantity of each
allocation instance meets minimum quantity/minimum increment rules for the instrument and the sum of allocated
quantities equals the block trade quantity. If any error is found the Respondent must reject the entire Allocation
using the AllocationInstructionAck message with the appropriate reject reason code. In this event, whether the
trade that has been completed or is pending completion, the order is a still a live order. A rejection of the
AllocationInstruction message does not equate to a reject of the order placed in this case. The Initiator can send a
new AllocationInstruction message with the correct instructions and information to the Respondent.
If the Respondent accepts the AllocationInstruction, the message flow would continue as shown in Figure 5 with
the Respondent sending the AllocationReport message to communicate the sub-account level calculations for net
monies and accrued interest if appropriate. At this stage the Initiator still has the option to reject the
validated/calculated allocation message due to differences in calculations of net money, gross amounts, etc., for
each of the allocated sub-accounts. Alternatively the Initiator can acknowledge back to the Respondent that the
validated/calculated message is accepted. Both the Initiator’s response is communicated via the use of the
AllocationReportAck message type.
Figure 6 illustrates the message flow of the confirmation process for each of the allocated account instance (the
sub-accounts in the AllocationInstruction message) the Respondent would use once the allocation calculations
have been confirmed by the Initiator.
The Confirmation message is an optional message that the Respondent can use to report back, confirms or raise an
exception of the booking/confirm status of each of the allocation instances in the trade. When the “confirmed”
status is reported to the Initiator it indicates that that piece of the allocated trade is ready to settle. Each
Confirmation message will report the details of a single “ticket”, therefore the account names, fees, net money
and settlement information are reported using fields designated for single account trades.
Once the “confirmed” is received from the Respondent the Initiator has the final say by sending the
ConfirmationAck message with the “affirmed” status. However, should the Initiator disagree with the
Respondent’s “confirm” the Initiator can send a reject using the ConfirmationAck message with a status of
“rejected” and provide a reason for rejection.
The Allocation Instruction message type is used by the Initiator to report one or more orders and block trades
along with associated allocations to a 3rd party or VMU for trade matching.
The Respondent will use the Trade Capture Report, or an Execution Report depending on the 3 rd party’s
requirements, message type to report trades to a 3rd party. This notice of execution will be for block level trades.
Indication Of Interest
An IOI must specify price information by using either one of the set of price information fields (see General
Usage Rules section)
Either the IOIQty or the NoLegs repeating block is required.. If the NoLegs repeating block is used, put “0”
(zero) in the IOIQty field. IOIQty is required and used for offerings of single instruments. The NoLegs repeating
block is used for multilegs (swaps/switches/rolls). In FI’s use there would only be two legs – a buy leg and a sell
leg.
ValidUntilTime is where the IOI sender can specify the “firm time” of the offering.
Quote Request
In this message the Initiator can specify what form the quote should be in by using the QuotePriceType field.
The ClOrdID field has been added to this message allowing the Initiator to assign a ClOrdID when requesting for
quotes that are of QuoteType “Tradable” and OrdType of “Limit”.
To submit a “my bid/offer” quote request the Initiator will need to specify QuoteType of “Tradable” and OrdType
of “Limit”. Pricing information must be specified using either one of the set of price information fields (see
General Usage Rules section)
ValidUntilTime – used by the Initiator to indicate the period of time the resulting Quote must be valid for
ExpireTime – used by the Initiator to indicate the period of time when this quote request expires
OrderQtyData component block – required when QuoteType is “Tradeable”
Quote Response
Initiator will use the QuoteRespType field to indicate what type of response this is, i.e. “hit/lift”, “counter”, etc.
IOIid is required if the Quote Response is used to respond to an IOI (offering) message, the field would contain
the ID of the IOI message.
Fields required when QuoteRespType is “hit/lift” or “counter quote”: OrderQtyData component block, Side,
ValidUntilTime, ClOrdID (see paragraph below), and either one of the set of price information fields (see General
Usage Rules section).
In the initial use of the “hit/lift” QuoteRespType, the Initiator is required to assign a ClOrdID. This ClOrdID will
be reused throughout the negotiation process, including in the “counter”, until the negotiation ends in either a fill
or the negotiation dialog is terminated by either party.
In a “counter quote” to a Quote, only a limited set of data elements can change depending on the security type.
Price can be expected to change, but also Instrument being quoted can change in some markets as well as
Stipulations and ClearingCode within the Parties component block.
In a “counter quote” with a “my price” set, OrdType must be “Limit” and either one of the set of price
information fields (see General Usage Rules section).
Quote
Fields required when QuoteType is “counter” or “Tradeable”: OrderQtyData component block, Side,
ValidUntilTime, and either one of the set of price information fields (see General Usage Rules section).
For the Multileg Order, if the following fields are not applicable to all legs of the trade then the NestedParties
component block associated with each leg within the NoLegs repeating block will be used: Account,
AccountType, NoAllocs repeating block, SettlType, and SettlDate.
Execution Report
This message should always use SettlType “future” with a value for SettlDate.
Stipulations component block information must be reiterated and echo back by the Respondent if Initiator had
provided information in the Stipulations component block.
For multilegs only use the NoLegs blocks of the Execution Report message for swaps/switches/rolls when
OrdStatus is “new”. The partial fill or fill (OrdStatus) Execution Report for each of the legs will be reported
separated and execution price for each leg is conveyed in LastPx, AvgPx and LastPxPar, if applicable.
The following fields are required when OrdStatus is “partial”, “filled” or “calculated”: PriceType, Price
The following fields are required when ExecType is “trade” or “trade correct”: LastQty, LastPx, AvgPx,
LastPxPar (when conditionally applicable)
The following fields are required when OrdStatus is “filled” or “calculated” AND if NumDaysInterest is
populated and not zero: AccruedInterestRate, AccruedInterestAmt
GrossTradeAmt and NetMoney is required when OrdStatus is “filled” or “calculated”.
NumDaysInterest is required where applicable based on security type and when OrdStatus is “filled” or
“calculated”.
InterestAtMaturity is required in lieu of AccruedInterestAmt for security types that pay lump-sum at maturity.
Allocation Instruction
PreviouslyReported, ReversalIndicator and MatchType is conditionally required when Initiator is sending the
Allocation Instruction message to a 3rd party or VMU.
This message should always use SettlType “future” with a value for SettlDate.
GrossTradeAmt – Initiators are required to send this information when sending Allocation post-trade.
For Financing Trades Use QtyType and ContractMultiplier if necessary to identify how quantities are to be
expressed and specify in OrderQty the block cash amount to be allocated and in AllocQty the cash amount to be
assigned to each fund.
Allocation Report
Respondents are required to send this information when reporting the Allocation back with calculations.
NetMoney is required from Respondents when reporting the Allocation back with calculations.
NumDaysInterest, AccruedInterestAmt and AccruedInterestRate is required from Respondents when reporting the
Allocation back with calculations for security types where this information can be derived or is available.
InterestAtMaturity is required in lieu of AccruedInterestAmt for security types that pay lump-sum at maturity.
AllocNetMoney is required from Respondents when reporting the Allocation back with calculations.
AllocAccruedInterestAmt is required, if the value is not zero, from Respondents when reporting the Allocation
back with calculations. AllocAccruedInterestAmt should be calculated and rounded appropriately for each
allocation instance. This means that the sum of AllocAccruedInterestAmt will not always match
AccruedInterestAmt.
AllocInterestAtMaturity is required, if value is not zero, from Respondents when reporting the Allocation back
with calculations. AllocInterestAtMaturity is required in lieu of AllocAccruedInterestAmt for security types that
pay lump-sum at maturity. Similar to AccruedInterestAmt, the sum of AllocInterestAtMaturity will not always
match InterestAtMaturity.
For Financing Trades use the same quantity rules as given for the Allocation Instruction above.
SecurityType=REPO
UnderlyingSecurityType=AGENCY
UnderlyingIssuer=CA Housing Trust
UnderlyingCountryOfIssue=CA
SecurityType=REPO
UnderlyingSecurityType=CORP
UnderlyingNoStipulations=1
UnderlyingStipulationType=RATING
UnderlyingStipulationValue=>bbb-
Haircut Reduction in market value <UnderlyingStipulations> UnderlyingStipType=HAIRCUT
taken on assigned securities
in calculating their UnderlyingStipValue=<percent>
collateral value – based on
market volatility and credit.
Largest piece Maximum size of securities <Stipulations> StipulationType=MAXDNOM
acceptable in the transaction
StiuplationValue=<size>
Lookback days Number of business days <Stipulations> StipulationType=LOOKBACK
prior to floating rate reset
date when the benchmark StiuplationValue=<number of days>
price will be captured and
used to determine the new
rate upon reset
Collateral Management
The following diagrams illustrates an example flow for collateral management once a repo or financing deal has
been completed. Figures 8 to 11 shows an example for 2-party model and Figure 12 shows an example for 3-party
model.
Message Dialog
In FX the trading dialog typically starts with a request for quote by the customer or a request for streaming prices
by the customer. Once the customer receives the rate and quantity desired for the currency pair they wish to deal
in the dealer offering the rate will contacted and a trade could be consummated.
The discussed usages of FIX for FX trading focused on the interactions between the customer and the bank or
dealer, and illustrated in the diagrams in the following sections11.
Price Discovery
In FX price discovery there are two main ways in which customers receive prices from their bank or dealer.
One is through a request for quote (via phone or electronically) and the second is through a price stream - the
latter is typically in electronic form.
In FIX a distinction is made between the two types of price discovery methods. The Quote message set is
used to support "one-off" quote requests. The Market Data message set is used to support requests for
indicative and executable price streams for FX asset types that do not require negotiation. It should also be
noted that the Quote message set will also support "one-off" quote requests that may be "hit" with an order
message without any negotiation. 12
Quoting Message Dialog
The quote/order usage model of the Quote message set shown in Figure 1 is a straightforward request for a
"one-off" quote that is then "hit"13. The dialog flow is described below.
A. The Initiator or customer requests a quote from the Respondent or dealer. The Respondent responds with
either:
1. a quote by sending the Quote message
11 Further enhancements will be made to the protocol to better support FX dealings through 3rd party electronic trading platforms and
exhcnages.
12 Negotiation in FX is currently not covered although the protocol supports such interaction.
13 It should be noted that in this model the New Order message (rather than the QuoteResponse message) is used to "hit" the tradeable Quote
when the Negotiation model is not supported. The QuoteResponse message is used to "hit" a tradeable Quote when the Negotiation model is
being supported.
2. decline to provide a quote, reject the request, or indicate that a quote cannot be provided by sending
a Quote Request Reject message with an appropriate reject reason. Although the Respondent can let
the request time out if an expiration time is specified, it is best practice to explicitly respond with a
reject if the dealer does not want to provide or cannot provide a quote.
B. The Initiator then responds with either:
1. a New Order to accept the quote provided
2. do nothing and just let the quote expire. The Initiator is not obligated to explicitly indicate to the
dealer that they do not wish to act on the quote provided.
3. a QuoteResponse message to explicitly indicate to the Respondent that the Initiator has either "done
away" or "pass" on the quote, or has "expired" when the Quote was received after the ExpireTime in
the Quote Request
C. If the Initiator places an order the Respondent responds with an acknowledgement that the order has been
received and either:
1. fills the order by sending an Execution Report
2. rejects the order. This meets the plain English document requirement that the Respondent reserves
the right to reject an order that is placed against a quote.
Additionally in a "one-off" quote request, the dealer may update the Quote as long as the Quote has not
expired. The updated Quote may contain a new expiration time or preserve the existing expiration time. The
updated Quote is the only live quote, thus rendering the original quote obsolete or canceled. The dealer may
also cancel or "withdraw" a live quote prior to its expiration via the use of the Quote Cancel message. Once
the most current live Quote has expired or canceled/withdrawn the dealer may not update or "replace" it. It
would be up to the customer to issue a new quote request. The dealer may only update quotes corresponding
to a Quote Request before the expiration time of the request, indicated in ExpireTime field.
It should be noted that the Quote Request and Quote message interaction is used only for short-lived RFQs
and requests for a single rate quote. A "Short-lived" RFQ is defined as a request that has a very short life
span, mimicking a rate request that would be made over the phone - typically not longer than 1 or 2 minutes.
2. place an order against a market data entry that interests them at the same price and amount level
indicated in the market data entry
C. If an order is placed the Respondent will respond with the Execution Report to acknowledge receipt of
the order, followed by a fill (or partial if allowed) or a rejection if the quote can no longer be honored.
D. At any time the Initiator can stop the price stream subscription by sending a Market Data Request
message to "unsubscribe"
The Market Data messages will also support a full refresh subscription model. The differences would be in
the request and the response would be only Market Data Snapshot messages. For "exchange" style
aggregators this may be the Market Data usage model for them.
A price stream can be either executable/tradeable or indicative, where all the quotes in the particular price
stream are either tradeable or indicative, not both. The Initiator may explicitly specify in the Market Data
Request message that the request is for a tradeable or indicative price stream. If this is not specified the
Respondent should assume the request is for indicative price stream unless other arrangements are made
bilaterally (e.g. via customer profile configuration).
Trading platforms may require the Initiator to indicate which dealer's prices should be included in the price
stream. Alternatively, trading platforms may provide configurable customer profiles where defaulted dealers'
prices will always be provided in a price stream unless specifically indicated by the Initiator. Trading
platforms may respond with a single consolidated price stream with prices from all requested dealers or open
up individual price streams for each dealer, although the latter model is not the preferred model.
Vector Prices
Vector prices are described as price bands for FX rates for a specifically requested currency pair and tenor.
The Initiator would submit a request to the Respondent with at least the currency pair and the required tenor.
The Respondent who would supports displaying of vector prices may respond with the price bands. Each
band would be for an "up to" amount and the price for the band. It is similar to displaying the "depth of
book", however, the main difference between other asset types and FX is that the "book" is not swept when an
order is received from a customer.
For example: customer submits a request for a price stream for 6-month EUR/USD. The dealer may elect to
provide price bands by showing 3 price bands for the requested currency and tenor, for example:
Each band's size is an "up-to" amount. When a customer places an order, for example, for EUR 7,000,000
then the entire amount will be filled at the price from Band 2 in the example above, not from a combination
of Band 1 and Band 2, which would be a "sweep".
Vector prices or price bands are implicitly supported using the Market Data messages. Each market data
entry has an identifier, MDEntryID, thus a vector price would be represented by the number of MDEntryIDs
needed. In the example above, the Market Data message would identify each price band with its own
MDEntryID, as well as QuoteEntryID, for the stated same currency pair and from the same dealer. The
difference in the entries would be the amount and rate(s).
Example Scenarios
The following are example scenarios of how the Market Data Request can be used when sending a request to
different types of Respondent and what can be expected as a response.
1. Single Bank
In this scenario the Respondent is a single bank. The customer would likely be requesting prices for one
or more currency pairs and may request a specific quantity for each pair. The quantity in the request will
be treated as an "up to" quantity.
Market Data Request:
• Customer requests prices for a currency pair
• Customer may also request a specific quantity
• The target bank is implicit
The Respondent may provide prices at different quantity levels if the customer did not request a specific
quantity. The bank also may specify that the prices are indicative or tradeable if the customer did not
explicitly request tradeable prices.
Market Data messages:
• Bank may provide prices at different quantities if the Customer does not request a
specific quantity
• In this case, aggregated and non-aggregated "book" produces the same results
• Prices may be indicative or tradeable
MarketDepth="full" or MarketDepth="top of book". AggregatedBook would not be applicable as a the
results would the same as a non-aggregated book.
The Respondent would likely respond with a non-aggregated view of the market showing full depth of
book so that each bank's quotes can be discretely identified. The dealers may also specify whether the
prices are indicative or tradeable if the customer did not explicitly request tradeable prices.
Market Data messages:
• Will be full depth and not aggregated, so different bank's quotes can be identified
• Prices may be indicative or tradeable
FX Settlement Obligation
FX OTC Settlement requires that settlement information be reported to counterparties such that they are
aware of their obligations at both an individual trade level as well as an aggregated level. Trade level
settlement information includes the receiving accounts of both the central counterparty as well as the firm
counterparty. Settlement reporting for trades is considered as being reported at a gross level.
Settlement reporting can also be aggregated or netted across a series of trades for a given currency pair and
value date. The Settlement Obligation Report is used to inform counterparties of their settlement obligation
and provides information on where each party is to receive payment. Settlement account information may
include the bank at which each party holds a specific currency as well as CLS bank information. A Settlement
Obligation Report can be sent at various points throughout the settlement day with a status of preliminary or
final.
Central Counterparty Workflow
In a central counterparty workflow the Settlement Obligation Report will be sent out from the central
counterparty responsible for guaranteeing the FX OTC deal to each of the counterparties involved in the deal.
Reporting may take place intra-day or end-of-day with the reports being flagged accordingly. Settlement
Obligation Reports can report settlement as either net or gross. Settlement Obligation Reports will be reported
by value date.
FX OTC trades with settlement information will be sent on a real time basis as the trade is executed, received,
and posted by the central counterparty. Trades carrying settlement information are considered to be
specifying gross settlement. FX OTC trades will be reported as they occur – sometimes significantly in
advance of the value date.
Individual FX OTC trades are aggregated by value date into a Settlement Obligation Report which can be
sent to parties involved in the deal on an intra-day or end-of-day basis.
Instrument: EUR/USD
Trade1: Buy 1M EUR @ 1.25 Sell 1.25M USD
Trade2: Sell 1M EUR @ 1.35 Buy 1.35M USD
Aggregated: Receive .1M USD, Deliver 0 EUR
Spot Order
EUR/USD
Trading Firm Side=Buy
OrdQty=1,000,000
Price=1.2500
Order Entry and Fills
Exchange reports
fills to trading firm
and trades to
clearing entity
Fill
EUR/USD
Side=Buy
Exchange
OrdQty=1,000,000
Price=1.2500 Message Delivery
SettlDt=2006-07-20
Clearing/
Cleared Trade Reporting
Settlement
Trade Capture Trade Capture Trade Capture
EUR/USD EUR/USD EUR/USD
Side=Sell Side=Buy Side=Buy
LastQty=5,000,000 LastQty=1,000,000 LastQty=5,000,000
LastPrice=1.2000 LastPrice=1.2500 LastPrice =1.3000
ContraQty=6,000,000 ContraQty=1,250,000 ContraQty=6,500,000
Settlement
Instructions sent to
Message Delivery CLS via SWIFT API.
SWIFT CLS Sponsor may
Gateway be used
Banking and Settlement
MT300
CLS
Clearing Firm SWIFT NET CLS
Sponsor
SWIFT Delivery
Messages
$ $
Clearing firm
reconciles CLS
Settlement with
FIXML Settlement
Reports CME CLS Bank Firm CLS Bank
Usage Notes
This section discusses the detailed usage of specific fields within the messages and some specific FX asset type
usages as well. These usage notes were the compilation of discussions that occured within the GFXC's Technical
sub-committee during its review of the FIX protocol. These notes should be considered the starting point for
implementation FIX for FX.
General Usage Notes
This section lists usage notes that are common requirements among the messages used for FX trading.
1. FX symbology is defined in the Electronic Broking Services, Ltd. (see http://www.ebs.com) format
of "CCY1/CCY2", where CCY1 and CCY2 are ISO currency codes. This is read as "currency 2 per
currency 1". FX symbology is carried in the Symbol (55) field.
2. Currency (15) field denotes the dealt currency. This field is mandatory for FX trading interactions in
all messages types.
3. SettlType (63) was enhanced as of version FIX 5.0 to allow proper expressions of standard tenors. It
should be noted that for FX tenors expressed using Dx, Mx, Wx, and Yx values do not denote
business days, but calendar days. Usage of SettlType values are as follows:
0 = Regular / FX Spot settlement (T+1 or T+2 depending on currency). "Regular" is defined as the
default Spot settlement period for the dealt currency.
1 = Cash / TOD (T+0)
2 = Next Day (T+1) / TOM (T+1)
B = Broken date - for FX expressing non-standard tenor, SettlDate (64) must be specified
C = FX Spot Next settlement (Spot+1, aka "next day")
Dx = FX tenor expression for "days", e.g. "D5" for 5-days, where "x" is any integer > 0
Mx = FX tenor expression for "months", e.g. "M3" for 3-months, where "x" is any integer > 0
Wx = FX tenor expression for "weeks", e.g. "W13" for 13-weeks, where "x" is any integer > 0
Yx = FX tenor expression for "years", e.g. "Y1" for 1-year, where "x" is any integer > 0
4. "Settlement currency" for FX trading is defined as the "counter currency" of the transaction.
SettlCurrency (120) is optional except in the cases where the transaction is to be settled in a third
currency that is different from the currencies identified in the pair. When it is not sent, by default it
means the opposite currency in the pair from the dealt currency, as identified in Currency (15) field.
For non-NDF deals (FX swaps, spot and forward) the term "settlement currency" can only mean one
thing: the currency that is on the opposite from the dealt currency (expressed in FIX using Currency
(15) field). For example: Symbol is EUR/USD, and the dealt is EUR then SettlCurrency is USD.
For NDF deals the term "settlement currency" could be either the dealt currency or the "counter
currency" or a third currency. For example: In a USD/KRW NDF deal where the dealt currency is
KRW, the settlement currency is USD, if the dealt currency is USD then the settlement currency can
also be USD. In a GBP/KRW NDF deal where the deal typically settles in a third currency, USD in
this case, then the settlement currency is USD. (NDFs will be discussed in detail in the Phase 2 gap
analysis).
For FX OTC Spot Options, the settlement currency can refer to either the counter currency or the
currency of the option premium (or premia). However, for the purposes of FIX usage, it will refer to
the currency of the option premium.
5. CFI Code (ISO 10962) is encouraged as a means to differentiate between the different FX asset
types. The following are CFI Codes for the FX asset types currently supported in FIX (based on ISO
10962:2006)
FX Spot: RCSXXX (was MRCSXX)
FX Forward: FFCPNO
FX Swap: FFCPNW
NDF: FFCNNO
6. Either SettlType (63) or SettleDate (64) is required in Initiator sent messages (e.g. Quote Request,
Market Data Request, and Order messages) except as specified in the section "SettlDate and
SettlType Required Usage Exception" below.
7. The following fields' value are to be expressed in decimal form. For example, 61.99 points is
expressed and sent as 0.006199.
BidSwapPoints
OfferSwapPoints
LegBidForwardPoints
LegOfferForwardPoints
SwapPoints
LastSwapPoints
LegLastForwardPoints
MDForwardPoints
LastForwardPoints
MDEntryForwardPoints
Quote Request
The Quote Request message is sent by the Initiator to request a "one-off" quote for a specific currency pair
with specific tenor or settlement date (a.k.a. value date). The type of request, QuoteRequestType, should also
be specified to indicate whether the request is for an indicative quote or a tradeable/executable quote. For the
most part FX requests would be executable.
Note that the Quote Request does allow the Initiator to send, in a single request, multiple currency pairs to the
Respondent. When multiple currency pairs are requested, the Respondent will send multiple Quote messages
in response, this is because the Quote message can only provide a quote for a single currency pair. However,
it should be noted that the Quote messages for the different currency pairs would reference the same quote
request identifier (QuoteReqID).
For FX the Quote Request message may not be used to send a "can you meet this rate" type of request,
therefore order-related fields in the Quote Request message such as ClOrdID (11), Price (44), and Price2
(640) are not used in FX.
ExpireTime Usage
When requesting a short-lived Quote Request the ExpireTime must be specified. The ExpireTime is set by
the Initiator to indicate when the request expires and quotes corresponding to the request will not be accepted
and should not be sent after that time. Updates to the quotes may be sent within that ExpireTime period.
A Quote Request message that does not contain an ExpireTime will result in one and only one Quote message
from the Respondent (if the Respondent chooses to respond with a rate). There will be no updates to this
quote. This type of request may be viewed as "one-offs".
Field Usage Notes
1. Either the SettlType (63) or SettlDate (64) must be specified in the Quote Request to specify the
tenor or value date (respectively). See "SettlDate and SettlType Required Usage Exception" section
below on exceptions to this requirement for certain groups of FIX users.
2. QuoteType (537) values applicable for FX are
0 - Indicative quote
1 - Tradeable quote
Absence of this field implies a request for an indicative quote.
3. Side (54) indicates from the Initiator's perspective whether the request is for a buy or a sell. Absence
of this field indicates a request for a two-sided quote. For FX Swaps, if requesting a 1-sided quote,
the value "B" (as defined) should be used - the side for each leg (LegSide) would be defined in
NoLegs repeating group.
4. OrderQty (38) is required for FX. Specified the exact amount of the dealt currency to be transacted
if the rate is acceptable.
5. Currency (15) is required and specifies the dealt currency of OrderQty (38). For FX Swaps (using
NoLegs repeating group) this denotes the dealt currency of the swap.
6. ExpireTime (126) is required for short-lived requests. See "ExpireTime" usage above.
7. The minimum required fields in a request are:
• FX Spot: the currency pair (Symbol), side (Side), amount (OrderQty), settle date (SettlDate) or
tenor (SettlType), dealt currency (Currency)
• FX Forward: the currency pair (Symbol), side (Side), amount (OrderQty), settle date (SettlDate)
or tenor (SettlType), dealt currency (Currency)
• FX Swap: the currency pair (Symbol), side (Side), near and far amounts (LegQty), near and far
settle date (LegSettlDate) or near and far tenor (LegSettlType), dealt currency (Currency)
8. NoLegs repeating group is used to define an FX Swap.
Quote Response
The QuoteResponse message can be used by the Initiator in a "one-off" quoting flow to explicitly tell the
Respondent that the Initiator is "passing" on the quote, has "done away" or if the Quote was received after the
Quote Request's ExpireTime ("expired").
1. QuoteID (117) is required for FX when responding to a Quote. This is the Respondent's QuoteID.
2. Current values to use for FX in the QuoteRespType (694) field are:
3 - Expired
5 - Done away
6 - Pass
3. Fields from the Quote message should be echoed back in the Quote Response.
Quote
The Quote message is used by the Respondent to respond to a Quote Request message. If the Quote Request
contains multiple currency pairs in the request, the Respondent will send a quote message for each currency
pair. Each of these quote messages will have its own unique QuoteID while referencing the same
QuoteReqID supplied in the Quote Request message.
The Quote may be updated by the Respondent as long as the original Quote has not expired. The initial
Quote in response to a Quote Request would reference the QuoteReqID along with the time which is it valid
until. The update will be implied by reference to the same QuoteRequestID. The Respondent may, at some
time before the Quote expires, update the Quote by sending a Quote with a new QuoteID, referencing the
same QuoteReqID. The ValidUntilTime may be a new time or the same time as the replaced Quote. At any
one time there can only be one live quote for a QuoteReqID for a given currency pair (there may be multiple
currency pairs associated with the same QuoteReqID since the request may contain more than one currency
pair). The ValidUntilTime of the Quote cannot be later than the ExpireTime specified in the QuoteRequest.
Definition of ValidUntilTime in FX Quote
ValidUntilTime is defined as the time that the quote expires and as the time value that cannot extend past the
ExpiryTime on the QuoteRequest. The committee also agreed that as a matter of policy there should be only
one live quote for a QuoteRequestID for a given currency pair from a given quote provider at any one time.
It would be up to implementations to decide whether to honor a hit on a quote that has expired.
Field Usage Notes
1. OrderQty is required for "tradeable" quote and optional for "indicative". For FX Swap, OrderQty is
not required, even when QuoteType = tradeable, as the amounts are indicated in LegQty.
2. SettlType and SettlDate are required in Quote message, except as specified in the "SettlDate and
SettlType Required Usage Exception" section below.
3. LegRefID is required for FX Swap.
4. BidPx and OfferPx expresses the "all-in" rate. For single-sided quote, either BidPx or OfferPx is
required. For two-sided quote, both BidPx and OfferPx is required. For FX Swaps these are not
required.
5. MinBidSize can be used to specify the minimum or floor amount to qualify for the FX rate specified
in BidPx.
6. BidSize always represents that maximum or ceiling or "up to" amount for the FX rate specified in
BidPx.
7. MinOfferSize can be used to specify the minimum or floor amount to qualify for the FX rate
specified in OfferPx.
8. OfferSize always represents the maximum or ceiling or "up to" amount for the FX rate specified in
OfferPx.
9. ValidUntilTime is required for FX. See usage noted in "Definition of ValidUntilTime in FX Quote"
section above.
10. BidSpotRate can be used to specify the bid spot rate. For forward bid quotes, if BidPx is specified,
either BidSpotRate or BidForwardPoints should be specified.
11. OfferSpotRate can be used to specify the offer spot rate. For forward offer quotes, if OfferPx is
specified, either OfferSpotRate or OfferForwardPoints should be specified.
12. BidForwardPoints is the bid forward points added to BidSpotRate. This may be a negative value.
For forward bid quotes, if BidPx is specified, either BidSpotRate or BidForwardPoints should be
specified.
13. OfferForwardPoints is the offer forward points added to OfferSpotRate. This may be negative value.
For forward offer quotes, if OfferPx is specified, either OfferSpotRate or OfferForwardPoints should
be specified.
14. BidSwapPoints and OfferSwapPoints are the swap points of an FX Swap quote.
Quote Cancel
The Quote Cancel message is used by the Respondent to cancel a previously sent Quote message that is still
"live" (i.e. not expired). Once a Quote has been canceled the Quote Request that initiated the chain would
also be considered "dead", in other words no further quotes will be provided against that request. At any
given time, there should only be one "live" quote for the corresponding Quote Request for the specific
currency pair (Quote Request may contain more than one currency pair).
Field Usage Notes
1. QuoteID is conditionally required when QuoteCancelType is "5" (cancel quote specified in QuoteID)
2. Symbol is conditionally required when QuoteCancelType is "1" (cancel for symbol) or "5" (cancel
quote specified)
8. QuoteEntryID is required and is a unique quote entry identifier as assigned by the Respondent.
9. MDQuoteType indicates whether the price is indicative or executable. Abscence of this field
indicates the price is indicative.
10. MDEntrySpotRate is used for specifying the spot rate. It is recommended that either spot rate or
forward points be specified for FX forwards.
11. MDEntryFowardPoints is used for specifying the forward points. This may be a negative value. It is
recommended that either spot rate or forward points be specified for FX forwards.
12. SettlDate and SettlType is required.
13. The Parties component block is optionally used by multi-bank portals to identify the banks that are
providing the rate information. PartyRole is required and in this case the role should be set to
"executing broker".
6. ExpireTime in this message allows the Respondent to specify when the price will expire
7. MinQty is optionally used by the Respondent to specify the minimum quantity in an order to qualify
for the rate quoted
8. MDQuoteType indicates whether the price is indicative or executable. Abscence of this field
indicates the price is indicative.
9. MDEntrySpotRate is used for specifying the spot rate. It is recommended that either spot rate or
forward points be specified for FX forwards.
10. MDEntryFowardPoints is used for specifying the forward points. This may be a negative value. It is
recommended that either spot rate or forward points be specified for FX forwards.
11. SettlDate and SettlType is required.
12. The Parties component block is optionally used by multi-bank portals to identify the dealers that are
providing the rate information. PartyRole is required and in this case the role should be set to
"executing broker".
The New Order - Multileg message is used by the Initiator to place a multilegged order with the dealer -
typically an FX Swap.
Field Usage Notes
1. For FX Swaps the Side field would carry the value "B" (as defined"). The LegSide will identify
which is the buy leg and which is the sell leg.
2. Symbol would specify the currenty pair in the swap.
3. SwapPoints is optionally used to express the differential between the far leg and the near leg.
4. NoLegs, required, for FX Swaps there would only be 2 legs.
5. LegSymbol, required, is the currency pair in the swap, same as Symbol
6. LegCurrency, required, is the dealt currency of the leg and denotes the currency denomination of
LegQty.
7. LegSide, required, denotes the side of the leg
8. LegQty, required, the amount of this leg denomincated in the currency specified in LegCurrency.
9. LegRefID is required. If the order is a result of a Quote message the value needs to match the
LegRefID of the quote message. If the order is a result of an "out of band" quote, the Initiator is
required to assign a unique identifier for each leg.
10. LegPrice is conditionally required when OrdType is "previously quoted". This is the "all in" rate for
this leg as specified in the quote.
11. Either LegSettlType or LegSettlDate should be specified. If the order is a result of a quote this
should be the same as in quote.
12. OrdType, if the FX Swap order is a result of a quote the OrdType = D (previously quoted). OrdType
G = Forex-swap may also be used.
13. QuoteID is required for FX Swap when the order is a result of a Quote message. Contains the
QuoteID from the Quote message.
14. SettlCurrency is used only to denote a third currency to be used for settlement (i.e. not one of the
currencies in the currency pair specified in Symbol). See also description in General Usage Notes.
15. Parties component block is conditionally required when an order is sent via a multi-bank portal. It is
used to identify the executing broker.
Execution Report
The Execution Report message is used by the Respondent to respond to an order (New Order - Single and
New Order - Multileg). The Execution Report message has several "modes" and provides information on the
status of the order.
When reporting an execution or trade (partial or full fill) the LastPx (31) field is used to specify the "all in"
rate for the partial or full fill. It is considered best practice that the spot rate and forward points used to arrive
at the "all in" rate be specified in LastSpotRate (194) and LastForwardPoints (195) when appropriate. For
example, if the fill is for a forward then both the LastSpotRate and LastForwardPoints should be specified.
Field Usage Notes
1. CalculatedCcyLastQty (1056) is used to express the contra amount or "contra order quantity" that
was executed. This is the quantity of the other side of the currency pair (from the dealt currency as
expressed in Currency (15)) and can be derived from LastQty (32) and LastPx (31).
2. LastQty expresses the quantity of the traded currency, as specified by Currency (150). For FX
Future if LastQty is expressed in terms of contracts ContractMultiplier (231) is conditionally
required.
3. Parties component block is conditionally required when an execution is sent by a bank via a multi-
bank portal. It is used to identify the executing broker.
4. LefRegID is required when using a single Execution Report message to report on both legs of an FX
Swap.
5. SettlType is optional but should be specified for spot and outright FX forward trades. For FX Swaps
the LegSettlType should be used instead.
6. SettlDate is required for FX spot and forward. Banks/dealers must specify the value date for spot
and outright FX forward trades. For FX Swap trades refer to the LegSettlDate.
7. OrderQty is required for FX spot and outright forward trades. For FX Swaps it is not required. See
LegQty.
8. OrdType is required if specified on the order.
9. LastSwapPoints is optionally used when ExecType = Trade or Trade Correct and it is a FX Swap
trade. used to express the swap points for the swap trade event.
10. LastPx is the "all in" price of the trade. Conditionally required when ExecType = Trade or Trade
Correct and the trade is for FX spot and forwards. Not required for FX Swap even when ExecType =
Trade or TradeCorrect as there is no "all in" rate that applies to both legs of a FX Swap.
11. For FX forward trades, either LastSpotRate or LastForwardPoints should be specified. These would
be the spot rate or forward points used in the "all in" price for the fill.
12. AvgPx is the "all in" price
13. TradeDate and TransactTime are required
14. GrossTradeAmt can be used for FX Future to express the notional value of a trade when LastQty and
other quantity fields are expressed in terms of number of contracts - in which case ContractMultiplier
(231) is conditionally required.
15. ContractMultiplier (231) is conditionally required when quantities are expressed in terms of number
of contracts for FX Futures.
16. For FX Swaps, LegSymbol, required, is the currency pair in the swap, same as Symbol
17. For FX Swaps, LegCurrency, required, is the dealt currency of the leg and denotes the currency
denomination of LegQty.
18. For FX Swaps, LegSide, required, denotes the side of the leg
19. For FX Swaps, LegQty, required, the amount of this leg denomincated in the currency specified in
LegCurrency.
20. For FX Swaps, LegSettlType is optional
21. For FX Swaps, LegSettlDate is required. Expresses the value date on thsi leg of the swap.
202 StrikePrice The spot price at which the option will be valued and
possibly exercised.
947 StrikeCurrency Currency the strike price is denominated in
107 SecurityDesc Optional description of the option contract
231 ContractMultiplier Specifies the ratio or multiply factor to convert from 1
"nominal" units (e.g. contracts) to total units (e.g.
shares) (e.g. 1.0, 100, 1000, etc). For FX options post
trade – recommend that contract multiplier be set to 1
and that all currency amounts be in their full
denominated value (as opposed to millions for
instance).
167 SecurityType Security Type “FOR” – foreign exchange “FOR”
469 Product Product class (derived from Bloomberg yellow key) “4”
“4” – foreign exchange
63 SettlType Not used for FX OTC Spot Option - use explicit dates
instead
64 SettleDate Settlement date for the option trade premium not the
exercise spot transaction
987 UnderlyingSettlementD Settlement date for the spot trade if the option is
ate exercised, usually MaturityDate(tag 541) + 2 business
days – following normal FX settlement conventions
Example:
The following example if for an EUR/USD FX OTC Spot Option 6 month contact settling on a standard date that
will deliver EUR if the contract is in the money as of the contract expiration date.
Report, Quote) it would not be required in implementations for the exception user group. The exception user
group is the retail user community and trading platforms utilized by this community.
In the retail FX trading space, the customers would open accounts by depositing cash that acts as margin for
their trading activities. These deposits are held in one of a few possible account currencies. As the customers
trades, instead of generating cash balances in the currencies traded, they generate profit and loss in their
account only. The P/L is realized when the "position" is closed (for example, Sell 1M EUR/USD and then
Buy back 1M EUR/USD). In retail FX trading, positions are not settled, instead the positions are
continuously rolled over on a daily basis, debiting or crediting the customer's account with interest in the
account currency. Positions remain open until the reverse transaction is made by the customer to close the
position.
For example a customer has a USD-based account and an initial cash deposit of $100,000 was made into the
account.
• At 11:00 EST the customer Sells 1M EUR/USD at 1.2300, therefore establishing an open position
• At 17:00 EST the EUR/USD rate is 1.2200
• At 17:00 EST, the customer's account would be credited with $70 as an interest payment for being
short EUR/USD. The account balance is now $100,070
• The account has generated a "floating P/L" in the account currency, USD, since the position has not
been "closed" by the customer.
• The position is still open (the customer still has not bought back the 1M EUR/USD to close the
position), so a distinction between Balance and Equity is made where Account Equity = Balance +
Floating P/L. In this example, the customer's Account Equity would be $110,070
• The customer's Account Equity will change in real-time as the EUR/USD rate changes. If the
customer decides at 17:15 EST to "close" the position at the EUR rate of 1.2205, then the customer's
Account Balance would be $109,570.
As can been seen by this FX retail trading example, that there is no settlement or cash delivery. If the
customer had decided not the buy back the 1M EUR/USD the position would remain open indefinitely. The
position would roll over daily, charging/crediting the appropriate interest payment daily.
Message Samples
These sample FIX message usage servers only to illustrate usgae of key fields in the different message types in the
context of FX. Data used are fictional. Only relevent fields from the header and message body are shown (i.e.
some message header and trailer fields are not shown).
Quote Request for FX Swap using NoLegs repeating group
The sample Quote Request messages shows examples for Spot/Forward (1M) and Forward/Forward (1M/3M).
Spot/Forward (1M)
35=R //MsgType - Quote Request message type
49=ABC_AM //SenderCompID - sending client
56=SSBFX //TargetcompID - target bank
131=Req123 //QuoteReqID - uniquely assigned by client, format is arbitrary
146=1 //NoRelatedSym
55=EUR/USD // [1] Symbol
15=EUR // [1] Currency - dealt currency
555=2 // [1] NoLegs
600=EUR/USD // [1] LegSymbol
687=1000000 // [1] LegQty - amount of near leg
587=0 // [1] LegSettlType - Regular/Spot ((T+1) or (T+2))
588=20060130 // [1] LegSettlDate - value date of near leg
654=A0001 // [1] LegRefID
Forward/Forward (1M/3M)
35=R //MsgType - Quote Request message type
49=ABC_AM //SenderCompID - sending client
56=SSBFX //TargetcompID - target bank
131=Req456 //QuoteReqID - uniquely assigned by client, format is arbitrary
146=1 //NoRelatedSym
55=EUR/USD // [1] Symbol
15=EUR // [1] Currency - dealt currency
555=2 // [1] NoLegs
600=EUR/USD // [1] LegSymbol
687=1000000 // [1] LegQty - amount of near leg
587=6 // [1] LegSettlType - future
588=20060228 // [1] LegSettlDate - value date of near leg
654=B0001 // [1] LegRefID
600=EUR/USD // [2] LegSymbol
687=1000000 // [2] LegQty - amount of far leg
587=6 // [2] LegSettlType - future
588=20060428 // [2] LegSettlDate - value date of far leg
654=B0002 // [2] LegRefID
126=20060127-14:47:23 // [1] ExpireTime - time the request expires
Note that in the examples, Side is not specified, thus the request is for a 2-sided quote.
Market Data Incremental Refresh - the bank updates the bid side
35=X //MsgType - Market Data Incremental Refresh message type
49=SSBFX //SenderCompID - sending bank
56=ABC_AM //TargetCompID - target client
262=20050922.09:30:59.1 //MDReqID - uniquely assigned by client, format is arbitrary
268=1 //NoMDEntries - number of MD entries
279=1 // [1] MDUpdateAction - change/update
278=<new unique entry ID> // [1] MDEntryID - new unique entry ID assigned by the bank
280=EED02091-47AD-4EDD-A0AA- // [1] MDEntryRefID - referencing the entry to be changed/updated
0B2D9D1B9B0F
270=1.2139 // [1] MDEntryPx - all-in bid price/rate
299=AAC02189-DF23-11FB-F135- // [1] QuoteEntryID - unique quote identifier assigned by the bank
4C0D4A83D238
Market Data Incremental Refresh - the exchange updates the one of the offers
35=X //MsgType - Market Data Incremental Refresh message type
49=FXEXCHANGE //SenderCompID - sending bank
56=ABC_AM //TargetCompID - target client
262=20050921.09:30:59.1 //MDReqID - uniquely assigned by client, format is arbitrary
268=1 //NoMDEntries - number of MD entries
279=1 // [1] MDUpdateAction - change/update
278=<new unique entry ID> // [1] MDEntryID - new unique entry ID assigned by the bank
280= FB5F1910-F110-11d2-BB9E- // [1] MDEntryRefID - referencing the entry to be changed/updated
00C04F795683
271=40000000 // [1] MDEntrySize - amount dropped
299=AAC02189-DF23-11FB-F135- // [1] QuoteEntryID - new unique quote identifier assigned by the
4C0D4A83D238 bank
Introduction
This section addresses issues and requirements that are specific to environments of exchanges and similar
marketplaces where many parties interact with a central system, and provides guidance for using the FIX Protocol
in these environments. The behaviour can differ from the typical buy-side/sell-side environments and is described
here where applicable . The content is produced by the former Exchange and ECN Working Group which has
been superseded by the Global Exchanges and Markets Committee.
The content of this section supplements the content in the other volumes of the FIX Protocol specification where
appropriate. Additionally the usage notes in this section may describe additional requirements above the base
requirements of the FIX Protocol that is recommended for use by Exchanges.
A Vanilla
Ref Description
A.1.a Filled order after order rests on book
A.1.b Part-filled day order after order rests on book, done for day
A.1.c Order filled upon hitting the book
A.1.d Order partially filled upon hitting the book
I TimeInForce
Ref Description
I.1.a Fill or Kill order cannot be filled
I.1.b Immediate or Cancel order that cannot be immediately hit
The ExecType is used to identify the purpose of the execution report message. The value of ExecType will
typically be New to convey the fact that a new order has been received and processed. However, the value of
OrdStatus in this initial response may not necessarily be New as the order might have been executed immediately.
The initial value of OrdStatus can therefore also be Partially Filled or Filled. It can even be Canceled if the order
has time in force values such as Fill or Kill and Immediate or Cancel and the order could not be executed
immediately (and in its entirety in case of Fill or Kill).
The following diagram illustrates the complete set of state transitions recommended for electronic exchange/ECN
environments. The dotted lines lead to initial order states other than New and apply to cases where an order does
not simply rest on the order book after having been accepted by the exchange/ECN. It is a possibility aimed at
increasing performance by reducing the overall number of “Execution Report” messages that need to be provided
and processed. Message flows with explicit messages to convey the order state New are equally possible.
Expired
Reject on entry
Filled
(Reject of
acc’d order) Expiry Full Execution
Cancel from
Book
Canceled
Full Execution
New Expiry
Rein- Suspended
statement Cancel from
Partial Execution Book
or reinstatement
”Overnight” store
(GT orders)
Accept order with Start of Day Cancel e.g. due to
immediate partial fill Activation corporate action
(GT orders)
Start of Day
Activation
(GT orders)
A.1.b – Part-filled day order after order rests on book, done for day
Time Message Message Sent Exec OrdStatus Order Cum Leaves Last Comment
Received
(ClOrdID, Type Qty Qty Qty Qty
(ClOrdID, OrigClOrdID)
OrigClOrdID)
1 New Order(X) 10000
2 Execution(X) Rejected Rejected 10000 0 0 0 If order is rejected by the exchange
2 Execution(X) New New 10000 0 10000 0
3 Execution(X) Trade Partially 10000 2000 8000 2000 Execution of 2000
Filled
4 Execution(X) Trade Partially 10000 3000 7000 1000 Execution of 1000
Filled
5 Execution(X) Done Done for 10000 3000 0 0 Assuming day order. See other examples which cover GT orders
for Day Day
A.1.c – Order filled upon hitting the book
Time Message Message Sent Exec OrdStatus Order Cum Leaves Last Comment
Received
(ClOrdID, Type Qty Qty Qty Qty
(ClOrdID, OrigClOrdID)
OrigClOrdID)
1 New Order(X) 10000
2 Execution(X) Rejected Rejected 10000 0 0 0 If order is rejected by the exchange
2 Execution(X) Trade Filled 10000 10000 0 10000 Immediate execution of 10000
Quote Identifiers
Quote Entity Identifer
Every individual quote needs a unique identifier. The identifier should refer back to investor and his wish to
invest (in the quote case, the quote issuer). In the case of continuous market maker quotes, the quote identifier
is preferably static (as the decision to quote do not really change). An important aspect of this identifier is that
it can be used on trades as a reference back to the quote (i.e. in Execution Reports and Trade Capture
Reports). A further aspect is that the cumulative quantity and other similar properties of the Execution Report
are maintained throughout the lifetime of the QuoteID (in practice normally terminated and restarted each
day). Note that in the case of Quote Negotiation where the Quote is used to reply to Quote Requests, the
quote identifier could have more of an order characteristic, and thereby be assigned a new value for every
quote request received.
Quote identifiers are supported through:
• QuoteEntryID (299) in Mass Quote messages
• QuoteID (117) field in single Quote messages
It is recommended that the QuoteEntryID (299) and QuoteID (117) remains static when quote updates are
done - in practice the quote identifier value does not change. In cases where a quote issuer is allowed to have
multiple simultaneous quotes in the market, the quote identifier identifies which one of those should be
updated.
The scope within which the quote identifier is unique varies and details of the identifier model should be
bilaterally agreed. Recognized models:
1. ID is unique in context of quote issuer (market maker + Quote ID). Includes model where the ID
is unique in itself but embeds the market maker identifier.
2. Separate ID not used at all (a quote is identified by market maker + Security)
3. ID unique in context of quote issuer and security (market maker + Security + Quote ID). This
means the ID is always “1” with the following exceptions:
o In cases where multiple quotes are allowed in a single security
o When quotes are used in quote negotiations (multiple parallel negotiations in same
security).
4. ID unique per market maker + QuoteID + QuoteSetID.
For continuous Market Maker quotes, a marketplace can assign the quote identifier values the Market Maker
should use, or leave that to the Market Maker. The former is preferred in cases where the marketplace wants a
globally unique quote entry index. This behavior is very similar to the marketplace assigned OrderIDs used in
order routing - but assignment is not done through interactive responses, it is done by bilateral
agreement/contract.
Quote Message Identifier
In cases where participants need an audit trail for quote messages, the Quote and Mass Quote messages need
a quote-issuer assigned identifier. The identifier must be unique for every submission of a quote (whether the
quote is new, updated or canceled). The primary usage is to serve as a message identifier. Users that so wish
can secondarily use the field as a revision count – which, together with the Quote identifier, could be unique.
The message identifier is relayed back on outbound messages produced as a result of the Quote. The preferred
message identifiers are:
• QuoteID (117) in the Mass Quote message
• QuoteMsgID (1166) for single Quote message
Quote referencing in Market Data, Executions (fills), etc.
Execution Reports, Trade Capture Reports, Market Data and other messages produced as a consequence of a
quote may need to refer to the quote. Some markets and users require that the exact revision of the quote is
relayed (i.e. the identifier of the message that last updated the quote).
The recommended approach is to:
• Use the ClOrdID (11) for the Quote entity identifier
• Use the SecondaryClOrdID (526) field for the Quote message identifier in cases where it needs to be
relayed
• In cases where the OrderID (37) field has no other usage, set it to “[N/A]” or the Quote entity
identifier
Details of identifier usage should be bilaterally agreed.
Use of Quote Identifiers
Inbound quote messages can have two identifiers:
• A message identifier that is used to identify each inbound message uniquely. This message identifier
has a purpose similar to the ClOrdID used for orders.
• An entity identifier that is used to identify each quote entry over time. This identifier has a purpose
similar to the OrderID used for orders, but it should be noted that the receiver of a quote does not
assign this identifier - it is expected to be entered by the quote issuer.
The following table illustrates the use of the Quote identifiers in various messages in quote workflows:
Table 1 - Quote Identifiers
Message Type Identifier Type Field Comment
Quote Message identifier QuoteMsgID
Entity identifier QuoteID
Mass Quote Message identifier QuoteID Note that the QuoteID is the
message identifier in Mass
Quote messages!
Entity identifier QuoteEntryID
Quote Cancel Message identifier QuoteMsgID
Entity Identiifier QuoteID
Quote Status Report Message identifier QuoteMsgID Note that in the case a Mass
Quote was the source of the
individual quote – the QuoteID
goes into the QuoteMsgID
Entity identifier QuoteID Note that in the case a Mass
Quote was the source of the
individual quote – the
QuoteEntryID goes into the
QuoteID
Mass Quote Message identifier QuoteID Note that in the case of a Quote
Acknowledgement Cancel - the QuoteMsgID of the
Quote Cancel go into the
QuoteID.
Message Type Identifier Type Field Comment
Note that in the case of a Quote
Status Request – the
QuoteStatusReqID go into the
QuoteID
Entity identifier QuoteEntryID Note that in the case a (Single)
Quote was the source of the
individual quote – the QuoteID
goes into the QuoteEntryID
Other messages Message identifier ClOrdID Note that the message identifier
of the original Quote/Mass
Quote message goes into the
ClOrdID for reference
Entity identifier SecondaryClOrdID Note that the entity identifier of
the original Quote/Mass Quote
message goes into the
SecondaryClOrdID for
reference
Response
Request (Single) Quote Set of Quotes
Quote Status Report Mass Quote Acknowledgement
Quote Status Quote Status Quote Entry Status
Quote Status • Rejected • Query • Active
Request
• Active • Rejected • Canceled
• Canceled • Expired
• Expired • Removed from
Market
• Removed from Market
• Quote Not Found
• Quote Not Found
Quote • Accepted N/A N/A
• Rejected
• Canceled (if both sides
= 0)
Mass Quote N/A • Accepted • Accepted
• Rejected • Rejected
• Canceled
(if both sides = 0)
Quote Cancel • Canceled • Accepted • Canceled
• Rejected • Rejected • Rejected (if
"locked")
Unsolicited • Removed from Market • Removed from • Removed from
Market Market
• Unsolicited Quote
Replenishment • Unsolicited Quote • Unsolicited Quote
Replenishment Replenishment
Workflows
Introduction
The following rules are used as the basis for the workflows:
1. A Mass Quote always results in a Mass Quote Acknowledgement unless QuoteResponseLevel (301)
= “0” (No Acknowledgement) has been specified. A Mass Quote’s should not result in multiple
Quote Status Reports in response.
a. The only exception to this rule occurs if restatements are needed due to automatic quantity
refreshes or similar. In this case, the QuoteID (117) of that Quote Status Report would carry
the QuoteEntryID (299) of the previously submitted Mass Quote.
2. A Quote Cancel can result in a Mass Quote Acknowledgement under the following conditions:
a. Multiple quotes are affected, i.e. the QuoteCancelType (298) is set to “1” (Cancel for
Symbol[s]), “2” (Cancel for Security Type[s]), “3” (Cancel for Underlying Symbol) or “4”
(Cancel all Quotes)
b. QuoteResponseLevel (301) has been set to “2” (Acknowledge each quote messages)
If both conditions are not met then the Quote Status Report should be used. An exception to the rule
would be a bilateral agreement to always do one or the other.
3. A Quote Status Request can result in a Mass Quote Acknowledgement under the following
conditions:
a. Multiple quotes are affected. This means that QuoteID (117) should not be provided and
<UndInstrmtGrp> or other filters are specified, meaning e.g. that all strikes in a series
should be returned. Since this is a query it is assumed that any qualified quote will be
reported.
If the condition is not met then the Quote Status Report should be used. An exception to the rule
would be a bilateral agreement to always do one or the other.
The below table defines what messages can be used to relay request responses and unsolicited actions back to
the quote issuer. The following abbreviations are used in the Comment column to clarify the mapping
between the response and the message of the quote origination:
• Q = Quote
• MQ = Mass Quote
• QSR = Quote Status report
• MQA = Mass Quote Acknowledgement
• QSRq = Quote Status Request
Note that:
• The QuoteMsgID (if used) is renewed for every message sent.
• The QuoteID will contain a new value when a quote is first inserted and that id is then referenced for
subsequent updates. The same id can be reused in cases where both sides of the quote are cancelled
or exhausted – so a quote issuer can assign a static QuoteID to every quote responsibility (security or
options series).
Single Quote with QuoteResponseLevel = 1 (Negative Ack only)
In the second example, illustrated in Figure 8, a Quote is again sent from the quote issuer to the marketplace.
The quote has the QuoteResponseLevel = 1. The marketplace only acknowledges the quote if there is an
error. If the marketplace encounters an error while processing the quote, a Quote Status Report message is
sent with the QuoteRejectReason set to the error encountered.
Usage Notes
Request for a Public or Private Quote
Some markets allow private quote negotiations where that the market maker responding to a Quote Request
provides a Quote for the requestor only (a Private Quote, also known as Directed Quote). Markets may also
allow the requestor to explicitly state whether he expects a directed or a public response. A public response is
a normal quote relayed as market data to all eligible parties and can be hit by other orders and/or quotes
according to normal market rules, whereas a directed Quote is visible to and can be hit by the requestor only.
Unless bilaterally agreed, the Quote Request specifies whether the request is private or public by using the
PrivateQuote (1171) indicator:
• “Y” = The negotiation is private, therefore the Quote should only be published to the requestor
• “N” (default value) = The negotiation is public,therefore the Quote should be published as market
data, viewable by market data subscribers
Directed Quote Requests
An intermediary like a marketplace could allow Quote Request initiators to direct the request to a single or
specific group of counterparties. Examples include:
• All eligible market participants. This instructs the marketplace to route the Quote Request to all
market participants eligible for such, including, but not limited to, market makers.
• Specified market participants. This implies that a list of participants is provided and that the
marketplace should route the request to them only.
• All eligible market makers in the respective securities. This instructs the marketplace to route the
Quote Request to all market makers eligible for Quote Requests.
• The primary market maker(s). Instructs the marketplace to route to specialists / primary market
makers / designated market makers (or whatever other similar terminology is used).
When the quote request is directed, the marketplace can choose to push the messages to the relevant actors
whether they subscribe (RFQ Request) to Quote Requests or not.
In order to support directed quote request, the RespondentType (1172) indicator must be specified
The RootParties component block can be used to list named receivers of the Quote Request. The following
PartyRoles are relevant:
• 17 = Contra Firm
• 37 = Contra Trader
Pre-trade Anonymity
A marketplace could allow the initiator of a quote negotiation to be anonymous when the Quote Request is
sent to the respondent(s). This may be handy when there is a risk the respondent may respond with a worse
quote upon knowing who the initiator is. Note, however, that the rest of the negotiation process does not
support anonymity.
In order to support anonymous quote requests, the PreTradeAnonymity (1091) indicator is used.
Minimum Executable Quantity
When a Respondent quotes a price to specific counterparties, the Respondent may choose to provide a better
price under the condition that a certain size is filled. In a Quote Negotiation situation, parties may need to
indicate a minimum execution quantity in order to solicit relevant prices and, in the case of the respondent,
avoid getting hit on lower than expected quantity. In cases where the Three-Party Matching model (decribed
below) is used, a minimum quantity is especially relevant.
The MinQty (110) field is used to specify a minimum executable quantity in a quote negotiation.
Finalising a Quote Negotiation
The Three-Party Matching Negotiation Model
When the marketplace acts as an intermediary in a private quote negotiation, it may want to control when the
trade is created. It would regard a trade to occur when both parties have issued matching firm commitments,
for example:
• One party issues a firm quote, the other a “Hit / Lift” Quote Response (both within time limits
provided in the negotiation process and specifying matching conditions).
• One party issues a firm “Counter” Quote Response and the other a “Hit / Lift” one (both within time
limits provided in the negotiation process and specifying matching conditions).
The marketplace would also automatically terminate the negotiation when specified time limits expires.
Any usage of marketplace matching must be bilaterally agreed.
The Trade-Reporting Model
In the trade reporting model the negotiation is finalized by the parties moving to the privately negotiated trade
workflows. When the parties through exchanging Quote Requests, Quote’s and Quote Responses have agreed
on the terms, they conclude the trade by exchanging Trade Capture Reports exactly as when reporting any
other privately negotiated trade.
Refer to TRADE CAPTURE (“STREETSIDE”) REPORTING in volume 5 of the specification.
Other Models
Other models can also be used such as the ones described in the FIXED INCOME and FOREIGN
EXCHANGE sections of this volume.
Quote Negotiation Scenarios
Public Tradable Quote
Vanilla
Figure 21: Vanilla Public Tradable Quote
Note that the Quote will be relayed to the initiator only in the case of a private quote; otherwise it will be
published as market data.
Initiator's Alternative Responses to (Private) Quote
Figure 26: Initiator's Alternative Responses to (Private) Quote
Respondent's Alternative Responses to Quote Response (Counter)
Figure 27: Respondent's Alternative Responses to Quote Response (Counter)
Multileg Orders
User-defined, Non-securitised Strategies
A user-defined non-securitized strategy (a.k.a. free combination) is a multi-leg order for a combination of
instruments where there is no pre-defined security in the market place - neither will the marketplace create a
security. This type of multi-leg order is more common in equities trading than in derivatives or fixed income
as a stock exchange is less likely to securitize multi-legs or show them as separate books over market data. If
implied orders are generated in the underlying books (Implied-Out orders), the multi-leg instrument itself
does not need to be securitized. In such cases the multi-leg security does not need to be added to reference
data or its book be made visible to other participants.
• Some marketplaces implement a variant of the above through creating temporary products for the
multi-legs. Those products are then periodically removed, for example, at end of day or week. Those
products are, however, generally made available to other brokers and displayed over market data as
separate books.
The New Order Multileg requires that the <Instruments> component block root level attribute is specified. As
a User-Defined, Non-Securitized Strategy will not refer to a pre-defined instrument and need not be
referenced as an instrument, Symbol (55) = “[N/A]” (or “MLEG”) may be used (without the quotes).
Specifying what Multileg Model applies for an Order
A marketplace supporting more than one of the multi-leg order models (see volume 4 of the FIX
specification) needs a clear indicator on the order to govern what model is to be used. This is especially
relevant in order to validate that an order request is executed in accordance with the intentions of the user
(creating a security / applying the order to an existing one / using a “free combination”). The MultilegModel
(1377) field allows the user to define the intent with the order.
The following table depicts the models and their impact on the multi-leg order:
Market Data
This section discusses the complexities of market data that occurs in some markets and provides recommendations
on how to implement FIX in these environments.
Subordinate Books
Marketplaces trading securities in different lot types stipulate rules for how orders may trade between these
lot types. In some markets lot types are integrated whereas other markets keep lot types separated. This is
commonly referred to as integrated vs non-integrated matching.
In the non-integrated matching model, orders are usually received for one order book and the marketplace
determines the appropriate lot type. This is done mainly to hide complexity of selecting the appropriate lot
type for clients; the order flow will still be distributed for just one order book. However, since they are not
integrated the marketplace will have to rank orders of different lot types independently. It would make no
sense to provide a common ranking since the orders are not allowed to trade between lot types.
This constitutes a problem in pre 5.0 SP1 FIX versions, as the messages did not facilitate the non integrated
matching. At that time only MDPriceLevel (1023) and MDEntryPositionNo (290) could be used to identify
the position/ranking of an order. Round Lot, Odd Lot and Block Lot would all have separate ranking and
individual MDEntryPosition per price level. Even if the LotType (1093) field is added to communicate the lot
size, clients would not necessarily know if the market is operating a non-integrated or integrated matching
model. Hence, a client cannot rely on just MDPriceLevel and MDEntryPositionNo to sort orders.
In order to divulge the sorting/ranking of orders when this cannot be derived from MDPriceLevel and
MDEntryPosition, the MDSubBookType (tbd) field is added to market data messages. The field is optional
and FIX clients in those complex environments must always consider MDSubBookType, MDPriceLevel, and
MDEntryPositionNo to be able to sort orders and quotes accordingly.
Example Integrated Matching
Consider a market place with integrated matching of lot types. Since the orders are tradable between lot
types, they have to be ranked and sorted accordingly. The complexity of selecting Lot Type would be hidden
for the Client.
Odd Lot
Block Lot
Consider the following orders entered with no previous orders on the book.
Order 1: Id=1, Price=10.00, Quantity=13, Side=Bid
Order 2: Id=2, Price=10.00, Quantity=100, Side=Bid
Order 3: Id=3, Price=10.00, Quantity=1000, Side=Bid
Order 4: Id=4, Price=9.00, Quantity=200, Side=Bid
Order 5: Id=5, Price=10.00, Quantity=100, Side=Bid
With integrated matching the orders of different lot types will be ranked and sorted independently.
Odd Lots
Price Level Position Order Id Price Quantity Lot Type
1 1 1 10.00 13 Odd Lot
Round Lots
Price Level Position Order Id Price Quantity Lot Type
1 1 2 10.00 100 Round Lot
1 2 5 10.00 100 Round Lot
2 1 4 9.00 200 Round Lot
Block Lots
Price Level Position Order Id Price Quantity Lot Type
1 1 3 10.00 1000 Block Lot
With the pre 5.0 SP1 implementation of the protocol, it would result in the following sequence of new orders
on the MarketDataIncrementalRefresh:
MDEntryId=1, MDPriceLevel=1, MDEntryPositionNo=1, MDEntryPx=10.00, MDEntrySize=13
MDEntryId=2, MDPriceLevel=1, MDEntryPositionNo=1, MDEntryPx=10.00, MDEntrySize=100
MDEntryId=3, MDPriceLevel=1, MDEntryPositionNo=1, MDEntryPx=10.00, MDEntrySize=1000
MDEntryId=4, MDPriceLevel=2, MDEntryPositionNo=1, MDEntryPx=9.00, MDEntrySize=100
MDEntryId=5, MDPriceLevel=1, MDEntryPositionNo=2, MDEntryPx=10.00, MDEntrySize=100
The Client would not be able to decipher this and build a proper order book copy. Based on the information
received and implicit push operations it would look as following:
Trade Statistics
A marketplace can choose to let Market Data receivers calculate statistics themselves. In markets with more
complex rules for what entries are eligible for inclusion in statistics, each market data entry needs an
indication showing if it is eligible for a certain type of statistic.
Eligibility indicators can be relayed in the Market Data Incremental Refresh message. They are used to define
whether an entry is eligible for inclusion in a piece of statistics or not:
• NoStatsIndicators (1175)
o StatsType (1176)
Business Workflow
Application Sequencing within a FIX session
A FIX session may act as the mechanism for distributing a number of “secondary” data sources that are
differentiated based on application, message type, or even originating party. Each application is assigned a
unique ApplID (1180). Each application assigns its own set of application-level sequence numbers which are
then uniquely identified using a combination of ApplID (1180) and ApplSeqNum (1181). Once a FIX session
is established the data is distributed and able to be identified by application. The receiver of the data can use
the application sequence number to manage resend requests based on sending application ID should the data
need to be retransmitted.
When a retransmission of data is necessary the Application Message Request is sent with the necessary
application ID and the sequence number range to precisely request the required data. The data will then be
resent without any disruption to the FIX session using the original application sequence numbers. Upon
receipt of the data the requester will process according to the application id specified.
Additionally, the ability to check for the most recent application sequence of a given application can be done
using ApplReqType (1347). The Application Message Request Ack will return the last application sequence
number produced by the application.
In order to allow deliberate application-level sequence gaps in the distribution of application data,
ApplLastSeqNum (1350) is used report the prior application sequence number for that ApplID (1180). This
will allow the receiving application to distinguish purposeful sequence gaps from application errors by
comparing the value of ApplLastSeqNum (1350) to the prior application sequence number received for that
same ApplID (1180).
Application Seqencing over an alternate protocol
Application sequencing provides a generally useful mechanism for sequencing streams of data. Market Data
feeds, which are inherently sequential, sent over a broadcast or multicast transport which do not guarantee
ordered delivery, need application sequencing to provide the ordered delivery mechanism. An application
generating a stream of data can assign ApplSeqNum (1181) values to each message allowing the Receiver to
detect when messages are out of sequence. The Application Message Request will allow a Receiver to recover
missed messages. Resend requests and retransmitted messages will most likely take place over a separate
back channel in which two-way communication can be conducted.
Business Cases
Concrete business cases for application sequencing include the following:
1. Data providers need to be sensitive regarding the amount of data they consolidate and send out -
particularly in a resend scenario. There needs to be a way to short-cut the potentially massive volumes of
data and pinpoint critical business information that is also sent on the same FIX session. It is always
possible that some “subscribers” may be receiving data for the first time due to delayed logon or
disconnect and are not at all interested in the potentially large volume of market data messages that may
be distributed before they can receive their “time and sales” information, for example.
2. Multiple FIX sessions are expensive to establish, maintain and manage both for host and client. This is
not a cost effective solution, especially for smaller firms, in distributing different types of application
data. The ability to send multiple sets of distinct application data over the same connection provides a
way to “leverage” a single FIX session without disrupting the session protocol.
3. FIX Session Resends require that huge amounts of data be stored by the Sender in order to support the
ability to resend the messages. Supporting secondary or tertiary sessions requires that the sender store
possibly the same data in duplicate or triplicate. If messages are sequenced by the generating application
the Sender is able to avoid duplicate data storage by resending the information from the original
application store and assigning new session sequence numbers as the data is resent. In this case the
Sender is able to avoid costly dual storage and processing associated with ancillary FIX sessions.
4. In the case of drop copy, data can be consolidated across multiple sessions and the original message
sequence number can serve as the application sequence number. An extended request for data, if handled
as an application request, can be based on the sequence number assigned by the sending application.
Given the application ID, the precise set of data can be extracted from the originating session and resent.
No additional data store is needed in this case.
5. Application Message Request allows the receiver of data to control what is resent. A receiver may not
want, for example, the volumes of market data messages that might be retransmitted after a lengthy
disconnect and may only be interested in the trade messages that are interspersed. The Application
Message Request would allow the requester to request a resend of only the application messages that they
are interested in by specifying previously defined application IDs and the relevant range of application
sequence numbers for those IDs.
6. Application sequencing provides a means of ensuring ordered delivery of messages as well as acting as
mechanism for data recovery for one-way broadcast-like transports. Application Message Requests
should be executed over a back channel in this case.
Application Indentification
An application is identified by the AppID (1180) field. It is recommended that the ID value be assigned
based on the business purpose of a stream of messages. The ApplID (1180) can be used very granular or very
broad depending on business requirements, but in both cases it has specific meaning both to the sender and
receiver of the data. The ApplID (1180) value is either agreed to on a bilateral basis or formally published by
the application data provider. In either case, the ApplID (1180) has inherent business meaning and provides a
large amount of flexibility in qualifying data over a single FIX session. ApplID (1180) provides a flexible
way of labeling data intermixed within a session. The Application Message Request message can be used to
request a list of available application IDs from the data provider (providers may implement authorisation
controls to disallow this or limit the results).