sese.038.001.03
Scope This message is sent by an account owner to an account servicer.
The account owner will generally be:
- a central securities depository participant which has an account with a central securities depository or a market infrastructure
- an investment manager which has an account with a custodian acting as accounting and/or settlement agent.
It is used to request the modification of non core business data (matching or non-matching) information in a pending or settled instruction. It can also be used for the enrichment of an incomplete transaction.
Usage The modification must only contain the data to be modified. The message may also be used to:
- re-send a message sent by the account owner to the account servicer,
- provide a third party with a copy of a message being sent by the account owner for information,
- re-send to a third party a copy of a message being sent by the account owner for information using the relevant elements in the Business Application Header.
ISO 15022 - 20022 Coexistence This ISO 20022 message is reversed engineered from ISO 15022. Both standards will coexist for a certain number of years. Until this coexistence period ends, the usage of certain data types is restricted to ensure interoperability between ISO 15022 and 20022 users. Compliance to these rules is mandatory in a coexistence environment. The coexistence restrictions are described in a Textual Rule linked to the Message Items they concern. These coexistence textual rules are clearly identified as follows: “CoexistenceXxxxRule”.
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
%% SecuritiesSettlementTransactionModificationRequestV03 recursion level 0 with max 0
SecuritiesSettlementTransactionModificationRequestV03 *-- "1..1" TransactionDetails64 : ModifiedTransactionDetails
SecuritiesSettlementTransactionModificationRequestV03 *-- "1..3" IUpdateType11Choice : UpdateType
Now, we will zero-in one-by-one on each of these building blocks.
ModifiedTransactionDetails building block
Identifies the details of the transaction that is being modified. Identifies the details of the transaction. For comparison, see the ISO20022 official specification
classDiagram
direction tb
%% TransactionDetails64 recursion level 0 with max 1
class TransactionDetails64{
AccountServicerTransactionIdentification IsoMax35Text
MarketInfrastructureTransactionIdentification IsoMax35Text
ProcessorTransactionIdentification IsoMax35Text
OtherTransactionIdentification IsoMax35Text
}
TransactionDetails64 *-- "1..1" SettlementTypeAndIdentification3 : AccountOwnerTransactionIdentification
TransactionDetails64 *-- "0..1" IPartyIdentification36Choice : AccountOwner
TransactionDetails64 *-- "1..1" SecuritiesAccount13 : SafekeepingAccount
TransactionDetails64 *-- "0..1" TransactionDetails28 : TransactionDetails
%% SettlementTypeAndIdentification3 recursion level 1 with max 1
class SettlementTypeAndIdentification3{
TransactionIdentification IsoMax35Text
SecuritiesMovementType ReceiveDelivery1Code
Payment DeliveryReceiptType2Code
}
%% IPartyIdentification36Choice recursion level 1 with max 1
%% SecuritiesAccount13 recursion level 1 with max 1
class SecuritiesAccount13{
Identification IsoMax35Text
Name IsoMax70Text
}
SecuritiesAccount13 *-- "0..1" GenericIdentification20 : Type
%% TransactionDetails28 recursion level 1 with max 1
TransactionDetails28 *-- "1..1" SecurityIdentification14 : FinancialInstrumentIdentification
TransactionDetails28 *-- "0..1" ITradeDate1Choice : TradeDate
TransactionDetails28 *-- "1..1" ISettlementDate1Choice : SettlementDate
TransactionDetails28 *-- "1..1" IQuantity6Choice : SettlementQuantity
TransactionDetails28 *-- "0..1" AmountAndDirection8 : SettlementAmount
TransactionDetails28 *-- "0..1" SettlementParties12 : DeliveringSettlementParties
TransactionDetails28 *-- "0..1" SettlementParties12 : ReceivingSettlementParties
TransactionDetails28 *-- "0..1" IPartyIdentification37Choice : Investor
TransactionDetails64 members
| Member name | Description | Data Type / Multiplicity |
|---|---|---|
| AccountOwnerTransactionIdentification | Unambiguous identification of the transaction as known by the account owner (or the instructing party managing the account). | SettlementTypeAndIdentification3 - Required 1..1 |
| AccountServicerTransactionIdentification | Unambiguous identification of the transaction as known by the account servicer. | IsoMax35Text - Optional 0..1 |
| MarketInfrastructureTransactionIdentification | Identification of a transaction assigned by a market infrastructure other than a central securities depository, for example, Target2-Securities. | IsoMax35Text - Optional 0..1 |
| ProcessorTransactionIdentification | Identification of the transaction assigned by the processor of the instruction other than the account owner the account servicer and the market infrastructure. | IsoMax35Text - Optional 0..1 |
| OtherTransactionIdentification | Identification of a transaction that cannot be identified using a standard reference element present in the message. | IsoMax35Text - Optional 0..1 |
| AccountOwner | Party that legally owns the account. | IPartyIdentification36Choice - Optional 0..1 |
| SafekeepingAccount | Account to or from which a securities entry is made. | SecuritiesAccount13 - Required 1..1 |
| TransactionDetails | Provides additional details on the transaction which can not be included within the structured fields of the message. | TransactionDetails28 - Optional 0..1 |
UpdateType building block
Specifies the type of update requested. Specifies the type of update requested. That is addition, deletion or modification. For comparison, see the ISO20022 official specification
classDiagram direction tb %% IUpdateType11Choice recursion level 0 with max 1
UpdateType11Choice members
| Member name | Description | Data Type / Multiplicity |
|---|
Extensibility and generalization considerations
To facilitate generalized design patterns in the system, the SecuritiesSettlementTransactionModificationRequestV03 implementation follows a specific implementaiton pattern. First of all, SecuritiesSettlementTransactionModificationRequestV03 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, SecuritiesSettlementTransactionModificationRequestV03Document implements IOuterDocument. Because SecuritiesSettlementTransactionModificationRequestV03 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type SecuritiesSettlementTransactionModificationRequestV03.
classDiagram
class IOuterRecord
SecuritiesSettlementTransactionModificationRequestV03 --|> IOuterRecord : Implements
SecuritiesSettlementTransactionModificationRequestV03Document --|> IOuterDocument~SecuritiesSettlementTransactionModificationRequestV03~ : Implements
class IOuterDocument~SecuritiesSettlementTransactionModificationRequestV03~ {
SecuritiesSettlementTransactionModificationRequestV03 Message
}
Document wrapper for serialization
The only real purpose SecuritiesSettlementTransactionModificationRequestV03Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:sese.038.001.03’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using SecuritiesSettlementTransactionModificationRequestV03.ToDocument() method. The returned SecuritiesSettlementTransactionModificationRequestV03Document value will serialize correctly according to ISO 20022 standards.
classDiagram
SecuritiesSettlementTransactionModificationRequestV03Document *-- SecuritiesSettlementTransactionModificationRequestV03 : 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:sese.038.001.03">
<SctiesSttlmTxModReq>
<ModfdTxDtls>
<!-- ModifiedTransactionDetails inner content -->
</ModfdTxDtls>
<UpdTp>
<!-- UpdateType inner content -->
</UpdTp>
</SctiesSttlmTxModReq>
</Document>
Data from ISO specification
This is the technical data from the specification document.
<messageDefinition
xmi:id="_rdfOUSRNEeON6sEIseGaUg"
nextVersions="_YSWH4wCTEeW_3KiG8SEjHA"
previousVersion="_51rRcQxyEeKMmbvHOtE4SA"
name="SecuritiesSettlementTransactionModificationRequestV03"
definition="Scope
This message is sent by an account owner to an account servicer. 

