Business Area: Infrastructure
As of EP284, November 2023
FIX Global Technical Committee
Table of Contents
Introduction
Infrastructure messaging is characterized as messages which are common to the business areas pre-trade, trade and post-trade.
The specific FIX infrastructure messaging categories are:
Descriptions of the specific FIX infrastructure application messages follow. There is a diagram for each of the messages depicting its components. Required components are shown with a red outline and repeating groups contain an arrow symbol. Some messages do not have any components. The detailed layout of all messages and components is provided in the appendix.
List of Messages and Components for Infrastructure
Messages
This section lists the infrastructure messages and the category each of them belongs to.
| MsgType(35) | Name | Category |
|---|---|---|
| BY | ApplicationMessageReport | Application Sequencing |
| BW | ApplicationMessageRequest | Application Sequencing |
| BX | ApplicationMessageRequestAck | Application Sequencing |
| j | BusinessMessageReject | Business Message Rejects |
| BC | NetworkCounterpartySystemStatusRequest | Network Status Communication |
| BD | NetworkCounterpartySystemStatusResponse | Network Status Communication |
| BE | UserRequest | User Management |
| BF | UserResponse | User Management |
| CB | UserNotification | User Management |
Components
This section lists components used by infrastructure messages defined in this part of the FIX specification. None of these are Common Components used by more than one category in this area. Messages may also reference Global Components, which are components used by messages across more than one area. Global Components are defined in the overall Introduction to the FIX specification.
Components can be either non-repeating or repeating (a.k.a. a “group”), i.e. contain multiple instances of a set of fields. Components can be nested to any level.
| Type | Name | Category |
|---|---|---|
| Repeating | ApplIDReportGrp | Application Sequencing |
| Repeating | ApplIDRequestAckGrp | Application Sequencing |
| Repeating | ApplIDRequestGrp | Application Sequencing |
| Repeating | CompIDReqGrp | Network Status Communication1 |
| Repeating | CompIDStatGrp | Network Status Communication2 |
| Repeating | ThrottleMsgTypeGrp | User Management3 |
| Repeating | ThrottleParamsGrp | User Management4 |
| Repeating | UsernameGrp | User Management |
Category – Business Rejects
Messages
Business Message Rejects
The BusinessMessageReject(35=j) message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject(35=3) message should be issued.
It should NOT be used whenever there is a session-level problem. In this case, use the session-level Reject(35=3) message if the FIX Session Protocol is being used. If the FIX Session Protocol is not being used, use an appropriate reject message of the given session protocol or the BusinessMessageReject(35=j) message may be used if no appropriate session protocol reject message is available. The message layout is available here.
It should also NOT be used in response to application-level messages that have a dedicated response message as detailed in the following sections.
Note the only exceptions to the appropriate responses defined below are:
- in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system. In this situation a BusinessMessageReject(35=j) with BusinessRejectReason(380) = 4 (Application not available) can be issued if the system is unable to send the specific “reject” message listed above due to this condition.
- in the event a valid business message is received, fulfills session-level rules, however, the message type is not supported by the recipient. In this situation a BusinessMessageReject(35=j) with BusinessRejectReason(380) = 3 (Unsupported Message Type) can be issued if the system is unable to send the specific “reject” message listed above because the receiving system cannot generate the related “reject” message.
- In the event a business message is received, fulfills session-level rules, but lacks a field conditionally required by the FIX specification. In this situation a BusinessMessageReject(35=j) with BusinessRejectReason(380) = 5 (Conditionally required field missing) can be issued if the system is unable to send the specific “reject” message listed above. One example of this would be a stop order missing StopPx(99). However, a BusinessMessageReject(35=j) message MUST NOT be used to enforce proprietary rules more restrictive than those explicit in the FIX specification, such as a broker requiring an order to contain an Account(1), which the FIX specification considers an optional field.
Components
This category does not have any components.
Standard Responses for Pre-Trade Messages
| Category | FIX Message | Appropriate Response(s) |
|---|---|---|
| Indication | CrossRequest(35=DS) | CrossRequestAck(35=DT) |
| Quotation Negotiation | MassQuote(35=i) | MassQuoteAck(35=b) |
| Quotation Negotiation | QuoteRequest(35=R) | QuoteRequestReject(35=AG) |
| Quotation Negotiation | Quote(35=S) | Depending on workflow implemented: QuoteAck(35=CW) or QuoteStatusReport(35=AI) |
| Quotation Negotiation | QuoteCancel(35=Z) | Depending on workflow implemented: QuoteAck(35=CW) or QuoteStatusReport(35=AI) |
| Quotation Negotiation | QuoteStatusRequest(35=a) | QuoteStatusReport(35=AI) |
| Quotation Negotiation | QuoteResponse(35=AJ) | QuoteStatusReport(35=AI) |
| Market Data | MarketDataRequest(35=V) | MarketDataRequestReject(35=Y) |
| Market Data | MarketDataStatisticsRequest(35=DO) | MarketDataStatisticsReport(35=DP) |
| Market Data | StreamAssignmentReport(35=CD) | StreamAssignmentReportACK(35=CE) |
| Market Data | StreamAssignmentRequest(35=CC) | StreamAssignmentReport(35=CD) |
| Securities Reference Data | DerivativeSecurityListRequest(35=z) | DerivativeSecurityList(35=AA) |
| Securities Reference Data | SecurityDefinitionRequest(35=c) | SecurityDefinition(35=d) |
| Securities Reference Data | SecurityListRequest(35=x) | SecurityList(35=y) |
| Securities Reference Data | SecurityMassStatusRequest(35=CN) | SecurityMassStatus(35=CO) |
| Securities Reference Data | SecurityStatusRequest(35=e) | SecurityStatus(35=f) |
| Securities Reference Data | SecurityTypeRequest(35=v) | SecurityTypes(35=w) |
| Market Structure Reference Data | TradingSessionStatusRequest(35=g) | TradingSessionStatus(35=h) |
| Market Structure Reference Data | TradingSessionListRequest(35=BI) | TradingSessionList(35=BJ) |
| Parties Reference Data | PartyActionRequest(35=DH) | PartyActionReport(35=DI) |
| Parties Reference Data | PartyDetailsDefinitionRequest(35=CX) | PartyDetailsDefinitionRequestAck(35=CY) |
| Parties Reference Data | PartyDetailsListRequest(35=CF) | PartyDetailsListReport(35=CG) |
| Parties Reference Data | PartyEntitlementsDefinitionRequest(35=DA) | PartyEntitlementstDefinitionRequestAck(35=DB) |
| Parties Reference Data | PartyEntitlementsRequest(35=CU) | PartyEntitlementsReport(35=CV) |
| Parties Reference Data | PartyRiskLimitCheckRequest(35=DF) | PartyRiskLimitCheckRequestAck(35=DG) |
| Parties Reference Data | PartyRiskLimitsDefinitionRequest(35=CS) | PartyRiskLimitsDefinitionRequestAck(35=CT) |
| Parties Reference Data | PartyRiskLimitsReport(35=CM) | PartyRiskLimitsReportAck(35=DE) |
| Parties Reference Data | PartyRiskLimitsRequest(35=CL) | PartyRiskLimitsReport(35=CM) |
| Parties Reference Data | PartyRiskLimitsUpdateReport(35=CR) | PartyRiskLimitsReportAck(35=DE) |
Standard Responses for Trade Messages
| Category | FIX Message | Appropriate Response(s) |
|---|---|---|
| Single General Order Handling | ExecutionReport(35=8) | DontKnowTrade(35=Q) or ExecutionAck(35=BN) |
| Single General Order Handling | NewOrderSingle(35=D) | ExecutionReport(35=8) |
| Single General Order Handling | OrderCancelReplaceRequest(35=G) | OrderCancelReject(35=9) |
| Single General Order Handling | OrderCancelRequest(35=F) | OrderCancelReject(35=9) |
| Single General Order Handling | OrderStatusRequest(35=H) | ExecutionReport(35=8) |
| Multileg Order Handling | MultilegOrderCancelReplace(35=AC) | OrderCancelReject(35=9) |
| Multileg Order Handling | NewOrderMultileg(35=AB) | ExecutionReport(35=8) |
| Cross Order Handling | CrossOrderCancelReplaceRequest(35=t) | OrderCancelReject(35=9) |
| Cross Order Handling | CrossOrderCancelRequest(35=u) | OrderCancelReject(35=9) |
| Cross Order Handling | NewOrderCross(35=s) | ExecutionReport(35=8) |
| Order Mass Handling | MassOrder(35=DJ) | MassOrderAck(35=DK) |
| Order Mass Handling | OrderMassActionRequest(35=CA) | OrderMassActionReport(35=BZ) |
| Order Mass Handling | OrderMassCancelRequest(35=q) | OrderMassCancelReport(35=r) |
| Order Mass Handling | OrderMassStatusRequest(35=AF) | ExecutionReport(35=8) |
| Program Trading | BidRequest(35=k) | BidResponse(35=l) |
| Program Trading | ListCancelRequest(35=K) | OrderCancelReject(35=9) |
| Program Trading | ListExecute(35=L) | ExecutionReport(35=8) |
| Program Trading | ListStatusRequest(35=M) | ListStatus(35=N) |
| Program Trading | NewOrderList(35=E) | ExecutionReport(35=8) |
Standard Responses for Post-Trade Messages
| Category | FIX Message | Appropriate Response(s) |
|---|---|---|
| Allocation | AllocationInstruction(35=J) | AllocationInstructionAck(35=P) |
| Allocation | AllocationInstructionAlertRequest(35=DU) | AllocationInstructionAlertRequestAck(35=DV) |
| Allocation | AllocationReport(35=AS) | AllocationReportAck(35=AT) |
| Confirmation | Confirmation(35=AK) | ConfirmationAck(35=AU) |
| Confirmation | ConfirmationRequest(35=BH) | Confirmation(35=AK) |
| Trade Capture | TradeCaptureReportRequest(35=AD) | TradeCaptureReportRequestAck(35=AQ) |
| Trade Capture | TradeCaptureReport(35=AE) | TradeCaptureReportAck(35=AR) |
| Trade Capture | TradeMatchReport(35=DC) | TradeMatchReportAck(35=DD) |
| Trade Management | TradeAggregationRequest(35=DW) | TradeAggregationReport(35=DX) |
| Position Maintenance | PositionMaintenanceRequest(35=AL) | PositionMaintenanceReport(35=AM) |
| Position Maintenance | PositionTransferInstruction(35=DL) | PositionTransferInstructionAck(35=DM) |
| Position Maintenance | RequestForPositions(35=AN) | RequestForPositionsAck(35=AO) |
| Collateral Management | CollateralAssignment(35=AY) | CollateralResponse(35=AZ) |
| Collateral Management | CollateralInquiry(35=BB) | CollateralInquiryAck(35=BG) |
| Collateral Management | CollateralReport(35=BA) | CollateralReportAck(35=DQ) |
| Collateral Management | CollateralRequest(35=AX) | CollateralAssignment(35=AY) |
| Margin Requirement Management | MarginRequirementInquiry(35=CH) | Depending on workflow implemented: MarginRequirementInquiryAck(35=CI) or MarginRequirementReport(35=CJ), PositionReport(35=AP) |
| Registration Instruction | RegistrationInstructions(35=o) | RegistrationInstructionsResponse(35=p) |
| Settlement Instruction | SettlementInstructionRequest(35=AV) | SettlementInstructions(35=T) |
| Pay Management | PayManagementReport(35=EA) | PayManagementReportAck(35=EB) |
| Pay Management | PayManagementRequest(35=DY) | Depending on workflow implemented: PayManagementRequestAck(35=DZ) or PayManagementReport(35=EA) |
| Settlement Status Management | SettlementStatusRequest(35=EC) | Depending on workflow implemented: SettlementStatusRequestAck(35=ED) or SettlementStatusReport(35=EE) |
| Settlement Status Management | SettlementStatusReport(35=EE) | SettlementStatusReportAck(35=EF) |
Key Fields for Application Message References
Messages which do not have a standard response message and can only be referenced via the BusinessMessageReject(35=j) message are as follows:
Pre-Trade
| Category | FIX Message | BusinessRejectRefID(379) |
|---|---|---|
| Indication | IOI(35=6) | IOIID(23) |
| Indication | Advertisement(35=7) | AdvId(2) |
| Indication | CrossRequestAck(35=DT) | CrossRequestID(2672) |
| Event Communication | News(35=B) | Headline(148) or NewsID(1472) |
| Event Communication | Email(35=C) | EmailThreadID(164) |
| Quotation Negotiation | MassQuoteAck(35=b) | QuoteReqID(131) or QuoteID(117) |
| Quotation Negotiation | QuoteAck(35=CW) | QuoteReqID(131) or QuoteID(117) or QuoteMsgID(1166) |
| Quotation Negotiation | QuoteRequestReject(35=R) | QuoteReqID(131) |
| Quotation Negotiation | QuoteStatusReport(35=AI) | QuoteStatusReqID(649) or QuoteRespID(693) or QuoteID(117) or QuoteMsgID(1166) |
| Quotation Negotiation | RFQRequest(35=AH) | RFQReqID(644) |
| Market Data | MarketDataIncrementalRefresh(35=X) | MDReqID(262) |
| Market Data | MarketDataReport(35=DR) | MDReportID(963) |
| Market Data | MarketDataSnapshotFullRefresh(35=W) | MDReqID(262) |
| Market Data | MarketDataStatisticsReport(35=DP) | MDStatisticRptID(2453) or MDStatisticReqID(2452) |
| Market Data | StreamAssignmentReportACK(35=CE) | StreamAsgnRptID(1501) |
| Securities Reference Data | DerivativeSecurityList(35=AA) | SecurityResponseID(322) |
| Securities Reference Data | SecurityDefinition(35=d) | SecurityResponseID(322) or SecurityReportID(964) |
| Securities Reference Data | SecurityDefinitionUpdateReport(35=BP) | SecurityResponseID(322) or SecurityReportID(964) |
| Securities Reference Data | SecurityList(35=y) | SecurityResponseID(322) |
| Securities Reference Data | SecurityListUpdateReport(35=BK) | SecurityResponseID(322) or SecurityReportID(964) |
| Securities Reference Data | SecurityMassStatus(35=CO) | SecurityStatusReqID(324) |
| Securities Reference Data | SecurityStatus(35=f) | SecurityStatusReqID(324) |
| Securities Reference Data | SecurityTypes(35=w) | SecurityResponseID(322) |
| Securities Reference Data | DerivativeSecurityListUpdateReport(35=BR) | SecurityResponseID(322) |
| Market Structure Reference Data | MarketDefinition(35=BU) | MarketReportID(1394) |
| Market Structure Reference Data | MarketDefinitionRequest(35=BT) | MarketReqID(1393) |
| Market Structure Reference Data | MarketDefinitionUpdateReport(35=BV) | MarketReportID(1394) or MarketReqID(1393) |
| Market Structure Reference Data | TradingSessionList(35=BJ) | TradSesReqID(335) |
| Market Structure Reference Data | TradingSessionListUpdateReport(35=BS) | TradSesReqID(335) |
| Market Structure Reference Data | TradingSessionStatus(35=h) | TradSesReqID(335) |
| Parties Reference Data | PartyDetailsDefinitionRequestAck(35=CY) | PartyDetailsListRequestID(1505) |
| Parties Reference Data | PartyDetailsListReport(35=CG) | PartyDetailsListReportID(1510) or PartyDetailsListRequestID(1505) |
| Parties Reference Data | PartyDetailsListUpdateReport(35=CK) | PartyDetailsListReportID(1510) or PartyDetailsListRequestID(1505) |
| Parties Reference Data | PartyEntitlementsReport(35=CV) | EntitlementReportID(1771) or EntitlementRequestID(1770) |
| Parties Reference Data | PartyEntitlementsUpdateReport(35=CZ) | EntitlementReportID(1771) or EntitlementRequestID(1770) |
| Parties Reference Data | PartyRiskLimitsDefinitionRequestAck(35=CT) | RiskLimitRequestID(1666) |
| Parties Reference Data | PartyRiskLimitsReportAck(35=DE) | RiskLimitReportID(1667) |
| Parties Action | PartyActionReport(35=DI) | PartyActionReportID(2331) or PartyActionRequestID(2328) |
| Parties Action | PartyRiskLimitCheckRequestAck(35=DG) | RiskLimitCheckRequestID(2318) |
Trade
| Category | FIX Message | BusinessRejectRefID(379) |
|---|---|---|
| Single General Order Handling | DontKnowTrade(35=Q) | ExecID(17)5 |
| Single General Order Handling | ExecutionAck(35=BN) | ExecID(17) |
| Single General Order Handling | OrderCancelReject(35=9) | ClOrdID(11) |
| Single General Order Handling | OrderMassCancelReport(35=r) | ClOrdID(11) |
| Order Mass Handling | MassOrderAck(35=DK) | MassOrderReportID(2424) |
| Order Mass Handling | OrderMassActionReport(35=BZ) | MassActionReportID(1369) or ClOrdID(11) |
| Program Trading | ListStatus(35=N) | ListID(66) |
| Program Trading | ListStrikePrice(35=m) | ListID(66) |
| Program Trading | BidResponse(35=l) | BidID(390) |
Post-Trade
| Category | FIX Message | BusinessRejectRefID(379) |
|---|---|---|
| Account Reporting | AccountSummaryReport(35=CQ) | AccountSummaryReportID(1699) |
| Allocation | AllocationInstructionAck(35=P) | AllocID(70) |
| Allocation | AllocationReportAck(35=AT) | AllocID(70) |
| Allocation | AllocationInstructionAlert(35=BM) | AllocID(70) |
| Allocation | AllocationInstructionAlertRequestAck(35=DV) | AllocRequestID(2758) |
| Confirmation | ConfirmationAck(35=AU) | ConfirmID(664) |
| Trade Capture | TradeCaptureReportRequestAck(35=AQ) | TradeRequestID(568) |
| Trade Capture | TradeCaptureReportAck(35=AR) | TradeReportID(571) |
| Trade Capture | TradeMatchReportAck(35=DD) | TradeMatchID(880) |
| Trade Management | TradeAggregationReport(35=DX) | TradeAggregationReportID(2792) or TradeAggregationRequestID(2786) |
| Position Maintenance | AdjustedPositionReport(35=BL) | PosMaintRptID(721) |
| Position Maintenance | AssignmentReport(35=AW) | AsgnRptID(833) |
| Position Maintenance | ContraryIntentionReport(35=BO) | ContIntRptID(977) |
| Position Maintenance | PositionMaintenanceReport(35=AM) | PosMaintRptID(721) or PosReqID(710) |
| Position Maintenance | PositionReport(35=AP) | PosMaintRptID(721) or PosReqID(710) |
| Position Maintenance | PositionTransferInstructionAck(35=DM) | TransferInstructionID(2436) |
| Position Maintenance | PositionTransferReport(35=DN) | TransferReportID(2438) or TransferInstructionID(2436) |
| Position Maintenance | RequestForPositionsAck(35=AO) | PosMaintRptID(721) |
| Collateral Management | CollateralResponse(35=AZ) | CollRespID(904) |
| Collateral Management | CollateralInquiryAck(35=BG) | CollInquiryID(909) |
| Collateral Management | CollateralReportAck(35=DQ) | CollRptID(908) |
| Margin Requirement Management | MarginRequirementInquiryAck(35=CI) | MarginReqmtInqID(1635) |
| Margin Requirement Management | MarginRequirementReport(35=CJ) | MarginReqmtRptID(1642) |
| Registration Instruction | RegistrationInstructionsResponse(35=p) | RegistID(513) |
| Settlement Instruction | SettlementInstructions(35=T) | SettInstMsgID(777) |
| Settlement Instruction | SettlementObligationReport(35=BQ) | SettlObligMsgID(1160) |
| Pay Management | PayManagementReportAck(35=EB) | PayReportID(2799) |
| Pay Management | PayManagementRequestAck(35=DZ) | PayRequestID(2812) |
| Settlement Status Management | SettlementStatusReportAck(35=EF) | SettlStatusReportID(2967) |
| Settlement Status Management | SettlementStatusRequestAck(35=ED) | SettlStatusRequestID(2965) |
Reject Codes for BusinessMessageReject(35=j) Message
| BusinessRejectReason(380) |
|---|
| 0 = Other |
| 1 = Unknown ID |
| 2 = Unknown Security |
| 3 = Unsupported Message Type (receive a valid, but unsupported MsgType) |
| 4 = Application not available |
| 5 = Conditionally Required Field Missing |
| 6 = Not Authorised |
| 7 = DeliverTo firm not available at this time |
| 8 = Throttle limit exceeded |
| 9 = Throttle limit exceeded, session will be disconnected |
| 10 = Throttled messages rejected on request |
| 18 = Invalid price increment |
Whenever possible, it is strongly recommended that the cause of the failure be described in Text(58) (e.g. “UNKNOWN SYBMOL: XYZ”).
Category – Network Status Communication
The Network Status messages are intended to be used by network services that facilitate FIX connectivity, allowing the service provider to convey to customers the FIX connection status of their counterparty(-ies).
It is envisaged these messages will be used in two scenarios:
Scenario A
Allow one counterparty using a “hub and spoke” FIX network to know whether another counterparty is currently connected to the hub (i.e. whether the counterparty’s session to the hub is up or not).
Scenario B
Allow a counterparty connecting to a global brokerage to know which regions within that brokerage are currently available as order routing destinations.
Messages
Network (Counterparty System) Status Requests
The NetworkCounterpartySystemStatusRequest(35=BC) message is sent either immediately after logging on to inform a network (counterparty system) of the type of updates required or to, at any other time in the FIX conversation, to change the nature of the types of status updates required. It can also be used with NetworkRequestType(935) = 1 (Snapshot) to request a one-off report of the status of a network (or counterparty) system. Finally this message can also be used to cancel a request to receive updates into the status of the counterparties on a network by sending a NetworkCounterpartySystemRequestStatusMessage(35=BC) message with NetworkRequestType = 4 (Stop Subscribing). The message layout is available here.
Network (Counterparty System) Status Responses
The NetworkCounterpartySystemStatusResponse(35=BD) message is sent in response to a NetworkCounterpartySystemStatusRequest(35=BC) message with a list of counterparties and their status in the repeating group CompIDStatGrp.
If the network response payload is larger than the maximum permitted message size for that FIX conversation the response would be several NetworkCounterpartySystemStatusResponse(35=BD) messages, the first with a status of full and then as many messages, as updates to the first message, adding information as required. The message layout is available here.
Components
CompIDReqGrp
This component is a repeating group used to convey one or more counterparties. The component layout is available here.
CompIDStatGrp
This component is a repeating group used to convey the connection status of one or more counterparties. The component layout is available here.
Category – User Management
The messages in this category are provided to allow the passing of individual user information or user level settings between two counterparties.
Messages
User Requests
The UserRequest(35=BE) message is used to initiate a user action, e.g. logon, logout or password change. It can also be used to request a report on a user’s status. The messages allow for specific functions by means of UserRequestType(924).
NOTE: While this message may be used to change user password, it is not encouraged to transmit passwords in a FIX conversation unless there is guarantee of end to end security of both the FIX conversation and any intermediate routing hubs that are involved in routing the message.
The message layout is available here.
User Responses
The UserResponse(35=BF) message is used to respond to a UserRequest(35=BE) message, it reports the status of the user after the completion of any action requested in the UserRequest(35=BE) message. The message layout is available here.
User Notifications
The UserNotification(35=CB) message is used to notify one or more users of an event or information from the sender of the message. This message is usually sent unsolicited from a marketplace (e.g. Exchange, ECN) to a market participant. The message layout is available here.
Components
ThrottleMsgTypeGrp
This component is a repeating group that is part of the ThrottleParamsGrp and may be used to convey one or more message types subject to the specified throttling parameters. The component layout is available here.
ThrottleParamsGrp
This component is a repeating group used to convey one or more parameters to control the flow rate of application messages. The component layout is available here.
UsernameGrp
This component is a repeating group used to convey one or more usernames. The component layout is available here.
Category – Application Sequencing
The Application Sequencing set of messages is used to manage application-level sequencing and address the segregation of retransmission of data over a session. This is primarily to address performance on a session when there is a need to retransmit data. These messages allow for the managing of this process based on specific upstream business systems and for the retransmission to occur over a separate FIX session or via other type of transport.
Introduction
FIX has a growing need to support application-level sequencing of messages in order to segregate the transmission of data over a session. The ability to identify and retransmit a subset of data by application and application sequence number range is an important feature in support of secondary distribution of data (see definition below). The current retransmission capabilities of the FIX session require that all messages on that session between the specified starting and ending message sequence number are resent rather than just those that have been produced by a specific upstream business process or application. This can pose capacity and performance problems for systems that need only a small set of messages related to an application. Secondary data distribution consists of a diverse set of data sourced from different applications; drop copy data, credit limit information, metrics, etc. It is not recommended that application sequencing is used over a conventional order routing or a transaction flow oriented connection. Standard FIX session capabilities should be used in this case.
Application sequencing greatly enhances the usefulness of FIX messages that are transmitted apart from the FIX session layer by making it possible for the receiver to detect and request missed messages on a specified feed. Market data sent over a broadcast or multicast transport is often in need of sequencing and retransmission. Application sequencing provides a means by which to sequence each message that is part of a broadcast stream such that the receiver can verify ordered delivery of the data. Application resends can then be requested when gaps are detected in the application sequence.
Background
The purpose of application-level sequencing is to allow messages being sent over a FIX session to be distinguished by the sending application that is upstream from the FIX engine. In the case that a session-level resend would result in an unnecessarily large number of messages being resent, application sequencing and recovery makes provision for the desired messages – and only the desired messages – to be seamlessly requested and resent while retaining the standard behaviors of the session protocol. It also provides the receiver with the flexibility to put off recovery of application level messages until a slow period or after the market has closed.
Extends control over resent data
The primary intent of application sequencing and recovery is to allow receivers to avoid a retransmission of large quantities of unusable data which may result in receivers needing to glean the retransmission for the data they actually need – such as critical drop copy information that is used in risk management applications. Application sequencing allows the channeling of different types of data across a single FIX session. For example, application sequencing can allow drop copy data to be sent over the same FIX session with order flow data. While this may not be practical from a trading standpoint the flexibility that it introduces is compelling. This allows data which has a higher importance and priority to be identified by application ID thereby allowing requests for retransmission to be issued promptly and precisely.
Support for secondary data distribution
Another goal of the proposal is to provide support for “secondary data” distribution. Application sequencing extends the capabilities of FIX such that secondary data can be distributed using a single channel. This data may be less time critical with less demanding latency requirements than order entry and market data, although this is not necessarily the case as drop copies are used for time sensitive risk management tasks. Secondary data may consist of drop copy fills, credit limit information, statistical data, trade confirmations, and best bids and offers for vendor consumption, etc. These are just a few of the possibilities. Application sequencing benefits data providers and their users by providing a common protocol which may be used to perform secondary data distribution. New applications transmitting data can be quickly introduced over an existing channel with minimal effort simply by introducing a new ApplID(1180) (application ID).
Transaction usage is not recommended
Application sequencing is not something that will be used in a normal order routing scenario. It has more relevance in large volume one-way connections in which the receiver would like to have some ability to control the data that is resent after a disconnect or data loss. There is no obvious advantage in using application sequencing with a regular trading connection since all data transmitted between sender and receiver is of equal importance in maintaining a viable trading session. Application sequencing should not be used to track broker connections that are in place for trading purposes. It should only be used for managing the flow of data when a FIX connection is used to deliver data in bulk and where there is a stated need to create classes of data.
Using Application Sequencing and Session Sequencing for Gap Detection
The use of ApplResendFlag(1352) on the ApplicationSequenceControl component (available on all FIX messages representing reports) is used to indicate that messages are being retransmitted as a result of an ApplicationMessageRequest(35=BW) message. When using the FIX Session Protocol, it is possible for both ApplResendFlag(1352) and PossDupFlag(43) to be set on the same message if the sender’s cache size is greater than zero and the message is being resent due to a session level ResendRequest(35=2) message.
The sender and receiver may agree to use a limited cache in order to benefit from the convenience of session-level retransmission. In this case, a message that is dropped in response to an ApplicationMessageRequest(35=BW) message may have both fields present. This scenario depends on whether (1) the sender is maintaining a cache and (2) the sender and receiver have agreed to fill any gaps to the extent possible using the session level.
In this scenario, a combination of application and session-level sequencing will be used to recover missed messages. A limited cache of session-level messages may be retained by the sender in order to recover messages that have been dropped within an pre-stated window defined by time or number of messages. When a FIX session ResendRequest(35=2) message is issued within this window the sender’s session will resend the messages. Once the window has been exceeded an ApplicationMessageRequest(35=BW) must be issued in order to recover dropped messages. The application level will not be aware that a gap has occurred until the session level has recovered what is available. Beyond this, the application will detect the gap according to the logic as described and issue a resend request at the application level using the ApplicationMessageRequest(35=BW) message.
NOTE: Gap detection and recovery with respect to the ApplicationMessageRequest(35=BW) message and response messages (e.g. ApplicationMessageRequestAck(35=BX) and resent application messages using the ApplicationSequenceControl component) may also need to take place at the application level since session level recovery may have been suspended.
Messages
Application Message Requests
The ApplicationMessageRequest(35=BW) message is used to request a retransmission of a set of one or more messages generated by the application identified in the ApplIDRequestGrp component. The type of retransmission request is specified with ApplReqType(1347). The message layout is available here.
Application Message Request Acknowledgements
The ApplicationMessageRequestAck(35=BX) message is used to acknowledge an ApplicationMessageRequest(35=BW) message providing a status on the request (i.e. whether successful or not) with ApplResponseType(1348). This message does not provide the actual content of the messages to be resent. The message layout is available here.
Application Message Reports
The ApplicationMessageReport(35=BY) message is used for different purposes as indicated by ApplReportType(1426). The message layout is available here.
Using Application Message Reports to reset application-level sequence number
The ApplicationMessageReport(35=BY) message with ApplReportType(1426) = 0 (Reset) is sent by the sender of an application to alert the receiver that the application sequence number of application RefApplID(1355) is being reset to ApplNewSeqNum(1399), for one or more RefApplID(1355) values, to the specified value(s). The next application message received will then conform to this value. In other words, ApplSeqNum(1181) in this message represents the next expected application sequence number the receiver will receive from the sender for the corresponding ApplID(1180). An ApplicationMessageReport(35=BY) message with ApplReportType(1426) = 0 (Reset) has no affect on, and is independent of, the FIX session sequence number in MsgSeqNum(34).
Using Application Message Reports to indicate last message sent
The ApplicationMessageReport(35=BY) message with ApplReportType(1426) = 1 (Last message) is sent by the sender of an application to indicate that the last message has been sent for one or more RefApplID(1355) values. Reception of this message mean the recipient can safely assume that no more message will be sent for that/or those RefApplID(1355) values. RefApplLastSeqNum(1357) should be set to ApplSeqNum(1181) on the last application-level message. RefApplID(1355) is set to ApplID(1180) on this message.
Using Application Message Report as keep-alive mechanism
For recipients of applications with infrequent message traffic it is a problem to detect a gap in the message flow. The gap cannot be detected until reception of the next message for that ApplID(1180). To mitigate this problem the ApplicationMessageReport(35=BY) message can be issued by the sender of an application at regular intervals. RefApplLastSeqNum(1357) should be set to the last ApplSeqNum(1181) sent for this application, identified by ApplID(1180) and referenced on the report by RefApplID(1355).
Using Application Message Report to indicate completion of resent messages
As part of a recovery scenario, the receiver (or consumer) may request all of the messages for one or more applications. Because of the potentially lengthy re-send situation, the request can be acknowledged with an ApplicationMessageRequestAck(35=BX) prior to beginning the re-send of messages. In this case, the receiver or consumer will begin seeing re-sent messages until the re-send is complete. However, once the re-send is complete, the receiver or consumer will only know that the re-send has completed when they receive a new copied message from that application identified with ApplID(1180) that no longer has ApplResendFlag(1352 ) = Y. If the specified ApplID(1180) is only “heartbeating” and there are no new messages to send, the consumer will still not know the application message re-send has actually finished. It is in this case that an ApplicationMessageReport(35=BY) can be generated, which signals completion by setting ApplReportType(1426) = 3 (application message re-send completed).
Components
ApplIDReportGrp
This component is a repeating group used to convey a new application sequence number for a reset and/or the last application sequence number of one or more applications identified by RefApplID(1355). The component layout is available here.
ApplIDRequestAckGrp
This component is a repeating group used to provide the status on a request to retransmit application messages for one or more applications identified by RefApplID(1355). In case of a succesful request, it provides information such as the range of application sequence numbers that will actually be returned per application. In case of failure, it provides a reason for the rejection for the specified application. The component layout is available here.
ApplIDRequestGrp
This component is a repeating group used to provide the range of application sequence numbers specified in ApplBegSeqNum(1182) and ApplEndSeqNum(1183) for retransmission from one or more applications identified by RefApplID(1355). The component layout is available here.
