As of EP258, July 2020

Introduction

Post-trade messaging is characterized as messages which are typically communicated after the placement and successful execution of an order and prior to settlement.

The specific FIX post-trade messaging categories are:

  1. ALLOCATION
  2. CONFIRMATION
  3. SETTLEMENT INSTRUCTIONS
  4. TRADE CAPTURE
  5. REGISTRATION INSTRUCTIONS
  6. POSITION MAINTENANCE
  7. COLLATERAL MANAGEMENT
  8. MARGIN REQUIREMENT MANAGEMENT
  9. ACCOUNT REPORTING
  10. TRADE MANAGEMENT
  11. PAY MANAGEMENT
  12. APPENDIX: COMPONENTS AND MESSAGES

Descriptions of the specific FIX pre-trade 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 Post-Trade

Components

This section lists components used by post-trade 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.

TypeNameCategory
RepeatingAllocAckGrpAllocation
RepeatingAllocCommissionDataGrpCommon Components
RepeatingAllocGrpAllocation
RepeatingAllocRegulatoryTradeIDGrpCommon Components
Non-RepeatingAveragePriceDetailTrade Capture Reporting1
RepeatingClrInstGrpCommon Components
RepeatingCollateralAmountGrpCommon Components
RepeatingCollateralReinvestmentGrpCommon Components
RepeatingCollInqQualGrpCollateral Management
RepeatingCpctyConfGrpConfirmation
RepeatingDlvyInstGrpCommon Components
RepeatingExecAllocGrpCommon Components
RepeatingExecCollGrpCollateral Management
RepeatingExecutionAggregationGrpTrade Management2
RepeatingExpirationQtyPosition Maintenance
RepeatingFundingSourceGrpCollateral Management3
RepeatingInstrmtMatchSideGrpTrade Capture Reporting
RepeatingLegPositionAmountDataTrade Capture Reporting
RepeatingMandatoryClearingJurisdictionGrpTrade Capture Reporting4
RepeatingMarginAmountCommon Components
RepeatingMarginReqmtInqQualGrpMargin Requirement Management
RepeatingMatchExceptionGrpConfirmation5
RepeatingMatchingDataPointGrpConfirmation6
RepeatingOrdAllocGrpCommon Components
RepeatingOrderAggregationGrpTrade Management7
RepeatingPayCollectGrpAccount Reporting
RepeatingPosUndInstrmtGrpPosition Maintenance
RepeatingPositionAmountDataCommon Components
RepeatingPositionQtyPosition Maintenance8
Non-RepeatingPostTradePaymentPay Management
RepeatingRelatedPositionGrpTrade Capture Reporting9
RepeatingRgstDistInstGrpRegistration Instruction
RepeatingRgstDtlsGrpRegistration Instruction
RepeatingSettlDetailsCommon Components
RepeatingSettlementAmountGrpAccount Reporting
RepeatingSettlInstGrpSettlement Instruction
Non-RepeatingSettlInstructionsDataCommon Components
RepeatingSettlObligationInstructionsSettlement Instruction
RepeatingSettlPartiesCommon Components
RepeatingSettlPtysSubGrpCommon Components
RepeatingSideCollateralAmountGrpTrade Capture Reporting10
RepeatingSideCollateralReinvestmentGrpTrade Capture Reporting11
RepeatingSideRegulatoryTradeIDGrpTrade Capture Reporting12
RepeatingSideTrdRegTSTrade Capture Reporting
RepeatingTradeAllocAmtGrpCommon Components
RepeatingTradeCapLegUnderlyingsGrpTrade Capture Reporting13
RepeatingTradePositionQtyTrade Capture Reporting14
RepeatingTradeQtyGrpTrade Capture Reporting15
Non-RepeatingTradeReportOrderDetailTrade Capture Reporting
RepeatingTransactionAttributeGrpCommon Components
RepeatingTrdAllocGrpTrade Capture Reporting
RepeatingTrdCapDtGrpTrade Capture Reporting
RepeatingTrdCapRptAckSideGrpTrade Capture Reporting
RepeatingTrdCapRptSideGrpTrade Capture Reporting
RepeatingTrdCollGrpCollateral Management
RepeatingTrdInstrmtLegExecGrpTrade Capture Reporting
RepeatingTrdInstrmtLegGrpTrade Capture Reporting
RepeatingTrdMatchSideGrpTrade Capture Reporting
RepeatingTrdRepIndicatorsGrpTrade Capture Reporting
RepeatingUndInstrmtCollGrpCollateral Management
RepeatingUnderlyingAmountPosition Maintenance
Non-RepeatingUnderlyingLegInstrumentTrade Capture Reporting16
RepeatingUnderlyingLegSecurityAltIDGrpTrade Capture Reporting17

Messages

This section lists the post-trade messages and the category each of them belongs to.

MsgType(35)NameCategory
CQAccountSummaryReportAccount Reporting
BLAdjustedPositionReportPosition Maintenance
JAllocationInstructionAllocation
PAllocationInstructionAckAllocation
BMAllocationInstructionAlertAllocation
DUAllocationInstructionAlertRequestAllocation
DVAllocationInstructionAlertRequestAckAllocation
ASAllocationReportAllocation
ATAllocationReportAckAllocation
AWAssignmentReportPosition Maintenance
AYCollateralAssignmentCollateral Management
BBCollateralInquiryCollateral Management
BGCollateralInquiryAckCollateral Management
BACollateralReportCollateral Management
DQCollateralReportAckCollateral Management
AXCollateralRequestCollateral Management
AZCollateralResponseCollateral Management
AKConfirmationConfirmation
AUConfirmationAckConfirmation
BHConfirmationRequestConfirmation
BOContraryIntentionReportPosition Maintenance
CHMarginRequirementInquiryMargin Requirement Management
CIMarginRequirementInquiryAckMargin Requirement Management
CJMarginRequirementReportMargin Requirement Management
EAPayManagementReportPay Management
EBPayManagementReportAckPay Management
DYPayManagementRequestPay Management
DZPayManagementRequestAckPay Management
AMPositionMaintenanceReportPosition Maintenance
ALPositionMaintenanceRequestPosition Maintenance
APPositionReportPosition Maintenance
DLPositionTransferInstructionPosition Maintenance
DMPositionTransferInstructionAckPosition Maintenance
DNPositionTransferReportPosition Maintenance
oRegistrationInstructionsRegistration Instruction
pRegistrationInstructionsResponseRegistration Instruction
ANRequestForPositionsPosition Maintenance
AORequestForPositionsAckPosition Maintenance
AVSettlementInstructionRequestSettlement Instruction
TSettlementInstructionsSettlement Instruction
BQSettlementObligationReportSettlement Instruction
DXTradeAggregationReportTrade Management
DWTradeAggregationRequestTrade Management
AETradeCaptureReportTrade Capture Reporting
ARTradeCaptureReportAckTrade Capture Reporting
ADTradeCaptureReportRequestTrade Capture Reporting
AQTradeCaptureReportRequestAckTrade Capture Reporting
DCTradeMatchReportTrade Capture Reporting
DDTradeMatchReportAckTrade Capture Reporting

Common Components

Common components are components that are used within a single business area but across two or more categories. Common components are global if they are used across two or more business areas and are described in the overall Introduction of the normative specification of the application layer.

AllocCommissionDataGrp

This component a repeating group that is conceptually identical to the CommissionDataGrp component. It is used to carry commission information such as the type of commission and the rate at the allocation level. It provides a means to express commission applicable for the specified allocation account.

In messages where the CommissionDataGrp or CommissionData component exists at a “higher” level in the message than the allocation, those components should only be used for overall commission. The AllocCommissionLegRefID(2663) field is used to reference the LegID(1788) within the InstrumentLeg component, allowing for specifying instrument leg specific commission values when a multilegged security is fully expressed in the same message.

The component layout is available here.

AllocRegulatoryTradeIDGrp

This component is a repeating group that is conceptually identical to the RegulatoryTradeIDGrp component. It is used to report the source, value and relationship of multiple trade identifiers for the same trade allocation instance. This component may be used to meet regulatory trade reporting requirements where identifiers such as the Unique Trade Identifier (UTI) are required to be reported, showing the chaining of these identifiers as needed. The component layout is available here.

ClrInstGrp

This component is a repeating group that provides a simple list of ClearingInstructions(577) values. The component layout is available here.

CollateralAmountGrp

This component is a repeating group that may be used to provide the current value of the collateral type on deposit. The currency of the collateral value may be optionally included. The component layout is available here.

CollateralReinvestmentGrp

This component is a repeating group that may be used to provide a breakdown of the cash collateral’s reinvestment types and amounts (e.g. CollateralType(1704)=“CASH”). The component layout is available here.

DlvyInstGrp

This component is a repeating group that is used to convey one or more delivery instructions, including party and/or account information (SettlParties component), whenever full details of settlement instructions are provided (AllocSettlInstType(780) = 2). The component layout is available here.

ExecAllocGrp

This component is a repeating group that is part of the allocation instruction and report messages. It supports a list of execution and/or trade references and a few additional attributes such as the quantity, price, and capacity. The component layout is available here.

MarginAmount

This component is a repeating group that is used to convey one or more margin amounts for different margin types. The component layout is available here.

OrdAllocGrp

This component is a repeating group that is part of various allocation and confirmation messages. It supports a list of order references including list orders and only very few additional attributes such as the quantity or average price of the orders. The component layout is available here.

PositionAmountData

This component is a repeating group that is used to report netted amounts associated with position quantities. In the listed derivatives market the amount is generally expressing a type of futures variation or option premium. In the equities market this may be the net pay or collect on a given position. The component layout is available here.

SettlDetails

This component is a repeating group that is used to convey settlement account information with the SettlParties component and where the settlement instructions originated, e.g. from the broker. The component layout is available here.

SettlInstructionsData

