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:

  1. BUSINESS MESSAGE REJECTS
  2. NETWORK STATUS COMMUNICATION
  3. USER MANAGEMENT
  4. APPLICATION SEQUENCING
  5. APPENDIX: COMPONENTS AND MESSAGES

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 Component Blocks and Messages for Infrastructure

Component Blocks

This section lists component blocks used by infrastructure messages defined in this part of the FIX specification. Messages may also reference Global Component blocks, which are components used by messages across all areas. Global Common Components are defined in the overall introduction to the FIX specification as well as online.

Component blocks can be either repeating (aka a group) or non-repeating, i.e. contain multiple instances of a set of fields. Component blocks can be nested to any level.

Type NameCategory
RepeatingApplIDReportGrpApplication Sequencing
RepeatingApplIDRequestAckGrpApplication Sequencing
RepeatingApplIDRequestGrpApplication Sequencing
RepeatingApplIDRequestGrpApplication Sequencing
RepeatingCompIDReqGrpNetwork Status Communication
RepeatingCompIDStatGrpNetwork Status Communication
RepeatingUsernameGrpUser Management

Messages

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

MsgType(35)NameCategory
BWApplicationMessageRequestApplication Sequencing
BXApplicationMessageRequestAckApplication Sequencing
BYApplicationMessageReportApplication 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.

The only exception to this rule is when a transport other than the FIX session protocol (FIX4 or FIXT) is being used (transport independence). An appropriate reject message of the given session protocol (e.g. Reject(35=3) for FIX4 or FIXT session layer) or the BusinessMessageReject(35=j) message should be used instead. The message layout is available here.

It should NOT be used in the following situations:

SituationAppropriate Response
Session-level problem meeting the criteria of the session-level Reject(35=3) messageUse the session-level Reject(35=3) message if the FIX session protocol FIX 4 or FIXT is being used.

If FIX4 or FIXT are not being used, use an appropriate reject message of the given session protocol or the BusinessMessageReject(35=j) message.

In response to:
– QuoteRequest(35=R)
Use the QuoteRequestReject(35=AG) message
In response to:
– Quote(35=S)
– QuoteCancel(35=Z)
– QuoteStatusRequest(35=a)
– QuoteResponse(35=AJ)
Use the QuoteStatusReport(35=AI) message
In response to:
– MassQuote(35=i)
Use the MassQuoteAck(35=b) message
In response to:
– MarketDataRequest(35=V)
Use the MarketDataRequestReject(35=Y) message
In response to:
– StreamAssignmentRequest(35=CC)
Use the StreamAssignmentReport(35=CD) message
In response to:
– StreamAssignmentReport(35=CD)
Use the StreamAssignmentReportACK(35=CE) message
In response to:
– SecurityDefinitionRequest(35=c)
Use the SecurityDefinition(35=d) message
In response to:
– SecurityTypeRequest(35=v)
Use the SecurityTypes(35=w) message
In response to:
– SecurityListRequest(35=x)
Use the SecurityList(35=y) message
In response to:
– DerivativeSecurityListRequest(35=z)
Use the DerivativeSecurityList(35=AA) message
In response to:
– SecurityStatusRequest(35=e)
Use the SecurityStatus(35=f) message
In response to:
– TradingSessionStatusRequest(35=g)
Use the TradingSessionStatus(35=h) message
In response to:
– TradingSessionListRequest(35=BI)
Use the TradingSessionList(35=BJ) message
In response to:
– PartyDetailsListRequest(35=CF)
Use the PartyDetailsListReport(35=CG) message
In response to:
– NewOrderSingle(35=D)
– OrderStatusRequest(35=H)
– OrderMassStatusRequest(35=AF)
– NewOrderCross(35=s)
– NewOrderMultileg(35=AB)
– NewOrderList(35=E)
– ListExecute(35=L)
Use the ExecutionReport(35=8) message
In response to:
– OrderCancelRequest(35=F)
– OrderCancelReplaceRequest(35=G)
– CrossOrderCancelRequest(35=u)
– CrossOrderCancelReplaceRequest(35=t)
– MultilegOrderCancelReplace(35=AC)
– ListCancelRequest(35=K)
Use the OrderCancelReject(35=9) message
In response to:
– ExecutionReport(35=8)
Use the DontKnowTrade(35=Q) message (DK’d) or the ExecutionReportAck(35=BN) message
In response to:
– OrderMassCancelRequest(35=q)
Use the OrderMassCancelReport(35=r) message
In response to:
– OrderMassActionRequest(35=CA)
Use the OrderMassActionReport(35=BZ) message
In response to:
– ListStatusRequest(35=M)
Use the ListStatus(35=N) message
In response to:
– BidRequest(35=k)
Use the BidResponse(35=l) message
In response to:
– AllocationInstruction(35=J)
Use the AllocationInstructionAck(35=P) message
In response to:
– AllocationReport(35=AS)
Use the AllocationReportAck(35=AT) message
In response to:
– Confirmation(35=AK)
Use the ConfirmationAck(35=AU) message
In response to:
– RegistrationInstructions(35=o)
Use the RegistrationInstructionsResponse(35=p) message
In response to:
– TradeCaptureReportRequest(35=AD)
Use the TradeCaptureReportRequestAck(35=AQ) message
In response to:
– TradeCaptureReport(35=AE)
Use the TradeCaptureReportAck(35=AR) message
In response to:
– ConfirmationRequest(35=BH)
Use the Confirmation(35=AK) message
In response to:
– SettlementInstructionRequest(35=AV)
Use the SettlementInstructions(35=T) message
In response to:
– PositionMaintenanceRequest(35=AL)
Use the PositionMaintenanceReport(35=AM) message
In response to:
– RequestForPositions(35=AN)
Use the RequestForPositionsAck(35=AO) message
In response to:
– CollateralRequest(35=AX)
Use the CollateralAssignment(35=AY) message
In response to:
– CollateralAssignment(35=AY)
Use the CollateralResponse(35=AZ) message
In response to:
– CollateralInquiry(35=BB)
Use the CollateralInquiryAck(35=BG) message

