auth.054.001.01
The CCPClearingMemberReport message is sent from the central counterparty to the national competent authority. It is used to inform the national competent authority about the central counterparties clearing members and their clients, and the related account structures.
Message Construction
Every ISO20022 message has at the highest level what we call ‘building blocks’. Because the message is constructed as immutable records, the association is by composition. Below you can see the relationship between the message and its constituent building blocks: For comparison, see the ISO20022 official specification
classDiagram direction LR %% CCPClearingMemberReportV01 recursion level 0 with max 0 CCPClearingMemberReportV01 *-- "1..1" ClearingMember1 : ClearingMember CCPClearingMemberReportV01 *-- "0..1" SupplementaryData1 : SupplementaryData
Now, we will zero-in one-by-one on each of these building blocks.
ClearingMember building block
Legal counterpart to trades cleared through a central counterparty. Legal counterpart to trades cleared through a central counterparty. For comparison, see the ISO20022 official specification
classDiagram direction tb %% ClearingMember1 recursion level 0 with max 1 class ClearingMember1{ CreditQuality CreditQuality1Code FuturesCommissionMerchantIndicator IsoTrueFalseIndicator MembershipValidFrom IsoISODate MembershipValidTo IsoISODate } ClearingMember1 *-- "1..1" IPartyIdentification118Choice : Identification ClearingMember1 *-- "0..1" IPartyIdentification118Choice : UltimateParentIdentification ClearingMember1 *-- "0..1" IPartyIdentification118Choice : SponsoringClearingMemberIdentification ClearingMember1 *-- "1..0" ClearingAccount1 : ClearingAccountOwner %% IPartyIdentification118Choice recursion level 1 with max 1 %% IPartyIdentification118Choice recursion level 1 with max 1 %% IPartyIdentification118Choice recursion level 1 with max 1 %% ClearingAccount1 recursion level 1 with max 1 class ClearingAccount1{ AccountType ClearingAccountType3Code } ClearingAccount1 *-- "1..0" CollateralAccount5 : CollateralAccountOwner
ClearingMember1 members
Member name | Description | Data Type / Multiplicity |
---|---|---|
Identification | Identification of the clearing member. | IPartyIdentification118Choice - Required 1..1 |
CreditQuality | Credit quality for the clearing member. | CreditQuality1Code - Required 1..1 |
UltimateParentIdentification | Identification of the ultimate parent of a clearing member if it is not the parent company itself. | IPartyIdentification118Choice - Optional 0..1 |
FuturesCommissionMerchantIndicator | Identifies whether the clearing member is registered under the Commodity Exchange Act. | IsoTrueFalseIndicator - Required 1..1 |
MembershipValidFrom | Date on which the entity becomes a clearing member contractually subject to the CCP’s Rulebook. | IsoISODate - Required 1..1 |
MembershipValidTo | Date on which the clearing member is no longer a member in any clearing services protected by the default waterfall as defined by the CCP’s rules. Typically this will be the day the clearing member’s default fund contribution is repaid or they are no longer contractually subject to rights of assessment. | IsoISODate - Optional 0..1 |
SponsoringClearingMemberIdentification | Identification of another clearing member or institution that acts as sponsor to the clearing member, undertaking certain of its obligations at the central counterparty on its behalf. These obligations typically include, but are not limited to, making default fund contributions and participating in default auctions. | IPartyIdentification118Choice - Optional 0..1 |
ClearingAccountOwner | Operational construct of a central counterparty that defines the relationship between collateral, margin and position accounts and upon default of a clearing member defines the segregation of losses on positions and assets held in that account. | ClearingAccount1 - Unknown 1..0 |
SupplementaryData building block
Additional information that cannot be captured in the structured elements and/or any other specific block. Additional information that can not be captured in the structured fields and/or any other specific block. For comparison, see the ISO20022 official specification
classDiagram direction tb %% SupplementaryData1 recursion level 0 with max 1 class SupplementaryData1{ PlaceAndName IsoMax350Text } SupplementaryData1 *-- "1..1" IsoSupplementaryDataEnvelope1 : Envelope %% IsoSupplementaryDataEnvelope1 recursion level 1 with max 1
SupplementaryData1 members
Member name | Description | Data Type / Multiplicity |
---|---|---|
PlaceAndName | Unambiguous reference to the location where the supplementary data must be inserted in the message instance. In the case of XML, this is expressed by a valid XPath. | IsoMax350Text - Optional 0..1 |
Envelope | Technical element wrapping the supplementary data. | IsoSupplementaryDataEnvelope1 - Required 1..1 |
Extensibility and generalization considerations
To facilitate generalized design patterns in the system, the CCPClearingMemberReportV01 implementation follows a specific implementaiton pattern. First of all, CCPClearingMemberReportV01 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, CCPClearingMemberReportV01Document implements IOuterDocument. Because CCPClearingMemberReportV01 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type CCPClearingMemberReportV01.
classDiagram class IOuterRecord CCPClearingMemberReportV01 --|> IOuterRecord : Implements CCPClearingMemberReportV01Document --|> IOuterDocument~CCPClearingMemberReportV01~ : Implements class IOuterDocument~CCPClearingMemberReportV01~ { CCPClearingMemberReportV01 Message }
Document wrapper for serialization
The only real purpose CCPClearingMemberReportV01Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:auth.054.001.01’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using CCPClearingMemberReportV01.ToDocument() method. The returned CCPClearingMemberReportV01Document value will serialize correctly according to ISO 20022 standards.
classDiagram CCPClearingMemberReportV01Document *-- CCPClearingMemberReportV01 : Document
Sample of message format
This is an abbreviated version of what the message should look like.
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:auth.054.001.01">
<CCPClrMmbRpt>
<ClrMmb>
<!-- ClearingMember inner content -->
</ClrMmb>
<SplmtryData>
<!-- SupplementaryData inner content -->
</SplmtryData>
</CCPClrMmbRpt>
</Document>
Data from ISO specification
This is the technical data from the specification document.
<messageDefinition
xmi:id="_yw5rkeUTEem3X-64-NKdqg"
name="CCPClearingMemberReportV01"
definition="The CCPClearingMemberReport message is sent from the central counterparty to the national competent authority. It is used to inform the national competent authority about the central counterparties clearing members and their clients, and the related account structures."
registrationStatus="Registered"
messageSet="_5z1DIOUQEem3X-64-NKdqg"
xmlTag="CCPClrMmbRpt"
rootElement="Document"
xmlns:xmi="http://www.omg.org/XMI">
<messageBuildingBlock
xmi:id="_yw5rmeUTEem3X-64-NKdqg"
name="ClearingMember"
definition="Legal counterpart to trades cleared through a central counterparty."
registrationStatus="Provisionally Registered"
minOccurs="1"
xmlTag="ClrMmb"
complexType="_l_0jkJXZEeaEh9L5Y0ZaKQ" />
<messageBuildingBlock
xmi:id="_yw5rm-UTEem3X-64-NKdqg"
name="SupplementaryData"
definition="Additional information that cannot be captured in the structured elements and/or any other specific block."
registrationStatus="Provisionally Registered"
minOccurs="0"
xmlTag="SplmtryData"
complexType="_Qn0zC9p-Ed-ak6NoX_4Aeg_468227563" />
<messageDefinitionIdentifier
businessArea="auth"
messageFunctionality="054"
flavour="001"
version="01" />
</messageDefinition>
ISO Building Blocks
The following items are used as building blocks to construct this message.