This component is part of various collateral and confirmation messages and used to convey key information regarding standing settlement and delivery instructions. It also provides a reference to standing settlement details regarding the source, delivery instructions, and settlement parties. The component layout is available here.

SettlParties

This component is a repeating group that is conceptually identical to the Parties component. It is used within the context of settlement instruction messages to distinguish between parties involved in the settlement and parties who are expected to execute the settlement process. The component layout is available here.

SettlPtysSubGrp

This component is a repeating group that is part of the SettlParties component and conceptually identical to the PtysSubGrp. It is used to provide additional or supplemental information related to the instance of the settlement party identifier it is attached to. The component layout is available here.

TradeAllocAmtGrp

This component is a repeating group that is used to communicate the monetary amounts associated with allocated positions. This is the per-allocation portion of the per-trade amount specified in the PositionAmountData component. The component layout is available here.

TransactionAttributeGrp

This component is a repeating group that may be used to provide additional transaction attributes for the trade and other post-trade events. The component layout is available here.

Category – Allocation

This section provides an overview on how the FIX Protocol may be used to support the process of providing an allocation instruction together with the appropriate responses.

Note in all of the following, the term ‘Initiator’ is taken to mean the initiator of an AllocationInstruction(35=J) message and the ‘Respondent’ to mean the receiver of that message.

Allocation instructions can be communicated by the Initiator via three different options:

  1. Pre-allocated order – in this option the Initiator would communicate the allocation instructions within the NewOrderSingle(35=D) message when the order is placed with the Respondent.
  2. Pre-trade allocation – in this option the Initiator would communicate the allocation instructions to the Respondent in a separate message using the AllocationInstruction(35=J) message. The AllocationInstruction(35=J) message is sent after the order is placed with the Respondent but before the trade is completed by the Respondent.
  3. Post-trade allocation – in this option the Initiator would communicate the allocation instructions to the Respondent in a separate message using the AllocationInstruction(35=J) message after the trade has been completed by the Respondent.

Note the use of options 1 and 2 lends itself best to scenarios where the average price can be agreed up front (e.g. principal trades) or where the allocation account details need to be communicated prior to execution in certain markets.

Pre-Allocated Orders

In the pre-allocated order scenario, the Initiator would send a NewOrderSingle(35=D) message that includes the allocation information needed by the Respondent to allocate the trade once the trade is completed. This scenario consists of the following steps:

  • Initiator sends a NewOrderSingle(35=D) message specifying one or more AllocAccount(79) and AllocQty(80) values within the repeating group PreAllocGrp. The entire message will contain a single AllocID(70) which can be referenced in subsequent messages.
  • Respondent sends ExecutionReport(35=8) messages for the “New” (ExecType(150) = 0 (New)) and resulting fills (ExecType(150) = F (Trade)).
  • Respondent may optionally send an AllocationInstructionAck(35=P) with AllocStatus(87) = 3 (Received).
  • If there are errors in the allocation information it is possible to either:
    • reject the order or
    • to accept the order and reject the allocation details via the use of the AllocationInstructionAck(35=P) message (see pre-trade allocation option for detail of block level and account level reject. Either is possible here).
    • For example – one account cannot be identified, or the quantity of one allocation instance does not meet minimum quantity/minimum increment rules for the instrument, or the sum of allocated quantities does not equal the block trade quantity.
  • Respondent may optionally send an AllocationInstructionAck(35=P) with AllocStatus(87) = 0 (Accepted).
  • The next step is “Confirmation”, see Confirmation category.

Note where the average price or allocation quantity cannot be agreed up front but the allocation account details do need to be communicated prior to execution (e.g. for regulatory reasons), the AllocationInstruction(35=J) can optionally be used post execution in ‘Ready to Book’ mode to communicate the booking instruction (including average price) to the sell-side. As well as providing confirmation of the average price, this also supports the combination of orders for booking and allocation. If this is done, the Respondent should respond with AllocationInstructionAck(35=P) messages with AllocStatus(87) = 3 (Received), then 0 (Accepted).

Cancel/Replace Processing for Pre-Allocated Orders

The AllocID(70) on the NewOrderSingle(35=D) message is used to uniquely define the set of allocations contained within that order. If the order is replaced, the OrderCancelReplaceRequest(35=G) message should be formatted as follows:

  • If the order details are changing but the allocation details are not (e.g. change in limit price), the repeating group PreAllocGrp should not be populated.
  • If the allocation details are changing, the repeating group PreAllocGrp should be populated with the new complete set of allocation details with a new AllocID(70) value. This is regardless of whether the rest of the order details are changing or not. Examples of this are:
    • the order is being re-allocated into different accounts or
    • the order quantity (OrderQty(38)) is changing (in which case the AllocQty(80) allocated to each account will also need to change).

    This ensures that AllocID(70) is always unique on messages and therefore avoids any potential ambiguity arising from sharing different versions of allocation details for the same AllocID(70).

Pre-Trade Allocation

In the pre-trade allocation scenario, the Initiator would send the allocation instructions after placing the order but before the order had been completed. This scenario consists of the following steps:

  • Initiator sends a NewOrderSingle(35=D) message (containing no allocation details).
  • Initiator sends an AllocationInstruction(35=J) message. If the average price has been agreed up front, this should be present on the message (AvgPx(6)).
  • Respondent sends ExecutionReport(35=8) messages for the “New” (ExecType(150) = 0 (New)) and resulting fills (ExecType(150) = F (Trade)).
  • Respondent sends AllocationInstructionAck(35=P) with AllocStatus(87) = 3 (Received).
  • Before accepting the instruction, the Respondent should determine that all accounts are known, the quantity of each allocation instance meets minimum quantity/minimum increment rules for the instrument and the sum of allocated quantities equals the block trade quantity. If any error is found the Respondent must either:
    • reject the entire allocation using the AllocationInstructionAck(35=P) message with the appropriate reject reason code in AllocRejCode(88) together with AllocStatus(87) = 1 (Block level reject) or
    • reject the accounts that are in error using the AllocationInstructionAck(35=P) message with the appropriate reject reason code in AllocRejCode(88) together with AllocStatus(87) = 2 (Account level reject).

    In this latter event, the Initiator can send another AllocationInstruction(35=J) message with the correct instructions and information to the Respondent. This cycle can be repeated until the allocation is accepted by the Respondent.

  • If the Respondent accepts the allocation, an AllocationInstructionAck(35=P) message is sent to the Initiator with AllocStatus(87) = 0 (Accepted).
  • The next step is “Confirmation”,

In the pre-trade allocation scenario, the AllocationInstruction(35=J) message may be used for a number of purposes using AllocType(626) to indicate the type or purpose of the message, see FIXimate for details.

Note that the US domestic equities booking and allocation model (AllocType(626) = 1) includes the MiscFeesGrp component and NetMoney(118) whereas the non-US domestic booking and allocation model (AllocType(626) = 2 a.k.a. the “international equities model”) does not. AllocType(626) = 5 (Ready-To-Book single order) is used to indicate to the Respondent firm that one or a combined (aggregated) set of orders are “Ready-To-Book” without specifying individual account breakdowns. This may be used to trigger post-trade allocation, matching, and settlement processing via other channels (e.g. post-trade industry utilities).

Post-Trade Allocation

The post-trade allocation scenario is very similar to that given above for pre-trade allocation. In this scenario, the Initiator would send the allocation instructions to the Respondent after receiving the ExecutionReport(35=8) message indicating that the trade is completed.

The AllocationInstruction(35=J) message may be used for a number of purposes using AllocType(626) to indicate the type or purpose of the message, see FIXimate for details.

Post-trade allocation can be computed via one of two methods:

  1. Using average price: each AllocAccount(79) has a single AllocAvgPx(153)
  2. Using executed price: combination of each AllocAccount(79) and AllocPrice(366) (unique LastPx(31)) (e.g. Japan)

Ready-To-Book Processing

The Ready-To-Book capability of the AllocationInstruction(35=J) message is designed to provide a clean interface between the “trading” and “booking” spaces. This allows buy-side firms to both trigger and provide suitable references which can be passed down to assist in the matching process within industry utilities (e.g. Virtual Matching Utilities) or bilaterally with their sell-side counterparts. Bookable units can be single fills, combinations of fills, single orders, or groups of orders for the same security, side, settlement date, etc. Automated booking instructions can be communicated either pre-trade or post-trade.

Booking instructions can be communicated Pre-Trade (at the time the order is being placed) to convey that as soon as the order is filled it can be considered by the Respondent as ready for booking (in particular when there is no additional quantity behind).

Booking instructions can also be communicated Post-Trade (after fills have been received and processed) to signal that a particular order is now ready for booking or to signal that a set of orders for the same security, side, settlement date, etc. is to be aggregated as single booking unit which is now ready for booking.

Fragmentation of Allocation Messages

FIX allocation messages support fragmentation in a way similar to MassQuote(35=i) and the program trading messages, e.g. NewOrderList(35=E) messages. If there are too many entries within a repeating group to fit into one physical message, the entries can be continued in subsequent messages by repeating the principal message reference and other required fields, then continuing with the repeating group. This is achieved by optionally using TotNoAllocs(892) (giving the total number of AllocAccount(79) details across the entire allocation) that supplements NoAllocs(78) (giving the number of AllocAccount(79) details in a particular message fragment). TotNoAllocs(892) is repeated with the same value in all fragments of the batch. For example, an AllocationInstruction(35=J) message with 200 allocation account instances could be fragmented across three messages – the first two containing TotNoAllocs(892) = 200, NoAllocs(78) = 80 and the third TotNoAllocs(892) = 200, NoAllocs(78) = 40. To help the receiver reconstitute the batch LastFragment(893) = Y (boolean field) is sent in the last fragment.

For fragmented allocation events the receiving application must persist state between messages to determine whether all instances of the repeating group have been received before acting on the instruction or processing the report.

