As of EP258, July 2020


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.

List of Components and Messages for Infrastructure


This section lists components used by infrastructure messages defined in this part of the FIX specification. Some 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.

RepeatingApplIDReportGrpApplication Sequencing
RepeatingApplIDRequestAckGrpApplication Sequencing
RepeatingApplIDRequestGrpApplication Sequencing
RepeatingCompIDReqGrpNetwork Status Communication1
RepeatingCompIDStatGrpNetwork Status Communication2
RepeatingThrottleMsgTypeGrpUser Management3
RepeatingThrottleParamsGrpUser Management4
RepeatingUsernameGrpUser Management


This section lists the infrastructure messages and the category each of them belongs to.

BYApplicationMessageReportApplication Sequencing
BWApplicationMessageRequestApplication Sequencing
BXApplicationMessageRequestAckApplication Sequencing
jBusinessMessageRejectBusiness Message Rejects
BCNetworkCounterpartySystemStatusRequestNetwork Status Communication
BDNetworkCounterpartySystemStatusResponseNetwork Status Communication
BEUserRequestUser Management
BFUserResponseUser Management
CBUserNotificationUser Management

Category – 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:

  1. 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.
  2. 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.
  3. 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.

Standard Responses for Pre-Trade Messages

CategoryFIX MessageAppropriate Response(s)
Quotation NegotiationMassQuote(35=i)MassQuoteAck(35=b)
Quotation NegotiationQuoteRequest(35=R)QuoteRequestReject(35=AG)
Quotation NegotiationQuote(35=S)Depending on workflow implemented: QuoteAck(35=CW) or QuoteStatusReport(35=AI)
Quotation NegotiationQuoteCancel(35=Z)Depending on workflow implemented: QuoteAck(35=CW) or QuoteStatusReport(35=AI)
Quotation NegotiationQuoteStatusRequest(35=a)QuoteStatusReport(35=AI)
Quotation NegotiationQuoteResponse(35=AJ)QuoteStatusReport(35=AI)
Market DataMarketDataRequest(35=V)MarketDataRequestReject(35=Y)
Market DataMarketDataStatisticsRequest(35=DO)MarketDataStatisticsReport(35=DP)
Market DataStreamAssignmentReport(35=CD)StreamAssignmentReportACK(35=CE)
Market DataStreamAssignmentRequest(35=CC)StreamAssignmentReport(35=CD)
Securities Reference DataDerivativeSecurityListRequest(35=z)DerivativeSecurityList(35=AA)
Securities Reference DataSecurityDefinitionRequest(35=c)SecurityDefinition(35=d)
Securities Reference DataSecurityListRequest(35=x)SecurityList(35=y)
Securities Reference DataSecurityMassStatusRequest(35=CN)SecurityMassStatus(35=CO)
Securities Reference DataSecurityStatusRequest(35=e)SecurityStatus(35=f)
Securities Reference DataSecurityTypeRequest(35=v)SecurityTypes(35=w)
Market Structure Reference DataTradingSessionStatusRequest(35=g)TradingSessionStatus(35=h)
Market Structure Reference DataTradingSessionListRequest(35=BI)TradingSessionList(35=BJ)
Parties Reference DataPartyActionRequest(35=DH)PartyActionReport(35=DI)
Parties Reference DataPartyDetailsDefinitionRequest(35=CX)PartyDetailsDefinitionRequestAck(35=CY)
Parties Reference DataPartyDetailsListRequest(35=CF)PartyDetailsListReport(35=CG)
Parties Reference DataPartyEntitlementsDefinitionRequest(35=DA)PartyEntitlementstDefinitionRequestAck(35=DB)
Parties Reference DataPartyEntitlementsRequest(35=CU)PartyEntitlementsReport(35=CV)
Parties Reference DataPartyRiskLimitCheckRequest(35=DF)PartyRiskLimitCheckRequestAck(35=DG)
Parties Reference DataPartyRiskLimitsDefinitionRequest(35=CS)PartyRiskLimitsDefinitionRequestAck(35=CT)
Parties Reference DataPartyRiskLimitReport(35=CM)PartyRiskLimitReportAck(35=DE)
Parties Reference DataPartyRiskLimitsRequest(35=CL)PartyRiskLimitsReport(35=CM)
Parties Reference DataPartyRiskLimitUpdateReport(35=CR)PartyRiskLimitReportAck(35=DE)

Standard Responses for Trade Messages

