SecuritiesFinancingReportingPairingRequestV02

auth.078.001.02

The SecuritiesFinancingReportingPairingRequest is sent by the trade repository (TR) to the other trade repositories (TRs) in order to identify the trade repository (TR) holding information on a second leg of a given transaction.

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
%% SecuritiesFinancingReportingPairingRequestV02 recursion level 0 with max 0
SecuritiesFinancingReportingPairingRequestV02 *-- "1..1" TradeTransactionIdentification15 : TransactionIdentification
SecuritiesFinancingReportingPairingRequestV02 *-- "0..1" SupplementaryData1 : SupplementaryData
  

Now, we will zero-in one-by-one on each of these building blocks.

TransactionIdentification building block

Set of information identifying the transactions that are to be paired. Provides details on transaction and conducting counterparty. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% TradeTransactionIdentification15 recursion level 0 with max 1
class TradeTransactionIdentification15{
    UniqueTradeIdentifier IsoMax52Text
}
TradeTransactionIdentification15 *-- "1..1" IOrganisationIdentification15Choice : ReportingCounterparty
TradeTransactionIdentification15 *-- "1..1" IPartyIdentification236Choice : OtherCounterparty
TradeTransactionIdentification15 *-- "0..1" MasterAgreement7 : MasterAgreement
TradeTransactionIdentification15 *-- "0..1" IOrganisationIdentification15Choice : AgentLender
TradeTransactionIdentification15 *-- "0..1" IOrganisationIdentification15Choice : TripartyAgent
%% IOrganisationIdentification15Choice recursion level 1 with max 1
%% IPartyIdentification236Choice recursion level 1 with max 1
%% MasterAgreement7 recursion level 1 with max 1
class MasterAgreement7{
    Version IsoMax50Text
    OtherMasterAgreementDetails IsoMax350Text
}
MasterAgreement7 *-- "1..1" IAgreementType2Choice : Type
%% IOrganisationIdentification15Choice recursion level 1 with max 1
%% IOrganisationIdentification15Choice recursion level 1 with max 1
  

TradeTransactionIdentification15 members

Member name Description Data Type / Multiplicity
ReportingCounterparty Unique code identifying the reporting counterparty. IOrganisationIdentification15Choice - Required 1..1
OtherCounterparty Unique code identifying the entity with which the reporting counterparty concluded the transaction. IPartyIdentification236Choice - Required 1..1
UniqueTradeIdentifier Unique trade Identifier (UTI) as agreed with the counterparty. IsoMax52Text - Optional 0..1
MasterAgreement Details related to the master agreement. MasterAgreement7 - Optional 0..1
AgentLender Identification of the agent lender involved in the securities lending transaction. IOrganisationIdentification15Choice - Optional 0..1
TripartyAgent Identification of the third party that administers the transaction. IOrganisationIdentification15Choice - Optional 0..1

SupplementaryData building block

Additional information that can not be captured in the structured fields 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 SecuritiesFinancingReportingPairingRequestV02 implementation follows a specific implementaiton pattern. First of all, SecuritiesFinancingReportingPairingRequestV02 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, SecuritiesFinancingReportingPairingRequestV02Document implements IOuterDocument. Because SecuritiesFinancingReportingPairingRequestV02 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type SecuritiesFinancingReportingPairingRequestV02.

classDiagram
    class IOuterRecord
    SecuritiesFinancingReportingPairingRequestV02 --|> IOuterRecord : Implements
    SecuritiesFinancingReportingPairingRequestV02Document --|> IOuterDocument~SecuritiesFinancingReportingPairingRequestV02~ : Implements
    class IOuterDocument~SecuritiesFinancingReportingPairingRequestV02~ {
        SecuritiesFinancingReportingPairingRequestV02 Message
     }
  

Document wrapper for serialization

The only real purpose SecuritiesFinancingReportingPairingRequestV02Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:auth.078.001.02’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using SecuritiesFinancingReportingPairingRequestV02.ToDocument() method. The returned SecuritiesFinancingReportingPairingRequestV02Document value will serialize correctly according to ISO 20022 standards.

classDiagram
    SecuritiesFinancingReportingPairingRequestV02Document *-- SecuritiesFinancingReportingPairingRequestV02 : 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.078.001.02">
    <SctiesFincgRptgPairgReq>
        <TxId>
            <!-- TransactionIdentification inner content -->
        </TxId>
        <SplmtryData>
            <!-- SupplementaryData inner content -->
        </SplmtryData>
    </SctiesFincgRptgPairgReq>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_mxP0EcIVEeunlsN4rAgJZA"
  previousVersion="_2zvL_QuAEeqVvtu9Ny8FDA"
  name="SecuritiesFinancingReportingPairingRequestV02"
  definition="The SecuritiesFinancingReportingPairingRequest is sent by the trade repository (TR) to the other trade repositories (TRs) in order to identify the trade repository (TR) holding information on a second leg of a given transaction."
  registrationStatus="Registered"
  messageSet="_9iTc0K2XEeuIDus5QP8udw"
  xmlTag="SctiesFincgRptgPairgReq"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <messageBuildingBlock
    xmi:id="_mxP0E8IVEeunlsN4rAgJZA"
    previousVersion="_2zvL_wuAEeqVvtu9Ny8FDA"
    name="TransactionIdentification"
    definition="Set of information identifying the transactions that are to be paired."
    registrationStatus="Provisionally Registered"
    minOccurs="1"
    xmlTag="TxId"
    complexType="__iW9QcIVEeunlsN4rAgJZA" />
  <messageBuildingBlock
    xmi:id="_mxP0FcIVEeunlsN4rAgJZA"
    previousVersion="_2zvMAQuAEeqVvtu9Ny8FDA"
    name="SupplementaryData"
    definition="Additional information that can not be captured in the structured fields and/or any other specific block."
    registrationStatus="Provisionally Registered"
    minOccurs="0"
    xmlTag="SplmtryData"
    complexType="_Qn0zC9p-Ed-ak6NoX_4Aeg_468227563" />
  <messageDefinitionIdentifier
    businessArea="auth"
    messageFunctionality="078"
    flavour="001"
    version="02" />
</messageDefinition>

ISO Building Blocks

The following items are used as building blocks to construct this message.