The Allocation Report Ack message is used to acknowledge the receipt of and provide status for an Allocation Report message.
It is possible that multiple Allocation Report Ack messages can be generated for a single Allocation Report message to acknowledge the receipt and then to detail the acceptance or rejection of the Allocation Report message.
It is recommended, when appropriate, that the MatchStatus <573> field be used in the Allocation Report Ack to denote whether any financial details provided in the Allocation Report with AllocStatus <87> of 'Accepted' were matched by the Initiator. If a match takes place and succeeds, then the match status will be '0-Compared and affirmed'. If the match takes place and fails, or no match takes place, then the match status will be '1-Uncompared or unaffirmed'.
Allocation Report Ack (aka Allocation Claim Ack)-
|Component Block - <StandardHeader>||Y||MsgType = AT|
May be used to link to a previously submitted AllocationInstructionAlertRequest <DU> message.
|715||ClearingBusinessDate||N||Indicates Clearing Business Date for which transaction will be settled.|
|819||AvgPxIndicator||N||Indicates if an allocation is to be average priced. Is also used to indicate if average price allocation group is complete or incomplete.|
|Component Block - <Instrument>||N|
|Component Block - <Parties>||N||Insert here the set of "Parties" (firm identification) fields defined in "Common Components of Application Messages"|
|793||SecondaryAllocID||N||Optional second identifier for the allocation report being acknowledged (need not be unique)|
Group identifier assigned by the clearinghouse
Firm assigned entity identifier for the allocation
Firm designated group identifier for average pricing
|60||TransactTime||N||Date/Time Allocation Report Ack generated|
Denotes the status of the allocation report; received (but not yet processed), rejected (at block or account level) or accepted (and processed).
AllocStatus will be conditionally required in a 2-party model when used by a counterparty to convey a change in status. It will be optional in a 3-party model in which only the central counterparty may issue the status of an allocation
|88||AllocRejCode||N||Required for AllocStatus = 1 (block level reject) and for AllocStatus 2 (account level reject) if the individual accounts and reject reasons are not provided in this message|
Required if AllocReportType = 8 (Request to Intermediary)
Indicates status that is requested to be transmitted to counterparty by the intermediary (i.e. clearing house)
|573||MatchStatus||N||Denotes whether the financial details provided on the Allocation Report were successfully matched.|
|58||Text||N||Can include explanation for AllocRejCode = 7 (other)|
|354||EncodedTextLen||N||Must be set if EncodedText field is specified and must immediately precede it.|
|355||EncodedText||N||Encoded (non-ASCII characters) representation of the Text field in the encoded format specified via the MessageEncoding field.|
EncodedRejectText <1665> field is specified and must immediately precede it.
|Component Block - <RegulatoryTradeIDGrp>||N|
|Component Block - <AllocAckGrp>||N||
This repeating group is optionally used for messages with AllocStatus = 2 (account level reject) to provide details of the individual accounts that caused the rejection, together with reject reasons. This group should not be populated where AllocStatus has any other value.
Indicates number of allocation groups to follow.
|Component Block - <StandardTrailer>||Y|