CategoryFIX MessageAppropriate Response(s)
Single General Order HandlingExecutionReport(35=8)DontKnowTrade(35=Q) or ExecutionAck(35=BN)
Single General Order HandlingNewOrderSingle(35=D)ExecutionReport(35=8)
Single General Order HandlingOrderCancelReplaceRequest(35=G)OrderCancelReject(35=9)
Single General Order HandlingOrderCancelRequest(35=F)OrderCancelReject(35=9)
Single General Order HandlingOrderStatusRequest(35=H)ExecutionReport(35=8)
Multileg Order HandlingMultilegOrderCancelReplace(35=AC)OrderCancelReject(35=9)
Multileg Order HandlingNewOrderMultileg(35=AB)ExecutionReport(35=8)
Cross Order HandlingCrossOrderCancelReplaceRequest(35=t)OrderCancelReject(35=9)
Cross Order HandlingCrossOrderCancelRequest(35=u)OrderCancelReject(35=9)
Cross Order HandlingNewOrderCross(35=s)ExecutionReport(35=8)
Order Mass HandlingMassOrder(35=DJ)MassOrderAck(35=DK)
Order Mass HandlingOrderMassActionRequest(35=CA)OrderMassActionReport(35=BZ)
Order Mass HandlingOrderMassCancelRequest(35=q)OrderMassCancelReport(35=r)
Order Mass HandlingOrderMassStatusRequest(35=AF)ExecutionReport(35=8)
Program TradingBidRequest(35=k)BidResponse(35=l)
Program TradingListCancelRequest(35=K)OrderCancelReject(35=9)
Program TradingListExecute(35=L)ExecutionReport(35=8)
Program TradingListStatusRequest(35=M)ListStatus(35=N)
Program TradingNewOrderList(35=E)ExecutionReport(35=8)

Standard Responses for Post-Trade Messages

CategoryFIX MessageAppropriate Response(s)
Trade CaptureTradeCaptureReportRequest(35=AD)TradeCaptureReportRequestAck(35=AQ)
Trade CaptureTradeCaptureReport(35=AE)TradeCaptureReportAck(35=AR)
Trade CaptureTradeMatchReport(35=DC)TradeMatchReportAck(35=DD)
Trade ManagementTradeAggregationRequest(35=DW)TradeAggregationReport(35=DX)
Position MaintenancePositionMaintenanceRequest(35=AL)PositionMaintenanceReport(35=AM)
Position MaintenancePositionTransferInstruction(35=DL)PositionTransferInstructionAck(35=DM)
Position MaintenanceRequestForPositions(35=AN)RequestForPositionsAck(35=AO)
Collateral ManagementCollateralAssignment(35=AY)CollateralResponse(35=AZ)
Collateral ManagementCollateralInquiry(35=BB)CollateralInquiryAck(35=BG)
Collateral ManagementCollateralReport(35=BA)CollateralReportAck(35=DQ)
Collateral ManagementCollateralRequest(35=AX)CollateralAssignment(35=AY)
Margin Requirement ManagementMarginRequirementInquiry(35=CH)Depending on workflow implemented: MarginRequirementInquiryAck(35=CI) or MarginRequirementReport(35=CJ), PositionReport(35=AP)
Registration InstructionRegistrationInstructions(35=o)RegistrationInstructionsResponse(35=p)
Settlement InstructionSettlementInstructionRequest(35=AV)SettlementInstructions(35=T)
Pay ManagementPayManagementReport(35=EA)PayManagementReportAck(35=EB)
Pay ManagementPayManagementRequest(35=DY)Depending on workflow implemented: PayManagementRequestAck(35=DZ) or PayManagementReport(35=EA)

Key Fields for Application Message References

Messages which can be referenced via the BusinessMessageReject(35=j) message are as follows:


CategoryFIX MessageBusinessRejectRefID(379)
Event CommunicationNews(35=B)Headline(148) or NewsID(1472)
Event CommunicationEmail(35=C)EmailThreadID(164)
Quotation NegotiationMassQuoteAck(35=b)QuoteReqID(131) or QuoteID(117)
Quotation NegotiationQuoteAck(35=CW)QuoteReqID(131) or QuoteID(117) or QuoteMsgID(1166)
Quotation NegotiationQuoteRequestReject(35=R)QuoteReqID(131)
Quotation NegotiationQuoteStatusReport(35=AI)QuoteStatusReqID(649) or QuoteRespID(693) or QuoteID(117) or QuoteMsgID(1166)
Quotation NegotiationRFQRequest(35=AH)RFQReqID(644)
Market DataMarketDataIncrementalRefresh(35=X)MDReqID(262)
Market DataMarketDataIncrementalRefresh(35=X)MDReqID(262)
Market DataMarketDataReport(35=DR)MDReportID(963)
Market DataMarketDataSnapshotFullRefresh(35=W)MDReqID(262)
Market DataMarketDataStatisticsReport(35=DP)MDStatisticRptID(2453) or MDStatisticReqID(2452)
Market DataStreamAssignmentReportACK(35=CE)StreamAsgnRptID(1501)
Securities Reference DataDerivativeSecurityList(35=AA)SecurityResponseID(322)
Securities Reference DataSecurityDefinition(35=d)SecurityResponseID(322) or SecurityReportID(964)
Securities Reference DataSecurityDefinitionUpdateReport(35=BP)SecurityResponseID(322) or SecurityReportID(964)
Securities Reference DataSecurityList(35=y)SecurityResponseID(322)
Securities Reference DataSecurityListUpdateReport(35=BK)SecurityResponseID(322) or SecurityReportID(964)
Securities Reference DataSecurityMassStatus(35=CO)SecurityStatusReqID(324)
Securities Reference DataSecurityStatus(35=f)SecurityStatusReqID(324)
Securities Reference DataSecurityTypes(35=w)SecurityResponseID(322)
Securities Reference DataDerivativeSecurityListUpdateReport(35=BR)SecurityResponseID(322)
Market Structure Reference DataMarketDefinition(35=BU)MarketReportID(1394)
Market Structure Reference DataMarketDefinitionRequest(35=BT)MarketReqID(1393)
Market Structure Reference DataMarketDefinitionUpdateReport(35=BV)MarketReportID(1394) or MarketReqID(1393)
Market Structure Reference DataTradingSessionList(35=BJ)TradSesReqID(335)
Market Structure Reference DataTradingSessionListUpdateReport(35=BS)TradSesReqID(335)
Market Structure Reference DataTradingSessionStatus(35=h)TradSesReqID(335)
Parties Reference DataPartyDetailsDefinitionRequestAck(35=CY)PartyDetailsListRequestID(1505)
Parties Reference DataPartyDetailsListReport(35=CG)PartyDetailsListReportID(1510) or PartyDetailsListRequestID(1505)
Parties Reference DataPartyDetailsListUpdateReport(35=CK)PartyDetailsListReportID(1510) or PartyDetailsListRequestID(1505)
Parties Reference DataPartyEntitlementsReport(35=CV)EntitlementReportID(1771) or EntitlementRequestID(1770)
Parties Reference DataPartyEntitlementsUpdateReport(35=CZ)EntitlementReportID(1771) or EntitlementRequestID(1770)
Parties Reference DataPartyRiskLimitsDefinitionRequestAck(35=CT)RiskLimitRequestID(1666)
Parties Reference DataPartyRiskLimitsReport(35=CM)RiskLimitReportID(1667) or RiskLimitRequestID(1666)
Parties Reference DataPartyRiskLimitsReportAck(35=DE)RiskLimitReportID(1667)
Parties Reference DataPartyRiskLimitsUpdateReport(35=CR)RiskLimitReportID(1667) or RiskLimitRequestID(1666)
Parties ActionPartyActionReport(35=DI)PartyActionReportID(2331) or PartyActionRequestID(2328)
Parties ActionPartyRiskLimitsCheckRequestAck(35=DG)RiskLimitCheckRequestID(2318)


CategoryFIX MessageBusinessRejectRefID(379)
Single General Order HandlingDontKnowTrade(35=Q)ExecID(17)5
Single General Order HandlingExecutionAck(35=BN)ExecID(17)
Single General Order HandlingOrderCancelReject(35=9)ClOrdID(11)
Single General Order HandlingOrderMassCancelReport(35=r)ClOrdID(11)
Order Mass HandlingMassOrderAck(35=DK)MassOrderReportID(2424)
Order Mass HandlingOrderMassActionReport(35=BZ)MassActionReportID(1369) or ClOrdID(11)
Order Mass HandlingOrderMassStatusRequest(35=AF)MassStatusReqID(584)
Program TradingListStatus(35=N)ListID(66)
Program TradingListStrikePrice(35=m)ListID(66)
Program TradingBidResponse(35=l)BidID(390)


