camt.024.001.07
Scope The ModifyStandingOrder message is sent by a member to the transaction administrator. It is used to request a change in the features of a permanent order for the transfer of funds between two accounts belonging to the same member and being held at the transaction administrator. Usage There should be one standing order per (direct) member and per business day. The ModifyStandingOrder message must not be used to request a transfer of funds between accounts during the working day. The liquidity transfer messages must be used for this purpose. There is no need to have a standing order to empty the settlement account at the end of the day and transfer the funds to the current account. For liquidity savings purposes, systems will effect the necessary transfers automatically when and where relevant. The ModifyStandingOrder message first identifies the standing order to be modified and then provide the details of the new standing order. The elements that can be modified are:
- amount
- account to be credited
- account to be debited
- account owner (for on behalf scenario)
- frequency of payment
- daytime or overnight processing
- dates when the standing order begins and ceases to be effective Based on the criteria received within the ModifyStandingOrder message, the transaction administrator will execute or reject the requested modifications. The transaction administrator may send a Receipt message as a reply to the Modify Standing Order request. To verify the outcome of the request, the member may submit a GetStandingOrder message with the appropriate search criteria.
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 %% ModifyStandingOrderV07 recursion level 0 with max 0 ModifyStandingOrderV07 *-- "1..1" MessageHeader1 : MessageHeader ModifyStandingOrderV07 *-- "1..1" StandingOrderIdentification6 : StandingOrderIdentification ModifyStandingOrderV07 *-- "1..1" StandingOrder8 : NewStandingOrderValueSet ModifyStandingOrderV07 *-- "0..1" SupplementaryData1 : SupplementaryData
Now, we will zero-in one-by-one on each of these building blocks.
MessageHeader building block
Common business identification for the message. Set of characteristics, such as the identification or the creation date and time, specific to the message. For comparison, see the ISO20022 official specification
classDiagram direction tb %% MessageHeader1 recursion level 0 with max 1 class MessageHeader1{ MessageIdentification IsoMax35Text CreationDateTime IsoISODateTime }
MessageHeader1 members
Member name | Description | Data Type / Multiplicity |
---|---|---|
MessageIdentification | Point to point reference, as assigned by the sender, to unambiguously identify the message. Usage: The sender has to make sure that MessageIdentification is unique for a pre-agreed period. | IsoMax35Text - Required 1..1 |
CreationDateTime | Date and time at which the message was created. | IsoISODateTime - Optional 0..1 |
StandingOrderIdentification building block
Identifies the standing order. Defines the elements used to uniquely identify a standing order. For comparison, see the ISO20022 official specification
classDiagram direction tb %% StandingOrderIdentification6 recursion level 0 with max 1 class StandingOrderIdentification6{ Identification IsoMax35Text } StandingOrderIdentification6 *-- "1..1" CashAccount40 : Account StandingOrderIdentification6 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : AccountOwner %% CashAccount40 recursion level 1 with max 1 class CashAccount40{ Currency ActiveOrHistoricCurrencyCode Name IsoMax70Text } CashAccount40 *-- "0..1" IAccountIdentification4Choice : Identification CashAccount40 *-- "0..1" ICashAccountType2Choice : Type CashAccount40 *-- "0..1" ProxyAccountIdentification1 : Proxy %% BranchAndFinancialInstitutionIdentification6 recursion level 1 with max 1 BranchAndFinancialInstitutionIdentification6 *-- "1..1" FinancialInstitutionIdentification18 : FinancialInstitutionIdentification BranchAndFinancialInstitutionIdentification6 *-- "0..1" BranchData3 : BranchIdentification
StandingOrderIdentification6 members
Member name | Description | Data Type / Multiplicity |
---|---|---|
Identification | Unique and unambiguous identification for a standing order, as assigned by the account servicer or the account owner. | IsoMax35Text - Optional 0..1 |
Account | Business relationship between two entities; one entity is the account owner, the other entity is the account servicer. | CashAccount40 - Required 1..1 |
AccountOwner | Party that legally owns the account. | BranchAndFinancialInstitutionIdentification6 - Optional 0..1 |
NewStandingOrderValueSet building block
New set of values for the standing order. New standing order values. For comparison, see the ISO20022 official specification
classDiagram direction tb %% StandingOrder8 recursion level 0 with max 1 class StandingOrder8{ Frequency Frequency2Code ZeroSweepIndicator IsoTrueFalseIndicator } StandingOrder8 *-- "0..1" IAmount2Choice : Amount StandingOrder8 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : Creditor StandingOrder8 *-- "0..1" CashAccount40 : CreditorAccount StandingOrder8 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : Debtor StandingOrder8 *-- "0..1" CashAccount40 : DebtorAccount StandingOrder8 *-- "0..1" IExecutionType1Choice : ExecutionType StandingOrder8 *-- "0..1" IDatePeriod2Choice : ValidityPeriod %% IAmount2Choice recursion level 1 with max 1 %% BranchAndFinancialInstitutionIdentification6 recursion level 1 with max 1 BranchAndFinancialInstitutionIdentification6 *-- "1..1" FinancialInstitutionIdentification18 : FinancialInstitutionIdentification BranchAndFinancialInstitutionIdentification6 *-- "0..1" BranchData3 : BranchIdentification %% CashAccount40 recursion level 1 with max 1 class CashAccount40{ Currency ActiveOrHistoricCurrencyCode Name IsoMax70Text } CashAccount40 *-- "0..1" IAccountIdentification4Choice : Identification CashAccount40 *-- "0..1" ICashAccountType2Choice : Type CashAccount40 *-- "0..1" ProxyAccountIdentification1 : Proxy %% BranchAndFinancialInstitutionIdentification6 recursion level 1 with max 1 BranchAndFinancialInstitutionIdentification6 *-- "1..1" FinancialInstitutionIdentification18 : FinancialInstitutionIdentification BranchAndFinancialInstitutionIdentification6 *-- "0..1" BranchData3 : BranchIdentification %% CashAccount40 recursion level 1 with max 1 class CashAccount40{ Currency ActiveOrHistoricCurrencyCode Name IsoMax70Text } CashAccount40 *-- "0..1" IAccountIdentification4Choice : Identification CashAccount40 *-- "0..1" ICashAccountType2Choice : Type CashAccount40 *-- "0..1" ProxyAccountIdentification1 : Proxy %% IExecutionType1Choice recursion level 1 with max 1 %% IDatePeriod2Choice recursion level 1 with max 1
StandingOrder8 members
Member name | Description | Data Type / Multiplicity |
---|---|---|
Amount | Amount of money and currency to be transferred when a payment instruction is created as a result of a standing order. | IAmount2Choice - Optional 0..1 |
Creditor | Party to which an amount of money is due. | BranchAndFinancialInstitutionIdentification6 - Optional 0..1 |
CreditorAccount | Cash account credited from a standing order mechanism. | CashAccount40 - Optional 0..1 |
Debtor | Party that owes an amount of money to the (ultimate) creditor. | BranchAndFinancialInstitutionIdentification6 - Optional 0..1 |
DebtorAccount | Cash account debited from a standing order mechanism. | CashAccount40 - Optional 0..1 |
ExecutionType | Defines whether the standing order is executed through a time-based or an event-based trigger. | IExecutionType1Choice - Optional 0..1 |
Frequency | Regularity with which payment instructions are to be created and processed as a result of the standing order, such as daily, weekly, or monthly. | Frequency2Code - Optional 0..1 |
ValidityPeriod | Dates during which the standing order is in effect. | IDatePeriod2Choice - Optional 0..1 |
ZeroSweepIndicator | Indicates whether the standing order is defined as a zero sweeping order. When true, the liquidity transfer standing order will transfer all amount of money out of the account so the resulting balance is zero. | IsoTrueFalseIndicator - Optional 0..1 |
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 ModifyStandingOrderV07 implementation follows a specific implementaiton pattern. First of all, ModifyStandingOrderV07 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, ModifyStandingOrderV07Document implements IOuterDocument. Because ModifyStandingOrderV07 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type ModifyStandingOrderV07.
classDiagram class IOuterRecord ModifyStandingOrderV07 --|> IOuterRecord : Implements ModifyStandingOrderV07Document --|> IOuterDocument~ModifyStandingOrderV07~ : Implements class IOuterDocument~ModifyStandingOrderV07~ { ModifyStandingOrderV07 Message }
Document wrapper for serialization
The only real purpose ModifyStandingOrderV07Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:camt.024.001.07’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using ModifyStandingOrderV07.ToDocument() method. The returned ModifyStandingOrderV07Document value will serialize correctly according to ISO 20022 standards.
classDiagram ModifyStandingOrderV07Document *-- ModifyStandingOrderV07 : 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:camt.024.001.07">
<ModfyStgOrdr>
<MsgHdr>
<!-- MessageHeader inner content -->
</MsgHdr>
<StgOrdrId>
<!-- StandingOrderIdentification inner content -->
</StgOrdrId>
<NewStgOrdrValSet>
<!-- NewStandingOrderValueSet inner content -->
</NewStgOrdrValSet>
<SplmtryData>
<!-- SupplementaryData inner content -->
</SplmtryData>
</ModfyStgOrdr>
</Document>
Data from ISO specification
This is the technical data from the specification document.
<messageDefinition
xmi:id="_ThUsj9b6Eeq_l4BJLVUF2Q"
previousVersion="_jwlb3RbvEeiyVv5j1vf1VQ"
name="ModifyStandingOrderV07"
definition="Scope
The ModifyStandingOrder message is sent by a member to the transaction administrator.
It is used to request a change in the features of a permanent order for the transfer of funds between two accounts belonging to the same member and being held at the transaction administrator.
Usage
There should be one standing order per (direct) member and per business day. The ModifyStandingOrder message must not be used to request a transfer of funds between accounts during the working day. The liquidity transfer messages must be used for this purpose. There is no need to have a standing order to empty the settlement account at the end of the day and transfer the funds to the current account. For liquidity savings purposes, systems will effect the necessary transfers automatically when and where relevant.
The ModifyStandingOrder message first identifies the standing order to be modified and then provide the details of the new standing order. The elements that can be modified are:
- amount
- account to be credited
- account to be debited
- account owner (for on behalf scenario)
- frequency of payment
- daytime or overnight processing
- dates when the standing order begins and ceases to be effective
Based on the criteria received within the ModifyStandingOrder message, the transaction administrator will execute or reject the requested modifications.
The transaction administrator may send a Receipt message as a reply to the Modify Standing Order request. To verify the outcome of the request, the member may submit a GetStandingOrder message with the appropriate search criteria."
registrationStatus="Registered"
messageSet="_SZTDoxcNEeiyVv5j1vf1VQ"
xmlTag="ModfyStgOrdr"
rootElement="Document"
xmlns:xmi="http://www.omg.org/XMI">
<messageBuildingBlock
xmi:id="_ThUsl9b6Eeq_l4BJLVUF2Q"
previousVersion="_jwlb4RbvEeiyVv5j1vf1VQ"
name="MessageHeader"
definition="Common business identification for the message."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="1"
xmlTag="MsgHdr"
complexType="_75DzkaMgEeCJ6YNENx4h-w_-613853819" />
<messageBuildingBlock
xmi:id="_ThUsmdb6Eeq_l4BJLVUF2Q"
previousVersion="_jwlb4xbvEeiyVv5j1vf1VQ"
name="StandingOrderIdentification"
definition="Identifies the standing order."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="1"
xmlTag="StgOrdrId"
complexType="_bSDs0dcZEeqRFcf2R4bPBw" />
<messageBuildingBlock
xmi:id="_ThUsm9b6Eeq_l4BJLVUF2Q"
previousVersion="_jwlb5RbvEeiyVv5j1vf1VQ"
name="NewStandingOrderValueSet"
definition="New set of values for the standing order."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="1"
xmlTag="NewStgOrdrValSet"
complexType="_eQ74wdcZEeqRFcf2R4bPBw" />
<messageBuildingBlock
xmi:id="_ThUsndb6Eeq_l4BJLVUF2Q"
previousVersion="_jwlb5xbvEeiyVv5j1vf1VQ"
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="camt"
messageFunctionality="024"
flavour="001"
version="07" />
</messageDefinition>
ISO Building Blocks
The following items are used as building blocks to construct this message.