For this to work some key rules must be enforced:

  1. The sender must supply a consistent value for TotNoAllocs(892) in all related fragments and must use the same primary message reference in all fragments of the batch, e.g. AllocID(70) in AllocationInstruction(35=J).
  2. The sender must ensure that fragments are transmitted in order without intervening traffic.
  3. The repeating group AllocGrp must reach capacity only in the last fragment, and that message must contain LastFragment(893) = Y.
  4. The receiver must acknowledge every fragment received (AllocationInstructionAck(35=P) with AllocStatus(87) = 3 (received)) and never reject a non-last fragment; acknowledgment of the final fragment accepts or rejects the entire set.

There are a number of design suggestions for implementing fragmentation:

  1. Optional block-level fields supplied in early fragments need not be repeated in subsequent fragments. If they are repeated and the values are different, the receiver may choose to reject (on receiving the last fragment) or to apply the last received value to the event.
  2. If a message supports multiple repeating groups, e.g. OrdAllocGrp, ExecAllocGrp, AllocGrp in AllocationInstruction(35=J), the sender may distribute the array instances over any and all fragments, as long as the repeating group AllocGrp is not filled before the last fragment.
  3. The receiver must be able to abort collecting an incomplete array – either on expiration of a timer or the receipt of an unrelated message from the same counterparty.
FIX MessageTotal number of fieldrelated Number of fieldPrincipal message reference
AllocationInstruction(35=J)TotNoAllocs(892)NoAllocs(78)AllocID(70)
AllocationReport(35=AS)TotNoAllocs(892)NoAllocs(78)AllocReportID(755)

Maximum message size for fragmentation purposes can be determined by using the optional MaxMessageSize(383) in the Logon(35=A) message or by mutual agreement between counterparties.

Components

AllocAckGrp

This component is a repeating group that is used in messages with AllocStatus(87) = 2 (Account level reject), to provide details of the individual accounts that were accepted or rejected. In the case of a reject, the reasons for the rejection should be specified. The component layout is available here.

AllocGrp

This component is a repeating group that is part of the main allocation messages and conveys one or more allocation instructions. Each of these instructions can convey parties (e.g. settlement location), commissions and fees as well as clearing and settlement instructions. The component layout is available here.

Messages

Allocation Instructions

The AllocationInstruction(35=J) message provides the ability to specify how an order or set of orders should be subdivided amongst one or more accounts. In versions of FIX prior to version 4.4, this same message was known as the Allocation(35=J) message. Note in versions of FIX prior to version 4.4, the Allocation(35=J) message was also used to communicate fee and expense details from the sell-side to the buy-side. This role has now been removed from the AllocationInstruction(35=J) message and is now performed by the new (to version 4.4) AllocationReport(35=AS) and Confirmation(35=AK) messages.,The AllocationReport(35=AS) message should be used for the sell-side initiated allocation role as defined in previous versions of the protocol.

Note the response to the AllocationInstruction(35=J) message is the AllocationInstructionAck(35=P) message. In versions of FIX prior to version 4.4, the AllocationInstructionAck(35=P) message was known as the AllocationAck(35=P) message.

Allocation is typically communicated Post-Trade (after fills have been received and processed). It can, however, also be communicated Pre-Trade (at the time the order is being placed) to specify the account(s) and their respective order quantities which make up the order. This is a regulatory requirement in certain markets and for certain types of securities.

In the context of bilateral (buy-side to sell-side) communication, the buy-side firm should be the “Initiator” of an AllocationInstruction(35=J) message and a sell-side firm would be the “Respondent”. An AllocationInstruction(35=J) message can be submitted with AllocTransType(71) = 0 (New), 1 (Replace) or 2 (Cancel). The AllocType(626) field indicates the type or purpose of the message, see FIXimate for details.

It is possible either to specify, in AllocSettlInstType(780) as part of the AllocGrp component, full settlement instruction details on the AllocationInstruction(35=J) message, to provide a reference to a settlement instruction held on a database of such instructions or to instruct the receiving party to perform a specific action, see FIXimate for details.

General guidelines applicable to this message:

  • AllocID(70) should be unique for all allocation messages with AllocTransType(71) = 0 (New).
  • When submitting messages with AllocTransType(71) = 1 (Replace) or 2 (Cancel), RefAllocID(72) and AllocCancReplaceReason(796) are required.
  • To reject an AllocationInstruction(35=J) message, an AllocationInstructionAck(35=P) message with AllocStatus(87) = 1 (Block level reject) or 2 (Account level reject) should be used. AllocStatus(87) = 1 (Block level reject) means the entire message has been rejected (e.g. due to one or more of the orders not matching, average price mismatch). AllocStatus(87) = 2 (Account level reject) is used when the block level matches successfully but one or more (or all) of the constituent account level details failed validation (e.g. account not found, incorrect fees). In the latter case, the rejecting party can (optionally) notify the instructing party of those allocation details that are being rejected by listing the offending account IDs in the repeating group AllocAckGrp of the AllocationInstructionAck(35=P) message.
  • The correct response to an AllocationInstructionAck(35=P) message with AllocStatus(87) = 1 (Block level reject) is a new AllocationInstruction(35=J) message with AllocTransType(71) = 0 (New) (as the previous message has been rejected in its entirety). In the case of AllocStatus(87) = 2 (Account level reject), either the original AllocationInstruction(35=J) message should be cancelled (a new AllocationInstruction(35=J) message referencing the original in RefAllocID(72), with AllocTransType(71) = 2 (Cancel)) and reinstated (a second new AllocationInstruction(35=J) message with AllocTransType(71) = 0 (New)), or fully replaced (a new AllocationInstruction(35=J), referencing the original in RefAllocID(72), with AllocTransType(71) = 1 (Replace)). Note a replacement allocation message (AllocTransType(71) = 2 (Replace)) must contain all data for the replacement allocation message. It is the responsibility of the recipient of this message to identify which items have been changed.
  • It is permissible (though not mandatory) for the Respondent to reject an AllocationInstruction(35=J) message with AllocTransType(71) = 2 (Cancel) or 1 (Replace) if the AllocationInstructionAck(35=P) message with AllocStatus(87) = 0 (Accepted) has already been sent. Manual communication would then be required to effect the required changes. This approach would generally be required where the Respondent is using the generation of the AllocationInstructionAck(35=P) message with AllocStatus(87) = 0 (Accepted) to move the allocation details into downstream processing (e.g. confirmation generation), in which case a subsequent cancellation of or amendment to the allocation details may require the details to be retrieved from the downstream process.
  • Where amendment or cancellation of an AllocationInstruction(35=J) message has taken place out-of-band (i.e. manually or via some other means outside FIX), an AllocationReport(35=AS) message can be sent from the recipient of the allocation/cancellation to confirm back to the initiator that the relevant action has taken place.
  • Where settling in markets where multiple alternative settlement locations exist, it is recommended that the settlement location (equivalent to ISO15022 ‘PSET’ field) be identified on each allocation detail within the repeating group AllocGrp. A NestedParties component is provided, which may be used for this purpose.

The allocation message contains repeating fields for each order, sub-account and individual execution. The following specific guidelines are applicable to this message:

  • The total quantity allocated must equal the value in Quantity(53). If present, the total quantity in the execution section (repeating group ExecAllocGrp) must also be equal to this value. Note that the total quantity of the allocation does not necessarily have to equal the total quantity of the orders being allocated (repeating group OrdAllocGrp). Good examples of where this does not necessarily take place are GT (Good Till) orders, especially where multi-day average pricing is taking place. The quantity of each order being booked (OrderBookingQty(800)) must also be specified on the message. This will be equal to the order quantity (OrderQty(38)) if the entire order is being booked, though can be less if only part of the order is being booked. The sum of the order booking quantities must equal the value in AllocQty(80).
  • The number of sub-account instances is indicated in NoAllocs(78).
  • Multiple orders can be combined for allocation for AllocType(626) = 5 (Ready-To-Book) or 7 (Warehouse instruction). Note that combined orders must refer to the same instrument and have the same trade date, settlement date and side. The Instrument component as well as TradeDate(75), SettlDate(64), and Side(54) are hence on the root level of the message and not part of the repeating group OrdAllocGrp. The identification of the orders to be combined can be achieved in one of two ways:
    • By identifying the number of orders in NoOrders(73) and each individual order in OrderID(37). AllocNoOrdersType(857) = 1 (Explicit list provided) is used to denote that this is happening. If any orders were handled outside FIX, ClOrdID(11) must be set to ‘MANUAL’. Regardless of whether the orders were handled within or outside FIX, OrderQty(38) and OrderAvgPx(799) must also be specified for each order. This is to assist in validating the message and, for manual orders, to help identify the correct orders to book.
    • By stating that an unspecified group of orders is to be combined, e.g. when orders were manually delivered or otherwise not delivered over FIX. In this case set AllocNoOrdersType(857) = 1 (Explicit list provided) and NoOrders(73) = 1 with a single instance having ClOrdID(11) = “MANUAL”. Note that use of this approach is only recommended where either the number of orders being booked is extremely large or some kind of aggregation rule is being used.
  • Multiple executions can be combined for allocation by identifying the number of executions in NoExecs(124) and each individual execution in ExecID(17). Combined executions must refer to the same instrument, trade date, settlement date and side. The Instrument component as well as TradeDate(75), SettlDate(64), and Side(54) are hence on the root level of the message and not part of the repeating group ExecAllocGrp.
  • Except where AllocTransType(71) = 2 (Cancel) or where AllocNoOrdersType(857) = 0 (Not specified), the list of orders being booked or allocated must be specified by using their ClOrdID(11). If any orders were handled outside FIX, ClOrdID(11) must be set to ‘MANUAL’. Regardless of whether the orders were handled within or outside FIX, and where the orders are specified, OrderQty(38) and OrderAvgPx(799) must also be specified for each order. This is to assist in validating the message and, for manual orders, to help identify the correct orders to book.