Note the only exceptions to this rule 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.

Key Fields for Application Message References

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

Pre-Trade

FIX MessageBusinessRejectRefID(379)
Indication of Interest – IOI(35=6)IOIID(23)
Advertisement(35=7)AdvId(2)
News(35=B)Headline(148) or NewsID(1472)
Email(35=C)EmailThreadID(164)
MarketDataSnapshotFullRefresh(35=W)MDReqID(262)
MarketDataIncrementalRefresh(35=X)MDReqID(262)
MarketDataRequestReject(35=Y)MDReqID(262)
MarketDefinition(35=BU)MarketReportID(1394)
MarketDefinitionRequest(35=BT)MarketReqID(1393)
MarketDefinitionUpdateReport(35=BV)MarketReportID(1394)
StreamAssignmentReportAck(35=CE)StreamAsgnRptID(1501)
SecurityDefinition(35=d)SecurityResponseID(322) or SecurityReportID(964)
SecurityDefinitionUpdateReport(35=BP)SecurityResponseID(322) or SecurityReportID(964)
SecurityStatus(35=f)SecurityStatusReqID(324)
SecurityTypes(35=w)SecurityResponseID(322)
SecurityList(35=y)SecurityResponseID(322)
SecurityListUpdateReport(35=BK)SecurityResponseID(322) or SecurityReportID(964)
DerivativeSecurityList(35=AA)SecurityResponseID(322)
DerivativeSecurityListUpdateReport(35=BR)SecurityResponseID(322)
TradingSessionStatus(35=h)TradSesReqID(335)
TradingSessionList(35=BJ)TradSesReqID(335)
TradingSessionListUpdateReport(35=BS)TradSesReqID(335)
PartyDetailsListReport(35=CG)PartyDetailsListReportID(1510)
MassQuoteAck(35=b)QuoteReqID(131) or QuoteID(117)
QuoteRequestReject(35=R)QuoteReqID(131)
RFQRequest(35=AH)RFQReqID(644)
QuoteStatusReport(35=AI)QuoteStatusReqID(649) or QuoteRespID(693) or QuoteID(117) or QuoteMsgID(1166)
OrderCancelReject(35=9)ClOrdID(11)

Trade

FIX MessageBusinessRejectRefID(379)
ListStatus(35=N)ListID(66)
ListStrikePrice(35=m)ListID(66)
BidResponse(35=l)BidID(390)
OrderMassCancelReport(35=r)ClOrdID(11)
OrderMassActionReport(35=BZ)MassActionReportID(1369) or ClOrdID(11)
OrderMassStatusRequest(35=AF)MassStatusReqID(584)
DontKnowTrade(35=Q)may respond with OrderCancelReject(35=9) if attempting to cancel order ExecID(17)
ExecutionAck(35=BN)ExecID(17)

Post-Trade

FIX MessageBusinessRejectRefID(379)
AllocationInstructionAck(35=P)AllocID(70)
AllocationReportAck(35=AT)AllocID(70)
AllocationInstructionAlert(35=BM)AllocID(70)
ConfirmationAck(35=AU)ConfirmID(664)
TradeCaptureReport(35=AE)TradeReportID(571)
TradeCaptureReportRequestAck(35=AQ)TradeRequestID(568)
TradeCaptureReportAck(35=AR)TradeReportID(571)
PositionMaintenanceReport(35=AM)PosMaintRptID(721)
RequestForPositionsAck(35=AO)PosMaintRptID(721)
AdjustedPositionReport(35=BL)PosMaintRptID(721)
PositionReport(35=AP)PosMaintRptID(721)
AssignmentReport(35=AW)AsgnRptID(833)
ContraryIntentionReport(35=BO)ContIntRptID(977)
SettlementInstructions(35=T)SettInstMsgID(777)
SettlementObligationReport(35=BQ)SettlObligMsgID(1160)
RegistrationInstructionsResponse(35=p)RegistID(513)
CollateralResponse(35=AZ)CollRespID(904)
CollateralInquiryAck(35=BG)CollInquiryID(909)
CollateralReport(35=BA)CollRptID(908)

Scenarios for BusinessMessageReject(35=j):

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

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.

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

Components

UsernameGrp

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

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

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

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 can 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 FIX4 or FIXT, 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.

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 ApplicationSequenceGrp component) may also need to take place at the application level since session level recovery may have been suspended.

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 requested for retransmission from one or more applications identified by RefApplID(1355). The component layout is available here.

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 specified in RefApplID(1355). The message can 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).