ModifyStandingOrderV07

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:

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&#xD;&#xA;The ModifyStandingOrder message is sent by a member to the transaction administrator.&#xD;&#xA;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.&#xD;&#xA;Usage&#xD;&#xA;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.&#xD;&#xA;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:&#xD;&#xA;- amount&#xD;&#xA;- account to be credited&#xD;&#xA;- account to be debited&#xD;&#xA;- account owner (for on behalf scenario)&#xD;&#xA;- frequency of payment&#xD;&#xA;- daytime or overnight processing&#xD;&#xA;- dates when the standing order begins and ceases to be effective&#xD;&#xA;Based on the criteria received within the ModifyStandingOrder message, the transaction administrator will execute or reject the requested modifications.&#xD;&#xA;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.