The message layout is available here.

Allocation Instruction Acknowledgements

In versions of FIX prior to version 4.4, this message was known as the AllocationAck(35=P) message.

The AllocationInstructionAck(35=P) message is used to acknowledge the receipt of and provide status for an AllocationInstruction(35=J) message.

The status is indicated by AllocStatus(87) as follows:

AllocStatus valueDescription
3 = Received, not yet processedUsed to acknowledge receipt of an AllocationInstruction(35=J) message. This should always be followed by a second AllocationInstructionAck(35=P) message with AllocStatus(87) = 0, 1 or 2 as follows or an AllocationReport(35=AS) message.
0 = AcceptedThe AllocationInstruction(35=J) message has been validated and processed successfully.
1 = Block level rejectThe entire AllocationInstruction(35=J) message has been rejected. AllocRejCode(88) must be populated when performing a block level reject; this gives the reason for rejecting the AllocationInstruction(35=J) message.
2 = Account level rejectThe AllocationInstruction(35=J) message has been validated and one or more of the constituent account level details in the repeating group AllocGrp has failed validation (e.g. account not found). In this case, it is possible (though not mandatory) to include a list of the account level details that failed validation together with reject reasons.

For an AllocationInstructionAck(35=P) message with AllocStatus(87) = 0 (Accepted) in response to an AllocationInstruction(35=J) message with AllocType(626) = 1 (Calculated), it is recommended that MatchStatus(573) be used to denote whether any financial details provided in the AllocationInstruction(35=J) message were matched by the Respondent. If a match takes place and succeeds, then MatchStatus = 0 (Compared, matched, or affirmed). If the match takes place and fails, or no match takes place, then MatchStatus = 1 (Uncompared, unmatched, or unaffirmed). The message layout is available here.

Allocation Instruction Alerts

The AllocationInstructionAlert(35=BM) message is used in a 3-party allocation model where notification of group creation and group updates to counterparties is needed. The message will also carry trade information that comprised the group to the counterparties. The message layout is available here.

Allocation Instruction Alert Requests

The AllocationInstructionAlertRequest(35=DU) message is used in a clearinghouse 3-party allocation model to request for AllocationInstructionAlert(35=BM) messages from the clearinghouse. The request may be used to obtain a one-time notification of the status of an allocation group. The message layout is available here.

Allocation Instruction Alert Request Acknowledgements

The AllocationInstructionAlertRequestAck(35=DV) message is used in a clearinghouse 3-party allocation model to acknowledge a AllocationInstructionAlertRequest(35=DU) message for an AllocationInstructionAlert(35=BM) message from the clearinghouse. The message layout is available here.

Allocation Reports

Sent from sell-side to buy-side, sell-side to 3rd-party or 3rd-party to buy-side, the AllocationReport(35=AS) message (a.k.a. “Allocation Claim”) provides an account breakdown of an order or set of orders plus any additional follow-up front-office information developed post-trade during the trade allocation, matching and calculation phase. In versions of FIX prior to version 4.4, this functionality was provided through the Allocation(35=J) message. Depending on the needs of the market and the timing of “confirmed” status, the role of AllocationReport(35=AS) can be taken over in whole or in part by the Confirmation(35=AK) message.

Note the response to the AllocationReport(35=AS) message is the AllocationReportAck(35=AT) message. In versions of FIX prior to version 4.4, the AllocationAck(35=P) message served this purpose.

An AllocationReport(35=AS) message can be submitted with different values of AllocReportType(794), see FIXimate for details, such as the following examples.

  • 3 (Sell-side calculated using preliminary) which includes repeating group MiscFeesGrp (as part of repeating group AllocGrp), AccruedInterestAmt(159) and NetMoney(118)
  • 4 (Sell-side calculated without preliminary) which includes repeating group MiscFeesGrp (as part of repeating group AllocGrp), AccruedInterestAmt(159) and NetMoney(118). (AllocType(626) = 4 (…sent unsolicited by sell-side…) in versions of FIX prior to version 4.4, i.e. where the allocations have been provided via some other mechanism or agreed earlier in the order process.)
  • 5 (Warehouse recap) – sent unsolicited by sell-side, used to communicate confirmation and current status of any warehoused position in a particular stock

Settlement instructions are supported on the AllocationReport(35=AS) message to allow the Respondent (sell-side party or carry firm) to send an override of its own instructions to the Initiator.

General guidelines applicable to this message:

  • AllocReportID(755) should be unique for all AllocationReport(35=AS) messages.
  • To reject an AllocationReport(35=AS) message, an AllocationReportAck(AT) message with AllocStatus(87) = 1 (Block level reject) or 2 (Account level reject) should be used. AllocStatus(87) = 1 (Block level reject) means the entire message has been rejected (e.g. net money mismatch). AllocStatus(87) = 2 (Account level reject) is used when the block level matches successfully but one or more (or all) of the constituent account level details fails validation (e.g. account not found, incorrect fees). In the latter case, the rejecting party can (optionally) notify the instructing party of those allocation details that are being rejected by listing the offending account numbers in the repeating group AllocAckGrp of the AllocationInstructionAck(35=AT) message.
  • A rejected AllocationReport(35=AS) must be resolved out-of-band.
  • Where settling in markets where multiple alternative settlement locations exist, it is recommended that the settlement location (equivalent to ISO15022 ‘PSET’ field) be identified on each allocation detail within the repeating group AllocGrp. NestedParties component is provided, which may be used for this purpose.

The allocation message contains repeating fields for each order, sub-account and individual execution. The following specific guidelines are applicable to this message:

  • The number of sub-account instances is indicated in NoAllocs(78).
  • Multiple orders can be combined for allocation for AllocType(626) = 5 (Ready-To-Book) or 7 (Warehouse instruction). Note that combined orders must refer to the same instrument and have the same trade date, settlement date and side. The Instrument component as well as TradeDate(75), SettlDate(64), and Side(54) are hence on the root level of the message and not part of the repeating group OrdAllocGrp. The identification of the orders to be combined can be achieved in one of two ways:
    • By identifying the number of orders in NoOrders(73) and each individual order in OrderID(37). AllocNoOrdersType(857) = 1 (Explicit list provided) is used to denote that this is happening. If any orders were handled outside FIX, ClOrdID(11) must be set to ‘MANUAL’. Regardless of whether the orders were handled within or outside FIX, OrderQty(38) and OrderAvgPx(799) must also be specified for each order. This is to assist in validating the message and, for manual orders, to help identify the correct orders to book.
    • By stating that an unspecified group of orders is to be combined, e.g. when orders were manually delivered or otherwise not delivered over FIX. In this case set AllocNoOrdersType(857) = 1 (Explicit list provided) and NoOrders(73) = 1 with a single instance having ClOrdID(11) = “MANUAL”. Note that use of this approach is only recommended where either the number of orders being booked is extremely large or some kind of aggregation rule is being used.
  • Multiple executions can be combined for allocation by identifying the number of executions in NoExecs(124) and each individual execution in ExecID(17). Combined executions must refer to the same instrument, trade date, settlement date and side. The Instrument component as well as TradeDate(75), SettlDate(64), and Side(54) are hence on the root level of the message and not part of the repeating group ExecAllocGrp.

The message layout is available here.

Allocation Report Acknowledgements

The AllocationReportAck(35=AT) message (a.k.a. “Allocation Claim Acknowledgements”) is used to acknowledge the receipt of and provide status for an AllocationReport(35=AS) message.

It is possible that multiple AllocationReportAck(35=AT) messages can be generated for a single AllocationReport(35=AS) message to acknowledge the receipt and then to detail the acceptance or rejection of the AllocationReport(35=AS) message.

It is recommended, when appropriate, that MatchStatus(573) be used in the AllocationReportAck(35=AT) message to denote whether any financial details provided in the AllocationReport(35=AS) message with AllocStatus(87) = 0 (Accepted) were matched by the Initiator. If a match takes place and succeeds, then MatchStatus = 0 (Compared, matched, or affirmed). If the match takes place and fails, or no match takes place, then MatchStatus = 1 (Uncompared, unmatched, or unaffirmed). The message layout is available here.

Category – Confirmation

This section provides an overview on how the FIX Protocol may be used to support the process of Confirmation together with the appropriate responses.

A similar (and detailed) overview is also provided at the start of the category on FIX Allocations. These two overviews provide a summary on how FIX messaging may be used for booking, allocation and confirmation up to the start of settlement processing.

Components

CpctyConfGrp

This component is a repeating group that is used to convey the (possibly) different capacities of the firm executing the orders together with the related quantities. The component layout is available here.

MatchExceptionGrp

This component is a repeating group that is used to detail the matching exceptions and variances identified during the matching process based on the defined matching criteria and tolerances. The component layout is available here.

MatchingDataPointGrp

This component is a repeating group that is used to detail all the trade attributes and tolerances used for trade matching. The component layout is available here.

Messages

Confirmations

The Confirmation(35=AK) messages are used to provide individual trade level confirmations from the sell-side to the buy-side. In versions of FIX prior to version 4.4, this role was performed by the Allocation(35=J) message. Unlike the Allocation(35=J) message, the Confirmation(35=AK) message operates at an allocation account (trade) level rather than block level, allowing for the affirmation or rejection of individual confirmations.

This message is also used to report back the booking status (confirmation, rejection, exception) of each allocation instance. When the buy-side, in response, “affirms” with the ConfirmationAck(35=AU) message, the trade is ready to settle.

Because each message reports the details of a single “ticket”, account names, fees, net money, and settlement information are reported using fields designated for single-account trades.

Every Confirmation(35=AK) message has a unique ConfirmID(664). It is recommended that the sell-side system trade reference be used as ConfirmID(664) where possible, in order to enable the ConfirmID(664) to be used as a mutually understood trade reference (e.g. for use in manual conversations regarding specific trades).

