Iso20022

FIToFIPaymentCancellationRequestV06

camt.056.001.06

Scope The FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest message is exchanged between the instructing agent and the instructed agent to request the cancellation of a interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer).

The FIToFIPaymentCancellationRequest supports for both the request for cancellation (the instructed agent - or assignee - has not yet processed and forwarded the payment instruction) as well as the request for refund (payment has been fully processed already by the instructed agent - or assignee).

Usage The FIToFIPaymentCancellationRequest 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
%% FIToFIPaymentCancellationRequestV06 recursion level 0 with max 0
FIToFIPaymentCancellationRequestV06 *-- "1..1" CaseAssignment3 : Assignment
FIToFIPaymentCancellationRequestV06 *-- "0..1" Case3 : Case
FIToFIPaymentCancellationRequestV06 *-- "0..1" ControlData1 : ControlData
FIToFIPaymentCancellationRequestV06 *-- "1..1" UnderlyingTransaction16 : Underlying
FIToFIPaymentCancellationRequestV06 *-- "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
%% UnderlyingTransaction16 recursion level 0 with max 1
UnderlyingTransaction16 *-- "0..1" OriginalGroupHeader6 : OriginalGroupInformationAndCancellation
UnderlyingTransaction16 *-- "0..0" PaymentTransaction75 : TransactionInformation
%% OriginalGroupHeader6 recursion level 1 with max 1
class OriginalGroupHeader6{
    GroupCancellationIdentification IsoMax35Text
    OriginalMessageIdentification IsoMax35Text
    OriginalMessageNameIdentification IsoMax35Text
    OriginalCreationDateTime IsoISODateTime
    NumberOfTransactions IsoMax15NumericText
    ControlSum IsoDecimalNumber
    GroupCancellation IsoGroupCancellationIndicator
}
OriginalGroupHeader6 *-- "0..1" Case3 : Case
OriginalGroupHeader6 *-- "0..0" PaymentCancellationReason3 : CancellationReasonInformation
%% PaymentTransaction75 recursion level 1 with max 1
class PaymentTransaction75{
    CancellationIdentification IsoMax35Text
    OriginalInstructionIdentification IsoMax35Text
    OriginalEndToEndIdentification IsoMax35Text
    OriginalTransactionIdentification IsoMax35Text
    OriginalClearingSystemReference IsoMax35Text
    OriginalInterbankSettlementAmount IsoActiveOrHistoricCurrencyAndAmount
    OriginalInterbankSettlementDate IsoISODate
}
PaymentTransaction75 *-- "0..1" Case3 : Case
PaymentTransaction75 *-- "0..1" OriginalGroupInformation3 : OriginalGroupInformation
PaymentTransaction75 *-- "0..1" BranchAndFinancialInstitutionIdentification5 : Assigner
PaymentTransaction75 *-- "0..1" BranchAndFinancialInstitutionIdentification5 : Assignee
PaymentTransaction75 *-- "0..0" PaymentCancellationReason3 : CancellationReasonInformation
PaymentTransaction75 *-- "0..1" OriginalTransactionReference24 : OriginalTransactionReference
PaymentTransaction75 *-- "0..0" SupplementaryData1 : SupplementaryData

UnderlyingTransaction16 members

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

classDiagram
    class IOuterRecord
    FIToFIPaymentCancellationRequestV06 --|> IOuterRecord : Implements
    FIToFIPaymentCancellationRequestV06Document --|> IOuterDocument~FIToFIPaymentCancellationRequestV06~ : Implements
    class IOuterDocument~FIToFIPaymentCancellationRequestV06~ {
        FIToFIPaymentCancellationRequestV06 Message
     }

Document wrapper for serialization

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