CategoryFIX MessageBusinessRejectRefID(379)
Account ReportingAccountSummaryReport(35=CQ)AccountSummaryReportID(1699)
Trade CaptureTradeCaptureReport(35=AE)TradeReportID(571) or TradeRequestID(568)
Trade CaptureTradeCaptureReportRequestAck(35=AQ)TradeRequestID(568)
Trade CaptureTradeCaptureReportAck(35=AR)TradeReportID(571)
Trade CaptureTradeMatchReportAck(35=DD)TradeMatchID(880)
Trade ManagementTradeAggregationReport(35=DX)TradeAggregationReportID(2792) or TradeAggregationRequestID(2786)
Position MaintenanceAdjustedPositionReport(35=BL)PosMaintRptID(721)
Position MaintenanceAssignmentReport(35=AW)AsgnRptID(833)
Position MaintenanceContraryIntentionReport(35=BO)ContIntRptID(977)
Position MaintenancePositionMaintenanceReport(35=AM)PosMaintRptID(721) or PosReqID(710)
Position MaintenancePositionReport(35=AP)PosMaintRptID(721) or PosReqID(710)
Position MaintenancePositionTransferInstructionAck(35=DM)TransferInstructionID(2436)
Position MaintenancePositionTransferReport(35=DN)TransferReportID(2438) or TransferInstructionID(2436)
Position MaintenanceRequestForPositionsAck(35=AO)PosMaintRptID(721)
Collateral ManagementCollateralResponse(35=AZ)CollRespID(904)
Collateral ManagementCollateralInquiryAck(35=BG)CollInquiryID(909)
Collateral ManagementCollateralReport(35=BA)CollRptID(908) or CollInquiryID(909)
Collateral ManagementCollateralReportAck(35=DQ)CollRptID(908)
Margin Requirement ManagementMarginRequirementInquiryAck(35=CI)MarginReqmtInqID(1635)
Margin Requirement ManagementMarginRequirementReport(35=CJ)MarginReqmtRptID(1642)
Registration InstructionRegistrationInstructionsResponse(35=p)RegistID(513)
Settlement InstructionSettlementInstructions(35=T)SettInstMsgID(777)
Settlement InstructionSettlementObligationReport(35=BQ)SettlObligMsgID(1160)
Pay ManagementPayManagementReport(35=EA)PayReportID(2799) or PayRequestID(2812)
Pay ManagementPayManagementReportAck(35=EB)PayReportID(2799)
Pay ManagementPayManagementRequestAck(35=DZ)PayRequestID(2812)

Reject Codes for BusinessMessageReject(35=j) Message

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

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.



This component is a repeating group used to convey one or more counterparties. The component layout is available here.


This component is a repeating group used to convey the connection status of one or more counterparties. The component layout is available here.


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. The message layout is available here.

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.

Category – User Management

These messages are provided in FIX to allow the passing of individual user information between two counterparties. The messages allow for specific functions by means of UserRequestType(924), see FIXimate for details.

NOTE: It is not encouraged to transmit passwords in a FIX conversation unless you can guarantee the end to end security of both the FIX conversation and any intermediate routing hubs that are involved in the routing.



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.


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.


This component is a repeating group used to convey one or more usernames. The component layout is available here.


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

Category – Application Sequencing


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


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

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



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.


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.


This component is a repeating group used to provide the range of application sequence numbers requested for retransmission from one or more applications identified by RefApplID(1355). The component layout is available here.


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 specified in RefApplID(1355). The message may be used for various types of transmission requests, see FIXimate for details.

The ApplicationMessageRequest(35=BW) message specifies the sequence number range using ApplBegSeqNum(1182) and ApplEndSeqNum(1183) for a given RefApplID(1355) to request messages for retransmission. 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), see FIXimate for details. 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).

  1. CompIDReqGrp added as common with FIX 4.4 but only used in the category Network Status Communication.↩︎
  2. CompIDStatGrp added as common with FIX 4.4 but only used in the category Network Status Communication.↩︎
  3. ThrottleMsgTypeGrp added as common with EP116 but only used in the category User Management.↩︎
  4. ThrottleParamsGrp added as common with EP116 but only used in the category User Management.↩︎
  5. May also respond with OrderCancelReject(35=9) message if attempting to cancel order identified with ExecID(17).↩︎