The capacity or capacities of the firm executing the order or orders covered by this confirmation is represented in the repeating group CpctyConfGrp. This is to support confirmations covering orders executed under more than one capacity (e.g. a mixture of agency and principal execution). OrderCapacityQty(863) (inside this repeating group) gives the quantity executed under each OrderCapacity(528). The sum of the OrderCapacityQty(863) values must equal the confirmation’s AllocQty(80). The message layout is available here.

Confirmation Acknowledgements

The ConfirmationAck(35=AU) (a.k.a. “Affirmation”) message is used to respond to a Confirmation(35=AK) message. The message layout is available here.

Confirmation Requests

The ConfirmationRequest(35=BH) message is used to request a Confirmation(35=AK) message. The message layout is available here.

Category – Settlement Instruction

Components

SettlInstGrp

This component is a repeating group that is used to convey one or more settlement instructions and contains the Parties component as well as the SettlInstructionsData component. It provides the ability to maintain settlement instructions with the SettlInstTransType(163) field. The component layout is available here.

SettlObligationInstructions

This component is a repeating group that is used to convey one or more settlement obligations. It contains the Instrument and Parties components as well as the SettlDetails component to convey settlement account details. The component layout is available here.

Messages

Settlement Instruction Requests

The SettlementInstructionRequest(35=AV) message is used to request standing settlement instructions from another party. This could be:

  • A buy-side firm requesting standing instructions from a sell-side firm.
  • A sell-side firm requesting standing instructions from a buy-side firm.
  • A sell-side or buy-side firm requesting standing instructions from a third party central static data database.
  • A third party central static data database requesting standing instructions from a sell-side or buy-side firm.

Settlement instructions can be requested for any combination of the following parameters (in addition to the party whose instructions are being requested):

  • AllocAccount(79)
  • Country (of settlement) via Parties component (PartyID(448) with PartyIDSource(447) = E (ISO Country Code) and PartyRole(452) = 10 (Settlement location))
  • Side(54)
  • SecurityType(167) (and/or CFIcode(461))
  • SettlCurrency(120)
  • EffectiveTime(168) (i.e. all instructions valid at any time from this date/time)
  • ExpiryTime(126) (i.e. all instructions valid until this date/time)
  • LastUpdateTime(779) (i.e. all instructions created or updated since this date/time)

Alternatively, settlement instructions can be queried by reference to a database of standing instructions using the identifiers of that database as follows:

  • StandInstDbType(169) – Database identifier (e.g. DTC SID)
  • StandInstDbName(170) – Database name (i.e. the Global Custodian’s name)
  • StandInstDbID(171) – ID of the settlement instructions on this database

The response to such a request should be a SettlementInstructions(35=T) message with SettlInstTransType(163) = N (New) containing all SSIs meeting the criteria specified in the SettlementInstructionRequest(35=AV) message. If the request cannot be processed, the request should be rejected with a SettlementInstruction(35=T) message with SettlInstMode(160) = 5 (Request reject). Similarly, if the request returns no data, the request should be rejected with a SettlementInstruction(35=T) message with SettlInstReqRejCode(792) = 2 (No matching settlement instructions found). The message layout is available here.

Settlement Instructions

The SettlementInstructions(35=T) message provides the broker’s, the institution’s, or the intermediary’s instructions for trade settlement. This message has been designed so that it can be sent from the broker to the institution, from the institution to the broker, or from either to an independent “standing instructions” database or matching system or, for CIV, from an intermediary to a fund manager.

The SettlementInstructions(35=T) message may be used in one of three modes (SettlInstMode(160)):

  1. SettlInstMode(160) = 1 to provide “standing instructions” for the settlement of trades occurring in the future. The message could either be sent in an ‘unsolicited’ fashion (i.e. a ‘push’-style update from one firm to that firm’s counterparties) or in response to a SettlementInstructionRequest(35=AV) message. In either of these scenarios, this message can provide multiple settlement instructions.
  2. SettlInstMode(160) = 5 to reject a SettlementInstructionRequest(35=AV) message (e.g. unable to process request, no matching settlement instructions found).
  3. SettlInstMode(160) = 4 to provide settlement instructions for a specific order with a single account either as overriding or standing instructions to support matching. ClOrdID(11) should be used to link the settlement instructions to the corresponding order.

The SettlementInstructions(35=T) message detail can be either explicitly specified (via the SettlInstructionsData component as part of the repeating group SettlInstGrp) or can exist within an independent standing instructions database and can be referenced via StandInstDbType(169), StandInstDbName(170), and StandInstDbID(171). The message layout is available here.

Settlement Obligation Reports

The SettlementObligationReport(35=BQ) message provides a central counterparty, institution, or individual counterparty with a capacity for reporting the final details of a currency settlement obligation. The settlement obligation is intended to be used for auxiliary reporting of settlement details that will be conducted over SWIFT or CLS in order to affect the instructions. The SettlementObligationReport(35=BQ) message is designed to allow multiple FX deals to be aggregated and netted into a single instruction to simplify the reporting process.

The SettlementObligationReport(35=BQ) message may be used in one of two modes:

  1. SettlObligMode(1159) = 1 (Preliminary) – the instructions have been generated prior to final cutoff and information is still subject to change up until cutoff has been reached
  2. SettlObligMode(1159) = 2 (Final) – the instructions have been generated with final settlement information which cannot subsequently be changed for the current settlement period

The message layout is available here.

Category – Trade Capture Reporting

Trade capture (a.k.a. “Streetside”) reporting allows sell-side firms (broker, exchange, ECN, central counter parties) to provide timely reporting of completed trades to parties involved in a trade as well as to external entities not involved in the execution of the trade. Trade capture reporting has been designed for several uses including sell-side trade reporting into an exchange or ECN, trade confirmation reporting by an exchange or clearing organization, and end of day trade reporting via static data files. For example, in the United States OCC (Options Clearing Corporation) and CME (Chicago Mercantile Exchange) both make extensive use of the TradeCaptureReport(35=AE) message for trade management, trade confirmation reporting, and end of day trade reconciliation via static data file. As settlement cycles reduce, such communication must be closer to real-time vs. an end-of-the day batch process. The TradeCaptureReport(35=AE) and TradeCaptureReportRequest(35=AD) messages have been designed to facilitate such communication.

Trade capture reporting has been expanded to include support for two-party (sell-side – buy-side) and three-party (sell-side – exchange/clearing house/VMU – buy-side) communication. Matched trades, unmatched trades, transfer, block trades, and exchange for physical (EFP) trades are supported.

Trade Capture Report Usages

TradeCaptureReport(35=AE) messages are used for various purposes including:

  • Relaying confirmed trades to various parties not directly involved in the execution, e.g. CSD’s, clearing houses, clearing firms and regulatory bodies. Those messages are outbound (from the marketplace).
  • Relaying confirmed trades to counterparties of the trade. Where ExecutionReport(35=8) messages may be sufficient for front-office purposes, TradeCaptureReport(35=AE) messages can serve more demanding back-office processes better. Those messages are outbound (from the marketplace).
  • Reporting of privately negotiated (“street-side”) trades, i.e. trades formed outside of the marketplace. Those messages are inbound (to the marketplace) but may also be used as outbound (when the marketplace relays them to counterparties).
  • Reporting of trades executed on the floor or from an automated order routing mechanism. These messages are inbound.
  • Requesting a cancellation or amendment of a confirmed trade. Those messages are inbound (to the marketplace) but may also be used as outbound (when the marketplace relays them to counterparties).

In Exchange, ECN and Central Counter Party models, a trade capture report process ends with a confirmed trade. The process is triggered by a request to register a new trade, replace a trade or cancel a trade. The process can involve the counterparty and / or a marketplace official acknowledgement and can therefore take some time. During this time, the initiator may change his mind and withdraw or request a change to the request.

The following rules apply to TradeCaptureReport(35=AE) message identifiers:

  • TradeReportID(571) is assigned by the submitter of the message and used as a pure message identifier.
  • TradeID(1003) is assigned by the marketplace when it records a confirmed trade. It should be noted that some marketplaces will assign the TradeID(1003) earlier in the process, meaning that (in the case of sequential ID assignment) there will be gaps when a trade is not completed.
  • TradeReportRefID(572) is assigned by the submitter when it wants to link a new message to a previous message. This would normally apply only when it requests a replace or cancel of an ongoing process (i.e. the marketplace has not yet recorded the confirmed trade) and when the marketplace issues confirmed trades ending the process of reporting and acknowledging a privately negotiated trade.
  • SecondaryTradeID(1040) can be assigned by the marketplace as an identifier for the process leading to a confirmed trade. It may be used by the submitter as an alternative to TradeReportRefID(572) in a cancel or replace. Note that a prerequisite to use the SecondaryTradeID(1040) is that the marketplace issues TradeCaptureReportAck(35=AR) messages providing that tag.

Components

AveragePriceDetail

This component may be used to provide average pricing details in a trade report, including the average pricing model used and the start and end times of the averaging period. The component layout is available here.

InstrmtMatchSideGrp

This component is a repeating group used to convey all trades for a given match event reported by instrument and trade side. Each trade match report can contain any number of trades for any number of instruments. This component contains all instruments together with all of the trade sides (possibly more than two) that occurred for each instrument within the same match event. The component layout is available here.

LegPositionAmountData

This component is a repeating group that is conceptually identical to PositionAmountData. It is used to report netted amounts associated with position quantities. In the listed derivatives market the amount is generally expressing a type of futures variation or option premium. In the equities market this may be the net pay or collect on a given position. The component layout is available here.

MandatoryClearingJurisdictionGrp

This component is a repeating group that may be used to specify the set of jurisdictions to which mandatory clearing applies. The component layout is available here.

RelatedPositionGrp

This component is a repeating group that may be used to identify positions that are related to each other or to other trades. This should not be used in lieu of explicit FIX fields that denote specific semantic relationships, but rather should be used when no such fields exist. The component layout is available here.

