AllocationReport <AS> message

Description

Sent from sell-side to buy-side, sell-side to 3rd-party or 3rd-party to buy-side, the AllocationReport <AS> (Claim) provides 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 message. Depending on the needs of the market and the timing of "confirmed" status, the role of AllocationReport <AS> can be taken over in whole or in part by the Confirmation <AK> message.

Note the response to the AllocationReport <AS> message is the AllocationReportAck <AT> message. In versions of FIX prior to version 4.4, the Allocation ACK served this purpose.

An AllocationReport <AS> message can be submitted with AllocReportType <794> of

• Sellside Calculated Using Preliminary (includes Misc Fees, Accrued Interest and Net Money)
• Sellside Calculated Without Preliminary (includes Misc Fees, Accrued Interest and Net Money). (AllocType <626> = "Sellside Initiated"), i.e. where the allocations have been provided via some other mechanism or agreed earlier in the order process.
• Warehouse recap - sent unsolicited by sellside, used to communicate confirmation and current status of any warehoused position in a particular stock (see Volume 7 - PRODUCT: EQUITIES for specific usage guidance on this topic)

Settlement instructions are supported on the Allocation Report 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 <AS> messages.
• To reject an AllocationReport <AS> message, an AllocationReportAck(AT) with AllocStatus <87> 'Block level reject' or 'Account <1> level reject' should be used. Use of 'Block level reject' means the entire message has been rejected (e.g. net money mismatch). 'Account <1> 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 MiscFees). 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 AllocationInstructionAck <P> message.
• A rejected AllocationReport <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 NoAllocs <78> repeating group. A nested parties component block is provided which can be used for this purpose.

The allocation message contains repeating fields for each order, sub-account and individual execution. The repeating fields are shown in the message definition below in typeface Bold-Italic and indented with the → symbol. The field's relative position within the repeating group in the message is important. For example, each instance of allocation must be in the order as shown in the message definition below.

• The number of sub-account instances is indicated in NoAllocs <78>.
• Multiple orders can be combined for allocation or for AllocType <626>=" Ready-To-Book" or 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. Note 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 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.

Allocation Report (aka Allocation Claim)

Structure

Related Messages

• Confirmation <AK>