Area – Post-Trade

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. APPENDIX: COMPONENTS AND MESSAGES

Descriptions of the specific FIX pre-trade application messages follow. There is a diagram for each of the messages depicting its components. Required components are shown with a red outline and repeating groups contain an arrow symbol. Some messages do not have any components.

List of Component Blocks and Messages for Post-Trade

Component Blocks

This section lists component blocks used by post-trade messages defined in this part of the FIX specification. Some of these are Common Component blocks used by more than one category in this area. Messages may also reference Global Component blocks, which are components used by messages across all areas. Global Common Components are defined in the overall introduction to the FIX specification as well as online.

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

Type NameCategory
RepeatingAllocAckGrpAllocation
RepeatingAllocGrpAllocation
RepeatingClrInstGrpCommon Components
RepeatingCollInqQualGrpCollateralManagement
RepeatingCpctyConfGrpConfirmation
RepeatingDlvyInstGrpCommon Components
RepeatingExecAllocGrpAllocation
RepeatingExecCollGrpCollateralManagement
RepeatingExpirationQtyPositionMaintenance
RepeatingOrdAllocGrpCommon Components
RepeatingPosUndInstrmtGrpPositionMaintenance
RepeatingPositionAmountDataCommon Components
RepeatingPositionQtyPositionMaintenance
RepeatingRgstDistInstGrpRegistrationInstruction
RepeatingRgstDtlsGrpRegistrationInstruction
RepeatingSettlDetailsCommon Components
RepeatingSettlInstGrpSettlementInstruction
Non-RepeatingSettlInstructionsDataCommon Components
RepeatingSettlObligationInstructionsSettlementInstruction
RepeatingSettlPartiesCommon Components
RepeatingSettlPtysSubGrpCommon Components
RepeatingSideTrdRegTSTradeCapture
RepeatingTradeCapLegUnderlyingsGrpTradeCapture
Non-RepeatingTradeReportOrderDetailTradeCapture
RepeatingTrdAllocGrpTradeCapture
RepeatingTrdCapDtGrpTradeCapture
RepeatingTrdCapRptAckSideGrpTradeCapture
RepeatingTrdCapRptSideGrpTradeCapture
RepeatingTrdCollGrpCollateralManagement
RepeatingTrdInstrmtLegGrpTradeCapture
RepeatingTrdRepIndicatorsGrpTradeCapture
RepeatingUndInstrmtCollGrpCollateralManagement
RepeatingUnderlyingAmountPositionMaintenance
Non-RepeatingUnderlyingLegInstrumentTradeCapture
RepeatingUnderlyingLegSecurityAltIDGrpTradeCapture

Messages

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

MsgType(35)NameCategory
BLAdjustedPositionReportPositionMaintenance
JAllocationInstructionAllocation
PAllocationInstructionAckAllocation
BMAllocationInstructionAlertAllocation
ASAllocationReportAllocation
ATAllocationReportAckAllocation
AWAssignmentReportPositionMaintenance
AYCollateralAssignmentCollateralManagement
BBCollateralInquiryCollateralManagement
BGCollateralInquiryAckCollateralManagement
BACollateralReportCollateralManagement
AXCollateralRequestCollateralManagement
AZCollateralResponseCollateralManagement
AKConfirmationConfirmation
AUConfirmationAckConfirmation
BHConfirmationRequestConfirmation
BOContraryIntentionReportPositionMaintenance
AMPositionMaintenanceReportPositionMaintenance
ALPositionMaintenanceRequestPositionMaintenance
APPositionReportPositionMaintenance
oRegistrationInstructionsRegistrationInstruction
pRegistrationInstructionsResponseRegistrationInstruction
ANRequestForPositionsPositionMaintenance
AORequestForPositionsAckPositionMaintenance
AVSettlementInstructionRequestSettlementInstruction
TSettlementInstructionsSettlementInstruction
BQSettlementObligationReportSettlementInstruction
AETradeCaptureReportTradeCapture
ARTradeCaptureReportAckTradeCapture
ADTradeCaptureReportRequestTradeCapture
AQTradeCaptureReportRequestAckTradeCapture

Common Components

ClrInstGrp

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

DlvyInstGrp

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

OrdAllocGrp

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

PositionAmountData

This component is a repeating group that is part of various allocation, assignment, position, and trade capture messages. It supports one or more position amounts of different types and currencies. The component layout is available here.

SettlDetails

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

SettlInstructionsData

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

SettlParties

This component is a repeating group that is similar but not identical to the global 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 common component SettlParties. 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.

Category – Allocation

This section provides an overview on how the FIX Protocol can 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 can 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 aka 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 can 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 can be used for a number of purposes using AllocType(626) to indicate the type or purpose of the message, see FIXimate for details.

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

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