SideCollateralAmountGrp

This component is a repeating group that is part of the TrdCapRptSideGrp component. It is used to provide the current value of the collateral type on deposit for a side of the trade report. The currency of the collateral value may be optionally included. The component layout is available here.

SideCollateralReinvestmentGrp

This component is a repeating group that is part of the SideCollateralAmountGrp component. It may be used to provide a breakdown of the cash collateral’s reinvestment types and amounts (e.g. SideCollateralType(2701)=“CASH”). The component layout is available here.

SideRegulatoryTradeIDGrp

This component is a repeating group that is part of the TrdCapRptSideGrp component and conceptually identical to the RegulatoryTradeIDGrp component. The component layout is available here.

SideTrdRegTS

This component is a repeating group that may be used to convey trading or regulatory timestamps specific to one side of the trade. It is a subset of the TrdRegTimestamps component. The component layout is available here.

TradeCapLegUnderlyingsGrp

This component is a repeating group that may be used to convey one or more underlying instruments for a given leg of a trade by means of the UnderlyingLegInstrument component. The component layout is available here.

TradePositionQty

This component is a repeating group that is used to specify, for a single trade side, the various types of position quantities in the position’s life-cycle including start-of-day, intraday, trade, adjustments, and end-of-day position quantities. The component layout is available here.

TradeQtyGrp

This component is a repeating group that is used to convey quantities of the trade that have been processed and the type of processing that has occurred for that trade quantity. The component layout is available here.

TradeReportOrderDetail

This component is used to convey some of the attributes of the order that was executed and resulted in the given trade side. It supports individual attributes such as order identifiers as well as the OrderQtyData and DisplayInstruction components. The component layout is available here.

TrdAllocGrp

This component is used to convey one or more trade allocations for a given side of the trade. It is small subset of the AllocGrp supporting basic allocation information, including the NestedParties2 component for parties and/or accounts in addition to AllocAccount(79). The component layout is available here.

TrdCapDtGrp

This component is a repeating group that is used to convey one or two dates and (optional) timestamps as filter criteria for the request. Two dates (possibly with times) represent a time range. The component layout is available here.

TrdCapRptAckSideGrp

This component is a repeating group that is used to acknowledge the information received for one or both sides of a single or multileg trade. It is almost identical to the TrdCapRptSideGrp component but formally only a subset. The component layout is available here.

TrdCapRptSideGrp

This component is a repeating group that is used to convey one or both sides of a single or multileg trade. It contains a large number of components to convey information such as parties, allocations, commissions, fees, stipulations, clearing instructions, settlement details, timestamps as well as information related to the order that was traded. The component layout is available here.

TrdInstrmtLegExecGrp

This component is a repeating group that comprises individual executions for legs of the trade side of a trade match report for a specific instrument. The component layout is available here.

TrdInstrmtLegGrp

This component is a repeating group that is used to convey execution information of a multileg instrument on a leg level. It is similar to the InstrmtLegExecGrp component in the ExecutionReport(35=8) message. The component layout is available here.

TrdMatchSideGrp

This component is a repeating group used to convey all trade sides for a single instance of the InstrmtMatchSideGrp component. The component layout is available here.

TrdRepIndicatorsGrp

This component is a repeating group that is used to convey one or more types of parties (TrdRepPartyRole(1388)) to whom the trade should be reported or not. It supports a white list as well as a black list of recipient types. It does not identify individual parties. The component layout is available here.

UnderlyingLegInstrument

This component is used to convey a single underlying instrument. It is a small subset of the InstrumentLeg component. The component layout is available here.

UnderlyingLegSecurityAltIDGrp

This component is a repeating group that is used to convey one or more alternate identifiers for the underlying of the given leg instrument. The component layout is available here.

Messages

Trade Capture Report Requests

The TradeCaptureReportRequest(35=AD) message may be used to:

  • Request one or more trade capture reports based upon selection criteria provided on the trade capture report request
  • Subscribe for trade capture reports based upon selection criteria provided on the trade capture report request.

The following (non-exhaustive) list of criteria can be specified on the TradeCaptureReportRequest(35=AD) message:

  • All trades matching specified trade identification: TradeReportID(571), TradeID(1003), SecondaryTradeID(1040), FirmTradeID(1041), SecondaryFirmTradeID(1042)
  • All trades matching specified trade types: TrdType(828), TrdSubType(829), TransferReason(830), SecondaryTrdType(855), TradeLinkID(820)
  • All trades matching the order identification information: OrderID(37), ClOrdID(11), ExecID(17)
  • Trades that have specified MatchStatus(573)
  • All trades for the party defined in the Parties component (use PartyID(448) and PartyIDSource(447))
    • This can be a trader id, firm, broker id, clearing firm (use mandatory PartyRole(452) to define the kind of party)
  • All trades for a specific instrument, specified using the Instrument component, the UnderlyingInstrument component, and/or the InstrumentLeg component inside the InstrmtLegGrp component.
  • All unreported trades (TradeRequestType(569) = 3) – Executions that have not been sent
  • All unmatched trades (TradeRequestType(569) = 2) – Trades that have not been matched
  • All trades matching specific date (ClearingBusinessDate(715)) and trading session criteria (TradingSessionID(336) and TradingSessionSubID(625))
  • Trades entered via a specific TradeInputSource(578)
  • Trades entered via a specific TradeInputDevice(579)
  • All advisories (TradeRequestType(569) = 4)

When using TradeRequestType(569) = 1, each field in the TradeCaptureReportRequest(35=AD) (other than TradeRequestID(568) and SubscriptionRequestType(263)) identify filters – trade reports that satisfy all specified filters will be returned. Note that the filters are combined using an implied “and” – a trade report must satisfy every specified filter to be returned.

The optional date or time range-specific filter criteria (within repeating group TrdCapDtGrp) may be used in one of two modes:

  • “Since” a time period. NoDates(580) = 1 with first TradeDate(75) (and optional TransactTime(60)) indicating the “since” (greater than or equal to operation) point in time.
  • “Between” time periods. NoDates(580) = 2 with first TradeDate(75) (and optional TransactTime(60)) indicating the “beginning” (greater than or equal to operation) point in time and the second TradeDate(75) (and optional TransactTime(60)) indicating the “ending” (less than or equal to operation) point in time.

TradeCaptureReport(35=AE) messages are the normal return type to a TradeCaptureReportRequest(35=AD) message.

The response to a TradeCaptureReportRequest(35=AD) message can be:

  • One or more TradeCaptureReport(35=AE) messages
  • A TradeCaptureReportRequestAck(35=AQ) message followed by zero or more TradeCaptureReport(35=AE) messages in two specific cases:
    • When the TradeCaptureReport(35=AE) messages are being delivered out-of-band (such as a file transfer),
    • When there is a processing delay between the time of the request and when the reports will be sent (for instance in a distributed trading environment where trades are distributed across multiple trading systems).
  • A TradeCaptureReportRequestAck(35=AQ) message only
    • When no trades are found that match the selection criteria specified on the TradeCaptureReportRequest(35=AD) message,
    • When the TradeCaptureReportRequest(35=AD) message was deemed invalid for business reasons by the counterparty.

The message layout is available here.

Trade Capture Report Request Acknowledgements

The TradeCaptureReportRequestAck(35=AQ) message is used to:

  • Provide an acknowledgement to a TradeCaptureReportRequest(35=AD) message in the case where theTradeCaptureReportRequest(35=AD) message is used to specify a subscription or delivery of reports via an out-of-band response transmission method.
  • Provide an acknowledgement to a TradeCaptureReportRequest(35=AD) message in the case when the return of the TradeCaptureReport(35=AE) messages matching that request will be delayed or delivered asynchronously. This is useful in distributed trading system environments.
  • Indicate that no trades were found that matched the selection criteria specified on the TradeCaptureReportRequest(35=AD) message (TotNumTradeReports(748) = 0).
  • The TradeCaptureReportRequest(35=AD) message was invalid for some business reason, such as request is not authorized, invalid or unknown instrument, party, trading session, etc. (use TradeRequestResult(749)).

NOTE: A TradeCaptureReportRequestAck(35=AQ) message is not required if one or more TradeCaptureReports(35=AE) will be returned in-band immediately.

The message layout is available here.

Trade Capture Reports

The TradeCaptureReport(35=AE) message can be:

  • Used to report trades between counterparties.
  • Used to report trades to a trade matching system
  • Can be sent unsolicited between counterparties.
  • Sent as a reply to a TradeCaptureReportRequest(35=AD).
  • May be used to report unmatched and matched trades.

The message layout is available here.

Trade Capture Report Acknowledgements

The TradeCaptureReportAck(35=AR) message can be:

  • Used to acknowledge trade capture reports received from a counterparty
  • Used to reject a trade capture report received from a counterparty

The message layout is available here.

Trade Match Reports

The TradeMatchReport(35=DC) message is used by exchanges, trading venues and ECNs to report matched trades to central counterparties (CCPs) as an atomic event. The message is used to express the one-to-one, one-to-many and many-to-many matches as well as implied matches in which more complex instruments can match with simpler instruments. The message layout is available here.

Trade Match Report Acknowledgements

The TradeMatchReportAck(35=DD) is used to respond to the TradeMatchReport(35=DC) message. It may be used to report on the status of the request (e.g. accepting the request or rejecting the request). The message layout is available here.

Category – Registration Instruction

Components

RgstDistInstGrp

This component is a repeating group that is used to convey one or more distribution instructions containing information such as the payment method and various attributes of a cash distribution involving an agent bank. The component layout is available here.

RgstDtlsGrp

This component is a repeating group that is used to convey one or more registration details such as contact information. Note that some of the individual fields in this component such as address details are redundant when using the embedded NestedParties component. The component layout is available here.

Messages

Registration Instructions

