Iso20022

CustomerPaymentCancellationRequestV04

camt.055.001.04

Scope The Customer Payment Cancellation Request message is sent by a case creator/case assigner to a case assignee. This message is used to request the cancellation of an original payment instruction. The Customer Payment Cancellation Request message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation or CustomerDirectDebitInitiation). Usage The Customer Payment Cancellation Request message must be answered with a:

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
%% CustomerPaymentCancellationRequestV04 recursion level 0 with max 0
CustomerPaymentCancellationRequestV04 *-- "1..1" CaseAssignment3 : Assignment
CustomerPaymentCancellationRequestV04 *-- "0..1" Case3 : Case
CustomerPaymentCancellationRequestV04 *-- "0..1" ControlData1 : ControlData
CustomerPaymentCancellationRequestV04 *-- "1..1" UnderlyingTransaction11 : Underlying
CustomerPaymentCancellationRequestV04 *-- "0..1" SupplementaryData1 : SupplementaryData

Now, we will zero-in one-by-one on each of these building blocks.

Assignment building block

Identifies the assignment of an investigation case from an assigner to an assignee. Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver. Represents the assignment of a case to a party. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% CaseAssignment3 recursion level 0 with max 1
class CaseAssignment3{
    Identification IsoMax35Text
    CreationDateTime IsoISODateTime
}
CaseAssignment3 *-- "1..1" IParty12Choice : Assigner
CaseAssignment3 *-- "1..1" IParty12Choice : Assignee
%% IParty12Choice recursion level 1 with max 1
%% IParty12Choice recursion level 1 with max 1

CaseAssignment3 members

Member name Description Data Type / Multiplicity
Identification Uniquely identifies the case assignment. IsoMax35Text - Required 1..1
Assigner Party who assigns the case. Usage: This is also the sender of the message.
Assignee Party to which the case is assigned. Usage: This is also the receiver of the message.
CreationDateTime Date and time at which the assignment was created. IsoISODateTime - Required 1..1

Case building block

Identifies the investigation case. Provides further details to identify an investigation case. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% Case3 recursion level 0 with max 1
class Case3{
    Identification IsoMax35Text
    ReopenCaseIndication IsoYesNoIndicator
}
Case3 *-- "1..1" IParty12Choice : Creator
%% IParty12Choice recursion level 1 with max 1

Case3 members

Member name Description Data Type / Multiplicity
Identification Uniquely identifies the case. IsoMax35Text - Required 1..1
Creator Party that created the investigation case. IParty12Choice - Required 1..1
ReopenCaseIndication Indicates whether or not the case was previously closed and is now re-opened. IsoYesNoIndicator - Optional 0..1

ControlData building block

Provides details on the number of transactions and the control sum of the message. Provides details of the number of transactions and the control sum of the message. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% ControlData1 recursion level 0 with max 1
class ControlData1{
    NumberOfTransactions IsoMax15NumericText
    ControlSum IsoDecimalNumber
}

ControlData1 members

Member name Description Data Type / Multiplicity
NumberOfTransactions Number of individual transactions contained in the message. IsoMax15NumericText - Required 1..1
ControlSum Total of all individual amounts included in the message, irrespective of currencies. IsoDecimalNumber - Optional 0..1

Underlying building block

Identifies the payment instruction to be cancelled. Identifies the underlying (group of) transaction(s) to which the investigation applies. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% UnderlyingTransaction11 recursion level 0 with max 1
UnderlyingTransaction11 *-- "0..1" OriginalGroupHeader4 : OriginalGroupInformationAndCancellation
UnderlyingTransaction11 *-- "0..0" OriginalPaymentInstruction13 : OriginalPaymentInformationAndCancellation
%% OriginalGroupHeader4 recursion level 1 with max 1
class OriginalGroupHeader4{
    GroupCancellationIdentification IsoMax35Text
    OriginalMessageIdentification IsoMax35Text
    OriginalMessageNameIdentification IsoMax35Text
    OriginalCreationDateTime IsoISODateTime
    NumberOfTransactions IsoMax15NumericText
    ControlSum IsoDecimalNumber
    GroupCancellation IsoGroupCancellationIndicator
}
OriginalGroupHeader4 *-- "0..1" Case3 : Case
OriginalGroupHeader4 *-- "0..0" PaymentCancellationReason2 : CancellationReasonInformation
%% OriginalPaymentInstruction13 recursion level 1 with max 1
class OriginalPaymentInstruction13{
    PaymentCancellationIdentification IsoMax35Text
    OriginalPaymentInformationIdentification IsoMax35Text
    NumberOfTransactions IsoMax15NumericText
    ControlSum IsoDecimalNumber
    PaymentInformationCancellation IsoGroupCancellationIndicator
}
OriginalPaymentInstruction13 *-- "0..1" Case3 : Case
OriginalPaymentInstruction13 *-- "0..1" OriginalGroupInformation3 : OriginalGroupInformation
OriginalPaymentInstruction13 *-- "0..0" PaymentCancellationReason2 : CancellationReasonInformation
OriginalPaymentInstruction13 *-- "0..0" PaymentTransaction58 : TransactionInformation

