This message used to to specify how an order or set of orders should be subdivided amongst one or more accounts. Prior to FIX 4.4, this message used the name "Allocation", and was also used to communicate fee and expense details from the sell-side to the buy-side. This role has now been removed from and is now performed by Allocation Report <35=AS> and Confirmation <35=AK>. The Allocation Report <35=AS> message should be used for the sell-side-initiated allocation role as defined in previous versions of the protocol.

The response to this message is the Allocation Instruction Ack <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 accounts and their respective order quantities which make up the order. This is a regulatory requirement in certain markets and for certain types of securities.

This message can be submitted with AllocTransType (71) = "new", "cancel" or "replace". The AllocType (626) field indicates the type or purpose of the message:

• Calculated - includes MiscFees and NetMoney (118)
• Preliminary - without MiscFees and NetMoney (118)
• Ready-To-Book
• Warehouse instruction

AllocSettlInstType (780) is used to specify full settlement instruction details, to provide a reference to a settlement instruction held on a database of such instructions or to instruct the receiving party to perform one of the following actions:

• Use default instructions
• Derive the instructions from the parameters of the trade
• Phone for instructions

AllocID (70) should be unique for all messages with AllocTransType (71) = "new".

When AllocTransType (71) = "replace" or "cancel", RefAllocID (72) and AllocCancReplaceReason (796) are required.

To reject an Allocation Instruction, an Allocation Instruction Ack <35=P> with AllocStatus (87) = "'Block-level reject" or "Account-level reject" should be used. Block-level reject is used to reject the entire message, e.g. due to one or more of the orders not matching. An account-level reject is used when the block-level matches successfully but one or more of the constituent account-level details failed validation, e.g. the account was not found. 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 Allocation Instruction Ack <35=P>. AllocGrp exists for this purpose.

The correct response to a block-level reject Allocation Instruction Ack <35=P> is a new Allocation Instruction with AllocTransType (71) = "new", as the previous message has been rejected in entirety. In the case of an account-level reject, either:

• the original Allocation Instruction should be cancelled (an Allocation Instruction referencing the original in RefAllocID (72), with AllocTransType (71) = "cancel") then reinstated (a second Allocation Instruction with AllocTransType (71) = "new")
• the original Allocation Instruction should be fully replaced (an Allocation Instruction referencing the original in RefAllocID (72), with AllocTransType (71) = "replace"). A replacement allocation message must contain all data for the replacement allocation. It is the responsibility of the recipient to identify which fields have been changed

Optionally, an Allocation Instruction with AllocTransType (71) = "cancel" or "replace" can be rejected if an Allocation Instruction Ack <35=P> with status = "accepted" has already been sent. Manual communication would then be required to effect the required changes. This approach would generally be required where the generation of the accepted Allocation Instruction Ack <35=P> is used to move the allocation details into downstream processing, e.g. confirmation generation. In which case, a subsequent cancellation or amendment may require the details to be retrieved from the downstream process.

Where an amendment or cancellation of an Allocation Instruction has taken place out outside of FIX, an Allocation Report <35=AS> message can be sent to confirm that the relevant action has taken place.

Where settling in markets where multiple alternative settlement locations exist, it is recommended that the settlement location be specified on each allocation detail within the AllocGrp component. A NestedParties component block exists for this purpose.

Quantity (53) must equal the total quantity allocated. If present, the total quantity in the execution section must also be equal to this value. The total quantity of the allocation does not necessarily have to equal the total quantity of the orders being allocated. For example in good-til (GT) orders, especially where multi-day average pricing is taking place. The quantity of each order being booked must also be specified on the message. This will be equal to the order quantity 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 be equal to Quantity (53).

The number of sub-account instances is indicated in the AllocGrp component.

Multiple orders can be combined for allocation or for AllocType (626) = "Ready-To-Book" or for AllocType (626) = "Warehouse instruction". Note that combined orders must refer to the same instrument and have the same trade date, settlement date and side. The identification of the orders to be combined can be achieved in one of two ways:

• By identifying the number of orders in the NoOrders (73) field and each individual order in the OrderID (37) fields. The AllocNoOrdersType (857) field is used to denote that this is happening and takes value "1=Explicit list provided". If any orders were handled outside FIX, the ClOrdID (11) must be set to 'MANUAL'. Regardless of whether the orders were handled within or outside FIX, the order quantity and average price 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. The NoOrders (73) field in this case is left blank. The AllocNoOrdersType (857) field is set to "0=Not specified" to specify that this is happening. 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 the NoExecs (124) field and each individual execution in the ExecID (17) fields. Combined executions must refer to the same instrument, trade date, settlement date and side.

Except where AllocTransType (71) = 'Cancel' or where AllocNoOrdersType (857) = "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, the ClOrdID (11) must be set to 'MANUAL'. Regardless of whether the orders were handled within or outside FIX, and where the orders are specified, the order quantity and average price 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.