As of EP284, November 2023

FIX Global Technical Committee

Table of Contents

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. SETTLEMENT STATUS MANAGEMENT

Descriptions of the specific FIX post-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. The detailed layout of all messages and components is provided in the appendix.

List of Messages and Components for Post-Trade

Messages

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

Messages for Post-Trade Business Area

MsgType(35)	Name	Category
CQ	AccountSummaryReport	Account Reporting
BL	AdjustedPositionReport	Position Maintenance
J	AllocationInstruction	Allocation
P	AllocationInstructionAck	Allocation
BM	AllocationInstructionAlert	Allocation
DU	AllocationInstructionAlertRequest	Allocation
DV	AllocationInstructionAlertRequestAck	Allocation
AS	AllocationReport	Allocation
AT	AllocationReportAck	Allocation
AW	AssignmentReport	Position Maintenance
AY	CollateralAssignment	Collateral Management
BB	CollateralInquiry	Collateral Management
BG	CollateralInquiryAck	Collateral Management
BA	CollateralReport	Collateral Management
DQ	CollateralReportAck	Collateral Management
AX	CollateralRequest	Collateral Management
AZ	CollateralResponse	Collateral Management
AK	Confirmation	Confirmation
AU	ConfirmationAck	Confirmation
BH	ConfirmationRequest	Confirmation
BO	ContraryIntentionReport	Position Maintenance
CH	MarginRequirementInquiry	Margin Requirement Management
CI	MarginRequirementInquiryAck	Margin Requirement Management
CJ	MarginRequirementReport	Margin Requirement Management
EA	PayManagementReport	Pay Management
EB	PayManagementReportAck	Pay Management
DY	PayManagementRequest	Pay Management
DZ	PayManagementRequestAck	Pay Management
AM	PositionMaintenanceReport	Position Maintenance
AL	PositionMaintenanceRequest	Position Maintenance
AP	PositionReport	Position Maintenance
DL	PositionTransferInstruction	Position Maintenance
DM	PositionTransferInstructionAck	Position Maintenance
DN	PositionTransferReport	Position Maintenance
o	RegistrationInstructions	Registration Instruction
p	RegistrationInstructionsResponse	Registration Instruction
AN	RequestForPositions	Position Maintenance
AO	RequestForPositionsAck	Position Maintenance
AV	SettlementInstructionRequest	Settlement Instruction
T	SettlementInstructions	Settlement Instruction
BQ	SettlementObligationReport	Settlement Instruction
EE	SettlementStatusReport	Settlement Status Management
EF	SettlementStatusReportAck	Settlement Status Management
EC	SettlementStatusRequest	Settlement Status Management
ED	SettlementStatusRequestAck	Settlement Status Management
DX	TradeAggregationReport	Trade Management
DW	TradeAggregationRequest	Trade Management
AE	TradeCaptureReport	Trade Capture Reporting
AR	TradeCaptureReportAck	Trade Capture Reporting
AD	TradeCaptureReportRequest	Trade Capture Reporting
AQ	TradeCaptureReportRequestAck	Trade Capture Reporting
DC	TradeMatchReport	Trade Capture Reporting
DD	TradeMatchReportAck	Trade Capture Reporting

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.

Components for Post-Trade Business Area