classDiagram
    FIToFIPaymentCancellationRequestV06Document *-- FIToFIPaymentCancellationRequestV06 : 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.056.001.06">
    <FIToFIPmtCxlReq>
        <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>
    </FIToFIPmtCxlReq>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_O2OwMUgZEeaGKYpLDboHPQ"
  nextVersions="_AOwWHV1tEeehlLdFiIrRgQ"
  previousVersion="_akmedzqxEeWZFYSPlduMhw"
  name="FIToFIPaymentCancellationRequestV06"
  definition="Scope&#xD;&#xA;The FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest message is exchanged between the instructing agent and the instructed agent to request the cancellation of a interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer).&#xD;&#xA;&#xD;&#xA;The FIToFIPaymentCancellationRequest supports for both the request for cancellation (the instructed agent - or assignee - has not yet processed and forwarded the payment instruction) as well as the request for refund (payment has been fully processed already by the instructed agent - or assignee).&#xD;&#xA;&#xD;&#xA;Usage&#xD;&#xA;The FIToFIPaymentCancellationRequest message must be answered with a:&#xD;&#xA;- ResolutionOfInvestigation message with a positive final outcome when the case assignee can perform the requested cancellation&#xD;&#xA;- ResolutionOfInvestigation 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;- RejectInvestigation message when the case assignee is unable or not authorised to perform the requested cancellation&#xD;&#xA;- NotificationOfCaseAssignment 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 FIToFIPaymentCancellationRequest 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 ResolutionOfInvestigation message.&#xD;&#xA;The processing of a FIToFI 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 FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest message and the element ReopenCaseIndication is set to 'Yes' or 'true'.&#xD;&#xA;The FIToFIPaymentCancellationRequest message has the following main characteristics:&#xD;&#xA;Case Identification:&#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 FIToFIPaymentCancellationRequest message the case 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 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 or transaction present in the cancellation request: For each group or transaction, 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;Cancellation of a cover payment:&#xA;The cancellation of a payment instruction for which cover is provided by a separate instruction always results in the cancellation of the whole transaction, including the cover. The case assignee performing the cancellation must initiate the return of funds to the case creator. The case assigner must not request the cancellation of the cover separately.&#xD;&#xA;Cancellation request initiators:&#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="FIToFIPmtCxlReq"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <constraint
    xmi:id="_O2OwM0gZEeaGKYpLDboHPQ"
    nextVersions="_AOwWH11tEeehlLdFiIrRgQ"
    previousVersion="_akmeeTqxEeWZFYSPlduMhw"
    name="MessageOrGroupCaseRule"
    definition="Case may be present at either Case, OriginalGroupInformationAndCancellation 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]&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="_O2OwNUgZEeaGKYpLDboHPQ"
    nextVersions="_AOwWIV1tEeehlLdFiIrRgQ"
    previousVersion="_akmeezqxEeWZFYSPlduMhw"
    name="MessageOrTransactionCaseRule"
    definition="Case may be present at either Case, OriginalGroupInformationAndCancellation 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[*]/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]&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;BooleanRule xsi:type=&quot;Presence&quot;&gt;&lt;leftOperand&gt;/Underlying[1]/TransactionInformation[1]&lt;/leftOperand&gt;&lt;/BooleanRule&gt;&lt;/onCondition&gt;&lt;/ComplexRule&gt;&lt;/RuleDefinition&gt;&#xA;" />
  <constraint
    xmi:id="_O2OwN0gZEeaGKYpLDboHPQ"
    nextVersions="_AOwWI11tEeehlLdFiIrRgQ"
    previousVersion="_akmefTqxEeWZFYSPlduMhw"
    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="_O2OwOUgZEeaGKYpLDboHPQ"
    nextVersions="_AOwWJV1tEeehlLdFiIrRgQ"
    previousVersion="_akmefzqxEeWZFYSPlduMhw"
    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="_O2OwO0gZEeaGKYpLDboHPQ"
    nextVersions="_AOwWJ11tEeehlLdFiIrRgQ"
    previousVersion="_akmegTqxEeWZFYSPlduMhw"
    name="Case"
    definition="Identifies the investigation case."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="0"
    xmlTag="Case"
    complexType="_tijOcFkyEeGeoaLUQk__nA_-1838378407" />
  <messageBuildingBlock
    xmi:id="_O2OwPUgZEeaGKYpLDboHPQ"
    nextVersions="_AOwWKV1tEeehlLdFiIrRgQ"
    previousVersion="_akmegzqxEeWZFYSPlduMhw"
    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="_O2OwP0gZEeaGKYpLDboHPQ"
    nextVersions="_AOwWK11tEeehlLdFiIrRgQ"
    previousVersion="_akmehTqxEeWZFYSPlduMhw"
    name="Underlying"
    definition="Identifies the payment instruction to be cancelled."
    registrationStatus="Provisionally Registered"
    minOccurs="1"
    xmlTag="Undrlyg"
    complexType="_xeOH20gtEeaGKYpLDboHPQ" />
  <messageBuildingBlock
    xmi:id="_O2OwQUgZEeaGKYpLDboHPQ"
    nextVersions="_AOwWLV1tEeehlLdFiIrRgQ"
    previousVersion="_akmehzqxEeWZFYSPlduMhw"
    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="056"
    flavour="001"
    version="06" />
</messageDefinition>

ISO Building Blocks

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