camt.008.001.10
Scope The CancelTransaction message is sent by a member to the transaction administrator. It is used to request the cancellation of one payment instruction held at the transaction administrator and sent by the member. Usage Following normal business flows, transactions registered by the transaction administrator may be queued for later settlement (because of insufficient funds available, because of risk or liquidity limits, etc.). A transaction may have a series of statuses. These can be transient (such as pending or related types), final (such as rejected, revoked and/or settled) or the status may even be defined as a proprietary status. Members of a system need to have information about the payments queue(s), and must have the ability to take action (that is, to cancel or modify the transaction(s) to be settled). Note, however, that actions by a member will always concern transactions in a transient status. For this reason, at any time during the operating hours of the system, the member can request the cancellation of a transaction that has not received a final status. The member will submit a CancelTransaction message containing the identification of the transaction to be cancelled. Based on the criteria received within the CancelTransaction message, the transaction administrator will execute or reject the requested cancellation. The transaction administrator may send a Receipt message as a reply to the CancelTransaction request. To verify the outcome of the request, the member may submit a GetTransaction 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
%% CancelTransactionV10 recursion level 0 with max 0
CancelTransactionV10 *-- "1..1" MessageHeader9 : MessageHeader
CancelTransactionV10 *-- "1..1" IPaymentIdentification7Choice : PaymentIdentification
CancelTransactionV10 *-- "0..1" CashAccount40 : CashAccount
CancelTransactionV10 *-- "0..1" PaymentCancellationReason5 : CancellationReason
CancelTransactionV10 *-- "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
%% MessageHeader9 recursion level 0 with max 1
class MessageHeader9{
MessageIdentification IsoMax35Text
CreationDateTime IsoISODateTime
}
MessageHeader9 *-- "0..1" IRequestType4Choice : RequestType
%% IRequestType4Choice recursion level 1 with max 1
MessageHeader9 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. |
| CreationDateTime | Date and time at which the message was created. | IsoISODateTime - Optional 0..1 |
| RequestType | Specific actions to be executed through the request. | IRequestType4Choice - Optional 0..1 |
PaymentIdentification building block
Reference to the instruction related to the payment for which information is requested. Choice between ways of identifying a payment instruction by its references and business identification. For comparison, see the ISO20022 official specification
classDiagram direction tb %% IPaymentIdentification7Choice recursion level 0 with max 1
PaymentIdentification7Choice members
| Member name | Description | Data Type / Multiplicity |
|---|
CashAccount building block
Account to or from which a cash entry is made. Provides the details to identify an account. For comparison, see the ISO20022 official specification
classDiagram
direction tb
%% CashAccount40 recursion level 0 with max 1
class CashAccount40{
Currency ActiveOrHistoricCurrencyCode
Name IsoMax70Text
}
CashAccount40 *-- "0..1" IAccountIdentification4Choice : Identification
CashAccount40 *-- "0..1" ICashAccountType2Choice : Type
CashAccount40 *-- "0..1" ProxyAccountIdentification1 : Proxy
%% IAccountIdentification4Choice recursion level 1 with max 1
%% ICashAccountType2Choice recursion level 1 with max 1
%% ProxyAccountIdentification1 recursion level 1 with max 1
class ProxyAccountIdentification1{
Identification IsoMax2048Text
}
ProxyAccountIdentification1 *-- "0..1" IProxyAccountType1Choice : Type
CashAccount40 members
| Member name | Description | Data Type / Multiplicity |
|---|---|---|
| Identification | Unique and unambiguous identification for the account between the account owner and the account servicer. | IAccountIdentification4Choice - Optional 0..1 |
| Type | Specifies the nature, or use of the account. | ICashAccountType2Choice - Optional 0..1 |
| Currency | Identification of the currency in which the account is held. | |
| Name | Name of the account, as assigned by the account servicing institution, in agreement with the account owner in order to provide an additional means of identification of the account. | |
| Proxy | Specifies an alternate assumed name for the identification of the account. | ProxyAccountIdentification1 - Optional 0..1 |
CancellationReason building block
Provides detailed information on the cancellation reason. Provides further details on the reason of the cancellation request. For comparison, see the ISO20022 official specification
classDiagram
direction tb
%% PaymentCancellationReason5 recursion level 0 with max 1
class PaymentCancellationReason5{
AdditionalInformation IsoMax105Text
}
PaymentCancellationReason5 *-- "0..1" PartyIdentification135 : Originator
PaymentCancellationReason5 *-- "0..1" ICancellationReason33Choice : Reason
%% PartyIdentification135 recursion level 1 with max 1
class PartyIdentification135{
Name IsoMax140Text
CountryOfResidence CountryCode
}
PartyIdentification135 *-- "0..1" PostalAddress24 : PostalAddress
PartyIdentification135 *-- "0..1" IParty38Choice : Identification
PartyIdentification135 *-- "0..1" Contact4 : ContactDetails
%% ICancellationReason33Choice recursion level 1 with max 1
PaymentCancellationReason5 members
| Member name | Description | Data Type / Multiplicity |
|---|---|---|
| Originator | Party that issues the cancellation request. | PartyIdentification135 - Optional 0..1 |
| Reason | Specifies the reason for the cancellation. | ICancellationReason33Choice - Optional 0..1 |
| AdditionalInformation | Further details on the cancellation request reason. | IsoMax105Text - Unknown 0..0 |
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 CancelTransactionV10 implementation follows a specific implementaiton pattern. First of all, CancelTransactionV10 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, CancelTransactionV10Document implements IOuterDocument. Because CancelTransactionV10 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type CancelTransactionV10.
classDiagram
class IOuterRecord
CancelTransactionV10 --|> IOuterRecord : Implements
CancelTransactionV10Document --|> IOuterDocument~CancelTransactionV10~ : Implements
class IOuterDocument~CancelTransactionV10~ {
CancelTransactionV10 Message
}
Document wrapper for serialization
The only real purpose CancelTransactionV10Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:camt.008.001.10’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using CancelTransactionV10.ToDocument() method. The returned CancelTransactionV10Document value will serialize correctly according to ISO 20022 standards.
classDiagram
CancelTransactionV10Document *-- CancelTransactionV10 : 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.008.001.10">
<CclTx>
<MsgHdr>
<!-- MessageHeader inner content -->
</MsgHdr>
<PmtId>
<!-- PaymentIdentification inner content -->
</PmtId>
<CshAcct>
<!-- CashAccount inner content -->
</CshAcct>
<CxlRsn>
<!-- CancellationReason inner content -->
</CxlRsn>
<SplmtryData>
<!-- SupplementaryData inner content -->
</SplmtryData>
</CclTx>
</Document>
Data from ISO specification
This is the technical data from the specification document.
<messageDefinition
xmi:id="_jx5UsQKxEe2rHs6fbn9-0A"
previousVersion="_ThK7gdb6Eeq_l4BJLVUF2Q"
name="CancelTransactionV10"
definition="Scope
The CancelTransaction message is sent by a member to the transaction administrator.
It is used to request the cancellation of one payment instruction held at the transaction administrator and sent by the member.
Usage
Following normal business flows, transactions registered by the transaction administrator may be queued for later settlement (because of insufficient funds available, because of risk or liquidity limits, etc.). A transaction may have a series of statuses. These can be transient (such as pending or related types), final (such as rejected, revoked and/or settled) or the status may even be defined as a proprietary status.
Members of a system need to have information about the payments queue(s), and must have the ability to take action (that is, to cancel or modify the transaction(s) to be settled). Note, however, that actions by a member will always concern transactions in a transient status.
For this reason, at any time during the operating hours of the system, the member can request the cancellation of a transaction that has not received a final status.
The member will submit a CancelTransaction message containing the identification of the transaction to be cancelled.
Based on the criteria received within the CancelTransaction message, the transaction administrator will execute or reject the requested cancellation.
The transaction administrator may send a Receipt message as a reply to the CancelTransaction request.
To verify the outcome of the request, the member may submit a GetTransaction message with the appropriate search criteria."
registrationStatus="Registered"
messageSet="_SZTDoxcNEeiyVv5j1vf1VQ"
xmlTag="CclTx"
rootElement="Document"
xmlns:xmi="http://www.omg.org/XMI">
<messageBuildingBlock
xmi:id="_jx5UuQKxEe2rHs6fbn9-0A"
previousVersion="_ThK7h9b6Eeq_l4BJLVUF2Q"
name="MessageHeader"
definition="Common business identification for the message."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="1"
xmlTag="MsgHdr"
complexType="_jAUZkZIhEeect698_YsnIA" />
<messageBuildingBlock
xmi:id="_jx5UuwKxEe2rHs6fbn9-0A"
previousVersion="_ThK7idb6Eeq_l4BJLVUF2Q"
name="PaymentIdentification"
definition="Reference to the instruction related to the payment for which information is requested."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="1"
xmlTag="PmtId"
complexType="_5F42wAKxEe2rHs6fbn9-0A" />
<messageBuildingBlock
xmi:id="_jx5UvQKxEe2rHs6fbn9-0A"
previousVersion="_ThK7i9b6Eeq_l4BJLVUF2Q"
name="CashAccount"
definition="Account to or from which a cash entry is made."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="0"
xmlTag="CshAcct"
complexType="_avXPcdcZEeqRFcf2R4bPBw" />
<messageBuildingBlock
xmi:id="_jx5UvwKxEe2rHs6fbn9-0A"
previousVersion="_ThK7jdb6Eeq_l4BJLVUF2Q"
name="CancellationReason"
definition="Provides detailed information on the cancellation reason."
registrationStatus="Provisionally Registered"
maxOccurs="1"
minOccurs="0"
xmlTag="CxlRsn"
complexType="_fzdu8cDQEeic67MXUoeXWA" />
<messageBuildingBlock
xmi:id="_jx5UwQKxEe2rHs6fbn9-0A"
previousVersion="_ThK7j9b6Eeq_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="008"
flavour="001"
version="10" />
</messageDefinition>
ISO Building Blocks
The following items are used as building blocks to construct this message.