Ready-To-Book Processing

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

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

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

Fragmentation of Allocation Messages

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

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

For this to work some key rules must be enforced:

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

There are a number of design suggestions for implementing fragmentation:

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

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

Components

AllocAckGrp

This component is a repeating group that is used for allocation acknowledgement and contains a subset of the information available in the AllocGrp component. 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.

ExecAllocGrp

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

Messages

Allocation Instructions

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

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

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

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

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

General guidelines applicable to this message:

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

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

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

The message layout is available here.

Allocation Instruction Acknowledgements

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

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

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

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

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

Allocation Instruction Alerts

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

Allocation Reports

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

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

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

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

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

General guidelines applicable to this message:

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

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

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

Category – Confirmation

This section provides an overview on how the FIX Protocol can 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 can be used for booking, allocation and confirmation up to the start of settlement processing.

Components

CpctyConfGrp

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

Messages

Confirmations

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

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

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

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

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

Confirmation Acknowledgements (aka Affirmations)

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

Confirmation Requests

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

Category – Settlement Instruction

Components

SettlInstGrp

This component is a repeating group that is used to convey one or more settlement instructions and contains the global Parties component as well as the common 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 global Instrument and Parties components as well as the common component SettlDetails to convey settlement account details. The component layout is available here.

Messages

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 can 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 Instruction Requests

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

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

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

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

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

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

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

Settlement 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 can be used in one of two modes:

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

The message layout is available here.

Category – Trade Capture (“Streetside”) Reporting

Trade capture 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 can be used by the submitter as an alternative to TradeReportRefID(572) in a cancel or replace. Note that a prerequisite to use the SecondaryTradeID(1040) is that the marketplace issues TradeCaptureReportAck(35=AR) messages providing that tag.

Components

SideTrdRegTS

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

TradeCapLegUnderlyingsGrp

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

TradeReportOrderDetail

This component is used to convey some of the attributes of the order that was executed and resulted in the given trade side. It supports individual attributes such as order identifiers as well as the global components OrderQtyData and DisplayInstruction. 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 global component NestedParties2 for parties and/or accounts in addition to AllocAccount(79). The component layout is available here.

TrdCapDtGrp

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

TrdCapRptAckSideGrp

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

TrdCapRptSideGrp

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

TrdInstrmtLegGrp

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

TrdRepIndicatorsGrp

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

UnderlyingLegInstrument

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

UnderlyingLegSecurityAltIDGrp

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

Messages

Trade Capture Report Requests

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

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

The following criteria can be specified on the TradeCaptureReportRequest(35=AD) message:

  • All trades matching specified trade identification: TradeReportID(571)
  • 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 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.
  • 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)

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) can be used in one of two modes:

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

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

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

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

The message layout is available here.

Trade Capture Report Request Acknowledgements

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

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

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

The message layout is available here.

Trade Capture Reports

The TradeCaptureReport(35=AE) message can be:

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

The message layout is available here.

Trade Capture Report Acknowledgements

The TradeCaptureReportAck(35=AR) message can be:

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

The message layout is available here.

Category – Registration Instruction

Components

RgstDistInstGrp

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

RgstDtlsGrp

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

Messages

Registration Instructions

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

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

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

Registration Instructions Responses

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

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

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

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

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

The message layout is available here.

Category – Position Maintenance

Clearing Services for Position Management

The Position Management Clearing Services can 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 can be used to invoke the following business functions. If requested, message-based response confirmations will be provided to the client.

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

Components

ExpirationQty

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

PositionQty

This component is a repeating group that is part of various position and assignment messages and required in most of them. It specifies the various types of position quantity in the position life-cycle including start-of-day, intraday, trade, adjustments, and end-of-day position quantities. Quantities are expressed in terms of long and short quantities. It also contains the global 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 global UndInstrmtGrp component but can contain additional information related to the settlement as well as to pay and collect amounts. The component layout is available here.

UnderlyingAmount

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

Messages

Position Maintenance Requests

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

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

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

Position Maintenance Reports

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

Requests For Positions

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

The message can be used to request a one time snapshot of positions or to subscribe to updates as they occur using the SubscriptionRequestType(263). The ResponseTransportType(725) can 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.

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

Position Reports

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

Adjusted Position Reports

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.

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.

Category – Collateral Management

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

Collateral Management Usage

Collateral management messages have been designed for the following uses:

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

Components

CollInqQualGrp

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

ExecCollGrp

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

TrdCollGrp

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

UndInstrmtCollGrp

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

Messages

Collateral Requests

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

Collateral Assignments

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

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

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

The message layout is available here.

Collateral Responses

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

Collateral Reports

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

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