Iso20022

ModifyReservationV05

camt.048.001.05

Scope The ModifyReservation message is used to request modifications in the details of one particular reservation set by the member and managed by the transaction administrator. Usage After the receipt of a ModifyReservation message the transaction administrator checks whether the amount of liquidity on the member account is sufficient to set the reservation. If there is enough liquidity available, the requested amount will be reserved. In case the requested amount exceeds the available liquidity, only the available liquidity will be reserved. The difference will not be blocked at a later point, even if the account balance of the member reaches the level of the initial reservation request. The reservation can be effected directly by the member, who has the possibility to:

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
%% ModifyReservationV05 recursion level 0 with max 0
ModifyReservationV05 *-- "1..1" MessageHeader1 : MessageHeader
ModifyReservationV05 *-- "1..1" ICurrentOrDefaultReservation2Choice : ReservationIdentification
ModifyReservationV05 *-- "1..1" Reservation4 : NewReservationValueSet
ModifyReservationV05 *-- "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

ReservationIdentification building block

Identification of the default reservation. Current or default reservation set by the member and managed by the transaction administrator. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% ICurrentOrDefaultReservation2Choice recursion level 0 with max 1

CurrentOrDefaultReservation2Choice members

Member name Description Data Type / Multiplicity

NewReservationValueSet building block

New reservation values. Liquidity set aside by the account owner for specific purposes. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% Reservation4 recursion level 0 with max 1
Reservation4 *-- "0..1" IDateAndDateTime2Choice : StartDateTime
Reservation4 *-- "1..1" IAmount2Choice : Amount
%% IDateAndDateTime2Choice recursion level 1 with max 1
%% IAmount2Choice recursion level 1 with max 1

Reservation4 members

Member name Description Data Type / Multiplicity
StartDateTime Date and time at which the reservation becomes effective. IDateAndDateTime2Choice - Optional 0..1
Amount Amount of money of the limit, expressed in an eligible currency. IAmount2Choice - Required 1..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 ModifyReservationV05 implementation follows a specific implementaiton pattern. First of all, ModifyReservationV05 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, ModifyReservationV05Document implements IOuterDocument. Because ModifyReservationV05 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type ModifyReservationV05.

classDiagram
    class IOuterRecord
    ModifyReservationV05 --|> IOuterRecord : Implements
    ModifyReservationV05Document --|> IOuterDocument~ModifyReservationV05~ : Implements
    class IOuterDocument~ModifyReservationV05~ {
        ModifyReservationV05 Message
     }

Document wrapper for serialization

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

classDiagram
    ModifyReservationV05Document *-- ModifyReservationV05 : 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.048.001.05">
    <ModfyRsvatn>
        <MsgHdr>
            <!-- MessageHeader inner content -->
        </MsgHdr>
        <RsvatnId>
            <!-- ReservationIdentification inner content -->
        </RsvatnId>
        <NewRsvatnValSet>
            <!-- NewReservationValueSet inner content -->
        </NewRsvatnValSet>
        <SplmtryData>
            <!-- SupplementaryData inner content -->
        </SplmtryData>
    </ModfyRsvatn>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_jwlb0xbvEeiyVv5j1vf1VQ"
  nextVersions="_ThUsgdb6Eeq_l4BJLVUF2Q"
  name="ModifyReservationV05"
  definition="Scope&#xA;The ModifyReservation message is used to request modifications in the details of one particular reservation set by the member and managed by the transaction administrator.&#xA;Usage&#xA;After the receipt of a ModifyReservation message the transaction administrator checks whether the amount of liquidity on the member account is sufficient to set the reservation.&#xA;If there is enough liquidity available, the requested amount will be reserved. In case the requested amount exceeds the available liquidity, only the available liquidity will be reserved. The difference will not be blocked at a later point, even if the account balance of the member reaches the level of the initial reservation request.&#xA;The reservation can be effected directly by the member, who has the possibility to: &#xA;- reset the reserved liquidity to zero&#xA;- change the reservation amount during the day with immediate effect&#xA;- input a default reservation amount for the following day(s); valid until a new reservation amount is requested&#xA;After the receipt of a ModifyReservation message the transaction administrator checks whether the amount of liquidity on the member account is sufficient to set the reservation."
  registrationStatus="Registered"
  messageSet="_S0OMdGY1EeuQ__SOdbf47A"
  xmlTag="ModfyRsvatn"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <messageBuildingBlock
    xmi:id="_jwlb1RbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUsh9b6Eeq_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="_jwlb1xbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUsidb6Eeq_l4BJLVUF2Q"
    name="ReservationIdentification"
    definition="Identification of the default reservation."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="RsvatnId"
    complexType="_BndOfW4-EeiU9cctagi5ow" />
  <messageBuildingBlock
    xmi:id="_jwlb2RbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUsi9b6Eeq_l4BJLVUF2Q"
    name="NewReservationValueSet"
    definition="New reservation values."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="NewRsvatnValSet"
    complexType="_hsth0ZliEeeE1Ya-LgRsuQ" />
  <messageBuildingBlock
    xmi:id="_jwlb2xbvEeiyVv5j1vf1VQ"
    nextVersions="_ThUsjdb6Eeq_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="048"
    flavour="001"
    version="05" />
</messageDefinition>

ISO Building Blocks

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