Type	Name	Category
Repeating	AllocAckGrp	Allocation
Repeating	AllocCommissionDataGrp	Common Components
Repeating	AllocGrp	Allocation
Repeating	AllocRegulatoryTradeIDGrp	Common Components
Non-Repeating	AveragePriceDetail	Trade Capture Reporting1
Repeating	ClrInstGrp	Common Components
Repeating	CollateralAmountGrp	Common Components
Repeating	CollateralReinvestmentGrp	Common Components
Repeating	CollInqQualGrp	Collateral Management
Repeating	CpctyConfGrp	Confirmation
Repeating	DlvyInstGrp	Common Components
Repeating	ExecAllocGrp	Common Components
Repeating	ExecCollGrp	Collateral Management
Repeating	ExecutionAggregationGrp	Trade Management2
Repeating	ExpirationQty	Position Maintenance
Repeating	FundingSourceGrp	Collateral Management3
Repeating	InstrmtMatchSideGrp	Trade Capture Reporting
Repeating	LegPositionAmountData	Trade Capture Reporting
Repeating	MandatoryClearingJurisdictionGrp	Trade Capture Reporting4
Repeating	MarginAmount	Common Components
Repeating	MarginReqmtInqQualGrp	Margin Requirement Management
Repeating	MatchExceptionGrp	Confirmation5
Repeating	MatchingDataPointGrp	Confirmation6
Repeating	OrdAllocGrp	Common Components
Repeating	OrderAggregationGrp	Trade Management7
Repeating	PayCollectGrp	Account Reporting
Repeating	PosUndInstrmtGrp	Position Maintenance
Repeating	PositionAmountData	Common Components
Repeating	PositionQty	Position Maintenance8
Non-Repeating	PostTradePayment	Pay Management
Repeating	RelatedPositionGrp	Trade Capture Reporting9
Repeating	RgstDistInstGrp	Registration Instruction
Repeating	RgstDtlsGrp	Registration Instruction
Repeating	SettlDetails	Common Components
Repeating	SettlementAmountGrp	Account Reporting
Repeating	SettlInstGrp	Settlement Instruction
Non-Repeating	SettlInstructionsData	Common Components
Repeating	SettlObligationInstructions	Settlement Instruction
Repeating	SettlParties	Common Components
Repeating	SettlPtysSubGrp	Common Components
Non-Repeating	SettlTradeDetails	Settlement Status Management
Repeating	SideCollateralAmountGrp	Trade Capture Reporting10
Repeating	SideCollateralReinvestmentGrp	Trade Capture Reporting11
Repeating	SideRegulatoryTradeIDGrp	Trade Capture Reporting12
Repeating	SideTrdRegTS	Trade Capture Reporting
Repeating	TradeAllocAmtGrp	Common Components
Repeating	TradePositionQty	Trade Capture Reporting13
Repeating	TradeQtyGrp	Trade Capture Reporting14
Non-Repeating	TradeReportOrderDetail	Trade Capture Reporting
Repeating	TransactionAttributeGrp	Common Components
Repeating	TrdAllocGrp	Trade Capture Reporting
Repeating	TrdCapDtGrp	Trade Capture Reporting
Repeating	TrdCapRptAckSideGrp	Trade Capture Reporting
Repeating	TrdCapRptSideGrp	Trade Capture Reporting
Repeating	TrdCollGrp	Collateral Management
Repeating	TrdInstrmtLegExecGrp	Trade Capture Reporting
Repeating	TrdInstrmtLegGrp	Trade Capture Reporting
Repeating	TrdMatchSideGrp	Trade Capture Reporting
Repeating	TrdRepIndicatorsGrp	Trade Capture Reporting
Repeating	UndInstrmtCollGrp	Collateral Management
Repeating	UnderlyingAmount	Position Maintenance

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 Message	Total number of field	related Number of field	Principal 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.

Messages

Allocation Instructions

The AllocationInstruction(35=J) message provides the ability to specify how an order, set of orders or set of fills should be subdivided amongst one or more accounts. AllocationInstruction(35=J) messages are typically sent by the participant (i.e. Initiator) who had placed orders, e.g. buy-side institutions communicating with their executing brokers, clearing firms communicating with their clearing house. It may also be used in workflows where 3^rd party intermediaries facilitate the communication between participants. The AllocationReport(35=AS) message should be used for allocation activities initiated by the Respondent.

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

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(87)	Description
3 = Received, not yet processed	Used 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 = Accepted	The AllocationInstruction(35=J) message has been validated and processed successfully.
1 = Block level reject	The 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 reject	The 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 clearing house 3-party allocation model to request for AllocationInstructionAlert(35=BM) messages from the clearing house. 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 clearing house 3-party allocation model to acknowledge a AllocationInstructionAlertRequest(35=DU) message for an AllocationInstructionAlert(35=BM) message from the clearing house. The message layout is available here.

Allocation Reports

