The AccountSummaryReport is provided by the clearinghouse to its clearing members on a daily basis. It contains margin, settlement, collateral and pay/collect data for each clearing member level account type. Clearing member account types will be described through use of the Parties component and PtysSubGrp sub-component.
In certain usages, the clearing members can send the AccountSummaryReport message to the clearinghouse as needed. For example, clearing members can send this message to the clearinghouse to identify the value of collateral for each customer (to satisfy CFTC Legally Segregated Operationally Commingled (LSOC) regulatory reporting obligations).
Clearing organizations can also send the AccountSummaryReport message to regulators to meet regulatory reporting obligations. For example, clearing organizations can use this message to submit daily reports for each clearing member ("CM") 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).
Additional detail from the official source
The Parties component and PtysSubGrp sub-component are used to describe the clearing member 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 MarginAmountData 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.
Message structure 113 distinct fields
Source order, including nested components and groups. Group counts precede the repeated entries. “Required here” is relative to the enclosing component or group, not unconditional in the message. A dash means not marked required; conditional requirements remain in the source notes. This is a reference, not a counterparty-specific validator.
Includes nested components and groups. Escape clears the filter.
Trading partner LocationID (i.e. geographic location and/or desk) used when delivering messages via a third party. (Can be embedded within encrypted data section.)
Trading partner LocationID (i.e. geographic location and/or desk) used when delivering messages via a third party. (Can be embedded within encrypted data section.)
Always required for retransmitted messages, whether prompted by the sending system or as the result of a resend request. (Can be embedded within encrypted data section.)
Required for message resent as a result of a ResendRequest. If data is not available set to same value as SendingTime (Can be embedded within encrypted data section.)
The last MsgSeqNum value received by the FIX engine and processed by downstream application, such as trading system or order routing system. Can be specified on every message sent. Useful for detecting a backlog with a counterparty.
HopGrpRepeating groupCount tag 627—
Number of repeating groups of historical "hop" information. Only applicable if OnBehalfOfCompID is used, however, its use is optional. Note that some market regulations or counterparties may require tracking of message hops.
Application sequence number assigned to the message by the application generating the message. Used only if application sequencing is in effect. Conditionally required if ApplID has been specified.
The previous sequence number in the application sequence stream. Permits an application to publish messages with sequence gaps where it cannot be avoided. Used only if application sequencing is in effect. Conditionally required if ApplID has been specified
Used to indicate that a message is being sent in response to an Application Message Request. Used only if application sequencing is in effect. It is possible for both ApplResendFlag and PossDupFlag to be set on the same message if the Sender's cache size is greater than zero and the message is being resent due to a session level resend request.