Iso20022

ModifyStandingOrderV06

camt.024.001.06

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
%% ModifyStandingOrderV06 recursion level 0 with max 0
ModifyStandingOrderV06 *-- "1..1" MessageHeader1 : MessageHeader
ModifyStandingOrderV06 *-- "1..1" StandingOrderIdentification4 : StandingOrderIdentification
ModifyStandingOrderV06 *-- "1..1" StandingOrder7 : NewStandingOrderValueSet
ModifyStandingOrderV06 *-- "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
%% StandingOrderIdentification4 recursion level 0 with max 1
class StandingOrderIdentification4{
    Identification IsoMax35Text
}
StandingOrderIdentification4 *-- "1..1" CashAccount38 : Account
StandingOrderIdentification4 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : AccountOwner
%% CashAccount38 recursion level 1 with max 1
class CashAccount38{
    Currency ActiveOrHistoricCurrencyCode
    Name IsoMax70Text
}
CashAccount38 *-- "1..1" IAccountIdentification4Choice : Identification
CashAccount38 *-- "0..1" ICashAccountType2Choice : Type
CashAccount38 *-- "0..1" ProxyAccountIdentification1 : Proxy
%% BranchAndFinancialInstitutionIdentification6 recursion level 1 with max 1
BranchAndFinancialInstitutionIdentification6 *-- "1..1" FinancialInstitutionIdentification18 : FinancialInstitutionIdentification
BranchAndFinancialInstitutionIdentification6 *-- "0..1" BranchData3 : BranchIdentification

StandingOrderIdentification4 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. .
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
%% StandingOrder7 recursion level 0 with max 1
class StandingOrder7{
    Frequency Frequency2Code
    ZeroSweepIndicator IsoTrueFalseIndicator
}
StandingOrder7 *-- "0..1" IAmount2Choice : Amount
StandingOrder7 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : Creditor
StandingOrder7 *-- "0..1" CashAccount38 : CreditorAccount
StandingOrder7 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : Debtor
StandingOrder7 *-- "0..1" CashAccount38 : DebtorAccount
StandingOrder7 *-- "0..1" IExecutionType1Choice : ExecutionType
StandingOrder7 *-- "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
%% CashAccount38 recursion level 1 with max 1
class CashAccount38{
    Currency ActiveOrHistoricCurrencyCode
    Name IsoMax70Text
}
CashAccount38 *-- "1..1" IAccountIdentification4Choice : Identification
CashAccount38 *-- "0..1" ICashAccountType2Choice : Type
CashAccount38 *-- "0..1" ProxyAccountIdentification1 : Proxy
%% BranchAndFinancialInstitutionIdentification6 recursion level 1 with max 1
BranchAndFinancialInstitutionIdentification6 *-- "1..1" FinancialInstitutionIdentification18 : FinancialInstitutionIdentification
BranchAndFinancialInstitutionIdentification6 *-- "0..1" BranchData3 : BranchIdentification
%% CashAccount38 recursion level 1 with max 1
class CashAccount38{
    Currency ActiveOrHistoricCurrencyCode
    Name IsoMax70Text
}
CashAccount38 *-- "1..1" IAccountIdentification4Choice : Identification
CashAccount38 *-- "0..1" ICashAccountType2Choice : Type
CashAccount38 *-- "0..1" ProxyAccountIdentification1 : Proxy
%% IExecutionType1Choice recursion level 1 with max 1
%% IDatePeriod2Choice recursion level 1 with max 1

StandingOrder7 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. CashAccount38 - 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. CashAccount38 - 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 ModifyStandingOrderV06 implementation follows a specific implementaiton pattern. First of all, ModifyStandingOrderV06 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, ModifyStandingOrderV06Document implements IOuterDocument. Because ModifyStandingOrderV06 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type ModifyStandingOrderV06.

classDiagram
    class IOuterRecord
    ModifyStandingOrderV06 --|> IOuterRecord : Implements
    ModifyStandingOrderV06Document --|> IOuterDocument~ModifyStandingOrderV06~ : Implements
    class IOuterDocument~ModifyStandingOrderV06~ {
        ModifyStandingOrderV06 Message
     }

Document wrapper for serialization

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

classDiagram
    ModifyStandingOrderV06Document *-- ModifyStandingOrderV06 : 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.06">
    <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="_jwlb3RbvEeiyVv5j1vf1VQ"
  nextVersions="_ThUsj9b6Eeq_l4BJLVUF2Q"
  name="ModifyStandingOrderV06"
  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="_S0OMdGY1EeuQ__SOdbf47A"
  xmlTag="ModfyStgOrdr"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <constraint
    xmi:id="_jwlb3xbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUskdb6Eeq_l4BJLVUF2Q"
    name="ModifyStandingOrderRules"
    definition="The NewStandingOrderValueSet can consist on an Amount, a DebitAccount, a CreditAccount, a ValidityPeriod or a Periodicity. At a minimum, one of these elements must be present."
    registrationStatus="Provisionally Registered" />
  <messageBuildingBlock
    xmi:id="_jwlb4RbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUsl9b6Eeq_l4BJLVUF2Q"
    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="_jwlb4xbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUsmdb6Eeq_l4BJLVUF2Q"
    name="StandingOrderIdentification"
    definition="Identifies the standing order."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="StgOrdrId"
    complexType="_CZ-QhW4-EeiU9cctagi5ow" />
  <messageBuildingBlock
    xmi:id="_jwlb5RbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUsm9b6Eeq_l4BJLVUF2Q"
    name="NewStandingOrderValueSet"
    definition="New set of values for the standing order."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="NewStgOrdrValSet"
    complexType="_parnIXXtEei3jO6riKEVXg" />
  <messageBuildingBlock
    xmi:id="_jwlb5xbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUsndb6Eeq_l4BJLVUF2Q"
    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="06" />
</messageDefinition>

ISO Building Blocks

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