UnderlyingTransaction11 members

Member name Description Data Type / Multiplicity
OriginalGroupInformationAndCancellation Provides information on the original message, to which the cancellation refers. OriginalGroupHeader4 - Optional 0..1
OriginalPaymentInformationAndCancellation Provides information on the original (group of) transactions, to which the cancellation request refers. OriginalPaymentInstruction13 - 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 CustomerPaymentCancellationRequestV04 implementation follows a specific implementaiton pattern. First of all, CustomerPaymentCancellationRequestV04 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, CustomerPaymentCancellationRequestV04Document implements IOuterDocument. Because CustomerPaymentCancellationRequestV04 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type CustomerPaymentCancellationRequestV04.

classDiagram
    class IOuterRecord
    CustomerPaymentCancellationRequestV04 --|> IOuterRecord : Implements
    CustomerPaymentCancellationRequestV04Document --|> IOuterDocument~CustomerPaymentCancellationRequestV04~ : Implements
    class IOuterDocument~CustomerPaymentCancellationRequestV04~ {
        CustomerPaymentCancellationRequestV04 Message
     }

Document wrapper for serialization

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

classDiagram
    CustomerPaymentCancellationRequestV04Document *-- CustomerPaymentCancellationRequestV04 : 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.055.001.04">
    <CstmrPmtCxlReq>
        <Assgnmt>
            <!-- Assignment inner content -->
        </Assgnmt>
        <Case>
            <!-- Case inner content -->
        </Case>
        <CtrlData>
            <!-- ControlData inner content -->
        </CtrlData>
        <Undrlyg>
            <!-- Underlying inner content -->
        </Undrlyg>
        <SplmtryData>
            <!-- SupplementaryData inner content -->
        </SplmtryData>
    </CstmrPmtCxlReq>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_wQzafRPeEeSVo-TFVwFHvA"
  nextVersions="_akmd_zqxEeWZFYSPlduMhw"
  previousVersion="_Bi3msSGoEeKjd4jizyIDGA"
  name="CustomerPaymentCancellationRequestV04"
  definition="Scope&#xD;&#xA;The Customer Payment Cancellation Request message is sent by a case creator/case assigner to a case assignee.&#xD;&#xA;This message is used to request the cancellation of an original payment instruction. The Customer Payment Cancellation Request message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation or CustomerDirectDebitInitiation).&#xD;&#xA;Usage&#xD;&#xA;The Customer Payment Cancellation Request message must be answered with a:&#xD;&#xA;- Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested cancellation&#xD;&#xA;- Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested cancellation but fails to do so (too late, irrevocable instruction.)&#xD;&#xA;- Reject Investigation message when the case assignee is unable or not authorised to perform the requested cancellation&#xD;&#xA;- Notification Of Case Assignment message to indicate whether the case assignee will take on the case himself or reassign the case to a subsequent party in the payment processing chain.&#xD;&#xA;A Customer Payment Cancellation Request message concerns one and only one original payment instruction at a time.&#xD;&#xA;When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner. It may provide some details about the return in the Resolution Of Investigation message.&#xD;&#xA;The processing of a Customer Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution.&#xD;&#xA;The Customer Payment Cancellation Request message may be used to escalate a case after an unsuccessful request to modify the payment. In this scenario, the case identification remains the same as in the original Customer Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'.&#xD;&#xA;The Customer Payment Cancellation Request message has the following main characteristics:&#xD;&#xA;The case creator assigns a unique case identification and the reason code for the cancellation request. This information will be passed unchanged to all subsequent case assignee(s). For the Customer Payment Cancellation Request message has been made optional, as the message might be used outside of a case management environment where the case identification is not relevant.&#xD;&#xA;Moreover, the case identification may be present at different levels:&#xD;&#xA;- One unique case is defined per cancellation request message: If multiple underlying groups, payment information blocks or transactions are present in the message and the case assignee has already forwarded the transaction for which the cancellation is requested, the case cannot be forwarded to the next party in the chain (see rule on uniqueness of the case) and the case creator will have to issue individual cancellation requests for each underlying individual transaction. In response to this cancellation request, the case must also be present at the message level in the Resolution of Investigation message.&#xD;&#xA;- One case per original group, payment information or transaction present in the cancellation request: For each group, payment information block or transaction within the payment information, a unique case has been assigned. This means, when a payment instruction has already been forwarded by the case assignee, the cancellation request may be forwarded to next party in the payment chain, with the unique case assigned to the transaction. When the group can only be cancelled partially, new cancellation requests need however to be issued for the individual transactions within the group for which the cancellation request has not been successful. In response to this cancellation request, the case must be present in the cancellation details identifying the original group or transaction in the Resolution of Investigation message.&#xD;&#xA;- No case used in cancellation request message:&#xD;&#xA;The cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain."
  registrationStatus="Registered"
  messageSet="_urpIICeJEeOCeO5e7islRQ"
  xmlTag="CstmrPmtCxlReq"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <constraint
    xmi:id="_wQzafxPeEeSVo-TFVwFHvA"
    nextVersions="_akmeATqxEeWZFYSPlduMhw"
    previousVersion="_Bi3msyGoEeKjd4jizyIDGA"
    name="MessageOrGroupCaseRule"
    definition="Case may be present at either Case, OriginalGroupInformationAndCancellation, OriginalPaymentInformationAndCancellation or TransactionInformation level."
    registrationStatus="Provisionally Registered"
    expression="&lt;RuleDefinition xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;&gt;&lt;ComplexRule xsi:type=&quot;ComplexRule&quot;&gt;&lt;mustBe&gt;&lt;connector&gt;AND&lt;/connector&gt;&lt;BooleanRule xsi:type=&quot;Absence&quot;&gt;&lt;leftOperand&gt;/Underlying[*]/OriginalGroupInformationAndCancellation/Case&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;/mustBe&gt;&lt;onCondition&gt;&lt;connector&gt;AND&lt;/connector&gt;&lt;BooleanRule xsi:type=&quot;Presence&quot;&gt;&lt;leftOperand&gt;/Case&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;BooleanRule xsi:type=&quot;Presence&quot;&gt;&lt;leftOperand&gt;/Underlying[1]/OriginalGroupInformationAndCancellation&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;/onCondition&gt;&lt;/ComplexRule&gt;&lt;/RuleDefinition&gt;&#xA;" />
  <constraint
    xmi:id="_wQzagRPeEeSVo-TFVwFHvA"
    nextVersions="_akmeAzqxEeWZFYSPlduMhw"
    previousVersion="_Bi3mtyGoEeKjd4jizyIDGA"
    name="MessageOrPaymentInformationCaseRule"
    definition="Case may be present at either Case, OriginalGroupInformationAndCancellation, OriginalPaymentInformationAndCancellation or TransactionInformation level."
    registrationStatus="Provisionally Registered"
    expression="&lt;RuleDefinition xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;&gt;&lt;ComplexRule xsi:type=&quot;ComplexRule&quot;&gt;&lt;mustBe&gt;&lt;connector&gt;AND&lt;/connector&gt;&lt;BooleanRule xsi:type=&quot;Absence&quot;&gt;&lt;leftOperand&gt;/Underlying[*]/OriginalPaymentInformationAndCancellation[*]/Case&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;/mustBe&gt;&lt;onCondition&gt;&lt;connector&gt;AND&lt;/connector&gt;&lt;BooleanRule xsi:type=&quot;Presence&quot;&gt;&lt;leftOperand&gt;/Case&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;BooleanRule xsi:type=&quot;Presence&quot;&gt;&lt;leftOperand&gt;/Underlying[1]/OriginalPaymentInformationAndCancellation[1]&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;/onCondition&gt;&lt;/ComplexRule&gt;&lt;/RuleDefinition&gt;&#xA;" />
  <constraint
    xmi:id="_wQzagxPeEeSVo-TFVwFHvA"
    nextVersions="_akmeBTqxEeWZFYSPlduMhw"
    previousVersion="_Bi3muyGoEeKjd4jizyIDGA"
    name="MessageOrTransactionCaseRule"
    definition="Case may be present at either Case, OriginalGroupInformationAndCancellation, OriginalPaymentInformationAndCancellation or TransactionInformation level."
    registrationStatus="Provisionally Registered"
    expression="&lt;RuleDefinition xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;&gt;&lt;ComplexRule xsi:type=&quot;ComplexRule&quot;&gt;&lt;mustBe&gt;&lt;connector&gt;AND&lt;/connector&gt;&lt;BooleanRule xsi:type=&quot;Absence&quot;&gt;&lt;leftOperand&gt;/Underlying[*]/OriginalPaymentInformationAndCancellation[*]/TransactionInformation[*]/Case&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;/mustBe&gt;&lt;onCondition&gt;&lt;connector&gt;AND&lt;/connector&gt;&lt;BooleanRule xsi:type=&quot;Presence&quot;&gt;&lt;leftOperand&gt;/Case&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;BooleanRule xsi:type=&quot;Presence&quot;&gt;&lt;leftOperand&gt;/Underlying[1]/OriginalPaymentInformationAndCancellation[1]/TransactionInformation[1]/Case&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;/onCondition&gt;&lt;/ComplexRule&gt;&lt;/RuleDefinition&gt;&#xA;" />
  <constraint
    xmi:id="_wQzahRPeEeSVo-TFVwFHvA"
    nextVersions="_akmeBzqxEeWZFYSPlduMhw"
    previousVersion="_VfTpuSHZEeKGEZlIMFwKzg"
    name="SupplementaryDataRule"
    definition="The SupplementaryData building block at message level must not be used to provide additional information about a transaction. The SupplementaryData element at transaction level should be used for that purpose."
    registrationStatus="Provisionally Registered" />
  <messageBuildingBlock
    xmi:id="_wQzakRPeEeSVo-TFVwFHvA"
    nextVersions="_akmeEzqxEeWZFYSPlduMhw"
    previousVersion="_Bi3m0yGoEeKjd4jizyIDGA"
    name="Assignment"
    definition="Identifies the assignment of an investigation case from an assigner to an assignee.&#xA;Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="Assgnmt"
    complexType="_sbKvolkyEeGeoaLUQk__nA_1583838951" />
  <messageBuildingBlock
    xmi:id="_wQzakxPeEeSVo-TFVwFHvA"
    nextVersions="_akmeFTqxEeWZFYSPlduMhw"
    previousVersion="_Bi3m1yGoEeKjd4jizyIDGA"
    name="Case"
    definition="Identifies the investigation case."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="0"
    xmlTag="Case"
    complexType="_tijOcFkyEeGeoaLUQk__nA_-1838378407" />
  <messageBuildingBlock
    xmi:id="_wQzalRPeEeSVo-TFVwFHvA"
    nextVersions="_akmeFzqxEeWZFYSPlduMhw"
    previousVersion="_Bi3m2yGoEeKjd4jizyIDGA"
    name="ControlData"
    definition="Provides details on the number of transactions and the control sum of the message."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="0"
    xmlTag="CtrlData"
    complexType="_RqlQiNp-Ed-ak6NoX_4Aeg_518525040" />
  <messageBuildingBlock
    xmi:id="_wQzalxPeEeSVo-TFVwFHvA"
    nextVersions="_akmeGTqxEeWZFYSPlduMhw"
    previousVersion="_Bi3m3yGoEeKjd4jizyIDGA"
    name="Underlying"
    definition="Identifies the payment instruction to be cancelled."
    registrationStatus="Provisionally Registered"
    minOccurs="1"
    xmlTag="Undrlyg"
    complexType="_q2Qa6R72EeSxevWRRWxNAg" />
  <messageBuildingBlock
    xmi:id="_wQzamRPeEeSVo-TFVwFHvA"
    nextVersions="_akmeGzqxEeWZFYSPlduMhw"
    previousVersion="_Bi3m4yGoEeKjd4jizyIDGA"
    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="055"
    flavour="001"
    version="04" />
</messageDefinition>

ISO Building Blocks

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