AllocationReport(35=AS) messages are typically sent by the receiving participant (i.e. Respondent) who has to take action based on instructions conveyed via the AllocationInstruction(35=J). Respondents may include sell-sides, clearing houses, 3^rd-party intermediaries that facilitates communication between participants.

The AllocationReport(35=AS) message (a.k.a. “Allocation Claim”) provides an account breakdown of an order, set of orders or set of fills plus any additional follow-up front-office information developed post-trade during the trade allocation, matching and calculation phase. Depending on the supported workflow, 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.

An AllocationReport(35=AS) message can be submitted with different values of AllocReportType(794), 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 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.

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.

Category – Confirmation

The Confirmation messages are typically used in workflows that are primarily between buy-side and sell-side institutions, with optional 3^rd-party intermediaries involved who may provide additional services in this pre-settlement workflow. This is the next step in the buy-side and sell-side oriented pre-settlement workflow following the block trade allocation process.

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.

Messages

Confirmations

The Confirmation(35=AK) messages are used to provide individual account level trade confirmation or booking status, prior to settlement, from the sell-side to the buy-side. Unlike the AllocationInstruction(35=J) message, the Confirmation(35=AK) message operates at an allocation account (trade) level rather than block trade level, allowing for the affirmation or rejection of individual confirmations. Each Confirmation(35=AK) message reports the details of a single “ticket” with details such as account names, fees, net money, and settlement information being included using fields designated for single-account trades. When the buy-side, in response, “affirms” with the ConfirmationAck(35=AU) message, the trade is ready to settle.

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 may be used to “reject” a Confirmation(35=AK) rather than “affirm”, for example in situations where the details of the Confirmation(35=AK) message are in disagreement. 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.

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.

Category – Settlement Instruction

Messages

Settlement Instruction Requests

The SettlementInstructionRequest(35=AV) message is used to request standing settlement instructions from another party. For example, 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 standing settlement instructions database.
• A third party central standing settlement instructions 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)

