Iso20022

FIToFIPaymentCancellationRequestV10

camt.056.001.10

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 message supports 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
%% FIToFIPaymentCancellationRequestV10 recursion level 0 with max 0
FIToFIPaymentCancellationRequestV10 *-- "1..1" CaseAssignment5 : Assignment
FIToFIPaymentCancellationRequestV10 *-- "0..1" Case5 : Case
FIToFIPaymentCancellationRequestV10 *-- "0..1" ControlData1 : ControlData
FIToFIPaymentCancellationRequestV10 *-- "1..1" UnderlyingTransaction28 : Underlying
FIToFIPaymentCancellationRequestV10 *-- "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
%% CaseAssignment5 recursion level 0 with max 1
class CaseAssignment5{
    Identification IsoMax35Text
    CreationDateTime IsoISODateTime
}
CaseAssignment5 *-- "1..1" IParty40Choice : Assigner
CaseAssignment5 *-- "1..1" IParty40Choice : Assignee
%% IParty40Choice recursion level 1 with max 1
%% IParty40Choice recursion level 1 with max 1

CaseAssignment5 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
%% Case5 recursion level 0 with max 1
class Case5{
    Identification IsoMax35Text
    ReopenCaseIndication IsoYesNoIndicator
}
Case5 *-- "1..1" IParty40Choice : Creator
%% IParty40Choice recursion level 1 with max 1

Case5 members

Member name Description Data Type / Multiplicity
Identification Uniquely identifies the case. IsoMax35Text - Required 1..1
Creator Party that created the investigation case. IParty40Choice - 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
%% UnderlyingTransaction28 recursion level 0 with max 1
UnderlyingTransaction28 *-- "0..1" OriginalGroupHeader15 : OriginalGroupInformationAndCancellation
UnderlyingTransaction28 *-- "0..0" PaymentTransaction137 : TransactionInformation
%% OriginalGroupHeader15 recursion level 1 with max 1
class OriginalGroupHeader15{
    GroupCancellationIdentification IsoMax35Text
    OriginalMessageIdentification IsoMax35Text
    OriginalMessageNameIdentification IsoMax35Text
    OriginalCreationDateTime IsoISODateTime
    NumberOfTransactions IsoMax15NumericText
    ControlSum IsoDecimalNumber
    GroupCancellation IsoGroupCancellationIndicator
}
OriginalGroupHeader15 *-- "0..1" Case5 : Case
OriginalGroupHeader15 *-- "0..0" PaymentCancellationReason5 : CancellationReasonInformation
%% PaymentTransaction137 recursion level 1 with max 1
class PaymentTransaction137{
    CancellationIdentification IsoMax35Text
    OriginalInstructionIdentification IsoMax35Text
    OriginalEndToEndIdentification IsoMax35Text
    OriginalTransactionIdentification IsoMax35Text
    OriginalUETR IsoUUIDv4Identifier
    OriginalClearingSystemReference IsoMax35Text
    OriginalInterbankSettlementAmount IsoActiveOrHistoricCurrencyAndAmount
    OriginalInterbankSettlementDate IsoISODate
}
PaymentTransaction137 *-- "0..1" Case5 : Case
PaymentTransaction137 *-- "0..1" OriginalGroupInformation29 : OriginalGroupInformation
PaymentTransaction137 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : Assigner
PaymentTransaction137 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : Assignee
PaymentTransaction137 *-- "0..0" PaymentCancellationReason5 : CancellationReasonInformation
PaymentTransaction137 *-- "0..1" OriginalTransactionReference35 : OriginalTransactionReference
PaymentTransaction137 *-- "0..0" SupplementaryData1 : SupplementaryData

UnderlyingTransaction28 members

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

classDiagram
    class IOuterRecord
    FIToFIPaymentCancellationRequestV10 --|> IOuterRecord : Implements
    FIToFIPaymentCancellationRequestV10Document --|> IOuterDocument~FIToFIPaymentCancellationRequestV10~ : Implements
    class IOuterDocument~FIToFIPaymentCancellationRequestV10~ {
        FIToFIPaymentCancellationRequestV10 Message
     }

Document wrapper for serialization

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

classDiagram
    FIToFIPaymentCancellationRequestV10Document *-- FIToFIPaymentCancellationRequestV10 : 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.10">
    <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="_IBjZgdcBEeq_l4BJLVUF2Q"
  previousVersion="_LwAM7cP_Eemsic1bQcEtLA"
  name="FIToFIPaymentCancellationRequestV10"
  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 message supports 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 FIToFIPaymentCancellationRequest message case may lead to a DebitAuthorisationRequest 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: 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). &#xD;&#xA;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="_moz48_2VEeGjgKzdN0DbWA"
  xmlTag="FIToFIPmtCxlReq"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <constraint
    xmi:id="_IBjZg9cBEeq_l4BJLVUF2Q"
    previousVersion="_LwAM78P_Eemsic1bQcEtLA"
    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="_IBjZhdcBEeq_l4BJLVUF2Q"
    previousVersion="_LwAM8cP_Eemsic1bQcEtLA"
    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="_IBjZh9cBEeq_l4BJLVUF2Q"
    previousVersion="_LwAM88P_Eemsic1bQcEtLA"
    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="_IBjZj9cBEeq_l4BJLVUF2Q"
    previousVersion="_LwAM-8P_Eemsic1bQcEtLA"
    name="Assignment"
    definition="Identifies the assignment of an investigation case from an assigner to an assignee.&#xD;&#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="_BzPdIW49EeiU9cctagi5ow" />
  <messageBuildingBlock
    xmi:id="_IBjZkdcBEeq_l4BJLVUF2Q"
    previousVersion="_LwAM_cP_Eemsic1bQcEtLA"
    name="Case"
    definition="Identifies the investigation case."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="0"
    xmlTag="Case"
    complexType="_8BF4W248EeiU9cctagi5ow" />
  <messageBuildingBlock
    xmi:id="_IBjZk9cBEeq_l4BJLVUF2Q"
    previousVersion="_LwAM_8P_Eemsic1bQcEtLA"
    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="_IBjZldcBEeq_l4BJLVUF2Q"
    previousVersion="_LwANAcP_Eemsic1bQcEtLA"
    name="Underlying"
    definition="Identifies the payment instruction to be cancelled."
    registrationStatus="Provisionally Registered"
    minOccurs="1"
    xmlTag="Undrlyg"
    complexType="_c7S7gdcZEeqRFcf2R4bPBw" />
  <messageBuildingBlock
    xmi:id="_IBjZl9cBEeq_l4BJLVUF2Q"
    previousVersion="_LwANA8P_Eemsic1bQcEtLA"
    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="10" />
</messageDefinition>

ISO Building Blocks

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