The RegistrationInstructions(35=o) message type may be used by institutions or retail intermediaries wishing to electronically submit registration information to a broker or fund manager (for CIV) for an order or for an allocation.

A RegistrationInstructions(35=o) message can be submitted with RegistTransType(514) = 0 (New), 1 (Replace), or 2 (Cancel). The RegistTransType(514) field indicates the purpose of the message. RegistRefID(508) is required when replacing or cancelling registration instructions. Replacement RegistrationInstructions(35=o) messages must contain all data for the replacement registration.

The RegistrationInstructions(35=o) message contains the repeating group RgstDtlsGrp for multiple joint registrants. The number of registration details instances is indicated in NoRegistDtls(473). The message layout is available here.

Registration Instructions Responses

The RegistrationInstructionsResponse(35=p) message type may be used by broker or fund manager (for CIV) in response to a RegistrationInstructions(35=o) message submitted by an institution or retail intermediary for an order or for an allocation.

The RegistrationInstructionsResponse(35=p) message is used to:

  1. confirm the receipt of a RegistrationInstructions(35=o) message
  2. confirm changes to an existing RegistrationInstructions(35=o) message (i.e. accept cancel and replace requests)
  3. relay registration instructions status information
  4. relay assigned client and account IDs for RegistrationInstructions(35=o) messages with RegistTransType(514) = 0 (New)
  5. reject RegistrationInstructions(35=o) messages

Each RegistrationInstructionsResponse(35=p) message contains RegistStatus(506) which is used to communicate the current state of the registration instructions as understood by the broker or fund manager. The registration instruction statuses are as follows (in highest to lowest precedence):

RegistStatus(506)Description
A = AcceptedRegistration details are acceptable to the receiving broker, intermediary or fund manager. Assigned client and account IDs may be returned.
R = RejectedRegistration details have been rejected by the receiving broker, intermediary or fund manager.
H = HeldRegistration details have been held by the receiving broker, intermediary or fund manager. Assigned (possibly provisional) client and account Ids may be returned.
N = ReminderRegistration details are still outstanding.

The message layout is available here.

Category – Position Maintenance

Clearing Services for Position Management

The Position Management Clearing Services may be used to invoke the following business functions. If requested, message-based response confirmations will be provided to the client.

  1. Position Change Submission (Final Position Instructions)
  2. Position Adjustment
  3. Exercise Notice
  4. Abandonment Notice
  5. Margin Disposition
  6. Position Pledge
  7. Request for Position

Clearing Services for Post-Trade Processing

The Post-Trade Processing Clearing Services may be used to invoke the following business functions. If requested, message-based response confirmations will be provided to the client.

  1. ETP message format: Trade Change
  2. Give-up message format: Allocation, Accept, Reject, Release, Change, Delete
  3. Exchange for Physical (EFP) message format: Allocation, Accept, Reject, Change, Delete
  4. Average Price (APS) message format: Allocation, Accept, Change, Delete
  5. Mutual Offset (MOS) message format: Allocation, Accept, Reject, Change, Delete
  6. Trade Entry Edit message format: Trade Add, Transfer, Change

Components

ExpirationQty

This component is a repeating group that is used to convey one or more types of contrary expiration quantities when expiring options are to be exercised differently from the normal assignment process. The component layout is available here.

PositionQty

This component is a repeating group that is part of various position and assignment messages and required in most of them. It specifies the various types of position quantity in the position life-cycle including start-of-day, intraday, trade, adjustments, and end-of-day position quantities. Quantities are expressed in terms of long and short quantities. It also contains the NestedParties component to associate or distribute a position to a specific party other than the party that currently owns the position. The component layout is available here.

PosUndInstrmtGrp

This component is a repeating group that is used to convey one or more underlying instruments for the main instrument in the message. It is similar to the UndInstrmtGrp component but can contain additional information related to the settlement as well as to pay and collect amounts. The component layout is available here.

UnderlyingAmount

This component is a repeating group that is used to convey the underlying amounts, dates, settlement status and method for derivative positions. The component layout is available here.

Messages

Assignment Reports

AssignmentReport(35=AW) messages are sent from a clearing house to counterparties, such as a clearing firm as a result of the assignment process.

AssignmentReport(35=AW) messages can be sent unsolicited from the clearing house to a clearing firm.

AssignmentReport(35=AW) messages can be returned in response to a RequestForPositions(35=AN) message with PosReqType(724) = 3 (Assignments).

The message layout is available here.

Contrary Intention Reports

The ContraryIntentionReport(35=BO) message is used for reporting of contrary expiration quantities for options expiring on a Saturday. This information is required by options exchanges for regulatory purposes. The message layout is available here.

Position Maintenance Requests

The PositionMaintenanceRequest(35=AL) message allows the position owner to submit requests to the holder of a position which will result in a specific action being taken which will affect the position. Generally, the holder of the position is a central counter party or clearing organization but can also be a party providing investment services. Submission of a request may result in the following:

  • adjustment of both the long and short start of day position quantity
  • exercise of an option position into a position in the instrument underlying the option
  • abandonment of an option position that would otherwise exercise
  • netting of current day trades to change to the end of day long and short position
  • spreading of a position against other position in order to reduce margin requirements
  • pledge of a position for collateral purposes
  • large trader submission of the long and short quantities

The request may be submitted with PosMaintAction(712) = 1 (New), 2 (Replace), 3 (Cancel), or 4 (Reverse) and may refer to a specific position or a previously submitted message (OrigPosReqRefID(713) or PosMaintRptRefID(714)). The request is always submitted as of a specific date (ClearingBusinessDate(715)) which is therefore required. The parties both owning and holding the position are specified in the Parties component. The message layout is available here.

Position Maintenance Reports

The PositionMaintenanceReport(35=AM) message is sent by the holder of a position in response to a PositionMaintenanceRequest(35=AL) message and is used to confirm that a request has been successfully processed or rejected (PosMaintStatus(722)). The message layout is available here.

Position Reports

The PositionReport(35=AP) message is returned by the holder of a position in response to a RequestForPositions(35=AN) message. The purpose of the message is to report all aspects of a position and may be provided on a standing basis to report end of day positions to an owner. The message layout is available here.

Position Report Adjustments

The AdjustedPositionReport(35=BL) message is used to report changes in position, primarily in equity options, due to modifications to the underlying due to corporate actions. The message layout is available here.

Position Transfer Instructions

The PositionTransferInstruction(35=DL) message is sent by clearing firms to CCPs to initiate position transfers, or to accept or decline position transfers. The message layout is available here.

Position Transfer Instruction Acknowledgements

The PositionTransferInstructionAck(35=DM) message is sent by CCPs to clearing firms to acknowledge position transfer instructions, and to report errors processing position transfer instructions. It is intended to be a technical acknowledgment, not a business level acknowledgment which would instead be provided by the PositionTransferReport(35=DN) message. As such, TransferID(2437), a business level ID assigned by the CCP, need not be assigned when providing a technical acknowledgment to a new or rejected position transfer request. The message layout is available here.

Position Transfer Reports

The PositionTransferReport(35=DN) message is sent by CCPs to clearing firms indicating of positions that are to be transferred to the clearing firm, or to report on the status of the transfer to the clearing firms involved in the transfer process. The message layout is available here.

Requests For Positions

The RequestForPositions(35=AN) message is used by the owner of a position to request a PositionReport(35=AP) message from the holder of the position, usually the central counter party or clearing organization. The request can be made at several levels of granularity (e.g. only positions, trades, exercises, assignments, settlement activity) by means of PosReqType(724).

The message is used to request a one time snapshot of positions or to subscribe to updates as they occur using the SubscriptionRequestType(263). The ResponseTransportType(725) may be used to specify if the reports are to be sent in-band over the session transport or out-of-band over an alternative transport such as FTP. The message layout is available here.

Request for Positions Acknowledgements

The RequestForPositionsAck(35=AO) message is returned by the holder of the position in response to a RequestForPositions(35=AN) message. The purpose of the message is to acknowledge that a request has been received and is being processed. The message layout is available here.

Category – Collateral Management

The set of collateral management messages is used to manage collateral associated with positions resulting from trading activity. The collateral management messages have been designed to address both two-party and three-party interaction. The two-party model addresses communication between two counterparties to a trade. The three-party model supports communication involving an intermediary acting as a facilitator or guarantor to the trade, such as a clearing house or ATS.

Collateral Management Usage

Collateral management messages have been designed for the following uses:

  • Securities financing (such as repurchase agreements and securities lending)
  • Clearing House collateralization

Components

CollInqQualGrp

This component is a repeating group that is used to convey one or more qualifiers as filter criteria by means of CollInquiryQualifier(896). The component layout is available here.

ExecCollGrp

This component is a repeating group that is part of the various collateral messages to convey one or more references to executions. The component layout is available here.

FundingSourceGrp

This component is a repeating group that is used to specify the funding source(s) used to finance a margin loan or collateralized loan. The component layout is available here.

TrdCollGrp

This component is a repeating group that is part of the various collateral messages to convey one or more references to trades. The component layout is available here.

UndInstrmtCollGrp

This component is a repeating group that is used to convey one or more underlying instruments for the main instrument in the message. It is an extension of the UndInstrmtGrp component as it also provides the ability to maintain the underlying instruments of the collateral with the CollAction(944) field. The component layout is available here.

Messages

Collateral Requests

An initiator that requires collateral from a respondent sends a CollateralRequest(35=AX) message. The initiator can be either counterparty to a trade in a two-party model or an intermediary such as an ATS or clearinghouse in a three-party model. A CollateralAssignment(35=AY) message is expected as a response to a request for collateral. The message layout is available here.

Collateral Assignments

A CollateralAssignment(35=AY) message is used to assign collateral to cover a trading position. This message can be sent unsolicited or in reply to a CollateralRequest(35=AX) message. The response to a CollateralAssignment(35=AY) message is a CollateralResponse(35=AZ) message.