The specified parameters will act as filtering criteria for the request.

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 (e.g. 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.

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.

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.

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.

Fields specified in the request message serves as filter criteria for the request results.

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
• Sent unsolicited between counterparties
• Sent as a reply to a TradeCaptureReportRequest(35=AD) message
• Used to communicate unmatched and matched trades
• Used to report trades to trade repositories
• Used to report trades to regulatory agencies to comply with regulatory reporting

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 as an atomic event, for example to clearing houses. 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.

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 at the instrument leg level. 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 is part of the TrdCapRptSideGrp component. It 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.

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 and a list of related orders (RelatedOrderGrp component). 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 trade sides of a single or multileg instrument transaction. 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 or trade information of a multileg instrument on an instrument 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.

Category – Registration Instruction

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 = Accepted	Registration details are acceptable to the receiving broker, intermediary or fund manager. Assigned client and account IDs may be returned.
R = Rejected	Registration details have been rejected by the receiving broker, intermediary or fund manager.
H = Held	Registration details have been held by the receiving broker, intermediary or fund manager. Assigned (possibly provisional) client and account Ids may be returned.
N = Reminder	Registration details are still outstanding.

The message layout is available here.

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.

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

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 3^rd party providing investment or asset-servicing services. Submission of a maintenance request may result in the following (but not limited to these examples):

• 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 PositionReport(35=AP) message may also be used to report positions to satisfy regulatory reporting of positions.

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, clearing organization or 3^rd party providing investment or asset-servicing services. 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.

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 is required in many of these messages. It specifies the various types of position quantity in the position maintenance 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 within the PosUndInstrmtGrp component that is used to convey the pay and collect amounts associated with the underlying instrument, settlement dates, settlement status and method for derivative positions. The component 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 that requires collateralization or margin accounts. The collateral management messages have been designed to address both two-party and three-party interactions. 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 alternative trading system (ATS).

Collateral Management Usage

Collateral management messages have been designed for the following uses:

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

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 clearing house, 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 or margin account. 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. It may also be sent out without an explicit inquiry. This message may also be used for regulatory reporting of collateralized margin accounts or transactions. 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.

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 collateral instruments for the transaction’s instrument in the main level of the messages where this component is used. It is an extension of the UndInstrmtGrp component as it provides the additional ability to maintain the underlying collateral instruments with the CollAction(944) field. The component 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 central counterparty (CCP). The margin (e.g. total liability or performance bond) reflects this risk.

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 with varying levels of detail such that the results would be reported back at an aggregate level or at a detail level. It can also be used to inquire for margin excess/deficit or net position information. The successful result of an inquiry is one or more MarginRequirementReport(35=CJ) messages.

Margin excess/deficit inquiries 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, providing the status of the request with MarginReqmtInqStatus(1640). In case of an inquiry that cannot be fulfilled, the reasons for rejecting the inquiry are provided with MarginReqmtInqResult(1641). The message layout is available here.

Margin Requirement Reports

The MarginRequirementReport(35=CJ) message is used to as a response to a successful MarginRequirementInquiry(35=CH) message, returning 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. This message may also be used to report margin account information to regulators. Application sequencing may be used to support the re-request of a range of reports. The message layout is available here.

Components

MarginReqmtInqQualGrp

This component is a repeating group that is used to convey the type of requested content of the MarginRequirementReport(35=CJ) messages in response to a margin inquiry. The component 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 clearing house.

Messages

Account Summary Reports

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

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

Clearing houses may also send the AccountSummaryReport(35=CQ) message to regulators to meet regulatory reporting obligations. For example, clearing houses can use this message to submit daily reports for each clearing firm 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 firm 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.

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 clearing firm’s daily net settlement with the clearing house. 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.

Category – Trade Management

Trade Management messages are used to manage trades as part of post-trade workflows.

Messages

Trade Aggregation Requests

The TradeAggregationRequest(35=DW) message is used to request that the identified trades and/or orders 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.

Components

ExecutionAggregationGrp

This component is a repeating group that identifies the execution 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.

Category – Pay Management

These messages are 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.

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 respondent (e.g. broker) to the initiator (e.g. broker’s client). In which case the receiving party (e.g. 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.

Components

PostTradePayment

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

Category – Settlement Status Management

These messages are used for the communication of securities settlement status from a broker/dealer, custodian or some other outsourcer to the buy-side or investment/asset management community in near real-time. These messages are not intended to instruct or initiate settlement.

Messages

Settlement Status Requests

The SettlementStatusRequest(35=EC) message is used to request for the settlement status of a trade.

The message layout is available here.

Settlement Status Request Acknowledgements

The SettlementStatusRequestAck(35=ED) message is used to acknowledge the receipt of the SettlementStatusRequest(35=EC) message (i.e. a technical acknowledgement of receipt). Acceptance or rejection of the request is reported in the corresponding SettlementStatusReport(35=EE). The message layout is available here.

Settlement Status Reports

The SettlementStatusReport(35=EE) message may be used to respond to the SettlementStatusRequest(35=EC) message. It provides the status of the request (e.g. accepted, disputed) and may provide additional information related to the request.

The SettlementStatusReport(35=EE) message may also be sent unsolicited without an explicit request message by the party able to provide the settlement status for the trade identified in the report message.

The message layout is available here.

Settlement Status Report Acknowledgements

The SettlementStatusReportAck(35=EF) message is used as a response to the SettlementStatusReport(35=EE) message. It may be used to acknowledge or reject the SettlementStatusReport(35=EE) message. The message layout is available here.

Components

SettlTradeDetails

This component specifies the details which can be used to look up a single trade. The component layout is available here.

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 settlement delivery instructions, including party and/or account information (SettlParties component). The component layout is available here.

ExecAllocGrp

This component is a repeating group that is part of the allocation and confirmation messages. It allows a list of execution (i.e. fills) and/or trade references along with additional attributes such as the quantity, price, and capacity, to be provided that applies to the allocation or confirmation. 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 the allocation and confirmation messages. It allows a list of different types of order references along with additional attributes, such as the quantity or average price of the orders, to be provided that applies to the allocation or confirmation. The component layout is available here.

PositionAmountData

This component is a repeating group that is used to report netted amounts associated with different position types and their 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 identify settlement instruction information. The settlement instructions can be provided via a reference to a standing instruction database or by providing explicit settlement account information via the SettlParties component. It also provides a means to indicate 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.