The account owner will generally be:
- a central securities depository participant which has an account with a central securities depository or a market infrastructure
- an investment manager which has an account with a custodian acting as accounting and/or settlement agent.

It is used to request the modification of non core business data (matching or non-matching) information in a pending or settled instruction. It can also be used for the enrichment of an incomplete transaction.

Usage
The modification must only contain the data to be modified.
The message may also be used to:
- re-send a message sent by the account owner to the account servicer,
- provide a third party with a copy of a message being sent by the account owner for information,
- re-send to a third party a copy of a message being sent by the account owner for information
using the relevant elements in the Business Application Header.

ISO 15022 - 20022 Coexistence
This ISO 20022 message is reversed engineered from ISO 15022. Both standards will coexist for a certain number of years. Until this coexistence period ends, the usage of certain data types is restricted to ensure interoperability between ISO 15022 and 20022 users. Compliance to these rules is mandatory in a coexistence environment. The coexistence restrictions are described in a Textual Rule linked to the Message Items they concern. These coexistence textual rules are clearly identified as follows: “CoexistenceXxxxRule”."
registrationStatus="Registered"
messageSet="_urpIICeJEeOCeO5e7islRQ"
xmlTag="SctiesSttlmTxModReq"
rootElement="Document"
xmlns:xmi="http://www.omg.org/XMI">
<constraint
xmi:id="_rdfOUyRNEeON6sEIseGaUg"
nextVersions="_YSWH5QCTEeW_3KiG8SEjHA"
previousVersion="_51rRdQxyEeKMmbvHOtE4SA"
name="PhysicalInstructionDetailsUsageRule"
definition="PhysicalInstructionDetails can only be used with free of payment instructions."
registrationStatus="Provisionally Registered" />
<constraint
xmi:id="_rdfOVSRNEeON6sEIseGaUg"
nextVersions="_YSWH5wCTEeW_3KiG8SEjHA"
previousVersion="_51rReQxyEeKMmbvHOtE4SA"
name="SecuritiesFinancingSettlementUsageRule"
definition="In the framework of Securities Financing (repo, reverse repo, sec lending, sec borrowing), the SettlementInstruction can only be used for the plain vanilla settlement of the opening leg and closing leg."
registrationStatus="Provisionally Registered" />
<constraint
xmi:id="_rdfOVyRNEeON6sEIseGaUg"
nextVersions="_YSWH6QCTEeW_3KiG8SEjHA"
previousVersion="_51rRfQxyEeKMmbvHOtE4SA"
name="LinkagesUsageRule"
definition="The linkages can only be used when modifying the Paired or Turned Quantity. For the changes of linking and unlinking messages this must be done with the SecuritiesSettlementConditionsModificationRequest."
registrationStatus="Provisionally Registered" />
<messageBuildingBlock
xmi:id="_rdfOWSRNEeON6sEIseGaUg"
nextVersions="_YSWH6wCTEeW_3KiG8SEjHA"
previousVersion="_51rRgQxyEeKMmbvHOtE4SA"
name="ModifiedTransactionDetails"
definition="Identifies the details of the transaction that is being modified."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="1"
xmlTag="ModfdTxDtls"
complexType="_YJhacSXmEeODP_a1w_Y44Q" />
<messageBuildingBlock
xmi:id="_rdfOWyRNEeON6sEIseGaUg"
nextVersions="_YSWH7QCTEeW_3KiG8SEjHA"
previousVersion="_51rRhQxyEeKMmbvHOtE4SA"
name="UpdateType"
definition="Specifies the type of update requested."
registrationStatus="Provisionally Registered"
maxOccurs="3"
minOccurs="1"
xmlTag="UpdTp"
complexType="_5o94kyTwEeOSHvJr_wacAw" />
<messageDefinitionIdentifier
businessArea="sese"
messageFunctionality="038"
flavour="001"
version="03" />
</messageDefinition>
ISO Building Blocks
The following items are used as building blocks to construct this message.