The CollateralAssignment(35=AY) message may be used to perform the following:

  • Assign initial collateral
  • Replenish collateral
  • Replace/substitute collateral

The message layout is available here.

Collateral Responses

A CollateralResponse(35=AZ) message is used to respond to a CollateralAssignment(35=AY) message. The message layout is available here.

Collateral Reports

A CollateralReport(35=BA) message is used to report collateral status when responding to a CollateralInquiry(35=BB) message. The message layout is available here.

Collateral Report Acknowledgements

A CollateralReportAck(35=DQ) message is used as a response to the CollateralReport(35=BA) message. It may be used to reject a CollateralReport(35=BA) message when the content of the report is invalid based on the business rules of the receiver. The message may also be used to acknowledge receipt of a valid CollateralReport(35=BA) message. The message layout is available here.

Collateral Inquiries

A CollateralInquiry(35=BB) message is used to inquire for collateral status. It supports multiple criteria. The response to a CollateralInquiry(35=BB) is one or more CollateralReport(35=BA) messages. The message layout is available here.

Collateral Inquiry Acknowledgements

A CollateralInquiryAck(35=BG) message is used to respond to a CollateralInquiry(35=BB) message in the following situations:

  • When the CollateralInquiry(35=BB) message will result in an out-of-band response (such as a file transfer).
  • When the inquiry is otherwise valid but no collateral is found to match the criteria specified on the CollateralInquiry(35=BB) message.
  • When the CollateralInquiry(35=BB) message is invalid based upon the business rules of the counterparty.

The message layout is available here.

Category – Margin Requirement Management

The set of messages in this category is used to manage margin requirements and communicate the risk of a portfolio held for example at a CCP. The margin (e.g. total liability or performance bond) reflects this risk.

Components

MarginReqmtInqQualGrp

This component is a repeating group that is used to convey the requested content of the MarginRequirementReport(35=CJ) messages in response to a margin inquiry. The component layout is available here.

Messages

Margin Requirement Inquiries

A MarginRequirementInquiry(35=CH) message is used to initiate a margin requirement inquiry for a margin account. The inquiry may be submitted at the detail level or the summary level. It can also be used to inquire margin excess/deficit or net position information. Margin excess/deficit will provide information about the surplus or shortfall compared to a point in time from the past, e.g. the previous trading day or a more recent margin calculation. An inquiry for net position information will trigger one or more PositionReport(35=AP) messages instead of one or more MarginRequirementReport(35=CJ) messages.

If the inquiry is made at the detail level, the instrument must be specified with the desired level of detail. If the inquiry is made at the summary level, the instrument is not provided, implying a summary request is being made. For example, if the inquiring firm specifies SecurityType(167) = “FUT” in the Instrument component, then a detail report will be generated containing the margin requirements for all futures positions for the inquiring account. Similarly, if the inquiry is made at the summary level, the report will contain the total margin requirement aggregated to the level of each of the margin accounts. The message layout is available here.

Margin Requirement Inquiry Acknowledgements

A MarginRequirementInquiryAck(35=CI) message is used to respond to a MarginRequirementInquiry(35=CH) message. The message layout is available here.

Margin Requirement Reports

A MarginRequirementReport(35=CJ) message is used to return information about margin requirements either as on overview across all margin accounts or on a detailed level due to the inquiry making use of the optional Instrument component. Application sequencing may be used to support the re-request of a range of reports. The message layout is available here.

Category – Account Reporting

The messages in this category are used to manage account type level reporting; typically communicated to clearing firms by the clearinghouse.

Components

PayCollectGrp

This component is a repeating group that is intended to report individual pay/collect items to be considered when calculating net settlement.

A Pay/Collect is a payment or collection of funds by the clearing house to/from a clearing firm for a specific reason. Pay/Collects are typically netted to a single amount and factored into the firm’s daily net settlement. The currency of the pay/collect amount may be optionally included. The component layout is available here.

SettlementAmountGrp

This component is a repeating group of settlement amounts for an account. The component layout is available here.

Messages

Account Summary Reports

The AccountSummaryReport(35=CQ) message is provided by the clearinghouse to its clearing members on a daily basis. It contains margin, settlement, collateral and pay/collect data for each clearing member level account type. Clearing member account types will be described through use of the Parties component and PtysSubGrp sub-component.

In certain usages, the clearing members may send the AccountSummaryReport(35=CQ) message to the clearinghouse as needed. For example, clearing members can send this message to the clearinghouse to identify the value of collateral for each customer (to satisfy CFTC Legally Segregated Operationally Commingled (LSOC) regulatory reporting obligations).

Clearing organizations may also send the AccountSummaryReport(35=CQ) message to regulators to meet regulatory reporting obligations. For example, clearing organizations can use this message to submit daily reports for each clearing member (“CM”) by house origin and by each customer origin for all futures, options, and swaps positions, and all securities positions held in a segregated account or pursuant to a cross margining agreement, to a regulator (e.g. to the CFTC to meet Part 39, Section 39.19 reporting obligations).

The Parties component and PtysSubGrp sub-component are used to identify the clearing member number and account type for that report. Net settlement amount or amounts are provided using the SettlementAmountGrp component. Margin requirement amounts are provided using the MarginAmount component.

The current collateral values for each valid collateral type is provided using the CollateralAmountGrp component. Likewise pay/collect information is provided using the PayCollectGrp component. Margin and pay/collect amounts can optionally be tied to markets and market segments for clearing houses that support multiple markets and market segments.

The message layout is available here.

Category – Trade Management

Messages to manage trades as part of post-trade workflows.

Components

ExecutionAggregationGrp

This component is a repeating group that identifies the fills being aggregated together. The component layout is available here.

OrderAggregationGrp

This component is a repeating group that identifies the orders being aggregated together. The component layout is available here.

Messages

Trade Aggregation Requests

The TradeAggregationRequest(35=DW) message is used to request that the identified trades between the initiator and respondent be aggregated together for further processing. The message layout is available here.

Trade Aggregation Reports

The TradeAggregationReport(35=DX) message is used to respond to the TradeAggregationRequest(35=DW) message. It provides the status of the request (e.g. accepted or rejected) and may also provide additional information supplied by the respondent. The message layout is available here.

Category – Pay Management

Messages used to initiate and confirm expected or future payments to be made or received related to servicing of contracts or transactions after trade settlement. These messages are not intended to instruct or initiate remittance of funds transfers with banks.

Components

PostTradePayment

This component specifies the details of a payment between the parties involved. The component layout is available here.

Messages

Pay Management Requests

The PayManagementRequest(35=DY) message is used to communicate a future or expected payment to be made or received related to a trade or contract after its settlement.

It should be noted that this message, in the context of operational communication between investment managers and their brokers, is intended to agree and confirm on payment(s) to be made or received during the life of a contract.

The message layout is available here.

Pay Management Request Acknowledgements

The PayManagementRequestAck(35=DZ) message is used to acknowledge the receipt of the PayManagementRequest(35=DY) message (i.e. a technical acknowledgement of receipt). Acceptance or rejection of the request is reported in the corresponding PayManagementReport(35=EA). The message layout is available here.

Pay Management Reports

The PayManagementReport(35=EA) message may be used to respond to the PayManagementRequest(35=DY) message. It provides the status of the request (e.g. accepted, disputed) and may provide additional information related to the request. The PayManagementReport(35=EA) message may also be sent unsolicited by the broker to a client. In which case the client may acknowledge and resolve disputes out-of-band or with a simple PayManagementReportAck(35=EB) message. The PayManagementReport(35=EA) message may also be sent unsolicited to report the progress status of the payment itself with PayReportTransType(2804)=2 (Status).

It should be noted that this message, in the context of operational communication between investment managers and their brokers, is intended to agree and confirm on payment(s) to be made or received during the life of a contract.

The message layout is available here.

Pay Management Report Acknowledgements

The PayManagementReportAck(35=EB) message is used as a response to the PayManagementReport(35=EA) message. It may be used to accept, reject or dispute the details of the PayManagementReport(35=EA) message depending on the business rules of the receiver. This message may also be used to acknowledge the receipt of a PayManagementReport(35=EA) message. The message layout is available here.


  1. AveragePriceDetail added as common with EP240 but only used in the category Trade Capture Reporting.↩︎
  2. ExecutionAggregationGrp added as common with EP247 but only used in the category Trade Management.↩︎
  3. FundingSourceGrp added as common with EP254 but only used in the category Collateral Management.↩︎
  4. MandatoryClearingJurisdictionGrp added as common with EP169 but only used in the category Trade Capture Reporting.↩︎
  5. MatchExceptionGrp added as common with EP240 but only used in the category Confirmation.↩︎
  6. MatchingDataPointGrp added as common with EP240 but only used in the category Confirmation.↩︎
  7. OrderAggregationGrp added as common with EP247 but only used in the category Trade Management.↩︎
  8. PositionQty added as common with FIX 4.4 but only used in the category Position Maintenance.↩︎
  9. RelatedPositionGrp added as common with EP142 but only used in the category Trade Capture Reporting.↩︎
  10. SideCollateralAmountGrp added as common with EP227 but only used in the category Trade Capture Reporting.↩︎
  11. SideCollateralReinvestmentGrp added as common with EP254 but only used in the category Trade Capture Reporting.↩︎
  12. SideRegulatoryTradeIDGrp added as common with EP162 but only used in the category Trade Capture Reporting.↩︎
  13. TradeCapLegUnderlyingsGrp has been deprecated with EP187.↩︎
  14. TradePositionQty added as common with EP141 but only used in the category Trade Capture Reporting.↩︎
  15. TradeQtyGrp added as common with EP141 but only used in the category Trade Capture Reporting.↩︎
  16. UnderlyingLegInstrument has been deprecated with EP187.↩︎
  17. UnderlyingLegSecurityAltIDGrp has been deprecated with EP187.↩︎