UNIFI (ISO 20022) Message Definition Report
Edition August 2006
Payments Standards - Exceptions andInvestigations
Approved by UNIFI Payments SEG on 25 July 2006
Table Of Contents Overview .................................................................................................................................................................... 1
What does this document contain? ......................................................................................................................... 1Exceptions and Investigations messages ................................................................................................................ 1Business rationale for the Exceptions and Investigations messages ...................................................................... 1How to read ............................................................................................................................................................ 2
How to use the exceptions and investigations messages ........................................................................................ 3Introduction ............................................................................................................................................................ 3Concepts ................................................................................................................................................................. 3Rules ....................................................................................................................................................................... 4Case management main scenario ............................................................................................................................ 5Cancel case assignment scenario ............................................................................................................................ 7Request for duplicate instruction scenario .............................................................................................................. 8
Message Flows ........................................................................................................................................................... 9Request for cancellation scenario ........................................................................................................................... 9Request for modification scenario ........................................................................................................................ 11Claim non receipt scenario ................................................................................................................................... 17Unable to apply scenario ...................................................................................................................................... 22
Message: AdditionalPaymentInformation <camt.028.001.01> ...................................................................... 28Message Scope and Usage .................................................................................................................................... 28Message Structure ................................................................................................................................................. 29Message Items Description ................................................................................................................................... 30Business Example ................................................................................................................................................. 44
Message: CancelCaseAssignment <camt.032.001.01> .................................................................................... 49Message Scope and Usage .................................................................................................................................... 49Message Structure ................................................................................................................................................. 49Message Items Description ................................................................................................................................... 50Business Example ................................................................................................................................................. 52
Message: CaseStatusReport <camt.039.001.01> .............................................................................................. 58Message Scope and Usage .................................................................................................................................... 58Message Structure ................................................................................................................................................. 58Message Items Description ................................................................................................................................... 59Business Example ................................................................................................................................................. 64
Message: CaseStatusReportRequest <camt.038.001.01> ................................................................................ 67Message Scope and Usage .................................................................................................................................... 67Message Structure ................................................................................................................................................. 67Message Items Description ................................................................................................................................... 68Business Example ................................................................................................................................................. 70
Message: ClaimNonReceipt <camt.027.001.01> .............................................................................................. 73Message Scope and Usage .................................................................................................................................... 73Message Structure ................................................................................................................................................. 74Message Items Description ................................................................................................................................... 75Business Example ................................................................................................................................................. 79
Message: DebitAuthorisationRequest <camt.037.001.01> .............................................................................. 93Message Scope and Usage .................................................................................................................................... 93Message Structure ................................................................................................................................................. 93Message Items Description ................................................................................................................................... 94Business Example ................................................................................................................................................. 99
Message: DebitAuthorisationResponse <camt.036.001.01> ......................................................................... 104Message Scope and Usage .................................................................................................................................. 104Message Structure ............................................................................................................................................... 104
Message Items Description ................................................................................................................................. 105Business Example ............................................................................................................................................... 108
Message: NotificationOfCaseAssignment <camt.030.001.01> ...................................................................... 114Message Scope and Usage .................................................................................................................................. 114Message Structure ............................................................................................................................................... 115Message Items Description ................................................................................................................................. 115Business Example ............................................................................................................................................... 119
Message: RejectCaseAssignment <camt.031.001.01> ................................................................................... 126Message Scope and Usage .................................................................................................................................. 126Message Structure ............................................................................................................................................... 126Message Items Description ................................................................................................................................. 127Business Example ............................................................................................................................................... 130
Message: RequestForDuplicateInstruction <camt.033.001.01> ................................................................... 133Message Scope and Usage .................................................................................................................................. 133Message Structure ............................................................................................................................................... 133Message Items Description ................................................................................................................................. 134Business Example ............................................................................................................................................... 136
Message: RequestToCancelPayment <camt.008.002.01> ............................................................................. 139Message Scope and Usage .................................................................................................................................. 139Message Structure ............................................................................................................................................... 140Message Items Description ................................................................................................................................. 141Business Example ............................................................................................................................................... 145
Message: RequestToModifyPayment <camt.007.002.01> ............................................................................ 153Message Scope and Usage .................................................................................................................................. 153Message Structure ............................................................................................................................................... 155Message Items Description ................................................................................................................................. 157Business Example ............................................................................................................................................... 173
Message: ResolutionOfInvestigation <camt.029.001.01> .............................................................................. 185Message Scope and Usage .................................................................................................................................. 185Message Structure ............................................................................................................................................... 186Message Items Description ................................................................................................................................. 187Business Example ............................................................................................................................................... 194
Message: UnableToApply <camt.026.001.01> ............................................................................................... 196Message Scope and Usage .................................................................................................................................. 196Message Structure ............................................................................................................................................... 197Message Items Description ................................................................................................................................. 198Business Example ............................................................................................................................................... 204
Message Item Types .............................................................................................................................................. 223Data Types .......................................................................................................................................................... 223End Points ........................................................................................................................................................... 232
Indexes ................................................................................................................................................................... 268Index of Message Items ...................................................................................................................................... 268Index of XML tags ............................................................................................................................................. 281Index of Message Item Types ............................................................................................................................. 295
Errata ..................................................................................................................................................................... 305Definition for RejectionReason Code UKNW ................................................................................................... 305
Revision Record .................................................................................................................................................... 306
OverviewWhat does this document contain?This document describes a set of Payments Exceptions and Investigations messages approved by the Payments Standards Evaluation Group as UNIFI messages on 25 July 2006.The set of Exceptions and Investigations messages documented in this report is exchanged between case assigners and case assignees. The set supports the following payment-related investigation activities:1. Request to cancel payment: this request is initiated by the party that initiated the payment. It includes the
RequestForDebitAuthorisation and its confirmation, but excludes the return of funds.2. Request to modify payment: this request is initiated by the party that initiated the payment. It includes the
AdditionalInformation message sent to the beneficiary. 3. Unable to apply: this activity is initiated by a party instructed to make a payment or the beneficiary of the payment.4. Claim non-receipt: this activity is initiated by the party waiting for a payment. This party contacts its debtor. The
debtor creates a case and assigns it by sending the case to the party instructed to make the payment. The activity also covers missing cover situations.
These specific activities are supported by the concept of case management. The case management messages are:
Exceptions and Investigations messages- the ResolutionOfInvestigation message: this message provides a definite answer to the inquiry (positive or negative),
and enables the case assignee to close the case. - the NotificationOfCaseAssignment message: this message notifies the case assigner that a case has been assigned
to a next party in the payment chain.- the RequestForDuplicateInstruction message: this message requests a copy of the original transaction from the case
assigner/creator. It is used when the case assignee is not able to find the payment transaction that the enquiry is related to.
- the RejectCaseAssignment message: this message is sent from the case assignee when he does not have the payment transaction that the enquiry is related to.
- the CancelCaseAssignment message: this message is sent by the case creator and forwarded to the next case assignee if the case has been wrongly allocated or the case has been solved by other means.
- the CaseStatusReportRequest message: this message is used to request the status of a case under investigation.- the CaseStatusReport message: this message is used to provide the status of the case in response to a
CaseStatusReportRequest message.- the DebitAuthorisationRequest: this message is used to request debit authorisation from the creditor.- the DebitAuthorisationResponse message: this message is used by a creditor to provide an answer to a
DebitAuthorisationrequest message.- the AdditionalPaymentInformation message: this message is used to provide additional information about a payment
instruction.
Business rationale for the Exceptions and Investigations messages
In an average payments operations department, two to five percent of all payments made on any particular day result in an enquiry. In an effort to improve the competitive position of their cash management offerings, financial institutions are putting increasing pressure on their payments operations. While many processing units achieve impressive straight-through processing (STP) rates, it has become clear that the cost of handling each enquiry resulting from a payment is multiplied in the total payment cost.
Management of exceptions and investigations remains one of the most labour-intensive activities for a financial institution, largely because it blocks increased automation. The reason for this is the widespread use of free-format messages combined with a lack of industry rules.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Overview
Page 1
In response to increasing regulatory and competitive pressure, financial institutions are looking at implementing activity-based pricing, and at invoicing their payments services separately from the processing. This approach is designed to generate additional revenue. However, it requires a high level of service, supported by standardised customer reporting.
The fact remains that improving customer service levels though fast and efficient resolution of problems is a key differentiating factor for customer retention.
How to readIn compliance with ISO 20022, UML (Unified Modelling Language) is used to depict business and logical models. As knowledge of UML is not a requirement to discuss the business standards, the data format for the messages are presented in a user-friendlier way. This way of representation is automatically generated from the models, thereby ensuring absolute consistency between the model information and the published standard.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Overview
Page 2
How to use the exceptions and investigations messages
This section describes the context and various work flows supporting the Exceptions and Investigations processes.
Introduction
An exception or investigation process starts when a problem occurs in the normal execution of a payment transaction:- an expected payment is not received;- a payment is received but is incorrect;- a payment is received but some information is missing, preventing its processing;- a payment must be modified, following a decision by the party instructing the payment or due to a processing error;- a payment needs to be cancelled, following a decision by the party instructing the payment or due to a processing
error.
Four different types of exception and investigation processes have been covered and a corresponding set of messages developed:- Request for cancellation: occurs when the instructing party requests cancellation of a payment instruction.- Request for modification: occurs when the instructing party requests modification of a payment instruction.- Unable to apply: occurs when insufficient or incorrect information prevents the processing of a payment instruction,
eg, the account number is missing or incorrect, the account is closed, the name and account do not match, the final agent is missing. Processing of a payment instruction covers both the execution of the instruction and the reconciliation of the instruction.
- Claim non receipt: occurs when a party expecting a payment does not receive it or when an agent is missing the cover for a received payment instruction.
An exception or investigation process requires communication with several parties. It is therefore essential to clearly define the behaviour of each party involved and the communication between them. This may lead to an increased number of messages exchanged, but the exceptions and investigations processes become more efficient.
Each exception and investigation process is supported by a specific workflow. A workflow defines the set of messages to be exchanged between the parties and the sequence of exchanges.
This section contains the definition of a case management main scenario as well as related workflows explaining the basic principles supporting the four others. It also explains the main concepts driving the set of messages and the rules to be observed by the parties.
Concepts
The exception or investigation caseAn exception or investigation case is created each time an exception and investigation process needs to be initiated. This creation is internal to the party initiating an investigation workflow: the case creation and handling can be either electronic or paper-based. The steps in the process that follow the case creation can be either automated or manual. The first message exchanged in an investigation workflow is called a 'case assignment' message. There is one specific 'case assignment' message for each of the four activities:
Activity Case assignment message
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
How to use the exceptions and investigations messages
Page 3
Request for cancellation RequestToCancelPayment
Request for modification RequestToModifyPayment
Unable to apply UnableToApply
Claim non receipt ClaimNonReceipt
Case creator, case assigner and case assignee The party creating the case is called the case creator.The case creator or any other party sending a case assignment message is called the case assigner.The party receiving a case assignment message is called the case assignee.
Case identificationThe case creator must assign an identification to the case. This identification will be repeated in all messages related to this case by all parties involved in the workflow.
Rules
Uniqueness of the case identificationThe identification of a case must be unique for the case creator. The case creator must assign the case identification in such a way that it ensures uniqueness (eg, if a sequential number is assigned to each case, the range of numbers should be large enough to avoid ambiguity when restarting the sequence).In order to make this identification unique for all the parties involved in the workflow, the BIC (or BEI) of the case creator will always be repeated together with the case identification.A simple approach is to combine a date followed with a sequential number (e.g. 20050603000001).
The 'no by-pass' ruleEach workflow specifies the parties that a case can be assigned to. For example, a request for cancellation case assignment follows the route of the payment instruction (from instructing party to instructed party), while the unable to apply case assignment is sent in the opposite direction (from the instructed party to the instructing party).
The following table summarises the direction of the various investigation activities:
Activity Case assignment message Case assigner Case assignee
Request for cancellation
RequestToCancelPayment Instructing party Instructed party/creditor
Request for modification
RequestToModifyPayment Instructing party Instructed party/creditor
Unable to apply UnableToApply Instructed party/creditor Instructing party
Claim non receipt * ClaimNonReceipt Instructing party Instructed party
* the claim non receipt activity encompasses the missing cover situation, which has a different behaviour: the case is first assigned by the final agent to the first agent and then follows the route of the payment instruction (cover payment).
The 'no by-pass' rule specifies that no party involved in the original payment transaction can be by-passed in the exception and investigation workflow. It also specifies that all parties involved in an investigation workflow must be kept informed of the status of the investigation at all times. It means that:
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
How to use the exceptions and investigations messages
Page 4
- the ResolutionOfInvestigation message must be sent by the party solving the investigation to the case assigner. This ResolutionOfInvestigation message must be forwarded to all preceding case assignees until it reaches the case creator.
- each time a case is assigned to another party, the party must notify this new assignment to its case assigner. This NotificationOfAssignment message must also be forwarded up to the case creator.
Note: In the transition phase, not all financial institutions will be using the exceptions and investigations service. Some workflows are likely to involve financial institutions that have not yet implemented the principles described in this document. Each member of the service should try to follow these principles with other parties, even if a workflow involves a party that is not a member of this service.
Case management main scenario
This section describes the generic workflow supporting the four specific activities covered in the scope of the exception and investigation message set.
A B C D
1.CaseAssignment2.CaseAssignment
4. CaseAssignment3. NotificationOfAssignment
5. Notificat ionOfAssignment
6. NotificationOfAssignment
7.ResolutionOfInvestigation8.ResolutionOfInvestigation
9.ResolutionOfInvestigation
Step 1: A assigns a case to B
A case is assigned to another party by sending one of the four case assignment messages: RequestToCancelPayment, RequestToModifyPayment, UnableToApply or ClaimNonReceipt.
When a case is assigned to a case assignee, the case assignee must first check the validity of the assignment. The assignment is valid if the following two conditions are met:1. the case assignee can retrieve the underlying payment instruction (the instruction under investigation) and this
instruction has not been rejected or cancelled.2. the assignee is entitled to investigate the underlying payment instruction (eg, a request for cancellation assigned by
the final agent to the debtor does not make sense). Generally speaking, a case can be assigned by a case assigner to a case assignee if the underlying instruction was exchanged between the same two parties.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
How to use the exceptions and investigations messages
Page 5
If the assignment is valid, the case assignee must check that there is no other case open on this underlying instruction.
If there is no other case open for the same payment instruction, the case assignee must accept the case. Acceptance is implicit. There is no specific acceptance message sent to the case assigner.
If there is another case open on the same payment instruction, the case assignee can request the closure of one of the open cases. This is achieved by sending a ResolutionOfInvestigation message with the identification of the case to be closed.
If there is another case open on the same payment instruction the case assignee can request the cancellation of the duplicate case assignment by sending a CancelCaseAssignment. The CancelCaseAssignment message is answered by a ResolutionOfInvestigation message with AssignmentCancellationConfirmation set to 'yes'.
If the assignment is not valid, it must be rejected.
This is achieved by sending a RejectCaseAssignment message to the case assigner with the CaseAssignmentRejectionCode set to value:
NFND UnderlyingPaymentNotFound
The underlying payment instruction cannot be found.
NAUT NotAuthorisedToInvestigate The case assignee is not allowed to investigate this instruction (eg, case assignee is not the next party in the payment chain).
UKNW UnknownCase Used when receiving a ResolutionOfInvestigation or a DebitAuthorisation for an unknown case. It can also be used when a party rejects a case status request.
RJCT Rejected The payment instruction has been rejected.
CNCL Cancelled The payment instruction has been cancelled.
If the case assignee does not have enough information to retrieve the underlying instruction, it can request a copy of the original instruction (see the request for duplicate instruction workflow below).
Step 2: B assigns the case to C.If the case assignee is not able to solve the case and assumes the next party is able to resolve the case, the case assignment message is forwarded to the next party in the payment instruction processing chain.
Step 3: B sends a NotificationOfCaseAssignment to A.After assigning the case to the next party, B informs A of the new assignment of the case.
Step 4: C assigns the case to D.
Step 5: C sends a NotificationOfAssignment to B.After assigning the case to the next party, C informs B of the new assignment of the case.
Step 6: B forwards the NotificationOfAssignment to A.B informs A of the new assignment of the case to D.
Step 7: D sends a ResolutionOfInvestigation to C.After solving the case, D sends a ResolutionOfInvestigation to C.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
How to use the exceptions and investigations messages
Page 6
Step 8: C forwards the ResolutionOfInvestigation to B.
Step 9: B forwards the ResolutionOfInvestigation to A.
Cancel case assignment scenarioThis workflow can be initiated by the case assigner wanting to stop the processing of a case. It must be answered with a ResolutionOfInvestigation message expressing a positive or negative answer.It must be forwarded by all subsequent case assigners/case assignees until it reaches the case creator. If the first CancelCaseAssignment message is sent by the case creator, it will result in the case being cancelled. If it is sent by an intermediate assigner, only the assignment initiated by this party (and their potential subsequent assignments) will be cancelled.
A B C1. CaseAssignment
6. ResolutionOfInvestigation
3. CancelAssignement
2. CaseAss ignment
4. CancelAssignement
5. ResolutionOfInvestigation
Step 1: A assigns a case to B.
Step 2: B assigns a case to C.
Step 3: A requests the cancellation of the previous assignment by sending a CancelCaseAssignment message to B.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
How to use the exceptions and investigations messages
Page 7
Step 4: B forwards the request to C by sending a similar CancelCaseAssignment message to C.
Step 5: C replies to B with a ResolutionOfInvestigation message. Depending on the result of the request, the ResolutionOfInvestigation will contain an element (AssignmentCancellationConfirmation) set to 'yes' (cancellation confirmed) or 'no' (cancellation rejected).
Step 6: B forwards to A the response received from C.
Request for duplicate instruction scenarioThis scenario can be initiated by a case assignee that does not have enough information to retrieve the underlying instruction. In such a case, the case assignee can request a copy of the original instruction. This is achieved by sending a RequestForDuplicateInstruction message. It will be answered by a DuplicateInstruction message.
A B
CaseAssignment
RequestForDuplicateInstruction
DuplicateInstruction
Step 1: The case assigner assigns the case to the case assignee.
Step 2: The case assignee needs more information and requests a duplicate of the payment instruction referenced in the case using the RequestForDuplicateInstruction message.
Step 3: The case assigner returns a duplicate of the payment instruction using a DuplicateInstruction message. Note that this message can be used to return duplicates of a payment instruction in any format (eg, XML, FIN, EDIFACT, proprietary, ...).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
How to use the exceptions and investigations messages
Page 8
Message FlowsRequest for cancellation scenario
This scenario describes the workflow to cancel a payment instruction.
The party willing to cancel a payment instruction, ie, the debtor, first agent or any other agent involved in the payment instruction processing chain determines the case identification and the information necessary to identify the underlying payment and sends a RequestToCancelPayment message to its case assignee.
One of the following values must be used within the RequestToCancelPayment message to specify the reason for cancellation:
Cancellation Reason Codes
AGNT IncorrectAgent An agent in the payment workflow is incorrect.
DUPL DuplicatePayment The payment is a duplicate of another payment.
CURR IncorrectCurrency The currency of the payment is incorrect.
UPAY UnduePayment The payment is not justified.
CUST RequestedByCustomer Cancellation is requested by the debtor.
When the message reaches the case assignee: - the payment instruction may have been successfully processed,- the payment instruction may be pending execution,
or- the cancellation cannot be performed, eg, the request for cancellation case is outside the agreed limits or when the
payment instruction has been unsuccessfully processed.
If the payment has been successfully processed, the case assignee must:- forward the RequestToCancelPayment message to the next agent.
The RequestToCancelPayment message is sent to the next agent in the payment chain. The current agent becomes the case assigner and the next agent in the payment chain becomes the case assignee. The message sent is similar to the one received: the case identification and the reason for the cancellation remain the same. The identification of the underlying payment may be different: it must always be the identification used between the case assigner and the case assignee.
- reply with a NotificationOfCaseAssignment message to the case assigner. This message contains the case identification and a CaseForwardingNotification1Code with value:
FTHI FurtherInvestigation Case has been forwarded to the next party for further investigation.
If the payment is still pending execution, the case assignee:- can perform the cancellation,
and- sends a positive ResolutionOfInvestigation message to its case assigner. This message contains the case
identification and InvestigationExecutionConfirmation1Code with value:
CNCL CancelledAsPerRequest Returned when a requested cancellation is successful.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 9
If the request for cancellation cannot be performed, the ResolutionOfInvestigation message is used to reject the request. This message then contains a PaymentCancellationRejection1Code with one of the following values:
LEGL LegalDecision Reported when the cancellation cannot be accepted because of regulatory rules.
AGNT AgentDecision Reported when an agent refuses to cancel.
CUST CustomerDecision Reported when the cancellation cannot be accepted because of a customer decision (creditor).
When the case is assigned to the final agent and the payment has already been processed successfully, he must:- send a DebitAuthorisationRequest to the creditor.
This message must contain the case identification as in the RequestToCancelPayment. The underlying payment identification must be the identification appearing on the statement or the credit advice sent to the creditor. The reason for cancellation must be identical to the one received in the RequestToCancelPayment message.
- reply with a NotificationOfCaseAssignment message to the case assigner. This message will indicate that a request for debit authorisation has been issued to the creditor. The CaseForwardingNotification1Code is set to value:
DTAU RequestDebitAuthorisation Case has been forwarded to obtain authorisation to debit.
The creditor sends a DebitAuthorisationResponse to the final agent. This message must contain a DebitAuthorisationIndicator set to yes or no, depending on the decision of the creditor.
This response triggers the issuance by the final agent of a ResolutionOfInvestigation message to the preceding case assigner and up to the case creator.
When the response is positive, the InvestigationExecutionConfirmation1Code is set with value:
CNCL CancelledAsPerRequest Returned when a requested cancellation is successful.
When the response is negative, the PaymentCancellationRejection1Code is set with value:
CUST CustomerDecision Reported when the cancellation cannot be accepted because of a customer decision (creditor).
An optional reason in the form of a text (max. 140 characters) can be added to the code.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 10
Request for cancellation
Debtor FirstAgent FinalAgent Creditor
RequestToCancelPayment
RequestToCancelPayment
Notificat ionOfAssignmentDebitAuthorisationRequestNotificationOfAssignment
Notificat ionOfAssignment
DebitAuthorisationResponse
ResolutionOfInvestigation
ResolutionOfInvestigation
Request for modification scenario
This scenario describes the workflow when a payment instruction needs to be modified.The case creator creates an investigation case and assigns it by sending a RequestToModifyPayment message. The RequestToModifyPayment message stipulates the elements that are to be modified.
The following table summarises the information that can be modified within a payment instruction. The second column indicates the ultimate party within the payment instruction processing chain that may receive the RequestToModifyPayment message:
RelatedReference Up to the creditor
BankOperationCode Up to last instructed party
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 11
InstructionCode Up to last instructed party
RequestedExecutionDate Up to first instructed party
ValueDate Up to last instructed party
InterbankSettledAmount Up to last instructed party
Debtor Up to creditor
DebtorAccount Up to first instructed party
IntermediarySettlementAgent Up to next instructed agent
LastSettlementAgent Up to next instructed agent
PaymentScheme Up to next instructed agent
BeneficiaryInstitutionAccount Up to last instructed party
Creditor Up to last instructed party
CreditorAccount Up to last instructed party
Remittance information Up to creditor
Purpose Up to creditor
Instruction for final agent Up to last instructed agent
DetailsOfCharges Up to creditor
SenderToReceiverInformation Up to next instructed agent
On the case assignee's side, the following situations may occur:- the payment instruction has been cancelled, rejected or returned. This means the modification cannot take place and
the case assigner will be notified through the RejectCaseAssignment message.- the payment instruction has been successfully processed. The case assignee will forward the
RequestToModifyPayment message to the next instructed party (eg, if the remittance information needs to be modified). The case assignee sends a NotificationOfCaseAssignment message to the case assigner/case creator.
- the payment instruction is still pending execution at the case assignee and the modification can take place. The case assignee sends a ResolutionOfInvestigation message to the case assigner with the InvestigationExecutionConfirmation1Code element set to value MODI (ModifiedAsPerRequest).
- the payment instruction is still pending execution at the case assignee but the case assignee prefers not to modify the payment instruction (eg, for security reasons) and opts for a cancellation of the original payment instruction.The case assignee sends a ResolutionOfInvestigation message to the case assigner with the PaymentModificationRejection1Code element set to value UM20 (InstructionCancelledSubmitNewInstruction).
- the payment instruction is still pending execution at the case assignee and one of the elements cannot be successfully modified. The whole RequestToModifyPayment is rejected. The case assignee sends a negative ResolutionOfInvestigation message. At least one occurrence of the PaymentModificationRejection1Code element must contain one of the codes from the table below. If several elements of the request cannot be modified, then several occurrences of the PaymentModificationRejection1Code element can be used.
UM01 UnableToModifyRelatedReference RelatedReference cannot be modified.
UM02 UnableToModifyBankOperationCode BankOperationCode cannot be modified.
UM03 UnableToModifyInstructionCode InstructionCode cannot be modified.
UM04 UnableToModifyRequestedExecutionDate RequestedExecutionDate cannot be modified.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 12
UM05 UnableToModifyValueDate ValueDate cannot be modified.
UM06 UnableToModifyInterbankSettlementAccount InterbankSettlementAccount cannot be modified.
UM07 UnableToModifyDebtor Debtor cannot be modified.
UM08 UnableToModifyDebtorAccount DebtorAccount cannot be modified.
UM09 UnableToModifyReceiverCorrespondent ReceiverCorrespondent cannot be modified.
UM10 UnableToModifyThirdReimbursementInstitution ThirdReimbursementInstitution cannot be modified.
UM11 UnableToModifyPaymentScheme PaymentScheme cannot be modified.
UM12 UnableToModifyAccountOfBeneficiaryInstitution AccountOfBeneficiaryInstitution cannot be modified.
UM13 UnableToModifyCreditor Creditor cannot be modified.
UM14 UnableToModifyCreditorAccount CreditorAccount cannot be modified.
UM15 UnableToModifyRemittanceInformation RemittanceInformation cannot be modified.
UM16 UnableToModifyPaymentPurpose PaymentPurpose cannot be modified.
UM17 UnableToModifyDetailsOfCharges DetailsOfCharges cannot be modified.
UM18 UnableToModifySenderToReceiverInformation SenderToReceiver cannot be modified.
UM19 UnableToModifyInstructionForFinalAgent InstructionForFinalAgent cannot be modified.
UM20 InstructionCancelledSubmitNewInstruction Used to inform of cancellation and request a new payment instruction. This should only be used if an agent does not want to modify a pending payment.
UM21 UnableToModifySubmitCancellation Modification is not possible and the cancellation is requested.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 13
Request for modification
Debtor : CorporateApplication
FirstAgent : FinancialInstAppli...
FinalAgent : Financ ialInstAppli.. .
Creditor : CorporateApplication
RequestToModifyPaymentRequestToModifyPayment
RequestToModifyPaymentNotificationOfCaseAssignment
Notificat ionOfCaseAssignment
NotificationOfCaseAssignment
ResolutionOfInvestigation
ResolutionOfInvestigation
ResolutionOfInvestigation
Modification of the payment instruction amount scenario
When the RequestToModifyPayment message concerns the payment instruction amount, the following actions must be taken:
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 14
- if the amount of the original payment instruction is higher than the amount to be effectively paid to the creditor, the case assignee performing the modification must return the funds to the case assigner. This means that in some circumstances, the final agent will have to request debit authorisation from the creditor (when the payment instruction has been successfully processed up to the creditor).
- if the amount of the original payment instruction is lower than the amount to be effectively paid to the creditor, the case creator must send a new payment instruction to meet the difference. The latter action is not considered as an investigation case.
Request for modification when the amount is lower than the original amount
Debtor FirstAgent FinalAgentCreditor
RequestToModifyPaymentRequestToModifyPayment
DebitAuthorisationRequest
DebitAuthorisationResponseResolutionOfInvestigation
ResolutionOfInvestigation
Case assignment to the final agent scenario
When the RequestToModifyPayment message is assigned to the final agent, and when the payment instruction processing has been completed, there are three possible outcomes:
1. the RequestToModifyPayment does not contradict the payment instruction: the modified elements (eg, remittance information) are forwarded to the creditor. The RequestToModifyPayment message is used for this forwarding.
2. the RequestToModifyPayment contradicts the payment instruction (eg, wrong creditor): this requires full debit authorisation from the creditor. A DebitAuthorisationRequest must be sent to the creditor (please refer to the RequestToCancelPayment workflow for more details).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 15
3. the RequestToModifyPayment partially contradicts the payment instruction (eg, amount paid in excess): this requires partial debit authorisation from the creditor. A DebitAuthorisationRequest must be sent to the creditor (please refer to the RequestToCancelPayment workflow for more details).
Request for modification followed by a cancellation
Debtor First Agent Final Agent Creditor
RequestToModifyPaymentRequestToCancelPayment
NotificationOfAssignment
ResolutionOfInvestigationResolut ionOfInvest igation
DebitAuthorisationRequest
DebitAuthorisationResponse
NotificationOfAssignmentNotificationOfAssignment
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 16
Claim non receipt scenario
A claim non receipt case is initiated by the originator of the payment instruction (usually the debtor). The creditor may also ask its financial institution whether a payment has arrived. This possibility is considered marginal and not retained as a workflow in this set of standards.The workflow exclusively considers that the party expecting a payment contacts its debtor. The debtor creates a case and assigns the case to its first agent by sending a ClaimNonReceipt message. The case assignee checks the status of the received payment instruction. The payment instruction can be pending, rejected or cancelled, or executed:
1. if the payment instruction is pending, the case assignee confirms the instruction will be executed with a ResolutionOfInvestigation message. The case assignee sends a ResolutionOfInvestigation message to the case assigner. The ResolutionOfInvestigation message contains the InvestigationExecutionConfirmation1Code element set to value IPYI (PaymentInstructionInitiated).
2. if the payment instruction has been rejected or cancelled, the case assignee notifies the rejection or cancellation with a RejectCaseAssignment message.
3. if the payment instruction has been executed: the case assignee checks the execution status. Different actions can be taken:
3.1. if the payment instruction was correctly executed and the payment is 'not on us', the case assignee forwards the claim non receipt case to the next agent in the payment processing chain (by means of a ClaimNonReceipt message). This message is similar to the one received: the case identification remains the one assigned by the case creator. The identification of the underlying instruction may be different: it must be the identification used between the case assigner and the case assignee. This message must be followed by a NotificationOfCaseAssignment sent to the case assigner. This message simply contains the case identification and a CaseForwardingNotificationCode set to value FTHI (FurtherInvestigation).
3.2. if the payment instruction execution was correctly executed and the payment is 'on us', the case assignee returns the identification of the payment with a ResolutionOfInvestigation message (in the CorrectionTransaction component). Following reception of this message, the case assigner should close the case. This message contains in the InvestigationExecutionConfirmation1Code element set to value CONF (ConfirmationOfPayment).
3.3. if the payment instruction was incorrectly executed, the case assignee will initiate a RequestToCancelPayment or a RequestToModifyPayment.
When a cancellation is required, the case assignee initiates a correct payment and returns its identification to the case assigner with a ResolutionOfInvestigation message (within the CorrectionTransaction component). This ResolutionOfInvestigation message contains the InvestigationExecutionConfirmation1Code element set to value IPAY (PaymentInitiated) . The ResolutionOfInvestigation message will be forwarded up to the case creator.
When a modification is required, the case assignee sends a RequestToModifyPayment message to the next party. A NotificationOfCaseAssignment message must be sent to the initial case assigner. This message simply contains the case identification and a CaseForwardingNotificationCode set to value MODI (RequestToModify).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 17
Claim non receipt
Debtor : CorporateApplication
FirstAgent : FinancialInstAppli...
FinalAgent : FinancialInstAppli...
Creditor : CorporateApplication
ClaimNonReceipt
ClaimNonReceiptNotificationOfAssignment
Not ificationOfAssignmentAdditionalPaymentInformation
ResolutionOfInvestigation
ResolutionOfInvestigation
ResolutionOfInvestigation
NotificationOfAssignment
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 18
Claim non receipt followed by a modification
Debtor First Agent Final Agent Creditor
ClaimNonReceiptClaimNonReceipt
NotificationOfAssignment
NotificationOfAssignmentNotificationOFAssignment
RequestToModifyPayment
Resolut ionOfInvestigationResolutionOfInvestigation
ResolutionOfInvestigation
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 19
Claim non receipt followed by a cancellation
Debtor First Agent Final Agent Creditor
ClaimNonReceipt
ClaimNonReceipt
ResolutionOfInvestigation
NotificationOfAssignment
This party needs to cancel an instruct ion and initiates a new instruc tion.
Resolut ionOfInvestigation
Missing cover scenario
The missing cover situation is considered part of the claim non receipt case.
The missing cover corresponds to the situation where an agent has received a payment instruction (eg, MT 103) and is missing the cover (eg, MT 202).
The agent missing the cover is the case creator and assigns the case to the sender of the payment instruction (eg, MT 103). The ClaimNonReceipt message contains a specific MissingCoverIndicator element to stipulate the cover is missing which must be set to yes.
Upon receipt, the case assignee checks the execution of the cover instruction and the payment instruction:
- if the cover instruction (eg, MT 202) was sent correctly (ie, identical to the payment instruction elements), the missing cover case must be forwarded to the first settlement agent (the receiver of MT 202) for investigation. This agent in turn will also check if the cover has been executed correctly.
- if the cover instruction was not sent, the case assignee can either initiate the cover instruction (MT 202) or confirm that the cover instruction is not required and cancel the payment instruction (MT103).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 20
When the cover instruction needs to be initiated, the case assignee returns a ResolutionOfInvestigation message with the InvestigationExecutionConfirmation1Code element set to ICOV (CoverInitiated).
When the payment instruction needs to be cancelled, the case assignee returns a ResolutionOfInvestigation message with the InvestigationExecutionConfirmation1Code element set to CWFW (CancellationWillFollow).
- if the cover instruction was sent incorrectly, the case assignee can either modify or cancel the cover instruction.
When the cover instruction needs to be modified (eg, wrong creditor's account), the case assignee sends a RequestToModifyPayment message to the next party in the cover instruction processing chain. This case assignee, upon completion of the modification, returns a ResolutionOfInvestigation to its case assigner with the InvestigationExecutionConfirmation1Code element set to MCOV (CoverModified).
When the cover instruction needs to be cancelled (eg, wrong creditor), the case assignee sends a RequestToCancelPayment message and initiates a new cover instruction. This request for cancellation must be considered as a separate case. The new instruction must be initiated and its reference must be returned in the CorrectionTransaction element of the ResolutionOfInvestigation message. The InvestigationExecutionConfirmation1Code element must be set to ICOV (CoverInitiated).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 21
Missing cover
FirstAgent Firs tSettlementAgent ...
LastSettlementAgent ...
FinalAgent
ClaimNonReceipt
ResolutionOfInvestigation
2. ClaimNonReceipt
ClaimNonReceipt
NotificationOfAssignment
NotificationOfAssignment
ResolutionOfInvestigationResolutionOfInvest igation
Unable to apply scenario
The unable to apply scenario covers two main situations:- a payment instruction has been received, but incorrect/missing payment information prevents its processing (unable
to execute);
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 22
- a payment instruction or entry has been received, but incorrect/missing payment information prevents its reconciliation (unable to apply).
The unable to apply scenario describes how to request additional information when a party has received a payment instruction and is unable to apply or execute.
The party that is unable to apply or execute a payment instruction creates an investigation case and assigns the case to its instructing party by sending an UnableToApply message.
The case creator determines the case identification and the information necessary to identify the underlying payment. The underlying payment identification should be the one used by the case assignee (eg, the entry identification or the payment instruction identification).
The case creator must indicate the reason for assigning the case.
The UnableToApply message provides the possibility to specifically indicate the element from the payment instruction that is either missing or incorrect (within the MissingOrIncorrectInformation element).
The following list is used to identify incorrect information from the payment instruction:
IN01 IncorrectRelatedReference Related reference is incorrect.
IN02 IncorrectBankOperationCode Bank operation code is incorrect.
IN03 IncorrectInstructionCode Instruction code is incorrect.
IN04 IncorrectRequestedExecutionDate Requested execution date is incorrect.
IN05 IncorrectValueDate Value date is incorrect.
IN06 IncorrectInterbankSettledAmount Interbank settled amount is incorrect.
IN07 IncorrectDebtor Debtor is incorrect.
IN08 IncorrectDebtorAccount Debtor account is incorrect.
IN09 IncorrectReceiverCorrespondent Receiver correspondent is incorrect.
IN010 IncorrectThirdReimbursementInstitution Third reimbursement institution is incorrect.
IN011 IncorrectPaymentScheme Payment scheme is incorrect.
IN012 IncorrectAccountOfBeneficiaryInstitution Account of Beneficiary institution is incorrect.
IN013 IncorrectCreditor Creditor is incorrect.
IN014 IncorrectCreditorAccount Creditor account is incorrect.
IN15 IncorrectRemittanceInformation Remittance information is incorrect.
IN16 IncorrectPaymentPurpose Payment purpose is incorrect.
IN17 IncorrectDetailsOfCharges Details of charges is incorrect.
IN18 IncorrectSenderToReceiverInformation Sender to receiver information is incorrect.
IN19 IncorrectInstructionForFinalAgent Instruction for Final Agent is incorrect.
MM20 MismatchCreditorNameAccount Name and Account of Creditor mismatch.
MM21 MismatchDebtorNameAccount Name and Account of Debtor mismatched.
MM22 MismatchFinalAgentNameAccount Name and Account of Final Agent mismatched.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 23
The following list is used to identify missing information from the payment instruction:
MS01 MissingRemittanceInformation Remittance Information is missing.
MS02 MissingSenderToReceiverInformation Sender To Receiver Information is missing.
MS03 MissingDebtor Debtor is missing.
MS04 MissingDebtorAccount Debtor Account is missing.
MS05 MissingFirstAgent First Agent is missing.
MS06 MissingAmount Missing Amount
MS07 MissingNostroVostroAccount Nostro Vostro Account is missing.
MS08 MissingIntermediary Intermediary is missing.
MS09 MissingReimbursementAgent1 Reimbursement Agent (Field 53) is missing.
MS10 MissingReimbursementAgent2 Reimbursement Agent (Field 54) is missing.
MS11 MissingReimbursementAgent Reimbursement Agent (Field 55) is missing.
MS12 MissingCreditor Creditor is missing.
MS13 MissingCreditorAccount Creditor Account is missing.
MS14 MissingInstruction Indicates the payment instruction (MT103) is missing.
The case assignee checks the execution of the payment instruction. The result of this check can either be positive (payment instruction executed correctly) or negative (payment instruction executed incorrectly).
If the payment instruction was correctly executed, and if more information is available at the case assignee, the case assignee can send additional information when available to allow reconciliation by sending an AdditionalPaymentInformation message to the case assigner. The case assignee can decide to send all the additional information instead of only returning the missing or additional information.
If the payment instruction was correctly executed, and if no further information is available at the case assignee, the case assignee can assign the case by forwarding an UnableToApply message to the preceding agent. The sender identifies itself as the case assigner and the previous instructing party in the payment processing chain is the case assignee. The case identification remains the same. The identification of the underlying payment should become the case assignee's identification (eg, field 20 of the FIN message or InstructionReference of an XML payment instruction). In the latter case, the case assignee must send a NotificationOfCaseAssignment message to the case assigner.
If the payment instruction was incorrectly executed, the case assignee can either:- request the modification of the payment instruction by sending a RequestToModifyPayment message to the case
assigner,
or- request the cancellation of the payment instruction by sending a ResolutionOfInvestigation message with the
InvestigationExecutionConfirmation1Code set to CWFW (CancellationWillFollow) and by sending a RequestToCancelPayment message afterwards.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 24
Unable to apply followed by sending additional information
Debtor : CorporateApplication
FirstAgent : FinancialInstAppli...
FinalAgent : FinancialInstAppli...
Creditor : CorporateApplication
UnableToApplyUnableToApply
UnableToApply
AdditionalPaymentInformation
AdditionalPaymentInformation
AdditionalPaymentInformation
Not ificationOfAssignment
NotificationOfAssignmentNotificationOfAssignment
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 25
Unable to apply followed by a request for cancellation
Debtor : CorporateApplication
FirstAgent : FinancialInstAppli...
FinalAgent : FinancialInstAppli...
Creditor : CorporateApplication
UnableToApply
UnableToApply
UnableToApplyNotificationOfAssignment
Notificat ionOfAssignment
NotificationOfAssignment
RequestToCancelPaymentRequestToCancelPayment
DebitAuthorisationRequest
DebitAuthorisationResponse
ResolutionOfInvestigation
ResolutionOfInvestigation
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 26
Unable to apply followed by a request for modification
Debtor FirstAgent CreditorFinalAgent
UnableToApply
UnableToApplyUnableToApply NotificationOfAssignment
Notificat ionOfAssignment NotificationOfAssignment
RequestToModifyPaymentRequestToModifyPayment
RequestToModifyPayment
ResolutionOfInvestigationResolut ionOfInvest igation
Resolut ionOfInvest igation
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Flows
Page 27
Message: AdditionalPaymentInformation <camt.028.001.01>Message Scope and UsageScope
The AdditionalPaymentInformation message is sent by an account servicing institution to an account owner.
This message is used to provide additional or corrected information on a payment instruction or statement entry, in order to allow reconciliation.
Usage
The AdditionalPaymentInformation message provides elements which are usually not reported in a statement or advice message (eg, full remittance information, or identification of parties other than the account servicing institution and the account owner). It complements information already received about a payment instruction, in the form of an entry or copy of the original payment instruction.
The AdditionalPaymentInformation message covers one and only one original payment instruction. If several payment instructions need to be supplemented, multiple AdditionalPaymentInformation messages must be used.
The AdditionalPaymentInformation message is used in a:- ClaimNonReceipt workflow: when the processing of the payment instruction is complete, the account owner receives
further particulars or corrected information for its reconciliation processes.- RequestToModifyPayment workflow: when the processing of the payment instruction is complete and the
modification does not affect the accounting at the account servicing institution, the account owner receives further particulars or corrected information about a payment instruction or an entry passed to its account.
The AdditionalPaymentInformation message cannot be used to trigger a request for modification of a payment instruction activity. A RequestToModifyPayment message must be used.
In the majority of cases, the AdditionalPaymentInformation message provides sufficient information to close the case. A ResolutionOfInvestigation message can be used as a reply to close the case and inform previous parties in the chain.
OutlineThe AdditionalPaymentInformation message is composed of four building blocks.
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Payment Instruction ExtractThis building block is optional.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 28
D.Payment Complementary InformationThis building block is mandatory.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Underlying <Undrlyg> [1..1]
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 Information <Inf> [1..1]
4.1 RemittanceChoice <RmtChc> [0..1]
4.2 {Or Unstructured <Ustrd> [1..1] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 29
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.3 Or} Structured <Strd> [1..1]
4.4 ReferredDocumentType <RfrdDocTp> [0..1] Code
4.5 ReferredDocumentRelatedDate <RfrdDocRltdDt> [0..1] DateTime
4.6 ReferredDocumentAmount <RfrdDocAmt> [0..n]
4.7 {{Or DuePayableAmount <DuePyblAmt> [1..1] Amount
4.8 Or DiscountAppliedAmount <DscntApldAmt> [1..1] Amount
4.9 Or RemittedAmount <RmtdAmt> [1..1] Amount
4.10 Or CreditNoteAmount <CdtNoteAmt> [1..1] Amount
4.11 Or}} TaxAmount <TaxAmt> [1..1] Amount
4.12 DocumentReferenceNumber <DocRefNb> [0..1] Text
4.13 CreditorReference <CdtrRef> [0..1] Text
4.14 Invoicer <Invcr> [0..1] +
4.15 Invoicee <Invcee> [0..1] +
4.16 Debtor <Dbtr> [0..1] +
4.17 DebtorAccount <DbtrAcct> [0..1] +
4.18 FirstAgent <FrstAgt> [0..1] +
4.19 Amount <Amt> [0..1]
4.20 {Or InstructedAmount <InstdAmt> [1..1] Amount
4.21 Or} EquivalentAmount <EqvtAmt> [1..1]
4.22 Amount <Amt> [1..1] Amount
4.23 CurrencyOfTransfer <CcyOfTrf> [1..1] Code
4.24 NostroVostroAccount <NstrVstrAcct> [0..1] +
4.25 Intermediary <Intrmy> [0..1] +
4.26 FirstSettlementAgent <FrstSttlmAgt> [0..1] +
4.27 LastSettlementAgent <LastSttlmAgt> [0..1] +
4.28 IntermediarySettlementAgent <IntrmySttlmAgt> [0..1] +
4.29 Creditor <Cdtr> [0..1] +
4.30 CreditorAccount <CdtrAcct> [0..1] +
4.31 SenderToReceiverInformation <SndrToRcvrInf> [0..6] Text
Message Items DescriptionThe following section identifies the elements of the AdditionalPaymentInformation message.
1.0 Assignment <Assgnmt>Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 30
Definition: Identifies the assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 31
Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Underlying <Undrlyg>Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 32
Definition: Identifies the underlying payment instruction.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
3.1 AssignerInstructionIdentification <AssgnrInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2 AssigneeInstructionIdentification <AssgneInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.3 CurrencyAmount <CcyAmt>Presence: [0..1]Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or
the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
3.4 ValueDate <ValDt>Presence: [0..1]Definition: Value date of the payment.Data Type: ISODateTime
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 33
4.0 Information <Inf>Presence: [1..1]Definition: Additional information to the underlying payment instruction.Type: The Information block is composed of the following PaymentComplementaryInformation element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 RemittanceChoice <RmtChc> [0..1]
4.16 Debtor <Dbtr> [0..1] +
4.17 DebtorAccount <DbtrAcct> [0..1] +
4.18 FirstAgent <FrstAgt> [0..1] +
4.19 Amount <Amt> [0..1]
4.24 NostroVostroAccount <NstrVstrAcct> [0..1] +
4.25 Intermediary <Intrmy> [0..1] +
4.26 FirstSettlementAgent <FrstSttlmAgt> [0..1] +
4.27 LastSettlementAgent <LastSttlmAgt> [0..1] +
4.28 IntermediarySettlementAgent <IntrmySttlmAgt> [0..1] +
4.29 Creditor <Cdtr> [0..1] +
4.30 CreditorAccount <CdtrAcct> [0..1] +
4.31 SenderToReceiverInformation <SndrToRcvrInf> [0..6] Text
4.1 RemittanceChoice <RmtChc>Presence: [0..1]Definition: Remittance information.Type: This message item is composed of one of the following RemittanceInformation3Choice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.2 {Or Unstructured <Ustrd> [1..1] Text
4.3 Or} Structured <Strd> [1..1]
4.2 Unstructured <Ustrd>Presence: [1..1]This message item is part of choice 4.1 RemittanceChoice.Definition: Information, in free text form, to enable the matching, ie reconciliation, (reconciliation) of a payment with
the items that the payment is intended to settle, such as commercial invoices in an accounts receivable system.Data Type: Max140TextFormat: maxLength: 140
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 34
4.3 Structured <Strd>Presence: [1..1]This message item is part of choice 4.1 RemittanceChoice.Definition: Information in structured form, that is supplied to enable the matching, ie, reconciliation, of a payment with
the items that the payment is intended to settle, eg, commercial invoices in an account receivable system. Type: This message item is composed of the following StructuredRemittanceInformation2 element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.4 ReferredDocumentType <RfrdDocTp> [0..1] Code
4.5 ReferredDocumentRelatedDate <RfrdDocRltdDt> [0..1] DateTime
4.6 ReferredDocumentAmount <RfrdDocAmt> [0..n]
4.12 DocumentReferenceNumber <DocRefNb> [0..1] Text
4.13 CreditorReference <CdtrRef> [0..1] Text
4.14 Invoicer <Invcr> [0..1] +
4.15 Invoicee <Invcee> [0..1] +
4.4 ReferredDocumentType <RfrdDocTp>Presence: [0..1]Definition: Specifies the nature of the referred document/transaction, eg, invoice or credit note.Data Type: CodeWhen this message item is present, one of the following DocumentType1Code values must be used:
Code Name DefinitionCINV CommercialInvoice Document is an invoice.
CMCN CommercialContract Document is an agreement between the parties, stipulating the terms and conditions of the delivery of goods or services.
CNFA CreditNoteRelatedToFinancialAdjustment
Document is a credit note for the final amount settled for a commercial transaction.
CREN CreditNote Document is a credit note.
DEBN DebitNote Document is a debit note.
DNFA DebitNoteRelatedToFinancialAdjustment
Document is a debit note for the final amount settled for a commercial transaction.
FXDR ForeignExchangeDealReference
Document is a pre-agreed or pre-arranged foreign exchange transaction to which the payment transaction refers.
HIRI HireInvoice Document is an invoice for the hiring of human resources or renting goods or equipment.
MSIN MeteredServiceInvoice Document is an invoice claiming payment for the supply of metered services, eg, gas or electricity, supplied to a fixed meter.
RADM RemittanceAdviceMessage Document is a remittance advice sent separately from the current transaction.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 35
Code Name DefinitionRPIN RelatedPaymentInstruction Document is a linked payment instruction to which the
current payment instruction is related, eg, in a cover scenario.
SBIN SelfBilledInvoice Document is an invoice issued by the debtor.
SOAC StatementOfAccount Document is a statement of the transactions posted to the debtor's account at the supplier.
4.5 ReferredDocumentRelatedDate <RfrdDocRltdDt>Presence: [0..1]Definition: Date associated with the referred document, eg, date of issue. Data Type: ISODate
4.6 ReferredDocumentAmount <RfrdDocAmt>Presence: [0..n]Definition: Amount of money and currency of a document referred to in the remittance section. The amount is typically
either the original amount due and payable, or the amount actually remitted for the referred document.Type: This message item is composed of one of the following ReferredDocumentAmount1Choice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.7 {Or DuePayableAmount <DuePyblAmt> [1..1] Amount
4.8 Or DiscountAppliedAmount <DscntApldAmt> [1..1] Amount
4.9 Or RemittedAmount <RmtdAmt> [1..1] Amount
4.10 Or CreditNoteAmount <CdtNoteAmt> [1..1] Amount
4.11 Or} TaxAmount <TaxAmt> [1..1] Amount
4.7 DuePayableAmount <DuePyblAmt>Presence: [1..1]This message item is part of choice 4.6 ReferredDocumentAmount.Definition: Amount specified is the exact amount due and payable to the creditor.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.8 DiscountAppliedAmount <DscntApldAmt>Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 36
This message item is part of choice 4.6 ReferredDocumentAmount.Definition: Amount of money resulting from the application of an agreed discount to the amount due and payable to the
creditor.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.9 RemittedAmount <RmtdAmt>Presence: [1..1]This message item is part of choice 4.6 ReferredDocumentAmount.Definition: Amount of money remitted for the referred document.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.10 CreditNoteAmount <CdtNoteAmt>Presence: [1..1]This message item is part of choice 4.6 ReferredDocumentAmount.Definition: Amount specified for the referred document is the amount of a credit note.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.11 TaxAmount <TaxAmt>Presence: [1..1]This message item is part of choice 4.6 ReferredDocumentAmount.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 37
Definition: Quantity of cash resulting from the calculation of the tax.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.12 DocumentReferenceNumber <DocRefNb>Presence: [0..1]Definition: Unique and unambiguous identification of a document that distinguishes that document from another
document referred to in the remittance information, usually assigned by the originator of the referred document/transaction.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.13 CreditorReference <CdtrRef>Presence: [0..1]Definition: Unique and unambiguous reference assigned by the creditor to refer to the payment transaction.
Usage: if available, the initiating party should provide this reference in the structured remittance information, to enable reconciliation by the creditor upon receipt of the cash.
If the business context requires the use of a creditor reference or a payment remit identification, and only one identifier can be passed through the end-to-end chain, the creditor's reference or payment remittance identification should be quoted in the end-to-end transaction identification.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.14 Invoicer <Invcr>Presence: [0..1]Definition: Identification of the organization issuing the invoice when different than the creditor or final party Type: This message item is composed of the following PartyIdentification1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Name <Nm> [0..1] Text
PostalAddress <PstlAdr> [0..1]
Identification <Id> [0..1]
For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 38
4.15 Invoicee <Invcee>Presence: [0..1]Definition: Identification of the party to whom an invoice is issued, when different than the originator or debtor.Type: This message item is composed of the following PartyIdentification1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Name <Nm> [0..1] Text
PostalAddress <PstlAdr> [0..1]
Identification <Id> [0..1]
For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section
4.16 Debtor <Dbtr>Presence: [0..1]Definition: Debtor or Ordering customer of the payment instruction.Type: This message item is composed of the following PartyIdentification1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Name <Nm> [0..1] Text
PostalAddress <PstlAdr> [0..1]
Identification <Id> [0..1]
For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section
4.17 DebtorAccount <DbtrAcct>Presence: [0..1]Definition: Debtor account or Ordering customer account.Type: This message item is composed of the following CashAccount3 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Identification <Id> [1..1]
Type <Tp> [0 ..1] Code
Currency <Ccy> [0..1] Code
Name <Nm> [0..1] Text
For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section
4.18 FirstAgent <FrstAgt>Presence: [0..1]Definition: First Agent or Field 52 in Fin messages.Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 39
Or Message Item <XML Tag> Mult. Represent./Type
FinancialInstitutionIdentification <FinInstnId> [1..1]
BranchIdentification <BrnchId> [0..1]
For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section
4.19 Amount <Amt>Presence: [0..1]Definition: Instructed amount of the payment instruction (Field 33B)Type: This message item is composed of one of the following AmountType1Choice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.20 {Or InstructedAmount <InstdAmt> [1..1] Amount
4.21 Or} EquivalentAmount <EqvtAmt> [1..1]
4.20 InstructedAmount <InstdAmt>Presence: [1..1]This message item is part of choice 4.19 Amount.Definition: Amount of money to be transferred between debtor and creditor, before deduction of charges, expressed in
the currency of the debtor's account or in another currency..
Usage : Currency of the amount is expressed in the currency (or one of the currencies) of the debtor's account or another currency, eg, pay 1000000 EUR (and debtor's account is is EUR) or pay 1000000 JPY (and debtor's account is in EUR).
Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.21 EquivalentAmount <EqvtAmt>Presence: [1..1]This message item is part of choice 4.19 Amount.Definition: Amount of money to be transferred between the debtor and creditor, before deduction of charges, expressed
in the currency of the debtor's account, and to be transferred into a different currency.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 40
Usage : Currency of the amount is expressed in the currency of the debtor's account, but the amount to be transferred is in another currency. The first agent will convert the amount and currency to the to be transferred amount and currency, eg, 'pay equivalent of 100000 EUR in JPY'(and account is in EUR).
Type: This message item is composed of the following EquivalentAmount element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.22 Amount <Amt> [1..1] Amount
4.23 CurrencyOfTransfer <CcyOfTrf> [1..1] Code
4.22 Amount <Amt>Presence: [1..1]Definition: Amount of money to be transferred between debtor and creditor, before deduction of charges, expressed in
the currency of the debtor's account, and to be transferred in a different currency.
Usage : Currency of the amount is expressed in the currency of the debtor's account, but the amount to be transferred is in another currency. The first agent will convert the amount and currency to the to be transferred amount and currency, eg, 'pay equivalent of 100000 EUR in JPY'(and account is in EUR).
Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.23 CurrencyOfTransfer <CcyOfTrf>Presence: [1..1]Definition: Specifies the currency of the to be transferred amount, which is different from the currency of the debtor's
account.Data Type: CurrencyCodeFormat: [A-Z]{3,3}Rule(s): ValidationByTable
4.24 NostroVostroAccount <NstrVstrAcct>Presence: [0..1]Definition: Indicates the account used to cover a payment.Type: This message item is composed of the following CashAccount3 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Identification <Id> [1..1]
Type <Tp> [0 ..1] Code
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 41
Or Message Item <XML Tag> Mult. Represent./Type
Currency <Ccy> [0..1] Code
Name <Nm> [0..1] Text
For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section
4.25 Intermediary <Intrmy>Presence: [0..1]Definition: Intermediary bank.Type: This message item is composed of the following Intermediary1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Identification <Id> [1..1]
Account <Acct> [0..1]
Role <Role> [0..1] Text
For additional Type information, please refer to Intermediary1 p.247 in 'Message Item Types' section
4.26 FirstSettlementAgent <FrstSttlmAgt>Presence: [0..1]Definition: Correspondent of the first agent (Field 53 in MT202).Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):
Or Message Item <XML Tag> Mult. Represent./Type
FinancialInstitutionIdentification <FinInstnId> [1..1]
BranchIdentification <BrnchId> [0..1]
For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section
4.27 LastSettlementAgent <LastSttlmAgt>Presence: [0..1]Definition: Correspondent of the Final agent (Field 54 of Mt 202)Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):
Or Message Item <XML Tag> Mult. Represent./Type
FinancialInstitutionIdentification <FinInstnId> [1..1]
BranchIdentification <BrnchId> [0..1]
For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 42
4.28 IntermediarySettlementAgent <IntrmySttlmAgt>Presence: [0..1]Definition: Equivalent to Field 55 in MT202.Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):
Or Message Item <XML Tag> Mult. Represent./Type
FinancialInstitutionIdentification <FinInstnId> [1..1]
BranchIdentification <BrnchId> [0..1]
For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section
4.29 Creditor <Cdtr>Presence: [0..1]Definition: Creditor or Beneficiary customer of the payment instruction.Type: This message item is composed of the following PartyIdentification1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Name <Nm> [0..1] Text
PostalAddress <PstlAdr> [0..1]
Identification <Id> [0..1]
For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section
4.30 CreditorAccount <CdtrAcct>Presence: [0..1]Definition: Creditor account or Beneficiary customer account.Type: This message item is composed of the following CashAccount3 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Identification <Id> [1..1]
Type <Tp> [0 ..1] Code
Currency <Ccy> [0..1] Code
Name <Nm> [0..1] Text
For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section
4.31 SenderToReceiverInformation <SndrToRcvrInf>Presence: [0..6]Definition: Unformatted information from the sender to the receiver.Data Type: Max35Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 43
Format: maxLength: 35minLength: 1
Business Example
The following illustrates one scenario for the AdditionalPaymentInformation workflow. This scenario is based on an initial RequestToModifyPayment scenario. The AdditionalPaymentInformation message is shown in Step 3.1 below. The scenario is based on the payment characteristics in the table below.
Customer A (BEI CUSAGB2L) instructed Bank A (AAAAGB2L) to execute a payment. The payment settles a series of invoices received in January 2005 and referenced in the remittance information section of the payment instruction. The unstructured remittance information reproduced below refers to two commercial invoices.
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer A (BEI CUSAGB2L)
Receiver Bank A, London (AAAAGB2L)
Instruction Reference CPAY0123456789
Transaction Reference 20050127003
Requested Execution Date 2005-01-27
Instructed Amount and Currency
52317.48 GBP
Unstructured Remittance Information
/INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/
Final Agent Bank K, London (KKKKGB2L)
Creditor Customer S (ASUPGB2L)All Supplies and Co
Scenario 1, resulting in an AdditionalPaymentInformation message
NarrativeCustomer A checks its accounts payables. The dates for the two invoices have been incorrectly reported in the remittance information.
Step 1Customer A decides to request the modification of the payment instruction in order for the creditor to automatically reconcile the accounts receivables with the payment instruction amount. Customer A makes a request for modification of the payment instruction to change the remittance information content.
The following RequestToModifyPayment message is sent by Customer A to Bank A:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSTA20050003</Id><Assgnr>CUASGB2L</Assgnr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 44
<Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CPAY0123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<RmtInf><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has already been forwarded to Bank K, under reference 1030123456789. Bank A needs to forward the RequestToModifyPayment message to Bank K (Step 2.1). At the same time, Bank A informs Customer A of the case assignment to Bank K (Step 2.2).
Step 2.1Bank A requests the modification of the original payment instruction to Bank K.
The following RequestToModifyPayment message is sent by Bank A to Bank K:XML Instance
<camt.007.002.01><Assgnmt>
<Id>C103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<RmtInf><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 45
Step 2.2 Bank A informs Customer A of the case assignment to Bank K.
The following NotificationOfAssignment message is sent by Bank A to Customer A: XML Instance
<camt.030.001.01><Hdr>
<Id>RCUSTA20050001</Id><Fr>AAAAGB2L</Fr><To>CUSAGB2L</To><CreDtTm>2005-01-27T08:50:22</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</Case><Assgnmt>
<Id>C103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>MODI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank K receives the RequestToModifyPayment message from Bank A and checks the status of the instruction. The instruction has been correctly executed. The credit has been passed onto the account of Customer S and the customer has been informed. Bank K forwards the correct remittance information content to Customer S, using an AdditionalPaymentInformation message (Step 3.1). At the same time, as there is no further processing needed, a ResolutionOfInvestigation message is sent to Bank A, notifying that the information has been delivered to the customer (Step 3.2). Bank A in turn reverts to Customer A with a ResolutionOfInvestigation message (Step 3.3).
Step 3.1Bank K forwards additional information about the payment to Customer S.
The following AdditionalPaymentInformation message is sent by Bank K to Customer S:XML Instance
<camt.028.001.01><Assgnmt>
<Id>I103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:52:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 46
</Case><Undrlyg>
<AssgnrInstrId>I1030123456789</AssgnrInstrId></Undrlyg><Inf>
<RmtChc><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>
</RmtChc><Cdtr>
<Nm>All Supplies and Co</Nm><Id>
<OrgId><BEI>CUSBGB2L</BEI>
</OrgId></Id>
</Cdtr></Inf>
</camt.028.001.01>
Step 3.2Bank K informs Bank A of the resolution of the investigation.
The following ResolutionOfInvestigation message is sent by Bank K to Bank A.XML Instance
<camt.029.001.01><Assgnmt>
<Id>RKKKKAAAA20050127004</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T09:08:23</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Step 3.3Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A of the resolution of the investigation.
The following ResolutionOfInvestigation message is sent by Bank A to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>RAAAACUSA20050127004</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 47
<CreDtTm>2005-01-27T09:18:23</CreDtTm></Assgnmt><RslvdCase>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: AdditionalPaymentInformation <camt.028.001.01>
Page 48
Message: CancelCaseAssignment <camt.032.001.01>Message Scope and UsageScopeThe CancelCaseAssignment message is sent by a case creator/case assigner to a case assignee.This message is used to request the cancellation of a case.
Usage
The CancelCaseAssignment message is used to stop the processing of a case at a case assignee when a case assignment is incorrect or when the root cause for the case disappears (eg, the account owner was able to reconcile after sending a ClaimNonReceipt message).
The CancelCaseAssignment message can be used to stop the processing of a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case
The CancelCaseAssignment message covers one and only one case at a time. If several case assignments need to be cancelled, then multiple CancelCaseAssignment messages must be sent.
The CancelCaseAssignment message must be forwarded by all subsequent case assignee(s) in the case processing chain until it reaches the case creator. When the CancelCaseAssignment message is assigned to a subsequent case assignee, a NotificationOfCaseAssignment message is sent to the case assigner/case creator, in reply. When the CancelCaseAssignment instruction has been acted upon by the relevant case assignee, a ResolutionOfInvestigation message is sent to the case assigner/case creator, in reply.
The CancelCaseAssignment message must not be used for other purposes. If, for example, a request to modify payment fails, and the case creator requests the cancellation of the payment, then a RequestToCancelPayment message must be used, with the case identification of the original RequestToModifyPayment message. The CancelCaseAssignment message is not an option.
OutlineThe CancelCaseAssignment message is composed of two building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
Message Structure
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 49
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Message Items DescriptionThe following section identifies the elements of the CancelCaseAssignment message.
1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 50
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 51
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
Business Example
The following illustrates the CancelCaseAssignment message.
Customer E (BEI EEEEUS33) instructed Bank N, New York (NNNNS33) to execute a payment. The payment settles an invoice received from Customer V (BEI VVVVUS33).
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer E (BEI EEEEUS33)
Receiver Bank N, New York (NNNNUS33)
Instruction Reference CECOMSUP001003
Transaction Reference 200505220002
Requested Execution Date 2005-05-25
Instructed Amount 10234.56 USD
Final Agent Bank F (FFFFUS33)
Creditor Customer V (VVVVUS33)
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 52
General Plumbing and Co
NarrativeCustomer E checks its accounts payables. The payment instruction contained an incorrect amount (the payment was made for an amount excluding VAT). As the amount to be paid is higher than the amount instructed, and for ease of reconciliation, Customer E requests the cancellation of the original payment instruction and issues a new payment instruction.The new payment instruction is not illustrated in this business example.
Step 1Customer E sends a request for the cancellation of the payment instruction to Bank N, New York.
The following RequestToCancelPayment message is sent by Customer E to Bank N:XML Instance
<camt.008.002.01><Assgnmt>
<Id>AB20050417CANC</Id><Assgnr>EEEEUS33</Assgnr><Assgne>NNNNUS33</Assgne><CreDtTm>2005-05-26T09:10:30</CreDtTm>
</Assgnmt><Case>
<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CECOMSUP001003</AssgnrInstrId><CcyAmt Ccy = "USD">10234.56</CcyAmt><ValDt>2005-05-25T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>CUST</CxlRsn></Justfn>
</camt.008.002.01>
Step 2Bank N receives the RequestToCancelPayment message from Customer E and investigates the status of the payment instruction. The payment instruction has been correctly executed and forwarded to Bank F under reference AFFFFUS4567. Bank N forwards the RequestToCancelPayment message to Bank F (Step 2.1) and informs Customer E about the case assignment (Step 2.2).
Step 2.1 Bank N forwards the RequestToCancelPayment message to Bank F.
The following RequestToCancelPayment message is sent by Bank N to Bank F:XML Instance
<camt.008.002.01><Assgnmt>
<Id>NNNNCANC0001200888</Id><Assgnr>NNNNUS33</Assgnr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 53
<Assgne>FFFFUS33</Assgne><CreDtTm>2005-05-26T10:07:23</CreDtTm>
</Assgnmt><Case>
<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>AFFFFUS4567</AssgnrInstrId><CcyAmt Ccy = "USD">10234.56</CcyAmt><ValDt>2005-05-25T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>CUST</CxlRsn></Justfn>
</camt.008.002.01>
Step 2.2 Bank N notifies the case assignment to Customer E.
The following NotificationOfCaseAssignment message is sent by Bank N to Customer E:XML Instance
<camt.030.001.01><Hdr>
<Id>RESPAB20050417CANC</Id><Fr>NNNNUS33</Fr><To>EEEEUS33</To><CreDtTm>2005-05-26T10:22:23</CreDtTm>
</Hdr><Case>
<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>
</Case><Assgnmt>
<Id>NNNNCANC0001200888</Id><Assgnr>NNNNUS33</Assgnr><Assgne>FFFFUS33</Assgne><CreDtTm>2005-05-26T10:07:23</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>CANC</Justfn></Ntfctn>
</camt.030.001.01>
Step 3In the meantime, Bank F, New York, receives the original payment instruction. However, the account number for the beneficiary customer is not present in the message. The payment processing rules at Bank F means that a return of the payment instruction is automatically generated, together with a reason code set to account number missing (this step is not illustrated here). Customer V holds an account with Bank G and not with Bank F, New York.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 54
When Customer E receives its statement, it reconciles the credit entry to its account (due to the return of funds) and the pending request to cancel the payment case.The cancellation of the original payment instruction is therefore no longer necessary and Customer E decides to request the cancellation of the case assignment (Step 3.1). In turn, Bank N will request the cancellation of the assignment to Bank F, New York (Step 3.2).
Step 3.1Customer E requests the cancellation of the case assignment to Bank N.
The following CancelCaseAssignment message is sent by Customer E to Bank N:XML Instance
<camt.032.001.01><Assgnmt>
<Id>CANCEEEE20050525001</Id><Assgnr>EEEEUS33</Assgnr><Assgne>NNNNUS33</Assgne><CreDtTm>2005-05-27T08:42:34</CreDtTm>
</Assgnmt><Case>
<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>
</Case></camt.032.001.01>
Step 3.2Bank N forwards the CancelCaseAssignment message to Bank F (Step 3.2.1) and informs Customer E of the case assignment (Step 3.2.2).
Step 3.2.1The following CancelCaseAssignment message is sent by Bank N to Bank F:XLM Instance
<camt.032.001.01><Assgnmt>
<Id>CANCNNNN20050527004</Id><Assgnr>NNNNUS33</Assgnr><Assgne>FFFFUS33</Assgne><CreDtTm>2005-05-27T09:07:35</CreDtTm>
</Assgnmt><Case>
<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>
</Case></camt.032.001.01>
Step 3.2.2The following NotificationOfCaseAssignment message is sent by Bank N to Customer E:XML Instance
<camt.030.001.01><Hdr>
<Id>RCANCEEEE20050525001</Id><Fr>NNNNUS33</Fr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 55
<To>EEEEUS33</To><CreDtTm>2005-05-27T10:21:23</CreDtTm>
</Hdr><Case>
<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>
</Case><Assgnmt>
<Id>CANCNNNN20050527004</Id><Assgnr>NNNNUS33</Assgnr><Assgne>FFFFUS33</Assgne><CreDtTm>2005-05-27T09:07:35</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>CANC</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Bank F, New York looks up the original instruction. The payment instruction has been returned. The case assignment can be cancelled and Bank F send a ResolutionOfInvestigation message to Bank N (its case assigner)(Step 4.1). Bank N informs Customer E, using the same message (Step 4.2).
Step 4.1The following ResolutionOfInvestigation message is sent by Bank F to Bank N:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFCONFCANC20050527004</Id><Assgnr>FFFFUS33</Assgnr><Assgne>NNNNUS33</Assgne><CreDtTm>2005-05-27T10:27:21</CreDtTm>
</Assgnmt><RslvdCase>
<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>
</RslvdCase><Sts>
<Conf>CNCL</Conf></Sts>
</camt.029.001.01>
Step 4.2The following ResolutionOfInvestigation message is sent by Bank N to Customer E:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONCANCEEEE20050525001</Id>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 56
<Assgnr>NNNNUS33</Assgnr><Assgne>EEEEUS33</Assgne><CreDtTm>2005-05-27T12:54:22</CreDtTm>
</Assgnmt><RslvdCase>
<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>
</RslvdCase><Sts>
<Conf>CANC</Conf></Sts>
</camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CancelCaseAssignment <camt.032.001.01>
Page 57
Message: CaseStatusReport <camt.039.001.01>Message Scope and UsageScopeThe CaseStatusReport message is sent by a case assignee to a case creator/case assigner.
This message is used to report on the status of a case.
Usage
A CaseStatusReport message is sent in reply to a CaseStatusReportRequest message.
The CaseStatusReport message covers one and only one case at a time. If a case assignee needs to report on several cases, then multiple CaseStatusReport messages must be sent.
The CaseStatusReport message may be forwarded to subsequent case assigner(s) until it reaches the case creator.
The CaseStatusReport message allows to indicate a case assignment to a subsequent case assignee.
The CaseStatusReport message must not be used in place of a ResolutionOfInvestigation or NotificationOfCaseAssignment message.
OutlineThe CaseStatusReport message is composed of four building blocks:
A.Report HeaderThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Case StatusThis building block is mandatory.
D.New AssignmentThis building block is optional.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Header <Hdr> [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 58
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.1 Identification <Id> [1..1] Text
1.2 From <Fr> [1..1] Identifier
1.3 To <To> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Status <Sts> [1..1]
3.1 DateTime <DtTm> [1..1] DateTime
3.2 CaseStatus <CaseSts> [1..1] Code
3.3 InvestigationStatus <InvstgtnSts> [0..1] Code
3.4 Reason <Rsn> [0..1] Text
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 NewAssignment <NewAssgnmt> [0..1]
4.1 Identification <Id> [1..1] Text
4.2 Assigner <Assgnr> [1..1] Identifier
4.3 Assignee <Assgne> [1..1] Identifier
4.4 CreationDateTime <CreDtTm> [1..1] DateTime
Message Items DescriptionThe following section identifies the elements of the CaseStatusReport message.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 59
1.0 Header <Hdr>Presence: [1..1]Definition: Specifies generic information about an investigation report.Type: The Header block is composed of the following ReportHeader element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 From <Fr> [1..1] Identifier
1.3 To <To> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of the report.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 From <Fr>Presence: [1..1]Definition: Party reporting the status of the case.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.3 To <To>Presence: [1..1]Definition: Party to which the status of the case is reported.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Creation date and time of the report generation.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 60
Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Status <Sts>Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 61
Definition: Defines the status of the case.Type: The Status block is composed of the following CaseStatus element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 DateTime <DtTm> [1..1] DateTime
3.2 CaseStatus <CaseSts> [1..1] Code
3.3 InvestigationStatus <InvstgtnSts> [0..1] Code
3.4 Reason <Rsn> [0..1] Text
3.1 DateTime <DtTm>Presence: [1..1]Definition: Date and time of the status.Data Type: ISODateTime
3.2 CaseStatus <CaseSts>Presence: [1..1]Definition: Status of the case.Data Type: CodeOne of the following CaseStatus1Code values must be used:
Code Name DefinitionASGN Assigned Case has been assigned to another party.
CLOSE Closed Case has been closed.
INVE UnderInvestigation Case is currently under investigation.
UKNW Unknown Case has never been assigned before.
3.3 InvestigationStatus <InvstgtnSts>Presence: [0..1]Definition: Status of the investigation.Data Type: CodeWhen this message item is present, one of the following InvestigationExecutionConfirmation1Code values must be used:
Code Name DefinitionACDA AcceptedDebitAuthorisation Returned when a creditor accepts the debit authorisation.
CNCL CancelledAsPerRequest Returned when a requested cancellation is successfull.
CONF ConfirmationOfPayment Returned when a payment has been checked and was correctly executed.
CWFW CancellationWillFollow Returned when a payment will be cancelled to solve an investigation case.
ICOV CoverInitiated Returned when a transfer of funds has been initiated (a cover payment) to resolve a case.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 62
Code Name DefinitionINFO AdditionalInformationSent Returned when additional information has been sent to the
beneficiary of a payment.
IPAY PaymentInitiated Returned when the result of an investigation is the initiation of payment instruction.
IPYI PaymentInstructionInitiated Returned when a payment instruction (eg. MT103) has been initiated to resolve a case.
MCOV CoverModified Returned when a transfer of funds has been modified (a cover payment) to resolve a case.
MODI ModifiedAsPerRequest Returned when a requested modification is successfull.
3.4 Reason <Rsn>Presence: [0..1]Definition: Free text justification of the status.Data Type: Max140TextFormat: maxLength: 140
minLength: 1
4.0 NewAssignment <NewAssgnmt>Presence: [0..1]Definition: Identifies the last assignment performed.Type: The NewAssignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 Identification <Id> [1..1] Text
4.2 Assigner <Assgnr> [1..1] Identifier
4.3 Assignee <Assgne> [1..1] Identifier
4.4 CreationDateTime <CreDtTm> [1..1] DateTime
4.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 63
Rule(s): AnyBICRule Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
4.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
4.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
Business Example
The following illustrates the usage of the CaseStatusReportRequest and CaseStatusReport messages, based on a RequestToModifyPayment workflow.
Customer G (BEI CUSGHKHH) instructed Bank G (GGGGHKHH) to execute a payment. The payment settles an invoice dated 02 May 2005 and referenced in the remittance information of the payment instruction.
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer G (BEI CUSGHKHH)
Receiver Bank G, Hong Kong (GGGGHKHH)
Instruction Reference GCOMPAY0123456789
Transaction Reference 20050524001
Requested Execution Date 2005-05-29
Instructed Amount and Currency 1267988.00 HKD
Unstructured Remittance Information /INV/20050502/HKD1267988,/200505030233/
Final Agent Bank K, Hong Kong (KKKKHKHH)
Creditor Customer H (BEI HSFIHKHH)Han and Sons Fisheries
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 64
NarrativeOn 27 May 2005, Customer G checks its accounts payables. A wrong amount has been paid to settle the invoice. As the execution date is not reached yet, Customer G requests the modification of the amount to be paid for the invoice.
Step 1Customer G requests the modification of the amount of the payment instruction (the amount should be 1331387.40 HKD instead of 1267988.00 HKD).
The following RequestToModifyPayment message is sent by Customer G to Bank G, Hong Kong:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSGHKHHMODGCOMPAY0123456789</Id><Assgnr>CUSGHKHH</Assgnr><Assgne>GGGGHKHH</Assgne><CreDtTm>2005-05-27T10:18:56</CreDtTm>
</Assgnmt><Case>
<Id>CUSGMOD050527001</Id><Cretr>CUSGHKHH</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>GCOMPAY0123456789</AssgnrInstrId><CcyAmt Ccy="HKD">1267988.00</CcyAmt><ValDt>2005-05-29T00:00:00</ValDt>
</Undrlyg><Mod>
<IntrBkSttldAmt Ccy="HKD">1331387.40</IntrBkSttldAmt></Mod>
</camt.007.002.01>
Step 2On 28 May 2005, Customer G has not yet received a response from Bank G on the RequestToModifyPayment message and requests a report of the status of the case, as the requested execution date is set for the next day.
The following CaseStatusReportRequest message is sent by Customer G to Bank G:XML Instance
<camt.038.001.01><ReqHdr>
<Id>CSRRCUSGMOD050527001</Id><Fr>CUSGHKHH</Fr><To>GGGGHKHH</To><CreDtTm>2005-05-28T10:35:30</CreDtTm>
</ReqHdr><Case>
<Id>CUSGMOD050527001</Id><Cretr>CUSGHKHH</Cretr>
</Case></camt.038.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 65
Step 3Bank G looks up the original case and assesses the status. The modification requested has been made on 27 May 2005, following the RequestToModifyPayment message and the case can be closed.
The following CaseStatusReport message is sent by Bank G to Customer G:XML Instance
<camt.039.001.01><Hdr>
<Id>HSBCRCSRRCUSGMOD050527001</Id><Fr>GGGGHKHH</Fr><To>CUSGHKHH</To><CreDtTm>2005-05-28T10:44:12</CreDtTm>
</Hdr><Case>
<Id>CUSGMOD050527001</Id><Cretr>CUSGHKHH</Cretr>
</Case><Sts>
<DtTm>2005-05-27T10:23:43</DtTm><CaseSts>CLOSE</CaseSts><InvstgtnSts>MODI</InvstgtnSts>
</Sts></camt.039.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReport <camt.039.001.01>
Page 66
Message: CaseStatusReportRequest <camt.038.001.01>Message Scope and UsageScopeThe CaseStatusReportRequest message is sent by a case creator/case assigner to a case assignee.
This message is used to request the status of a case.
Usage
The CaseStatusReportRequest message must be answered with a CaseStatusReport message.
The CaseStatusReportRequest message can be used to request the status of a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case
The CaseStatusReportRequest message covers one and only one case at a time. If a case creator/case assigner needs the status of several cases, then multiple CaseStatusReportRequest messages must be sent.
The CaseStatusReportRequest may be forwarded to subsequent case assignee(s) in the case processing chain.
The processing of a case generates NotificationOfCaseAssignment and/or ResolutionOfInvestigation messages to the case creator/case assigner. The CaseStatusReportRequest must therefore only be used when no information has been received from the case assignee within the expected time frame.
OutlineThe CaseStatusReportRequest message is composed of two building blocks:
A.Report HeaderThis building block is mandatory.
B.CaseThis building block is mandatory.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 RequestHeader <ReqHdr> [1..1]
1.1 Identification <Id> [1..1] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReportRequest <camt.038.001.01>
Page 67
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.2 From <Fr> [1..1] Identifier
1.3 To <To> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Message Items DescriptionThe following section identifies the elements of the CaseStatusReportRequest message.
1.0 RequestHeader <ReqHdr>Presence: [1..1]Definition: Identifies the party requesting the status, the requested party, the identification and the date of the status.Type: The RequestHeader block is composed of the following ReportHeader element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 From <Fr> [1..1] Identifier
1.3 To <To> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of the report.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 From <Fr>Presence: [1..1]Definition: Party reporting the status of the case.Data Type: AnyBICIdentifier
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReportRequest <camt.038.001.01>
Page 68
Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.3 To <To>Presence: [1..1]Definition: Party to which the status of the case is reported.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Creation date and time of the report generation.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReportRequest <camt.038.001.01>
Page 69
Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
Business Example
The following illustrates the usage of the CaseStatusReportRequest and CaseStatusReport messages, based on a RequestToModifyPayment workflow.
Customer G (BEI CUSGHKHH) instructed Bank G (GGGGHKHH) to execute a payment. The payment settles an invoice dated 02 May 2005 and referenced in the remittance information of the payment instruction.
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer G (BEI CUSGHKHH)
Receiver Bank G, Hong Kong (GGGGHKHH)
Instruction Reference GCOMPAY0123456789
Transaction Reference 20050524001
Requested Execution Date 2005-05-29
Instructed Amount and Currency 1267988.00 HKD
Unstructured Remittance Information /INV/20050502/HKD1267988,/200505030233/
Final Agent Bank K, Hong Kong (KKKKHKHH)
Creditor Customer H (BEI HSFIHKHH)Han and Sons Fisheries
NarrativeOn 27 May 2005, Customer G checks its accounts payables. A wrong amount has been paid to settle the invoice. As the execution date is not reached yet, Customer G requests the modification of the amount to be paid for the invoice.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReportRequest <camt.038.001.01>
Page 70
Step 1Customer G requests the modification of the amount of the payment instruction (the amount should be 1331387.40 HKD instead of 1267988.00 HKD).
The following RequestToModifyPayment message is sent by Customer G to Bank G, Hong Kong:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSGHKHHMODGCOMPAY0123456789</Id><Assgnr>CUSGHKHH</Assgnr><Assgne>GGGGHKHH</Assgne><CreDtTm>2005-05-27T10:18:56</CreDtTm>
</Assgnmt><Case>
<Id>CUSGMOD050527001</Id><Cretr>CUSGHKHH</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>GCOMPAY0123456789</AssgnrInstrId><CcyAmt Ccy="HKD">1267988.00</CcyAmt><ValDt>2005-05-29T00:00:00</ValDt>
</Undrlyg><Mod>
<IntrBkSttldAmt Ccy="HKD">1331387.40</IntrBkSttldAmt></Mod>
</camt.007.002.01>
Step 2On 28 May 2005, Customer G has not yet received a response from Bank G on the RequestToModifyPayment message and requests a report of the status of the case, as the requested execution date is set for the next day.
The following CaseStatusReportRequest message is sent by Customer G to Bank G:XML Instance
<camt.038.001.01><ReqHdr>
<Id>CSRRCUSGMOD050527001</Id><Fr>CUSGHKHH</Fr><To>GGGGHKHH</To><CreDtTm>2005-05-28T10:35:30</CreDtTm>
</ReqHdr><Case>
<Id>CUSGMOD050527001</Id><Cretr>CUSGHKHH</Cretr>
</Case></camt.038.001.01>
Step 3Bank G looks up the original case and assesses the status. The modification requested has been made on 27 May 2005, following the RequestToModifyPayment message and the case can be closed.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReportRequest <camt.038.001.01>
Page 71
The following CaseStatusReport message is sent by Bank G to Customer G:XML Instance
<camt.039.001.01><Hdr>
<Id>HSBCRCSRRCUSGMOD050527001</Id><Fr>GGGGHKHH</Fr><To>CUSGHKHH</To><CreDtTm>2005-05-28T10:44:12</CreDtTm>
</Hdr><Case>
<Id>CUSGMOD050527001</Id><Cretr>CUSGHKHH</Cretr>
</Case><Sts>
<DtTm>2005-05-27T10:23:43</DtTm><CaseSts>CLOSE</CaseSts><InvstgtnSts>MODI</InvstgtnSts>
</Sts></camt.039.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: CaseStatusReportRequest <camt.038.001.01>
Page 72
Message: ClaimNonReceipt <camt.027.001.01>Message Scope and UsageScopeThe ClaimNonReceipt message is sent by a case creator/case assigner to a case assignee.
This message is used to initiate an investigation for missing funds at the creditor (missing credit entry to its account) or at an agent along the processing chain (missing cover for a received payment instruction).
Usage
The claim non receipt case occurs in two situations:- the creditor is expecting funds from a particular debtor and cannot find the corresponding credit entry on its account.
In this situation, it is understood that the creditor will contact its debtor, and that the debtor will trigger the claim non receipt case on its behalf. A workflow where the creditor directly addresses a ClaimNonReceipt message to its account servicing institution is not retained.
- an agent in the processing chain cannot find a cover payment corresponding to the information in a received payment instruction. In this missing cover situation, the agent may directly trigger the investigation by sending a ClaimNonReceipt message to the sender of the original payment instruction.
The ClaimNonReceipt message covers one and only one payment instruction at a time. If several expected payment instructions/cover instructions are found missing, then multiple ClaimNonReceipt messages must be sent.Depending on the result of the analysis of the original payment instruction processing by a case assignee (incorrect routing, errors/omissions when processing the instruction, or no error) and the processing stage of the payment instruction, the claim non receipt case may be viewed as a: - RequestToCancelPayment message, sent to the subsequent agent in the payment processing chain, if the original
payment instruction has been incorrectly routed through the chain of agents. (This also entails that a new corrected payment instruction is issued).
- RequestToModifyPayment message, sent to the subsequent agent in the payment processing chain, if a truncation or omission has occurred during the processing of the original payment instruction.
In the cover is missing, the case assignee may also simply issue the omitted cover payment. The case assignee will issue a ResolutionOfInvestigation message with the CorrectionTransaction element mentioning the references of the cover payment.
The ClaimNonReceipt message may be forwarded to subsequent case assignees.
Main characteristicsThe ClaimNonReceipt message has the following main characteristics:
Case IdentificationThe case creator assigns a unique case identification. This information will be passed unchanged to subsequent case assignee(s).
Underlying Payment Instruction IdentificationThe case creator refers to the identification of the underlying payment instruction. This identification needs to be updated by the subsequent case assigner(s) in order to match the one used with their case assignee(s).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 73
MissingCoverIndicationThe MissingCoverIndication element distinguishes between a missing cover situation (when set to yes) or a missing funds situation (when set to no).
OutlineThe ClaimNonReceipt message is composed of four building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C. Payment Instruction ExtractThis building block is mandatory.
D. Missing Cover IndicatorThis building block is optional.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 74
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Underlying <Undrlyg> [1..1]
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 MissingCover <MssngCover> [0..1]
4.1 MissingCoverIndication <MssngCoverIndctn> [1..1] Indicator
Message Items DescriptionThe following section identifies the elements of the ClaimNonReceipt message.
1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies an assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 75
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies a case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example:
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 76
<Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Underlying <Undrlyg>Presence: [1..1]Definition: Identifies the payment instruction for which the Creditor has not received the funds.
Note: In case of a missing cover, it must be the Field 20 of the received MT103.In case of a claim non receipt initiated by the Debtor, it must be the identification of the instruction (Field 20 of MT103, Instruction Identification of the Payment Initiation or the Bulk Credit Transfer).
Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
3.1 AssignerInstructionIdentification <AssgnrInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 77
3.2 AssigneeInstructionIdentification <AssgneInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.3 CurrencyAmount <CcyAmt>Presence: [0..1]Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or
the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
3.4 ValueDate <ValDt>Presence: [0..1]Definition: Value date of the payment.Data Type: ISODateTime
4.0 MissingCover <MssngCover>Presence: [0..1]Definition: Indicates if the claim non receipt is a missing cover. The absence of the component means that the message
is not for a missing cover. Type: The MissingCover block is composed of the following MissingCover element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 MissingCoverIndication <MssngCoverIndctn> [1..1] Indicator
4.1 MissingCoverIndication <MssngCoverIndctn>Presence: [1..1]Definition: Indicates if the message is relative to a missing cover. Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 78
Business Example
The following illustrates four scenarios for the ClaimNonReceipt workflow.
Narrative for Scenarios 1, 2 and 3
Customer A (BEI AAAAFRPP) regularly orders goods from Customer V (BEI VVVVGB2L). Customer A settles its invoices on a monthly basis.
On 6 June 2005, Customer V calls Customer A to enquire about the payment for May 2005. After investigation, it appears that Customer A indeed requested payment to its bank (FFFFFRPP). Customer A issues a claim for non receipt investigation to Bank F on behalf of Customer V.
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer A, Paris (BEI AAAAFRPP)
Receiver Bank F, Paris (FFFFFRPP)
Instruction Reference 0505PAY09876543
Transaction Reference 200506020001
Requested Execution Date 2005-06-01
Instructed Amount 13498.52 GBP
Unstructured Remittance Information /INV/20050516/GBP8257.43/20050500102356//20050412/GBP5241.09/20050500202356/
Final Agent Bank U, London (UUUUGB2L)
Creditor Customer V (BEI VVVVGB2L)Country Fragrances plc
Scenario 1, resulting in a RequestToCancelPayment messageThe steps illustrated below are limited to the ClaimNonReceipt workflow. Details for the request for debit authorisation and debit authorisation response appear in the RequestToCancelPayment workflow.
Step 1The following ClaimNonReceipt message is sent by Customer A to Bank F:XML Instance
<camt.027.001.01><Assgnmt>
<Id>CNRVVVVGB2L200506020001</Id><Assgnr>AAAAFRPP</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-06T10:35:23</CreDtTm>
</Assgnmt><Case>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 79
</Case><Undrlyg>
<AssgnrInstrId>0505PAY09876543</AssgnrInstrId><CcyAmt Ccy = "GBP">13498.52</CcyAmt><ValDt>2005-06-01T00:00:00</ValDt>
</Undrlyg></camt.027.001.01>
Step 2Bank F looks up the original payment instruction. It has been executed correctly and sent to Bank U under reference 345601234. Bank F forwards the claim for non receipt investigation to Bank U, London for further investigation (Step 2.1). At the same time Bank F informs Customer A of the case assignment to Bank U (Step 2.2).
Step 2.1Bank F forwards the claim for non receipt to Bank U, London.
The following ClaimNonReceipt message is sent by Bank F to Bank U:XML Instance
<camt.027.001.01><Assgnmt>
<Id>CNRVVVVGB2L200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>UUUUGB2L</Assgne><CreDtTm>2005-06-06T10:45:21</CreDtTm>
</Assgnmt><Case>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>345601234</AssgnrInstrId><CcyAmt Ccy = "GBP">13498.52</CcyAmt><ValDt>2005-06-01T00:00:00</ValDt>
</Undrlyg></camt.027.001.01>
Step 2.2Bank F informs Customer A of the case assignment to Bank U, London.
The following NotificationOfCaseAssignment message is sent by Bank F to Customer A:XML Instance
<camt.030.001.01><Hdr>
<Id>REPCNR0505PAY09876543</Id><Fr>FFFFFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-06-06T10:52:59</CreDtTm>
</Hdr><Case>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 80
</Case><Assgnmt>
<Id>CNRVVVVGB2L200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>UUUUGB2L</Assgne><CreDtTm>2005-06-06T10:45:21</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank U looks up the original instruction. The funds have been wrongly credited to another customer's account (Customer Z). Bank U requests and obtains a debit authorisation from Customer Z and makes the entry with back value on the account of Customer V. The case is closed and Bank U informs Bank F that the investigation is resolved (Step 3.1). Upon receipt, Bank F informs Customer A of the case resolution (Step 3.2)
Step 3.1Bank U, London informs Bank F that the investigation is resolved.
The following ResolutionOfInvestigation message is sent by Bank U to Bank F:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSECNR200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-07T11:32:57</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>CONF</Conf></Sts>
</camt.029.001.01>
Step 3.2Bank F informs Customer A of the successful case resolution.
The following ResolutionOfInvestigation message is sent by Bank F to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSECNRVVVVGB2L200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-06-07T11:45:17</CreDtTm>
</Assgnmt>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 81
<RslvdCase><Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>CONF</Conf></Sts>
</camt.029.001.01>
Scenario 2, resulting in an AdditionalPaymentInformation message The initial steps of this scenario (Steps 1 and 2) replicate those described in scenario 1 above. Therefore the description of this scenario starts at Step 3.
Step 3Bank U, London looks up the original payment instruction and compares it against the statement delivered to Customer V. The remittance information, as well as the identity of the debtor, have not been correctly mentioned. The account owner reference attached to the entry is 20050602-;0001. Bank U decides to provide this additional payment information to Customer V.
The following AdditionalPaymentInformation message is sent by Bank U to Customer V:XML Instance
<camt.028.001.01><Assgnmt>
<Id>INFOVVVVGB2L200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>VVVVGB2L</Assgne><CreDtTm>2005-06-06T10:53:42</CreDtTm>
</Assgnmt><Case>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgneInstrId>200506020001</AssgneInstrId><CcyAmt Ccy = "GBP">13498.52</CcyAmt><ValDt>2005-06-01T00:00:00</ValDt>
</Undrlyg><Inf>
<RmtChc><Ustrd>/INV/20050516/GBP8257,43/20050500102356//20050412/GBP5241,09/20050500202356/</Ustrd>
</RmtChc><Dbtr>
<Nm>Customer A</Nm><Id>
<OrgId><BEI>AAAAFRPP</BEI>
</OrgId></Id>
</Dbtr><Cdtr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 82
<Id><OrgId>
<BEI>VVVVGB2L</BEI></OrgId>
</Id></Cdtr>
</Inf></camt.028.001.01>
Step 4Customer V, based on the additional payment information from Bank U, matches the entry with its accounts receivables. Customer V informs Bank U that the investigation has been resolved (Step 4.1). Bank U forwards the message to Bank F (Step 4.2). Bank F informs Customer A of the successful case resolution (Step 4.3).
Step 4.1Customer V solves the case.
The following ResolutionOfInvestigation message is sent by Customer V to Bank U:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSEVVVVGB2L200506020001</Id><Assgnr>VVVVGB2L</Assgnr><Assgne>UUUUGB2L</Assgne><CreDtTm>2005-06-07T11:45:47</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>CONF</Conf></Sts>
</camt.029.001.01>
Step 4.2Bank U closes the case and forwards the case resolution information to Bank F.
The following ResolutionOfInvestigation message is sent by Bank U to Bank F:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSECNR200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-07T11:54:54</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 83
<Sts><Conf>CONF</Conf>
</Sts></camt.029.001.01>
Step 4.3Bank F closes the case and forwards the case resolution information to Customer A.
The following ResolutionOfInvestigation message is sent by Bank F to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSECNR200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-06-07T12:15:15</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>CONF</Conf></Sts>
</camt.029.001.01>
Scenario 3, resulting in a RequestToModifyPayment messageThe initial steps of this scenario (steps 1 and 2) replicate those described in scenario 1 above. Therefore the description of this scenario starts at Step 3.
Step 3Bank U looks up the original payment instruction and compares it against the statement delivered to Customer V. The remittance information is incorrect. It should read /INV/20050516/GBP8257.43/20050500102356//20050412/GBP5241.09/20050500202356/ instead of: Payment for expenses May 2005. Bank U decides to request the modification of the payment instruction from Customer V (Step 3.1). Bank U notifies Bank F of the case assignment (Step 3.2). Upon receipt, Bank F informs Customer A (Step 3.3).
Step 3.1Bank U requests the modification of the payment instruction.
The following RequestToModifyPayment message is sent by Bank U to Customer V:XML Instance
<camt.007.002.01><Assgnmt>
<Id>MODIVVVVGB2L200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>VVVVGB2L</Assgne><CreDtTm>2005-06-06T10:53:42</CreDtTm>
</Assgnmt><Case>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 84
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgneInstrId>200506020001</AssgneInstrId><CcyAmt Ccy = "GBP">13498.52</CcyAmt><ValDt>2005-06-01T00:00:00</ValDt>
</Undrlyg><Mod>
<RmtInf><Ustrd>/INV/20050516/GBP8257.43/20050500102356//20050412/GBP5241.09/20050500202356/</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 3.2Bank U informs Bank F of the case assignment.
The following NotificationOfCaseAssignment message is sent by Bank U to Bank F:XML Instance
<camt.030.001.01><Hdr>
<Id>FORWFRAGB2L200506020001</Id><Fr>UUUUGB2L</Fr><To>FFFFFRPP</To><CreDtTm>2005-06-06T10:55:23</CreDtTm>
</Hdr><Case>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</Case><Assgnmt>
<Id>MODIVVVVGB2L200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>VVVVGB2L</Assgne><CreDtTm>2005-06-06T10:53:42</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>MODI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3.3Bank F informs Customer A of the case assignment.
The following NotificationOfCaseAssignment message is sent by Bank F to Customer A:XML Instance
<camt.030.001.01><Hdr>
<Id>FF200506020001</Id><Fr>FFFFFRPP</Fr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 85
<To>AAAAFRPP</To><CreDtTm>2005-06-06T11:05:25</CreDtTm>
</Hdr><Case>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</Case><Assgnmt>
<Id>MODIVVVVGB2L200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>VVVVGB2L</Assgne><CreDtTm>2005-06-06T10:53:42</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>MODI</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Based on the modification request, Customer V reconciles the entry with its accounts receivables. The case is closed. Customer V informs Bank U of the successful case resolution (Step 4.1). Upon receipt, Bank U closes the case and forwards the case resolution information to Bank F (Step 4.2). Bank F informs Customer A of the successful closure of the investigation (Step 4.3).
Step 4.1Customer V informs Bank U of the resolution of the case.
The following ResolutionOfInvestigation message is sent by Customer V to Bank U:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSEVVVVGB2L200506020001</Id><Assgnr>VVVVGB2L</Assgnr><Assgne>UUUUGB2L</Assgne><CreDtTm>2005-06-07T12:05:43</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Step 4.2Bank U informs Bank F of the resolution of the case.
The following ResolutionOfInvestigation message is sent by Bank U to Bank F:XML Instance
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 86
<camt.029.001.01><Assgnmt>
<Id>CLOSEVVVVGB2L200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-07T12:12:03</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Step 4.3Bank F informs Customer A of the resolution of the case.
The following ResolutionOfInvestigation message is sent by Bank F to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSEVVVVGB2L200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-06-07T12:17:04</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Scenario 4, resulting in a successful case resolutionThe following illustrates the fourth scenario for the ClaimNonReceipt workflow. This specific scenario corresponds to a missing cover case, ie, an agent has received an instruction (MT 103) which cannot be reconciled with an incoming cover payment (MT 202). The resolution of the investigation below relies upon the final agent modifying the cover payment by providing the correct reconciliation key (equivalent to the related reference in the MT 202).
NarrativeBank J (JJJJJPJT) receives a payment instruction (MT 103) referenced 123456789012 from Bank F (FFFFFRPP). The instruction indicates that the cover should be provided through its euro clearing correspondent, Bank D, Frankfurt (DDDDDEFF). During the reconciliation process of statements provided by Bank D, Bank J cannot trace the cover payment.
Characteristics of the payment instruction are as follows:
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 87
Description Value
Sender Bank F (FFFFFRPP)
Receiver Bank J (JJJJJPJT)
Instruction Reference 123456789012
Requested Execution Date 2005-;05-;05
Instructed Amount 2756.22 EUR
Step 1Bank J suspects that the cover for the payment instruction received was not executed and it decides to go back to the initiator of the MT 103 to enquire about the cover.The following ClaimNonReceipt message is sent by Bank J to Bank F:XML Instance
<camt.027.001.01><Assgnmt>
<Id>20050505COV123456789012</Id><Assgnr>JJJJJPJT</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-05-05T06:35:23</CreDtTm>
</Assgnmt><Case>
<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>
</Case><Undrlyg>
<AssgneInstrId>123456789012</AssgneInstrId><CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>
</Undrlyg><MssngCover>
<MssngCoverIndctn>true</MssngCoverIndctn></MssngCover>
</camt.027.001.01></Document>
Step 2Bank F looks up the original instruction and the cover. Both have been executed correctly. The transaction reference number for the MT 202 is COV12345678. Bank F assigns the claim for non receipt investigation to Bank H (the next agent for the MT 202, HHHHFRPP) (Step 2.1). Bank F informs Bank J of the case assignment to Bank H (Step 2.2).
Step 2.1Bank F assigns the claim non receipt request to Bank H.
The following ClaimNonReceipt message is sent by Bank F to Bank H:XML Instance
<camt.027.001.01><Assgnmt>
<Id>20050505COV12345678</Id>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 88
<Assgnr>FFFFFRPP</Assgnr><Assgne>HHHHFRPP</Assgne><CreDtTm>2005-05-05T09:35:23</CreDtTm>
</Assgnmt><Case>
<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>
</Case><Undrlyg>
<AssgneInstrId>COV12345678</AssgneInstrId><CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>
</Undrlyg></camt.027.001.01>
Step 2.2Bank F informs Bank J of the case assignment to Bank H.
The following NotificationOfCaseAssignment message is sent by Bank F to Bank J:XML Instance
<camt.030.001.01><Hdr>
<Id>INFOMC123456789012</Id><Fr>FFFFFRPP</Fr><To>JJJJJPJT</To><CreDtTm>2005-05-05T09:54:22</CreDtTm>
</Hdr><Case>
<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>
</Case><Assgnmt>
<Id>20050505COV12345678</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>HHHHFRPP</Assgne><CreDtTm>2005-05-05T09:35:23</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank H looks up the original transaction (MT 202) and finds out that it was correctly executed and forwarded to Bank D, under reference JJJJ1234567. It forwards the claim for non receipt investigation to the euro correspondent of Bank J, Bank D (Step 3.1). Bank H notifies the case assignment to Bank F (Step 3.2).
Step 3.1Bank H assigns the case to Bank D.
The following ClaimNonReceipt message is sent by Bank H to Bank D:
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 89
XML Instance<camt.027.001.01>
<Assgnmt><Id>20050505COV12345678</Id><Assgnr>HHHHFRPP</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-05-05T09:55:23</CreDtTm>
</Assgnmt><Case>
<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>JJJJ1234567</AssgnrInstrId><CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>
</Undrlyg></camt.027.001.01>
Step 3.2Bank H informs Bank F of the case assignment to Bank D.
The following NotificationOfCaseAssignment message is sent by Bank H to Bank F:XML Instance
<camt.030.001.01><Hdr>
<Id>FUMC123456789012</Id><Fr>HHHHFRPP</Fr><To>FFFFFRPP</To><CreDtTm>2005-05-05T09:59:18</CreDtTm>
</Hdr><Case>
<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>
</Case><Assgnmt>
<Id>20050505COV12345678</Id><Assgnr>HHHHFRPP</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-05-05T09:55:23</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Bank D checks the instruction received from Bank H. The MT 202 has been received late and the value date for the MT 202 is set for the next day. The credit entry for the MT 202 does not have the requested value date. Bank D decides to back value the entry to the preceding day for Bank J. Although the entry will be reported on the next day statement, it will bear the correct value date. The instruction has been modified and the case is therefore closed.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 90
Bank D informs Bank H of the successful case resolution (Step 4.1). Bank H forwards the resolution of the case to Bank F (Step 4.2). Finally Bank F reverts to Bank J with the same information (Step 4.3).
Step 4.1Bank D informs Bank H of the successful case resolution.
The following ResolutionOfInvestigation message is sent by Bank D to Bank H:XML Instance
<camt.029.001.01><Assgnmt>
<Id>REP20050505COV12345678</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>HHHHFRPP</Assgne><CreDtTm>2005-06-07T12:19:05</CreDtTm>
</Assgnmt><RslvdCase>
<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>
</RslvdCase><Sts>
<Conf>MCOV</Conf></Sts><CrrctnTx>
<CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>
</CrrctnTx></camt.029.001.01>
</Document>
Scenario 4.2Bank H informs Bank F of the successful case resolution.
The following ResolutionOfInvestigation message is sent by Bank H to Bank F:XML Instance
<camt.029.001.01><Assgnmt>
<Id>FOLL20050505COV12345678</Id><Assgnr>HHHHFRPP</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-07T12:22:05</CreDtTm>
</Assgnmt><RslvdCase>
<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>
</RslvdCase><Sts>
<Conf>MCOV</Conf></Sts><CrrctnTx>
<CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 91
</CrrctnTx></camt.029.001.01>
Step 4.3Bank F informs Bank J of the successful case resolution.
The following ResolutionOfInvestigation message is sent by Bank F to Bank J:XML Instance
<camt.029.001.01><Assgnmt>
<Id>FOLL20050505COV12345678</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>JJJJJPJT</Assgne><CreDtTm>2005-06-07T12:25:05</CreDtTm>
</Assgnmt><RslvdCase>
<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>
</RslvdCase><Sts>
<Conf>MCOV</Conf></Sts><CrrctnTx>
<CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>
</CrrctnTx></camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ClaimNonReceipt <camt.027.001.01>
Page 92
Message: DebitAuthorisationRequest <camt.037.001.01>Message Scope and UsageScopeThe DebitAuthorisationRequest message is sent by an account servicing institution to an account owner.
This message is used to request authorisation to debit an account.
Usage
The DebitAuthorisationRequest message must be answered with a DebitAuthorisationResponse message.
The DebitAuthorisationRequest message can be used to request debit authorisation in a:- request to modify payment case (lower amount or change of creditor)- request to cancel payment case (full amount)- unable to apply case (the creditor is not the intended beneficiary)- claim non receipt case (the creditor is not the intended beneficiary)
The DebitAuthorisationRequest message covers one and only one payment instruction at a time. If an account servicing institution needs to request debit authorisation for several instructions, then multiple DebitAuthorisationRequest messages must be sent.
The DebitAuthorisationRequest must be used exclusively between the account servicing institution and the account owner. It must not be used in place of a RequestToModifyPayment or RequestToCancelPayment message between subsequent agents.
OutlineThe DebitAuthorisationRequest message is composed of four building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Payment Instruction ExtractThis building block is mandatory.
D. Debit Authorisation DetailsThis building block is mandatory.
Message Structure
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 93
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Underlying <Undrlyg> [1..1]
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 Detail <Dtl> [1..1]
4.1 CancellationReason <CxlRsn> [1..1] Code
4.2 AmountToDebit <AmtToDbt> [0..1] Amount
4.3 ValueDateToDebit <ValDtToDbt> [0..1] DateTime
Message Items DescriptionThe following section identifies the elements of the DebitAuthorisationRequest message.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 94
1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the case assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 95
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: Yes
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 96
MeaningWhenFalse: No
3.0 Underlying <Undrlyg>Presence: [1..1]Definition: Identifies the underlying payment instructrion.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
3.1 AssignerInstructionIdentification <AssgnrInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2 AssigneeInstructionIdentification <AssgneInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.3 CurrencyAmount <CcyAmt>Presence: [0..1]Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or
the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
3.4 ValueDate <ValDt>Presence: [0..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 97
Definition: Value date of the payment.Data Type: ISODateTime
4.0 Detail <Dtl>Presence: [1..1]Definition: Detailed information about the request.Type: The Detail block is composed of the following DebitAuthorisationDetails element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 CancellationReason <CxlRsn> [1..1] Code
4.2 AmountToDebit <AmtToDbt> [0..1] Amount
4.3 ValueDateToDebit <ValDtToDbt> [0..1] DateTime
4.1 CancellationReason <CxlRsn>Presence: [1..1]Definition: Indicates the reason for cancellation.Data Type: CodeOne of the following CancellationReason1Code values must be used:
Code Name DefinitionAGNT IncorrectAgent Agent in the payment workflow is incorrect.
CURR IncorrectCurrency Currency of the payment is incorrect.
CUST RequestedByCustomer Cancellation requested by the Debtor.
DUPL DuplicatePayment Payment is a duplicate of another payment.
UPAY UnduePayment Payment is not justified.
4.2 AmountToDebit <AmtToDbt>Presence: [0..1]Definition: Amount of money to be transferred between the debtor and creditor, before charges.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.3 ValueDateToDebit <ValDtToDbt>Presence: [0..1]Definition: Value date for debiting the amount.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 98
Data Type: ISODate
Business Example
The following illustrates one scenario for the DebitAuthorisationRequest workflow. This scenario is based on an initial RequestToModifyPayment scenario. The DebitAuthorisationRequest message is shown in Step 3.1 below. The scenario is based on the payment characteristics in the table below.
Customer A (BEI CUSAGB2L) instructed Bank A (AAAAGB2L) to execute a payment. The payment settles a series of invoices received in January 2005 and referenced in the remittance information section of the payment instruction. The unstructured remittance information reproduced below refers to two commercial invoices.Characteristics of the payment instruction are as follows:
Description Value
Sender Customer A (BEI CUSAGB2L)
Receiver Bank A, London (AAAAGB2L)
Instruction Reference CPAY0123456789
Transaction Reference 20050127003
Requested Execution Date 2005-01-27
Instructed Amount and Currency
52317.48 GBP
Unstructured Remittance Information
/INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/
Final Agent Bank K, London (KKKKGB2L)
Creditor Customer S (ASUPGB2L)All Supplies and Co
Scenario 1, resulting in a DebitAuthorisationRequest message
NarrativeCustomer A checks its accounts payables and receivables, and discovers a credit note of 3743.52 GBP dated 15 December 2004 under reference 20041208204712 received from Customer S that should have been deducted from the amount of the last invoice.
Step 1 Customer A makes a request for modification of the payment instruction to lower the payment amount. The new payment amount is 48573.96 GBP instead of the original amount. Within the same request for modification, Customer A supplements the remittance information in order to allow Customer S to reconcile the new amount.
The following RequestToModifyPayment message is sent by Customer A to Bank A:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSTA20050001</Id><Assgnr>CUASGB2L</Assgnr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 99
<Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUASGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CPAY0123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<IntrBkSttldAmt Ccy = "GBP">48573.96</IntrBkSttldAmt><RmtInf>
<Ustrd>/INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/20041215/GBP3743.52/20041208304712</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has been forwarded, under reference 1030123456789 to Bank K for further processing. Bank A therefore forwards the RequestToModifyPayment message to Bank K (Step 2.1) and subsequently informs Customer A about the case assignment (Step 2.2).
Step 2.1Bank A forwards the RequestToModifyPayment message to Bank K:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUASGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<IntrBkSttldAmt Ccy = "GBP">48573.96</IntrBkSttldAmt><RmtInf>
<Ustrd>/INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/20041215/GBP3743.52/20041208304712</Ustrd>
</RmtInf>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 100
</Mod></camt.007.002.01>
Step 2.2Bank A informs Customer A of the case assignment to Bank K.
The following NotificationOfCaseAssignment message is sent to Customer A by Bank A:XML Instance
<camt.030.001.01><Hdr>
<Id>AAAACUSA20050127003</Id><Fr>AAAAGB2L</Fr><To>CUSAGB2L</To><CreDtTm>2005-01-27T08:45:30</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Assgnmt>
<Id>Q103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>MODI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank K receives the RequestToModifyPayment message from Bank A and checks the status of the instruction. The credit has been passed onto the account of Customer S who has already been notified. Bank K needs to request debit authorisation from Customer S (Step 3.1) and to inform Bank A of the case assignment (Step 3.2).
Step 3.1Bank K requests debit authorisation from Customer S.
The following DebitAuthorisationRequest message is sent by Bank K to Customer S:XML Instance
<camt.037.001.01><Assgnmt>
<Id>103KKKKSUPPLIES1234567890</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:50:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 101
<Undrlyg><AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Dtl>
<CxlRsn>CUST</CxlRsn><AmtToDbt Ccy = "GBP">3743.52</AmtToDbt>
</Dtl></camt.037.001.01>
Step 3.2Bank K informs Bank A of the case assignment.
The following NotificationOfAssignment message is sent by Bank K to Bank A:XML Instance
<camt.030.001.01><Hdr>
<Id>KKKKAAAA20050127004</Id><Fr>KKKKGB2L</Fr><To>AAAAGB2L</To><CreDtTm>2005-01-27T08:55:00</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Assgnmt>
<Id>103KKKKSUPPLIES12345678901</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:50:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>DTAU</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Customer S responds positively to the request for debit authorisation from Bank K.
The following DebitAuthorisationResponse message is sent by Customer S to Bank K:XML Instance
<camt.036.001.01><Assgnmt>
<Id>REP103KKKKSUPPLIES12345678901</Id><Assgnr>ASUPGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T10:55:23</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 102
<Cretr>CUSAGB2L</Cretr></Case><Conf>
<DbtAuthstn>true</DbtAuthstn></Conf>
</camt.036.001.01>
Step 5Upon receipt of the positive DebitAuthorisationResponse message, Bank K debits the account of Customer S for the amount specified and returns the funds in favour of Customer A via Bank A. (This process is not illustrated here) Bank K also informs the case assigner, Bank A, about the positive case resolution.
The following ResolutionOfInvestigation message is sent by Bank K to Bank A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>R103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T10:59:42</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
Step 6Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A of the resolution of the investigation.
The following ResolutionOfInvestigation message is sent by Bank A to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>RCUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne><CreDtTm>2005-01-27T11:04:27</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationRequest <camt.037.001.01>
Page 103
Message: DebitAuthorisationResponse <camt.036.001.01>Message Scope and UsageScopeThe DebitAuthorisationResponse message is sent by an account owner to its account servicing institution.
This message is used to approve or reject a debit authorisation request.
UsageThe DebitAuthorisationResponse message is used to reply to a DebitAuthorisationRequest message.
The DebitAuthorisationResponse message covers one and only one payment instruction at a time. If an account owner needs to reply to several DebitAuthorisationRequest messages, then multiple DebitAuthorisationResponse messages must be sent.
The DebitAuthorisationResponse message indicates whether the account owner is in agreement to the request by means of a code. It also allows further details to be given about the debit authorisation, such as acceptable amount and value date for the debit.
The DebitAuthorisationResponse message must be used exclusively between the account owner and the account servicing institution. It must not be used in place of a ResolutionOfInvestigation message between subsequent agents.
OutlineThe DebitAuthorisationResponse message is composed of three building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Debit Authorisation ConfirmationThis building block is mandatory.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 104
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Confirmation <Conf> [1..1]
3.1 DebitAuthorisation <DbtAuthstn> [1..1] Indicator
3.2 AmountToDebit <AmtToDbt> [0..1] Amount
3.3 ValueDateToDebit <ValDtToDbt> [0..1] DateTime
3.4 Reason <Rsn> [0..1] Text
Message Items DescriptionThe following section identifies the elements of the DebitAuthorisationResponse message.
1.0 Assignment <Assgnmt>Presence: [1..1]Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 105
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 106
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Confirmation <Conf>Presence: [1..1]Type: The Confirmation block is composed of the following DebitAuthorisationConfirmation element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 DebitAuthorisation <DbtAuthstn> [1..1] Indicator
3.2 AmountToDebit <AmtToDbt> [0..1] Amount
3.3 ValueDateToDebit <ValDtToDbt> [0..1] DateTime
3.4 Reason <Rsn> [0..1] Text
3.1 DebitAuthorisation <DbtAuthstn>Presence: [1..1]Definition: Code expressing the decision taken by the account owner relative to the request for debit authorization.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 107
3.2 AmountToDebit <AmtToDbt>Presence: [0..1]Definition: Amount authorised for debit. The party providing the debit authority may want to authorise the amount less
charges and they may only be prepared to approve the debit for value today rather than the original value date.
Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
3.3 ValueDateToDebit <ValDtToDbt>Presence: [0..1]Definition: Value date for debiting the amount.Data Type: ISODate
3.4 Reason <Rsn>Presence: [0..1]Definition: Justification for partial authorisation of debit. Data Type: Max140TextFormat: maxLength: 140
minLength: 1
Business Example
The following illustrates one scenario for the DebitAuthorisationResponse workflow. This scenario is based on an initial RequestToModifyPayment scenario. The DebitAuthorisationResponse message is shown in Step 4 below. The scenario is based on the payment characteristics in the table below.
Customer A (BEI CUSAGB2L) instructed Bank A (AAAAGB2L) to execute a payment. The payment settles a series of invoices received in January 2005 and referenced in the remittance information section of the payment instruction. The unstructured remittance information reproduced below refers to two commercial invoices.Characteristics of the payment instruction are as follows:
Description Value
Sender Customer A (BEI CUSAGB2L)
Receiver Bank A, London (AAAAGB2L)
Instruction Reference CPAY0123456789
Transaction Reference 20050127003
Requested Execution Date 2005-01-27
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 108
Instructed Amount and Currency
52317.48 GBP
Unstructured Remittance Information
/INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/
Final Agent Bank K, London (KKKKGB2L)
Creditor Customer S (ASUPGB2L)All Supplies and Co
Scenario 1, resulting in a DebitAuthorisationRequest message
NarrativeCustomer A checks its accounts payables and receivables, and discovers a credit note of 3743.52 GBP dated 15 December 2004 under reference 20041208204712 received from Customer S that should have been deducted from the amount of the last invoice.
Step 1 Customer A makes a request for modification of the payment instruction to lower the payment amount. The new payment amount is 48573.96 GBP instead of the original amount. Within the same request for modification, Customer A supplements the remittance information in order to allow Customer S to reconcile the new amount.
The following RequestToModifyPayment message is sent by Customer A to Bank A:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSTA20050001</Id><Assgnr>CUASGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUASGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CPAY0123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<IntrBkSttldAmt Ccy = "GBP">48573.96</IntrBkSttldAmt><RmtInf>
<Ustrd>/INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/20041215/GBP3743.52/20041208304712</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 109
Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has been forwarded, under reference 1030123456789 to Bank K for further processing. Bank A therefore forwards the RequestToModifyPayment message to Bank K (Step 2.1) and subsequently informs Customer A about the case assignment (Step 2.2).
Step 2.1Bank A forwards the RequestToModifyPayment message to Bank K:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUASGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<IntrBkSttldAmt Ccy = "GBP">48573.96</IntrBkSttldAmt><RmtInf>
<Ustrd>/INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/20041215/GBP3743.52/20041208304712</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 2.2Bank A informs Customer A of the case assignment to Bank K.
The following NotificationOfCaseAssignment message is sent to Customer A by Bank A:XML Instance
<camt.030.001.01><Hdr>
<Id>AAAACUSA20050127003</Id><Fr>AAAAGB2L</Fr><To>CUSAGB2L</To><CreDtTm>2005-01-27T08:45:30</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 110
<Assgnmt><Id>Q103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>MODI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank K receives the RequestToModifyPayment message from Bank A and checks the status of the instruction. The credit has been passed onto the account of Customer S who has already been notified. Bank K needs to request debit authorisation from Customer S (Step 3.1) and to inform Bank A of the case assignment (Step 3.2).
Step 3.1Bank K requests debit authorisation from Customer S.
The following DebitAuthorisationRequest message is sent by Bank K to Customer S:XML Instance
<camt.037.001.01><Assgnmt>
<Id>103KKKKSUPPLIES1234567890</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:50:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Dtl>
<CxlRsn>CUST</CxlRsn><AmtToDbt Ccy = "GBP">3743.52</AmtToDbt>
</Dtl></camt.037.001.01>
Step 3.2Bank K informs Bank A of the case assignment.
The following NotificationOfAssignment message is sent by Bank K to Bank A:XML Instance
<camt.030.001.01><Hdr>
<Id>KKKKAAAA20050127004</Id><Fr>KKKKGB2L</Fr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 111
<To>AAAAGB2L</To><CreDtTm>2005-01-27T08:55:00</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Assgnmt>
<Id>103KKKKSUPPLIES12345678901</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:50:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>DTAU</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Customer S responds positively to the request for debit authorisation from Bank K.
The following DebitAuthorisationResponse message is sent by Customer S to Bank K:XML Instance
<camt.036.001.01><Assgnmt>
<Id>REP103KKKKSUPPLIES12345678901</Id><Assgnr>ASUPGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T10:55:23</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Conf>
<DbtAuthstn>true</DbtAuthstn></Conf>
</camt.036.001.01>
Step 5Upon receipt of the positive DebitAuthorisationResponse message, Bank K debits the account of Customer S for the amount specified and returns the funds in favour of Customer A via Bank A. (This process is not illustrated here) Bank K also informs the case assigner, Bank A, about the positive case resolution.
The following ResolutionOfInvestigation message is sent by Bank K to Bank A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>R103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 112
<CreDtTm>2005-01-27T10:59:42</CreDtTm></Assgnmt><RslvdCase>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
Step 6Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A of the resolution of the investigation.
The following ResolutionOfInvestigation message is sent by Bank A to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>RCUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne><CreDtTm>2005-01-27T11:04:27</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: DebitAuthorisationResponse <camt.036.001.01>
Page 113
Message: NotificationOfCaseAssignment <camt.030.001.01>Message Scope and UsageScopeThe NotificationOfCaseAssignment message is sent by a case assignee to a case creator/case assigner.
This message is used to inform the case assigner of further action that is undertaken by the case assignee to process the case, eg, the assignment of the case to a next case assignee.
Usage
The NotificationOfCaseAssignment message is used to notify the case creator/case assigner of further action undertaken by the case assignee in a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case
The NotificationOfCaseAssignment message covers one and only one case at a time. If the case assignee needs to inform a case creator/case assigner about several cases, then multiple NotificationOfCaseAssignment messages must be sent.
The NotificationOfCaseAssignment message must be forwarded by all subsequent case assigner(s) until it reaches the case creator.
The NotificationOfCaseAssignment message must not be used in place of a ResolutionOfInvestigation or a CaseStatusReport message.
OutlineThe NotificationOfCaseAssignment message is composed of four building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Report HeaderThis building block is mandatory.
D.Case Forwarding NotificationThis building block is mandatory.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 114
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Header <Hdr> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 From <Fr> [1..1] Identifier
1.3 To <To> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Assignment <Assgnmt> [1..1]
3.1 Identification <Id> [1..1] Text
3.2 Assigner <Assgnr> [1..1] Identifier
3.3 Assignee <Assgne> [1..1] Identifier
3.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 Notification <Ntfctn> [1..1]
4.1 Justification <Justfn> [1..1] Code
Message Items DescriptionThe following section identifies the elements of the NotificationOfCaseAssignment message.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 115
1.0 Header <Hdr>Presence: [1..1]Definition: Specifies generic information about the notification.
The receiver of a notification is necessarily the party which assigned the case to the sender.Type: The Header block is composed of the following ReportHeader element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 From <Fr> [1..1] Identifier
1.3 To <To> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of the report.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 From <Fr>Presence: [1..1]Definition: Party reporting the status of the case.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.3 To <To>Presence: [1..1]Definition: Party to which the status of the case is reported.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Creation date and time of the report generation.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 116
Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Assignment <Assgnmt>Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 117
Definition: Identifies the current assignment of the case.
The Assigner must be the emitter of the notification.The Assignee must be another Party in the payment chain.
Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 Identification <Id> [1..1] Text
3.2 Assigner <Assgnr> [1..1] Identifier
3.3 Assignee <Assgne> [1..1] Identifier
3.4 CreationDateTime <CreDtTm> [1..1] DateTime
3.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
3.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 118
3.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
4.0 Notification <Ntfctn>Presence: [1..1]Definition: Information about the type of action taken.Type: The Notification block is composed of the following CaseForwardingNotification element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 Justification <Justfn> [1..1] Code
4.1 Justification <Justfn>Presence: [1..1]Definition: Justification for the forward action.Data Type: CodeOne of the following CaseForwardingNotification1Code values must be used:
Code Name DefinitionCANC RequestToCancel Case has been forwarded to the next Party for cancellation.
DTAU RequestDebitAuthorisation Case has been forwarded to obtain authorisation to debit.
FTHI FurtherInvestigation Case has been forwarded to the next Party for further investigation.
MODI RequestToModify Case has been forwarded to the next Party for modification.
SAIN SentAdditionalInformation Additonal information has been forwarded to the Creditor.
Business Example
The following illustrates one scenario for the NotificationOfCaseAssignment workflow. This scenario is based on an initial RequestToCancelPayment scenario. The NotificationOfCaseAssignment message is shown in Steps 2.2, 3.2 and 3.3 below. The scenario is based on the payment characteristics in the table below.
Customer A (BEI AAAAFRPP) instructed Bank B, Paris to execute a payment. The payment settles a series of invoices received in March and April 2005 and referenced in the remittance information of the payment instruction.
Description Value
Sender Customer A, Paris (BEI AAAAFRPP)
Receiver Bank B, Paris (BBBBFRPP)
Instruction Reference CBPAY09876543
Transaction Reference 200504170001
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 119
Requested Execution Date 2005-04-17
Instructed Amount 12347.56 EUR
Unstructured Remittance Information /INV/20050329/EUR8257.43/20050400104712//20050412/EUR4090.13/20050400204712/
Final Agent Bank C, Paris (CCCCFRPP)
Creditor Customer D, Paris (DDDDFRPP)Tristan Recording Studios
Scenario 1
NarrativeCustomer A checks its account payables. It appears that the invoice received in March has been paid by other means and the invoice received in April was due in May 2005 only. Customer A requests the cancellation of the payment instruction.
Step 1Customer A requests the cancellation of the payment instruction to Bank B, Paris.
The following RequestToCancelPayment message is sent by Customer A to Bank B:XML Instance
<camt.008.002.01><Assgnmt>
<Id>AB20050417CANC</Id><Assgnr>AAAAFRPP</Assgnr><Assgne>BBBBFRPP</Assgne><CreDtTm>2005-04-19T10:09:30</CreDtTm>
</Assgnmt><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CBPAY09876543</AssgnrInstrId><CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 2Bank B assesses the RequestToCancelPayment message. After the necessary checks and look up of the original instruction, it appears that the instruction has already been forwarded to Bank C, under reference O1234598760. Bank B forwards the RequestToCancelPayment message to Bank C (Step 2.1) and notifies the case assignment to Customer A (Step 2.2).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 120
Step 2.1Bank B forwards the request to cancel the payment to Bank C.
The following RequestToCancelPayment message is sent by Bank B to Bank C:XML Instance
<camt.008.002.01><Assgnmt>
<Id>BBBBCANC0001200504</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T10:13:42</CreDtTm>
</Assgnmt><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>O1234598760</AssgnrInstrId><CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 2.2Bank B notifies the case assignment to Customer A.
The following NotificationOfCaseAssignment message is sent by Bank B to Customer A.XML Instance
<camt.030.001.01><Hdr>
<Id>RCUSTB20050419</Id><Fr>BBBBFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-04-19T10:22:23</CreDtTm>
</Hdr><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Assgnmt>
<Id>BBBBCANC0001200504</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T10:13:42</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>CANC</Justfn></Ntfctn>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 121
</camt.030.001.01>
Step 3Bank C receives the RequestToCancelPayment message from Bank B and checks the status of the instruction. The instruction has been correctly executed. The credit has been passed onto the account of Customer D and Customer D has been informed (the Account Owner Reference is E20050418027, with value date 18 April 2005). Bank C requests the debit authorisation from Customer D (Step 3.1). At the same time, Bank C informs Bank B about its request to Customer D (Step 3.2). Upon receipt of the case assignment notification from Bank C, Bank B forwards the information to Customer A (Step 3.3).
Step 3.1Bank C requests a debit authorisation from Customer D.
The following DebitAuthorisationRequest message is sent by Bank C to Customer D:XML Instance
<camt.037.001.01><Assgnmt>
<Id>BNPRFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>
</Assgnmt><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgneInstrId>E20050418027</AssgneInstrId><CcyAmt Ccy="EUR">12347.56</CcyAmt><ValDt>2005-04-18T00:00:00</ValDt>
</Undrlyg><Dtl>
<CxlRsn>CUST</CxlRsn><AmtToDbt Ccy="EUR">12347.56</AmtToDbt>
</Dtl></camt.037.001.01>
Step 3.2Bank C informs Bank B about the debit authorisation request to Customer D.
The following NotificationOfCaseAssignment message is sent by Bank C to Bank B:XML Instance
<camt.030.001.01><Hdr>
<Id>RCCCCBBBB20050419004</Id><Fr>CCCCFRPP</Fr><To>BBBBFRPP</To><CreDtTm>2005-01-27T10:21:23</CreDtTm>
</Hdr><Case>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 122
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Assgnmt>
<Id>CCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>DTAU</Justfn></Ntfctn>
</camt.030.001.01>
Step 3.3Upon receipt of the message from Bank C, Bank B confirms the case assignment to Customer A.
The following NotificationOfCaseAssignment message is sent by Bank B to Customer A:XML Instance
<camt.030.001.01><Hdr>
<Id>RBBBBAAAA20050419012</Id><Fr>BBBBFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-01-27T10:25:42</CreDtTm>
</Hdr><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Assgnmt>
<Id>CCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>DTAU</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Customer D, after further investigation, recognises that the payment was indeed not due and grants the debit authorisation to Bank C.
The following DebitAuthorisationResponse message is sent by Customer D to Bank C:XML Instance
<camt.036.001.01><Assgnmt>
<Id>RCCCCFDA20050419001</Id><Assgnr>DDDDFRPP</Assgnr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 123
<Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T12:17:43</CreDtTm>
</Assgnmt><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Conf>
<DbtAuthstn>true</DbtAuthstn></Conf>
</camt.036.001.01>
Step 5Bank C, upon receipt of the DebitAuthorisationResponse message, closes the case and informs Bank B that the investigation is resolved (Step 5.1). Bank C returns the corresponding funds to Customer A, via Bank B (not illustrated here). Bank B informs Customer A that the investigation is resolved, allowing the case closure(Step 5.2).
Step 5.1The following ResolutionOfInvestigation message is sent by Bank C to Bank B:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFCCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>BBBBFRPP</Assgne><CreDtTm>2005-04-19T12:35:22</CreDtTm>
</Assgnmt><RslvdCase>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
Step 5.2The following ResolutionOfInvestigation message is sent by Bank B to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFBBBBCANC20050419013</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-04-19T12:43:11</CreDtTm>
</Assgnmt><RslvdCase>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 124
<Sts><Conf>ACDA</Conf>
</Sts></camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: NotificationOfCaseAssignment <camt.030.001.01>
Page 125
Message: RejectCaseAssignment <camt.031.001.01>Message Scope and UsageScopeThe RejectCaseAssignment message is sent by a case assignee to a case creator/case assigner.
This message is used to reject a case.
Usage
The RejectCaseAssignment message is used to notify the case creator/case assigner of the rejection of an assignment by the case assignee in a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case
Rejecting a case assignment occurs when the case assignee is unable to trace the original payment instruction or when the case assignee is unable, or does not have authority, to process the assigned case.
The RejectCaseAssignment message covers one and only one case at a time. If the case assignee needs to reject several case assignments, then multiple RejectCaseAssignment messages must be sent.
The RejectCaseAssignment message must be forwarded by all subsequent case assignee(s) until it reaches the case assigner.
The RejectCaseAssignment message must not be used in place of a ResolutionOfInvestigation or CaseStatusReport message.
OutlineThe RejectCaseAssignment message is composed of three building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Case Assignment Rejection JustificationThis building block is mandatory.
Message Structure
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RejectCaseAssignment <camt.031.001.01>
Page 126
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Justification <Justfn> [1..1]
3.1 RejectionReason <RjctnRsn> [1..1] Code
Message Items DescriptionThe following section identifies the elements of the RejectCaseAssignment message.
1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RejectCaseAssignment <camt.031.001.01>
Page 127
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RejectCaseAssignment <camt.031.001.01>
Page 128
Index Or Message Item <XML Tag> Mult. Represent./Type
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Justification <Justfn>Presence: [1..1]Definition: Specifies the reason for not accepting a Case.Type: The Justification block is composed of the following CaseAssignmentRejectionJustification element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 RejectionReason <RjctnRsn> [1..1] Code
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RejectCaseAssignment <camt.031.001.01>
Page 129
3.1 RejectionReason <RjctnRsn>Presence: [1..1]Definition: Reason for rejecting a case assignment.Data Type: CodeOne of the following CaseAssignmentRejection1Code values must be used:
Code Name DefinitionCNCL PaymentCancelled Used when the payment instruction has been cancelled.
NAUT NotAuthorisedToInvestigate Case Assignee is not allowed to investigate on this instruction (eg. Case Assignee is not the next party in the payment chain).
NFND UnderlyingPaymentNotFound
Underlying instruction can not be found.
RJCT PaymentRejected Used when the payment instruction has been rejected.
UKNW UnknownCase Used when receiving a ResolutionOfInvestigation or a DebitAuthorisation for an unknown case. It could be used as well when a party rejects a case status request.
Business Example
The following illustrates the usage of the RejectCaseAssignment message, based on a RequestToModifyPayment workflow.
Customer C (BEI CCCCJPJT) instructed Bank J in Japan (JJJJJPJT) to execute a payment on 23 January 2005. The payment settles a series of invoices received in January 2005 and referred to in the remittance information of the payment instruction.
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer C (BEI CCCCJPJT)
Receiver Bank J, Tokyo (JJJJJPJT)
Instruction Reference 123JPY20050123
Transaction Reference 20050127
Requested Execution Date 2005-01-27
Instructed Amount and Currency 4257567 JPY
Unstructured Remittance Information /INV/20041223/JPY1000000/20050100104712//20050113/JPY3257567/20050100204712/
Final Agent Bank K, Tokyo (KKKKJPJT)
Creditor Customer A (BEI AAAAJPJT)Shikako Ltd
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RejectCaseAssignment <camt.031.001.01>
Page 130
NarrativeOn 25 January 2005, Customer C checks its accounts payables. The payment should have been made to another final agent. As the execution of the payment instruction is foreseen for a future value date, Customer C requests the modification of the payment instruction and indicates the correct final agent.
Although the case may be forwarded to another financial institution, this scenario limits itself to the interaction between the customer and the first financial institution.
Step 1Customer C sends by mistake a request to modify payment to Bank V, instead of Bank J.
The following RequestToModifyPayment message is sent by Customer C to Bank V:XML Instance
<camt.007.002.01><Assgnmt>
<Id>ABCDEFGHIJKLMNOPQRST123456789012345</Id><Assgnr>CCCCJPJT</Assgnr><Assgne>VVVVJPJT</Assgne><CreDtTm>2005-01-25T10:35:43</CreDtTm>
</Assgnmt><Case>
<Id>MOD123JPY20050123</Id><Cretr>CCCCJPJT</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>123JPY20050123</AssgnrInstrId><CcyAmt Ccy = "JPY">4257567</CcyAmt><ValDt>2005-01-27T00:00:00</ValDt>
</Undrlyg><Mod>
<LastSttlmAgt><FinInstnId>
<BIC>LLLLJPJT</BIC></FinInstnId>
</LastSttlmAgt></Mod>
</camt.007.002.01>
Step 2Upon receipt of the RequestToModifyPayment message, Bank V investigates the original instruction but cannot trace it. Bank V therefore rejects the case assignment.
The following RejectCaseAssignment message is sent by Bank V to Customer C:XML Instance
<camt.031.001.01><Assgnmt>
<Id>ABCDEFGHIJKLMNOPQRST123456789012345</Id><Assgnr>VVVVJPJT</Assgnr><Assgne>CCCCJPJT</Assgne><CreDtTm>2005-01-25T11:07:38</CreDtTm>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RejectCaseAssignment <camt.031.001.01>
Page 131
</Assgnmt><Case>
<Id>MOD123JPY20050123</Id><Cretr>CCCCJPJT</Cretr>
</Case><Justfn>
<RjctnRsn>NFND</RjctnRsn></Justfn>
</camt.031.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RejectCaseAssignment <camt.031.001.01>
Page 132
Message: RequestForDuplicateInstruction <camt.033.001.01>Message Scope and UsageScopeThe RequestForDuplicateInstruction message is sent by the case assignee to the case creator/case assigner.
This message is used to request a copy of the original payment instruction considered in the case.
Usage
The RequestForDuplicateInstruction message must be answered with a DuplicateInstruction message.
The RequestForDuplicateInstruction message must be used when a case assignee requests a copy of the original payment instruction. This occurs, eg, when the case assignee cannot trace the payment instruction based on the elements mentioned in the case assignment message.
The RequestForDuplicateInstruction covers one and only one instruction at a time. If several payment instruction copies are needed by the case assignee, then multiple RequestForDuplicateInstruction messages must be sent.
The RequestForDuplicateInstruction message must be used exclusively between the case assignee and its case creator/case assigner.
OutlineThe RequestForDuplicateInstruction message is composed of two blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestForDuplicateInstruction <camt.033.001.01>
Page 133
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Message Items DescriptionThe following section identifies the elements of the RequestForDuplicateInstruction message.
1.0 Assignment <Assgnmt>Presence: [1..1]Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestForDuplicateInstruction <camt.033.001.01>
Page 134
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestForDuplicateInstruction <camt.033.001.01>
Page 135
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
Business Example
The following illustrates the usage of the RequestForDuplicateInstruction message and the DuplicateInstruction message (as a reply to the request), based on a RequestToCancelPayment workflow. Although the request for cancellation may be pursued after full details of the original instruction have been provided, this scenario is limited to the provision of the duplicate instruction.
Customer B (BEI CUSBFRPP) instructed Bank F, Paris to execute a payment. The payment settles a series of invoices received in March and April 2005 and referred to in the remittance information of the payment instruction.Characteristics of the payment instruction are as follows:
Description Value
Sender Customer B (BEI CUSBFRPP)
Receiver Bank F, Paris (FFFFFRPP)
Instruction Reference CBPAY09876543
Transaction Reference 200504170001
Requested Execution Date 2005-04-17
Instructed Amount 12347.56 EUR
Unstructured Remittance Information /INV/20050329/EUR8257.43/20050400104712//20050412/EUR4090.13/20050400204712/
Final Agent Bank A, Paris (AAAAFRPP)
Creditor Customer C (BEI CUSCFRPP)Tristan Recording Studios
NarrativeCustomer B checks its account payables. The invoice received in March has been paid by other means and the invoice received in April was due in May 2005 only. Customer B requests the cancellation of the payment instruction.
Step 1Customer B sends a request for cancellation of the payment to Bank F, Paris.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestForDuplicateInstruction <camt.033.001.01>
Page 136
The following RequestToCancelPayment message is sent by Customer B to Bank F:XML Instance
<camt.008.002.01><Assgnmt>
<Id>AB20050417CANC</Id><Assgnr>CUSBFRPP</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-04-19T10:09:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSB200504001</Id><Cretr>CUSBFRPP</Cretr>
</Case><Undrlyg>
<CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 2Bank F assesses the RequestToCancelPayment message. Although the RequestToCancelPayment message is correctly formatted, Bank F does not want to act upon the request solely based on the identity of the sender, amount, currency and value date. In the RequestToCancelPayment message shown above, the Assigner Instruction Identification element is missing.
Bank F therefore requests a copy of the original instruction to make sure the instruction to be cancelled is unambiguously identified.
The following RequestForDuplicateInstruction message is sent by Bank F to Customer B: XML Instance
<camt.033.001.01><Assgnmt>
<Id>REPAB20050417</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>CUSBFRPP</Assgne><CreDtTm>2005-04-19T11:02:23</CreDtTm>
</Assgnmt><Case>
<Id>CUSB200504001</Id><Cretr>CUSBFRPP</Cretr>
</Case></camt.033.001.01>
Step 3Customer B receives the request for duplicate instruction from Bank F and looks up the original instruction. He sends a copy of the original instruction to Bank F.
The following DuplicateInstruction message is sent by Customer B to Bank F:
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestForDuplicateInstruction <camt.033.001.01>
Page 137
XML Instance<camt.034.001.01>
<Assgnmt><Id>DUPLAB20050417CANC</Id><Assgnr>CUSBFRPP</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-04-19T11:08:32</CreDtTm>
</Assgnmt><Case>
<Id>CUSB200504001</Id><Cretr>CUSBFRPP</Cretr>
</Case><DplctInstr>
<Tp>103</Tp><Cntnt>
:20:CBPAY09876543//:32A:050417EUR12347.56//:33B:EUR12347.56//:50A:CUSBFRPP//:59:Tristan Recording Studios //239 Bld Haussmann//75009 Paris//:71A:SHA
</Cntnt></DplctInstr>
</camt.034.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestForDuplicateInstruction <camt.033.001.01>
Page 138
Message: RequestToCancelPayment <camt.008.002.01>Message Scope and UsageScopeThe RequestToCancelPayment 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.
Usage
The RequestToCancelPayment message must be answered with a:- ResolutionOfInvestigation message with a positive final outcome when the case assignee can perform the requested
cancellation- ResolutionOfInvestigation message with a negative final outcome when the case assignee could perform the
requested cancellation but fails to do so (too late, irrevocable instruction, ...)- RejectCaseAssignment message when the case assignee is unable or authorised to perform the requested cancellation- NotificationOfCaseAssignment message whene the case assignee forwards the case assignment to a subsequent
case assignee.
A RequestToCancelPayment message concerns one and only one original payment instruction at a time. If several original payment instructions need to be cancelled, then multiple RequestToCancelPayment messages must be sent.
When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner.
The funds must be forwarded by all subsequent case assigner(s) until they reach the case creator.
The processing of a request to cancel payment case may end with a DebitAuthorisationRequest message sent to the creditor by its account servicing institution.
The RequestToCancelPayment 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 RequestToModifyPayment message and the element ReopenCaseIndication is set to yes.
Main characteristicsThe RequestToCancelPayment message has the following main characteristics:
Case Identification and Reason CodeThe 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).
Cancellation of a cover paymentThe 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.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 139
Cancellation request initiatorsThe cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain.
OutlineThe RequestToCancelPayment message is composed of four building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Payment Instruction ExtractThis building block is mandatory.
D.Debit Authorisation DetailsThis building block is optional.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 140
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Underlying <Undrlyg> [1..1]
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 Justification <Justfn> [1..1]
4.1 CancellationReason <CxlRsn> [1..1] Code
4.2 AmountToDebit <AmtToDbt> [0..1] Amount
4.3 ValueDateToDebit <ValDtToDbt> [0..1] DateTime
Message Items DescriptionThe following section identifies the elements of the RequestToCancelPayment message.
1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the assignment of a case from an assigner to an assignee.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 141
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 142
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Underlying <Undrlyg>Presence: [1..1]Definition: Identifies the payment instruction to be cancelled.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
3.1 AssignerInstructionIdentification <AssgnrInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner.Data Type: Max35TextFormat: maxLength: 35
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 143
minLength: 1
3.2 AssigneeInstructionIdentification <AssgneInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.3 CurrencyAmount <CcyAmt>Presence: [0..1]Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or
the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
3.4 ValueDate <ValDt>Presence: [0..1]Definition: Value date of the payment.Data Type: ISODateTime
4.0 Justification <Justfn>Presence: [1..1]Definition: Defines the reason for requesting the cancellation.Type: The Justification block is composed of the following DebitAuthorisationDetails element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 CancellationReason <CxlRsn> [1..1] Code
4.2 AmountToDebit <AmtToDbt> [0..1] Amount
4.3 ValueDateToDebit <ValDtToDbt> [0..1] DateTime
4.1 CancellationReason <CxlRsn>Presence: [1..1]Definition: Indicates the reason for cancellation.Data Type: CodeOne of the following CancellationReason1Code values must be used:
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 144
Code Name DefinitionAGNT IncorrectAgent Agent in the payment workflow is incorrect.
CURR IncorrectCurrency Currency of the payment is incorrect.
CUST RequestedByCustomer Cancellation requested by the Debtor.
DUPL DuplicatePayment Payment is a duplicate of another payment.
UPAY UnduePayment Payment is not justified.
4.2 AmountToDebit <AmtToDbt>Presence: [0..1]Definition: Amount of money to be transferred between the debtor and creditor, before charges.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.3 ValueDateToDebit <ValDtToDbt>Presence: [0..1]Definition: Value date for debiting the amount.Data Type: ISODate
Business Example
The following illustrates two scenarios for the RequestToCancelPayment workflow.
Scenario 1, resulting in a ResolutionOfInvestigation message There is no further assignment down the chain as the payment instruction is cancelled before execution by the case assignee.
Customer D (BEI DDDDDEFF) instructed Bank F, Frankfurt (FFFFDEFF) to execute a payment instruction.
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer D (BEI DDDDDEFF)
Receiver Bank F, Frankfurt (FFFFDEFF)
Instruction Reference CDPAY20050423001
Transaction Reference 200504171234
Requested Execution Date 2005-04-23
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 145
Instructed Amount 175000.00 EUR
Final Agent Bank G, Frankfurt (GGGGDEFF)
Creditor Customer E (BEI EEEEDEFF)Hanswagen GmBH
NarrativeOn 22 April 2005, Customer D checks its accounts payables. The payment made under reference CDPAY20050423-001 should not have been sent to Bank F for execution on 17 April 2005. This should have been a end of the month payment.
Customer D requests the cancellation of the payment instruction.
Step 1The following RequestToCancelPayment message is sent by Customer D to Bank F:XML Instance
<camt.008.002.01><Assgnmt>
<Id>CD20050423CANC</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>FFFFDEFF</Assgne><CreDtTm>2005-04-22T10:17:32</CreDtTm>
</Assgnmt><Case>
<Id>DDDD20050423001</Id><Cretr>DDDDDEFF</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CDPAY20050423001</AssgnrInstrId><CcyAmt Ccy = "EUR">175000.00</CcyAmt><ValDt>2005-04-23T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 2Bank F assesses the RequestToCancelPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has not been processed yet and the cancellation can be performed. Bank F executes the cancellation and replies with a ResolutionOfInvestigation message to Customer D.
The following ResolutionOfInvestigation message is sent by Bank F to Customer D:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFFFFFCANC20050423001</Id><Assgnr>FFFFDEFF</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-04-22T10:23:42</CreDtTm>
</Assgnmt>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 146
<RslvdCase><Id>DDDD20050423001</Id><Cretr>DDDDDEFF</Cretr>
</RslvdCase><Sts>
<Conf>CNCL</Conf></Sts>
</camt.029.001.01>
Scenario 2, resulting in a DebitAuthorisationRequest message
Customer A (BEI AAAAFRPP) instructed Bank B, Paris to execute a payment. The payment settles a series of invoices received in March and April 2005 and referenced in the remittance information of the payment instruction.
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer A, Paris (BEI AAAAFRPP)
Receiver Bank B, Paris (BBBBFRPP)
Instruction Reference CBPAY09876543
Transaction Reference 200504170001
Requested Execution Date 2005-04-17
Instructed Amount 12347.56 EUR
Unstructured Remittance Information /INV/20050329/EUR8257.43/20050400104712//20050412/EUR4090.13/20050400204712/
Final Agent Bank C, Paris (CCCCFRPP)
Creditor Customer D, Paris (DDDDFRPP)Tristan Recording Studios
NarrativeCustomer A checks its account payables. It appears that the invoice received in March has been paid by other means and the invoice received in April was due in May 2005 only. Customer A requests the cancellation of the payment instruction.
Step 1Customer A requests the cancellation of the payment instruction to Bank B, Paris.
The following RequestToCancelPayment message is sent by Customer A to Bank B:XML Instance
<camt.008.002.01><Assgnmt>
<Id>AB20050417CANC</Id><Assgnr>AAAAFRPP</Assgnr><Assgne>BBBBFRPP</Assgne><CreDtTm>2005-04-19T10:09:30</CreDtTm>
</Assgnmt><Case>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 147
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CBPAY09876543</AssgnrInstrId><CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 2Bank B assesses the RequestToCancelPayment message. After the necessary checks and look up of the original instruction, it appears that the instruction has already been forwarded to Bank C, under reference O1234598760. Bank B forwards the RequestToCancelPayment message to Bank C (Step 2.1) and notifies the case assignment to Customer A (Step 2.2).
Step 2.1Bank B forwards the request to cancel the payment to Bank C.
The following RequestToCancelPayment message is sent by Bank B to Bank C:XML Instance
<camt.008.002.01><Assgnmt>
<Id>BBBBCANC0001200504</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T10:13:42</CreDtTm>
</Assgnmt><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>O1234598760</AssgnrInstrId><CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 2.2Bank B notifies the case assignment to Customer A.
The following NotificationOfCaseAssignment message is sent by Bank B to Customer A.XML Instance
<camt.030.001.01><Hdr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 148
<Id>RCUSTB20050419</Id><Fr>BBBBFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-04-19T10:22:23</CreDtTm>
</Hdr><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Assgnmt>
<Id>BBBBCANC0001200504</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T10:13:42</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>CANC</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank C receives the RequestToCancelPayment message from Bank B and checks the status of the instruction. The instruction has been correctly executed. The credit has been passed onto the account of Customer D and Customer D has been informed (the Account Owner Reference is E20050418027, with value date 18 April 2005). Bank C requests the debit authorisation from Customer D (Step 3.1). At the same time, Bank C informs Bank B about its request to Customer D (Step 3.2). Upon receipt of the case assignment notification from Bank C, Bank B forwards the information to Customer A (Step 3.3).
Step 3.1Bank C requests a debit authorisation from Customer D.
The following DebitAuthorisationRequest message is sent by Bank C to Customer D:XML Instance
<camt.037.001.01><Assgnmt>
<Id>BNPRFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>
</Assgnmt><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Undrlyg>
<AssgneInstrId>E20050418027</AssgneInstrId><CcyAmt Ccy="EUR">12347.56</CcyAmt><ValDt>2005-04-18T00:00:00</ValDt>
</Undrlyg><Dtl>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 149
<CxlRsn>CUST</CxlRsn><AmtToDbt Ccy="EUR">12347.56</AmtToDbt>
</Dtl></camt.037.001.01>
Step 3.2Bank C informs Bank B about the debit authorisation request to Customer D.
The following NotificationOfCaseAssignment message is sent by Bank C to Bank B:XML Instance
<camt.030.001.01><Hdr>
<Id>RCCCCBBBB20050419004</Id><Fr>CCCCFRPP</Fr><To>BBBBFRPP</To><CreDtTm>2005-01-27T10:21:23</CreDtTm>
</Hdr><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Assgnmt>
<Id>CCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>DTAU</Justfn></Ntfctn>
</camt.030.001.01>
Step 3.3Upon receipt of the message from Bank C, Bank B confirms the case assignment to Customer A.
The following NotificationOfCaseAssignment message is sent by Bank B to Customer A:XML Instance
<camt.030.001.01><Hdr>
<Id>RBBBBAAAA20050419012</Id><Fr>BBBBFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-01-27T10:25:42</CreDtTm>
</Hdr><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Assgnmt>
<Id>CCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 150
<Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>DTAU</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Customer D, after further investigation, recognises that the payment was indeed not due and grants the debit authorisation to Bank C.
The following DebitAuthorisationResponse message is sent by Customer D to Bank C:XML Instance
<camt.036.001.01><Assgnmt>
<Id>RCCCCFDA20050419001</Id><Assgnr>DDDDFRPP</Assgnr><Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T12:17:43</CreDtTm>
</Assgnmt><Case>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</Case><Conf>
<DbtAuthstn>true</DbtAuthstn></Conf>
</camt.036.001.01>
Step 5Bank C, upon receipt of the DebitAuthorisationResponse message, closes the case and informs Bank B that the investigation is resolved (Step 5.1). Bank C returns the corresponding funds to Customer A, via Bank B (not illustrated here). Bank B informs Customer A that the investigation is resolved, allowing the case closure (Step 5.2).
Step 5.1The following ResolutionOfInvestigation message is sent by Bank C to Bank B:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFCCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>BBBBFRPP</Assgne><CreDtTm>2005-04-19T12:35:22</CreDtTm>
</Assgnmt><RslvdCase>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 151
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
Step 5.2The following ResolutionOfInvestigation message is sent by Bank B to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFBBBBCANC20050419013</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-04-19T12:43:11</CreDtTm>
</Assgnmt><RslvdCase>
<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToCancelPayment <camt.008.002.01>
Page 152
Message: RequestToModifyPayment <camt.007.002.01>Message Scope and UsageScope
The RequestToModifyPayment message is sent by a case creator/case assigner to a case assignee.
This message is used to request the modification of characteristics of an original payment instruction.
Usage
The RequestToModifyPayment message must be answered with a:- ResolutionOfInvestigation message with a positive final outcome when the case assignee can perform the requested
modification- ResolutionOfInvestigation message with a negative final outcome when the case assignee could perform the
requested modification but fails to do so (too late, irrevocable instruction, one requested element cannot be modified, ...)
- RejectCaseAssignment message when the case assignee is unable or authorised to perform the requested modification- NotificationOfCaseAssignment message whenever the case assignee forwards the case assignment to a subsequent
case assignee.
The RequestToModifyPayment message covers one and only one original instruction at a time. If several original payment instructions need to be modified, then multiple RequestToModifyPayment messages must be sent.
The RequestToModifyPayment message can be sent to request the modification of one or several elements of the original payment instruction. If many elements need to be modified, it is recommended to cancel the original payment instruction and initiate a new one.
The RequestToModifyPayment must be processed on an all or nothing basis. If one of the elements to be modified cannot be altered, the assignment must be rejected in full (by means of a RejectCaseAssignment message) or not performed (by means of a negative ResolutionOfInvestigation message).
The RequestToModifyPayment message must never be sent to request the modification of the currency of the original payment instruction. A RequestToCancelPayment message must be used instead and a new payment instruction initiated.
The RequestToModifyPayment message may be forwarded to subsequent case assignee(s).
When a RequestToModifyPayment message is used to decrease the amount of the original payment instruction, the modification will trigger a return of funds from the case assignee to the case creator.
The RequestToModifyPayment message must never be sent to request the increase of the amount of the original payment instruction. A RequestToCancelPayment message must be used instead and a new payment instruction initiated. Alternatively, a new instruction with the complementary amount must be sent. In this latter case, this is not considered as an exception or investigation instruction.
Depending on the requested modification(s) and the processing stage of the original payment instruction, the processing of a request to modify payment case may end with one of the following:- an AdditionalPaymentInformation message sent to the creditor of the original payment instruction
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 153
- a DebitAuthorisationRequest message sent to the creditor of the original payment instruction- a RequestToCancelPayment message sent to a subsequent case assignee
The RequestToModifyPayment message can be sent to correct characteristics of an original payment instruction following receipt of an UnableToApply message. In this scenario, the case identification will remain the same.
Main characteristicsThe RequestToModifyPayment message has the following main characteristics:
Case IdentificationThe case creator assigns a unique case identification. This information will be passed unchanged to all subsequent case assignee(s).
Modification of a cover paymentLowering the amount of an original payment instruction for which cover is provided by a separate instruction will systematically mean the modification of the whole transaction, including the cover. The case assignee performing the amount modification must initiate the return of funds in excess to the case creator.The modification of the agents' information on an original payment instruction for which cover is provided by a separate instruction will systematically mean the whole transaction is modified, ie, the cover is executed through the agent(s) mentioned in the RequestToModifyPayment message. The cover payment must not be modified separately.
Information that can be modifiedThe modification of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment processing chain.
The case creator provides the information to be modified in line with agreements made with the case assignee. If the case assignee needs in turn to assign the case to a subsequent case assignee, the requested modification(s) must be in line with the agreement made with the next case assignee and a NotificationOfCaseAssignment message must be sent to the case assigner. Otherwise, the request to modify payment case must be rejected (by means of a negative ResolutionOfInvestigation message).
OutlineThe RequestToModifyPayment message is composed of four building blocks:
A. Case AssignmentThis building block is mandatory.
B. CaseThis building block is mandatory.
C. Payment Instruction ExtractThis building block is mandatory.
D. Requested ModificationThis building block is mandatory.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 154
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Underlying <Undrlyg> [1..1]
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 Modification <Mod> [1..1]
4.1 RelatedReference <RltdRef> [0..1] Text
4.2 BankOperationCode <BkOprCd> [0..1] Code
4.3 InstructionCode <InstrCd> [0..1] Code
4.4 RequestedExecutionDate <ReqdExctnDt> [0..1] DateTime
4.5 ValueDate <ValDt> [0..1] DateTime
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 155
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.6 InterbankSettledAmount <IntrBkSttldAmt> [0..1] Amount
4.7 Debtor <Dbtr> [0..1] +
4.8 DebtorAccount <DbtrAcct> [0..1] +
4.9 IntermediarySettlementAgent <IntrmySttlmAgt> [0..1] +
4.10 LastSettlementAgent <LastSttlmAgt> [0..1] +
4.11 PaymentScheme <PmtSchme> [0..1]
4.12 {Or Code <Cd> [1..1] Code
4.13 Or} ProprietaryInformation <PrtryInf> [1..1] Text
4.14 BeneficiaryInstitutionAccount <BnfcryInstnAcct> [0..1] +
4.15 Creditor <Cdtr> [0..1] +
4.16 CreditorAccount <CdtrAcct> [0..1] +
4.17 RemittanceInformation <RmtInf> [0..1]
4.18 {Or Unstructured <Ustrd> [1..1] Text
4.19 Or} Structured <Strd> [1..1]
4.20 ReferredDocumentType <RfrdDocTp> [0..1] Code
4.21 ReferredDocumentRelatedDate <RfrdDocRltdDt> [0..1] DateTime
4.22 ReferredDocumentAmount <RfrdDocAmt> [0..n]
4.23 {{Or DuePayableAmount <DuePyblAmt> [1..1] Amount
4.24 Or DiscountAppliedAmount <DscntApldAmt> [1..1] Amount
4.25 Or RemittedAmount <RmtdAmt> [1..1] Amount
4.26 Or CreditNoteAmount <CdtNoteAmt> [1..1] Amount
4.27 Or}} TaxAmount <TaxAmt> [1..1] Amount
4.28 DocumentReferenceNumber <DocRefNb> [0..1] Text
4.29 CreditorReference <CdtrRef> [0..1] Text
4.30 Invoicer <Invcr> [0..1] +
4.31 Invoicee <Invcee> [0..1] +
4.32 Purpose <Purp> [0..1]
4.33 {Or Proprietary <Prtry> [1..1] Text
4.34 Or} Code <Cd> [1..1] Code
4.35 InstructionForFinalAgent <InstrForFnlAgt> [0..1]
4.36 Code <Cd> [0..2] Code
4.37 Proprietary <Prtry> [0..1] Text
4.38 DetailsOfCharges <DtlsOfChrgs> [0..1] Code
4.39 SenderToReceiverInformation <SndrToRcvrInf> [0..6] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 156
Message Items DescriptionThe following section identifies the elements of the RequestToModifyPayment message.
1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 157
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 158
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Underlying <Undrlyg>Presence: [1..1]Definition: Identifies the Payment Transaction to modify.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
3.1 AssignerInstructionIdentification <AssgnrInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2 AssigneeInstructionIdentification <AssgneInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.3 CurrencyAmount <CcyAmt>Presence: [0..1]Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or
the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 159
Rule(s): CurrencyCodeValidationByTable
3.4 ValueDate <ValDt>Presence: [0..1]Definition: Value date of the payment.Data Type: ISODateTime
4.0 Modification <Mod>Presence: [1..1]Type: The Modification block is composed of the following RequestedModification element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 RelatedReference <RltdRef> [0..1] Text
4.2 BankOperationCode <BkOprCd> [0..1] Code
4.3 InstructionCode <InstrCd> [0..1] Code
4.4 RequestedExecutionDate <ReqdExctnDt> [0..1] DateTime
4.5 ValueDate <ValDt> [0..1] DateTime
4.6 InterbankSettledAmount <IntrBkSttldAmt> [0..1] Amount
4.7 Debtor <Dbtr> [0..1] +
4.8 DebtorAccount <DbtrAcct> [0..1] +
4.9 IntermediarySettlementAgent <IntrmySttlmAgt> [0..1] +
4.10 LastSettlementAgent <LastSttlmAgt> [0..1] +
4.11 PaymentScheme <PmtSchme> [0..1]
4.14 BeneficiaryInstitutionAccount <BnfcryInstnAcct> [0..1] +
4.15 Creditor <Cdtr> [0..1] +
4.16 CreditorAccount <CdtrAcct> [0..1] +
4.17 RemittanceInformation <RmtInf> [0..1]
4.32 Purpose <Purp> [0..1]
4.35 InstructionForFinalAgent <InstrForFnlAgt> [0..1]
4.38 DetailsOfCharges <DtlsOfChrgs> [0..1] Code
4.39 SenderToReceiverInformation <SndrToRcvrInf> [0..6] Text
4.1 RelatedReference <RltdRef>Presence: [0..1]Definition: Reference relating to a linked payment instruction or agreement which is meaningful to both parties (eg, the
content of field 21 in a cover instruction).Data Type: Max35TextFormat: maxLength: 35
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 160
4.2 BankOperationCode <BkOprCd>Presence: [0..1]Definition: SWIFT defined service level applies to the payment instruction.Data Type: CodeWhen this message item is present, one of the following SWIFTServiceLevel2Code values must be used:
Code Name DefinitionSPAY SWIFTPay Credit transfer is to be processed according to the
SWIFTPay Service Level.
SSTD Standard Credit transfer is to be processed according to the Standard Service Level.
4.3 InstructionCode <InstrCd>Presence: [0..1]Definition: Further information related to the processing of the payment instruction. The instruction can relate to a level
of service between the bank and the customer, or give instructions to and for specific parties in the payment chain.
Data Type: CodeWhen this message item is present, one of the following Instruction1Code values must be used:
Code Name DefinitionPBEN PayTheBeneficiary Beneficiary to be paid only after verification of identity.
TFRO TimeFrom Payment instruction will be valid and eligible for execution from the date and time stipulated.
TTIL TimeTill Payment instruction is valid and eligible for execution until the date and time stipulated. Otherwise, the payment instruction will be rejected.
4.4 RequestedExecutionDate <ReqdExctnDt>Presence: [0..1]Definition: Date and time the originator (debtor or creditor) requests the clearing agent to process the payment instruction.Data Type: ISODate
4.5 ValueDate <ValDt>Presence: [0..1]Definition: Date on which the amount of money ceases to be available to theagent that owes the money, or when the
amount of money becomes available to the agent to which the money is due.Data Type: ISODate
4.6 InterbankSettledAmount <IntrBkSttldAmt>Presence: [0..1]Definition: Amount of money transferred between the instructing agent and instructed agent.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 161
Format: CurrencyAndAmountfractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.7 Debtor <Dbtr>Presence: [0..1]Definition: Debtor or Ordering customer of the payment instruction.Type: This message item is composed of the following PartyIdentification1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Name <Nm> [0..1] Text
PostalAddress <PstlAdr> [0..1]
Identification <Id> [0..1]
For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section
4.8 DebtorAccount <DbtrAcct>Presence: [0..1]Definition: Account to or from which a cash entry is made.Type: This message item is composed of the following CashAccount3 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Identification <Id> [1..1]
Type <Tp> [0 ..1] Code
Currency <Ccy> [0..1] Code
Name <Nm> [0..1] Text
For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section
4.9 IntermediarySettlementAgent <IntrmySttlmAgt>Presence: [0..1]Definition: Party that executes a cash transfer received via a clearing agent or on request of an agreement party.Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):
Or Message Item <XML Tag> Mult. Represent./Type
FinancialInstitutionIdentification <FinInstnId> [1..1]
BranchIdentification <BrnchId> [0..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 162
For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section
4.10 LastSettlementAgent <LastSttlmAgt>Presence: [0..1]Definition: Party that executes a cash transfer received via a clearing agent or on request of an agreement party.Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):
Or Message Item <XML Tag> Mult. Represent./Type
FinancialInstitutionIdentification <FinInstnId> [1..1]
BranchIdentification <BrnchId> [0..1]
For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section
4.11 PaymentScheme <PmtSchme>Presence: [0..1]Definition: Specification of a pre-agreed offering between clearing agents, or the channel through which the payment
instruction is to be processed. This payment scheme can point to a specific rulebook governing the rules of clearing and settlement between two parties.
Type: This message item is composed of one of the following PaymentSchemeChoice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.12 {Or Code <Cd> [1..1] Code
4.13 Or} ProprietaryInformation <PrtryInf> [1..1] Text
4.12 Code <Cd>Presence: [1..1]This message item is part of choice 4.11 PaymentScheme.Definition: Specifies the channel through which the payment instruction is to be processed in coded form. Data Type: CodeOne of the following CashClearingSystem2Code values must be used:
Code Name DefinitionACH ACH Automated Clearing House. Payment system that clears
cash transfers and settles the proceeds in a lump sum, usually on a multilateral netting basis.
CHI CHIPS CHIPS is the Clearing House Interbank Payment System.
FDN FedNet FedNet is a link to a Federal Bank account via the internet. FedNet enables checking of account balance, transactions, take print outs of account statement, transfer funds to third party accounts, E-shopping, BSNL Payments, Deposit opening, Deposit Renewal, Request for Demand Draft, Cheque Book etc.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 163
Code Name DefinitionRTG RTGS Real Time Gross Settlement System. Payment system that
simultaneously clears individual transfers and settles them in central bank money.
4.13 ProprietaryInformation <PrtryInf>Presence: [1..1]This message item is part of choice 4.11 PaymentScheme.Definition: Channel that is specific to a user community and is required for use within that user community.
Usage : if the channel is included in the list of codes provided for the payment scheme, the code element should be used instead of the proprietary element.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.14 BeneficiaryInstitutionAccount <BnfcryInstnAcct>Presence: [0..1]Definition: Account to or from which a cash entry is made.Type: This message item is composed of the following CashAccount3 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Identification <Id> [1..1]
Type <Tp> [0 ..1] Code
Currency <Ccy> [0..1] Code
Name <Nm> [0..1] Text
For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section
4.15 Creditor <Cdtr>Presence: [0..1]Definition: Entity involved in an activity.Type: This message item is composed of the following PartyIdentification1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Name <Nm> [0..1] Text
PostalAddress <PstlAdr> [0..1]
Identification <Id> [0..1]
For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 164
4.16 CreditorAccount <CdtrAcct>Presence: [0..1]Definition: Account to or from which a cash entry is made.Type: This message item is composed of the following CashAccount3 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Identification <Id> [1..1]
Type <Tp> [0 ..1] Code
Currency <Ccy> [0..1] Code
Name <Nm> [0..1] Text
For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section
4.17 RemittanceInformation <RmtInf>Presence: [0..1]Definition: Structured information that enables the matching, ie, reconciliation, of a payment with the items that the
payment is intended to settle, eg, commercial invoices in an account receivable system.Type: This message item is composed of one of the following RemittanceInformation3Choice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.18 {Or Unstructured <Ustrd> [1..1] Text
4.19 Or} Structured <Strd> [1..1]
4.18 Unstructured <Ustrd>Presence: [1..1]This message item is part of choice 4.17 RemittanceInformation.Definition: Information, in free text form, to enable the matching, ie reconciliation, (reconciliation) of a payment with
the items that the payment is intended to settle, such as commercial invoices in an accounts receivable system.Data Type: Max140TextFormat: maxLength: 140
minLength: 1
4.19 Structured <Strd>Presence: [1..1]This message item is part of choice 4.17 RemittanceInformation.Definition: Information in structured form, that is supplied to enable the matching, ie, reconciliation, of a payment with
the items that the payment is intended to settle, eg, commercial invoices in an account receivable system. Type: This message item is composed of the following StructuredRemittanceInformation2 element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.20 ReferredDocumentType <RfrdDocTp> [0..1] Code
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 165
Index Or Message Item <XML Tag> Mult. Represent./Type
4.21 ReferredDocumentRelatedDate <RfrdDocRltdDt> [0..1] DateTime
4.22 ReferredDocumentAmount <RfrdDocAmt> [0..n]
4.28 DocumentReferenceNumber <DocRefNb> [0..1] Text
4.29 CreditorReference <CdtrRef> [0..1] Text
4.30 Invoicer <Invcr> [0..1] +
4.31 Invoicee <Invcee> [0..1] +
4.20 ReferredDocumentType <RfrdDocTp>Presence: [0..1]Definition: Specifies the nature of the referred document/transaction, eg, invoice or credit note.Data Type: CodeWhen this message item is present, one of the following DocumentType1Code values must be used:
Code Name DefinitionCINV CommercialInvoice Document is an invoice.
CMCN CommercialContract Document is an agreement between the parties, stipulating the terms and conditions of the delivery of goods or services.
CNFA CreditNoteRelatedToFinancialAdjustment
Document is a credit note for the final amount settled for a commercial transaction.
CREN CreditNote Document is a credit note.
DEBN DebitNote Document is a debit note.
DNFA DebitNoteRelatedToFinancialAdjustment
Document is a debit note for the final amount settled for a commercial transaction.
FXDR ForeignExchangeDealReference
Document is a pre-agreed or pre-arranged foreign exchange transaction to which the payment transaction refers.
HIRI HireInvoice Document is an invoice for the hiring of human resources or renting goods or equipment.
MSIN MeteredServiceInvoice Document is an invoice claiming payment for the supply of metered services, eg, gas or electricity, supplied to a fixed meter.
RADM RemittanceAdviceMessage Document is a remittance advice sent separately from the current transaction.
RPIN RelatedPaymentInstruction Document is a linked payment instruction to which the current payment instruction is related, eg, in a cover scenario.
SBIN SelfBilledInvoice Document is an invoice issued by the debtor.
SOAC StatementOfAccount Document is a statement of the transactions posted to the debtor's account at the supplier.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 166
4.21 ReferredDocumentRelatedDate <RfrdDocRltdDt>Presence: [0..1]Definition: Date associated with the referred document, eg, date of issue. Data Type: ISODate
4.22 ReferredDocumentAmount <RfrdDocAmt>Presence: [0..n]Definition: Amount of money and currency of a document referred to in the remittance section. The amount is typically
either the original amount due and payable, or the amount actually remitted for the referred document.Type: This message item is composed of one of the following ReferredDocumentAmount1Choice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.23 {Or DuePayableAmount <DuePyblAmt> [1..1] Amount
4.24 Or DiscountAppliedAmount <DscntApldAmt> [1..1] Amount
4.25 Or RemittedAmount <RmtdAmt> [1..1] Amount
4.26 Or CreditNoteAmount <CdtNoteAmt> [1..1] Amount
4.27 Or} TaxAmount <TaxAmt> [1..1] Amount
4.23 DuePayableAmount <DuePyblAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Amount specified is the exact amount due and payable to the creditor.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.24 DiscountAppliedAmount <DscntApldAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Amount of money resulting from the application of an agreed discount to the amount due and payable to the
creditor.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 167
CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.25 RemittedAmount <RmtdAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Amount of money remitted for the referred document.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.26 CreditNoteAmount <CdtNoteAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Amount specified for the referred document is the amount of a credit note.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.27 TaxAmount <TaxAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Quantity of cash resulting from the calculation of the tax.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 168
Rule(s): CurrencyCodeValidationByTable
4.28 DocumentReferenceNumber <DocRefNb>Presence: [0..1]Definition: Unique and unambiguous identification of a document that distinguishes that document from another
document referred to in the remittance information, usually assigned by the originator of the referred document/transaction.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.29 CreditorReference <CdtrRef>Presence: [0..1]Definition: Unique and unambiguous reference assigned by the creditor to refer to the payment transaction.
Usage: if available, the initiating party should provide this reference in the structured remittance information, to enable reconciliation by the creditor upon receipt of the cash.
If the business context requires the use of a creditor reference or a payment remit identification, and only one identifier can be passed through the end-to-end chain, the creditor's reference or payment remittance identification should be quoted in the end-to-end transaction identification.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.30 Invoicer <Invcr>Presence: [0..1]Definition: Identification of the organization issuing the invoice when different than the creditor or final party Type: This message item is composed of the following PartyIdentification1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Name <Nm> [0..1] Text
PostalAddress <PstlAdr> [0..1]
Identification <Id> [0..1]
For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section
4.31 Invoicee <Invcee>Presence: [0..1]Definition: Identification of the party to whom an invoice is issued, when different than the originator or debtor.Type: This message item is composed of the following PartyIdentification1 element(s):
Or Message Item <XML Tag> Mult. Represent./Type
Name <Nm> [0..1] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 169
Or Message Item <XML Tag> Mult. Represent./Type
PostalAddress <PstlAdr> [0..1]
Identification <Id> [0..1]
For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section
4.32 Purpose <Purp>Presence: [0..1]Definition: Underlying reason for the payment transaction, eg, a charity payment, or a commercial agreement between
the creditor and the debtor.Type: This message item is composed of one of the following PurposeChoice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.33 {Or Proprietary <Prtry> [1..1] Text
4.34 Or} Code <Cd> [1..1] Code
4.33 Proprietary <Prtry>Presence: [1..1]This message item is part of choice 4.32 Purpose.Definition: Payment transaction purpose that is specific to a user community and is required for use within that user
community.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.34 Code <Cd>Presence: [1..1]This message item is part of choice 4.32 Purpose.Definition: Specifies the type of transaction that resulted in the payment initiation in coded form Data Type: CodeOne of the following PaymentPurpose1Code values must be used:
Code Name DefinitionADVA AdvancePayment Transaction is an advance payment.
AGRT AgriculturalTransfer Transaction is related to the agricultural domain.
ALMY AlimonyPayment Transaction is the payment of alimony.
BECH ChildBenefit Transaction is related to a payment made to assist parent/guardian to maintain child.
BENE UnemploymentDisabilityBenefit
Transaction is related to a payment to a person who is unemployed/disabled.
BONU BonusPayment. Transaction is related to payment of a bonus.
CASH CashManagementTransfer Transaction is a general cash management instruction.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 170
Code Name DefinitionCBFF CapitalBuilding Transaction is related to capital building fringe fortune, ie
capital building for retirement.
CHAR CharityPayment Transaction is a payment for charity reasons.
CMDT CommodityTransfer Transaction is payment of commodities.
COLL CollectionPayment Collection of funds initiated via a credit transfer.
COMC CommercialCredit Transaction is payment of commercial credit.
COMM Commission Transaction is payment of commission.
COMT ConsumerThirdPartyConsolidatedPayment
Payment used by a third party who can collect funds to pay on behalf of consumers, ie credit counseling or bill payment companies.
COST Costs Transaction is related to payment of costs.
CPYR Copyright Transaction is payment of copyright.
DBTC DebitCollectionPayment Collection of funds initiated via a debit transfer.
DIVI Dividend Transaction is payment of dividends.
FREX ForeignExchange Transaction is related to a foreign exchange operation.
GDDS PurchaseSaleOfGoods Transaction is related to purchase and sale of goods.
GOVT GovernmentPayment Transaction is a payment to or from a government department.
HEDG Hedging Transaction is related to a hedging operation.
IHRP InstalmentHirePurchaseAgreement
Transaction is payment for an installment/hire-purchase agreement.
INSU InsurancePremium Transaction is payment of an insurance premium.
INTC IntraCompanyPayment Transaction is an intra-company payment, ie, a payment between two companies belonging to the same group.
INTE Interest Transaction is payment of interest.
LICF LicenseFee Transaction is payment of a license fee.
LOAN Loan Transaction is related to transfer of loan to borrower.
LOAR LoanRepayment Transaction is related to repayment of loan to lender.
NETT Netting Transaction is related to a netting operation.
PAYR Payroll Transaction is related to the payment of payroll.
PENS PensionPayment Transaction is the payment of pension.
REFU Refund Transaction is the payment of a refund.
RENT Rent Transaction is the payment of rent.
ROYA Royalties Transaction is the payment of royalties.
SALA SalaryPayment Transaction is the payment of salaries.
SCVE PurchaseSaleOfServices Transaction is related to purchase and sale of services.
SECU Securities Transaction is the payment of securities.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 171
Code Name DefinitionSSBE SocialSecurityBenefit Transaction is a social security benefit, ie payment made by
a government to support individuals.
SUBS Subscription Transaction is the payment of a subscription.
SUPP SupplierPayment Transaction is related to a payment to a supplier.
TAXS TaxPayment Transaction is the payment of taxes
TREA TreasuryPayment Transaction is related to treasury operations.
VATX ValueAddedTaxPayment Transaction is the payment of value added tax.
4.35 InstructionForFinalAgent <InstrForFnlAgt>Presence: [0..1]Definition: Further information related to the processing of the payment instruction. The instruction can relate to a level
of service between the bank and the customer, or give instructions to and for specific parties in the payment chain.
Type: This message item is composed of the following InstructionForFinalAgent element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.36 Code <Cd> [0..2] Code
4.37 Proprietary <Prtry> [0..1] Text
4.36 Code <Cd>Presence: [0..2]Definition: Further information related to the processing of the payment instruction, provided by the initiating party,
and intended for the final agent, in coded form.Data Type: CodeWhen this message item is present, one of the following Instruction3Code values must be used:
Code Name DefinitionCHQB PayCreditorByCheque Beneficiary must be paid by cheque.
HOLD HoldCashForCreditor Cash must be held for the beneficiary, who will call.. Pay on identification.
PHOB PhoneBeneficiary Please advise/contact beneficiary/claimant by phone
TELB Telecom Please advise/contact beneficiary/claimant by the most efficient means of telecommunication.
4.37 Proprietary <Prtry>Presence: [0..1]Definition: Instruction to the final agent that is specific to a user community and is required for use within that user
community.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 172
Usage : The proprietary element should only be used when the coded element does not provide sufficient codes or when the selected code in the coded element needs to be supplemented by additional information such as a passport number or telephone number.
Data Type: Max140TextFormat: maxLength: 140
minLength: 1
4.38 DetailsOfCharges <DtlsOfChrgs>Presence: [0..1]Definition: Party(ies) liable for a charge associated with the transfer of cash.Data Type: CodeWhen this message item is present, one of the following ChargeBearer1Code values must be used:
Code Name DefinitionBEN BorneByCreditor All transaction charges are to be borne by the creditor.
OUR BorneByDebtor All transaction charges are to be borne by the debtor.
SHA Shared Under the credit transfer scenario, transaction charges on the sender's side are to be borne by the debtor; transaction charges on the receiver's side are to be borne by the creditor.
4.39 SenderToReceiverInformation <SndrToRcvrInf>Presence: [0..6]Definition: Unformatted information from the sender to the receiver.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
Business Example
The following illustrates three scenarios for the RequestToModifyPayment workflow. All scenarios are based on the payment characteristics in the table below.
Customer A (BEI CUSAGB2L) instructed Bank A (AAAAGB2L) to execute a payment. The payment settles a series of invoices received in January 2005 and referenced in the remittance information section of the payment instruction. The unstructured remittance information reproduced below refers to two commercial invoices.Characteristics of the payment instruction are as follows:
Description Value
Sender Customer A (BEI CUSAGB2L)
Receiver Bank A, London (AAAAGB2L)
Instruction Reference CPAY0123456789
Transaction Reference 20050127003
Requested Execution Date 2005-01-27
Instructed Amount and Currency
52317.48 GBP
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 173
Unstructured Remittance Information
/INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/
Final Agent Bank K, London (KKKKGB2L)
Creditor Customer S (ASUPGB2L)All Supplies and Co
Scenario 1, resulting in an AdditionalPaymentInformation message
NarrativeCustomer A checks its accounts payables. The dates for the two invoices have been incorrectly reported in the remittance information.
Step 1Customer A decides to request the modification of the payment instruction in order for the creditor to automatically reconcile the accounts receivables with the payment instruction amount. Customer A makes a request for modification of the payment instruction to change the remittance information content.
The following RequestToModifyPayment message is sent by Customer A to Bank A:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSTA20050003</Id><Assgnr>CUASGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CPAY0123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<RmtInf><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has already been forwarded to Bank K, under reference 1030123456789. Bank A needs to forward the RequestToModifyPayment message to Bank K (Step 2.1). At the same time, Bank A informs Customer A of the case assignment to Bank K (Step 2.2).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 174
Step 2.1Bank A requests the modification of the original payment instruction to Bank K.
The following RequestToModifyPayment message is sent by Bank A to Bank K:XML Instance
<camt.007.002.01><Assgnmt>
<Id>C103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<RmtInf><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 2.2 Bank A informs Customer A of the case assignment to Bank K.
The following NotificationOfAssignment message is sent by Bank A to Customer A: XML Instance
<camt.030.001.01><Hdr>
<Id>RCUSTA20050001</Id><Fr>AAAAGB2L</Fr><To>CUSAGB2L</To><CreDtTm>2005-01-27T08:50:22</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</Case><Assgnmt>
<Id>C103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>MODI</Justfn>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 175
</Ntfctn></camt.030.001.01>
Step 3Bank K receives the RequestToModifyPayment message from Bank A and checks the status of the instruction. The instruction has been correctly executed. The credit has been passed onto the account of Customer S and the customer has been informed. Bank K forwards the correct remittance information content to Customer S, using an AdditionalPaymentInformation message (Step 3.1). At the same time, as there is no further processing needed, a ResolutionOfInvestigation message is sent to Bank A, notifying that the information has been delivered to the customer (Step 3.2). Bank A in turn reverts to Customer A with a ResolutionOfInvestigation message (Step 3.3).
Step 3.1Bank K forwards additional information about the payment to Customer S.
The following AdditionalPaymentInformation message is sent by Bank K to Customer S:XML Instance
<camt.028.001.01><Assgnmt>
<Id>I103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:52:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>I1030123456789</AssgnrInstrId></Undrlyg><Inf>
<RmtChc><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>
</RmtChc><Cdtr>
<Nm>All Supplies and Co</Nm><Id>
<OrgId><BEI>CUSBGB2L</BEI>
</OrgId></Id>
</Cdtr></Inf>
</camt.028.001.01>
Step 3.2Bank K informs Bank A of the resolution of the investigation.
The following ResolutionOfInvestigation message is sent by Bank K to Bank A.XML Instance
<camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 176
<Assgnmt><Id>RKKKKAAAA20050127004</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T09:08:23</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Step 3.3Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A of the resolution of the investigation.
The following ResolutionOfInvestigation message is sent by Bank A to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>RAAAACUSA20050127004</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne><CreDtTm>2005-01-27T09:18:23</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Scenario 2, resulting in a RequestToCancelPayment message
NarrativeCustomer A checks its accounts payables. The invoices are payable to the account of Customer C with Bank W (WWWWGB2L) instead of Bank K.
Step 1Customer A makes a request for modification of the payment instruction to change the final agent (creditor's financial institution).
The following RequestToModifyPayment message is sent by Customer A to Bank A:XML Instance
<camt.007.002.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 177
<Assgnmt><Id>CUSTA20050001</Id><Assgnr>CUSAGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050002</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CPAY0123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<LastSttlmAgt><FinInstnId>
<BIC>WWWWGB2L</BIC></FinInstnId>
</LastSttlmAgt></Mod>
</camt.007.002.01>
Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has already been forwarded to Bank K, under reference 1030123456789. Bank A needs to request the cancellation of the instruction to Bank K (Step 2.1) and re issue the instruction to Bank W. (This new instruction is not illustrated here) At the same time, Bank A informs Customer A of the case assignment to Bank K (Step 2.2).
Step 2.1Bank A requests the cancellation of the original payment instruction to Bank K.
The following RequestToCancelPayment message is sent by Bank A to Bank K:XML Instance
<camt.008.002.01><Assgnmt>
<Id>C103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050002</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Justfn>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 178
<CxlRsn>AGNT</CxlRsn></Justfn>
</camt.008.002.01>
Step 2.2Bank A informs Customer A of the case assignment to Bank K.
The following NotificationOfAssignment message is sent by Bank A to Customer A: XML Instance
<camt.030.001.01><Hdr>
<Id>RCUSTA20050001</Id><Fr>AAAAGB2L</Fr><To>CUSAGB2L</To><CreDtTm>2005-01-27T08:50:22</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050002</Id><Cretr>CUSAGB2L</Cretr>
</Case><Assgnmt>
<Id>C103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>CANC</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank K receives the RequestToCancelPayment message from Bank A and checks the status of the instruction. The credit has not yet been passed onto the account of Customer S. Bank K cancels the instruction and reverts to Bank A with a ResolutionOfInvestigation message. If the instruction had been settled between Bank A and Bank K, a return of funds would be necessary (not illustrated in this scenario).
The following ResolutionOfInvestigation message is sent by Bank K to Bank A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>RC103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:54:30</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050002</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 179
<Conf>CNCL</Conf></Sts>
</camt.029.001.01>
Step 4Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A at the resolution of the investigation.
The following ResolutionOfInvestigation message is sent by Bank A to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>RCUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne><CreDtTm>2005-01-27T11:04:27</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050002</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Scenario 3, resulting in a DebitAuthorisationRequest message
NarrativeCustomer A checks its accounts payables and receivables, and discovers a credit note of 3743.52 GBP dated 15 December 2004 under reference 20041208204712 received from Customer S that should have been deducted from the amount of the last invoice.
Step 1 Customer A makes a request for modification of the payment instruction to lower the payment amount. The new payment amount is 48573.96 GBP instead of the original amount. Within the same request for modification, Customer A supplements the remittance information in order to allow Customer S to reconcile the new amount.
The following RequestToModifyPayment message is sent by Customer A to Bank A:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSTA20050001</Id><Assgnr>CUASGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUASGB2L</Cretr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 180
</Case><Undrlyg>
<AssgnrInstrId>CPAY0123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<IntrBkSttldAmt Ccy = "GBP">48573.96</IntrBkSttldAmt><RmtInf>
<Ustrd>/INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/20041215/GBP3743.52/20041208304712</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has been forwarded, under reference 1030123456789 to Bank K for further processing. Bank A therefore forwards the RequestToModifyPayment message to Bank K (Step 2.1) and subsequently informs Customer A about the case assignment (Step 2.2).
Step 2.1Bank A forwards the RequestToModifyPayment message to Bank K:XML Instance
<camt.007.002.01><Assgnmt>
<Id>CUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUASGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<IntrBkSttldAmt Ccy = "GBP">48573.96</IntrBkSttldAmt><RmtInf>
<Ustrd>/INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/20041215/GBP3743.52/20041208304712</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 2.2Bank A informs Customer A of the case assignment to Bank K.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 181
The following NotificationOfCaseAssignment message is sent to Customer A by Bank A:XML Instance
<camt.030.001.01><Hdr>
<Id>AAAACUSA20050127003</Id><Fr>AAAAGB2L</Fr><To>CUSAGB2L</To><CreDtTm>2005-01-27T08:45:30</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Assgnmt>
<Id>Q103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>MODI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank K receives the RequestToModifyPayment message from Bank A and checks the status of the instruction. The credit has been passed onto the account of Customer S who has already been notified. Bank K needs to request debit authorisation from Customer S (Step 3.1) and to inform Bank A of the case assignment (Step 3.2).
Step 3.1Bank K requests debit authorisation from Customer S.
The following DebitAuthorisationRequest message is sent by Bank K to Customer S:XML Instance
<camt.037.001.01><Assgnmt>
<Id>103KKKKSUPPLIES1234567890</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:50:30</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Dtl>
<CxlRsn>CUST</CxlRsn>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 182
<AmtToDbt Ccy = "GBP">3743.52</AmtToDbt></Dtl>
</camt.037.001.01>
Step 3.2Bank K informs Bank A of the case assignment.
The following NotificationOfAssignment message is sent by Bank K to Bank A:XML Instance
<camt.030.001.01><Hdr>
<Id>KKKKAAAA20050127004</Id><Fr>KKKKGB2L</Fr><To>AAAAGB2L</To><CreDtTm>2005-01-27T08:55:00</CreDtTm>
</Hdr><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Assgnmt>
<Id>103KKKKSUPPLIES12345678901</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:50:30</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>DTAU</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Customer S responds positively to the request for debit authorisation from Bank K.
The following DebitAuthorisationResponse message is sent by Customer S to Bank K:XML Instance
<camt.036.001.01><Assgnmt>
<Id>REP103KKKKSUPPLIES12345678901</Id><Assgnr>ASUPGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T10:55:23</CreDtTm>
</Assgnmt><Case>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</Case><Conf>
<DbtAuthstn>true</DbtAuthstn></Conf>
</camt.036.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 183
Step 5Upon receipt of the positive DebitAuthorisationResponse message, Bank K debits the account of Customer S for the amount specified and returns the funds in favour of Customer A via Bank A. (This process is not illustrated here) Bank K also informs the case assigner, Bank A, about the positive case resolution.
The following ResolutionOfInvestigation message is sent by Bank K to Bank A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>R103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T10:59:42</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
Step 6Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A of the resolution of the investigation.
The following ResolutionOfInvestigation message is sent by Bank A to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>RCUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne><CreDtTm>2005-01-27T11:04:27</CreDtTm>
</Assgnmt><RslvdCase>
<Id>CUSTA20050001</Id><Cretr>CUSAGB2L</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: RequestToModifyPayment <camt.007.002.01>
Page 184
Message: ResolutionOfInvestigation <camt.029.001.01>Message Scope and UsageScopeThe ResolutionOfInvestigation message is sent by a case assignee to a case creator/case assigner.
This message is used to inform of the resolution of a case, and optionally provides details about the corrective action undertaken by the case assignee.
Usage
The ResolutionOfInvestigation message is used by the case assignee to inform a case creator/case assigner about the resolution of a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case
The ResolutionOfInvestigation message covers one and only one case at a time. If the case assignee needs to communicate about several cases, then several ResolutionOfInvestigation messages must be sent.
The ResolutionOfInvestigation message provides:- the final outcome of the case, whether positive or negative- optionally, the details of the corrective action undertaken by the case assignee
Whenever a payment instruction has been generated to solve the case under investigation, the optional CorrectionTransaction component present in the message must be completed.
The ResolutionOfInvestigation message must be forwarded by all subsequent case assignee(s) until it reaches the case creator.
The ResolutionOfInvestigation message must not be used in place of a RejectCaseAssignment or CaseStatusReport or NotificationOfAssignment message.
OutlineThe ResolutionOfInvestigation message is composed of four building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Payment Instruction ExtractThis building block is optional.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 185
D. Investigation Status ChoiceThis building block is optional.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 ResolvedCase <RslvdCase> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Status <Sts> [0..1]
3.1 {Or Confirmation <Conf> [1..1] Code
3.2 Or RejectedModification <RjctdMod> [1..14] Code
3.3 Or RejectedCancellation <RjctdCxl> [1..1]
3.4 ReasonCode <RsnCd> [1..1] Code
3.5 Reason <Rsn> [0..1] Text
3.6 Or DuplicateOf <DplctOf> [1..1]
3.7 Identification <Id> [1..1] Text
3.8 Creator <Cretr> [1..1] Identifier
3.9 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
3.10 Or} AssignmentCancellationConfirmation <AssgnmtCxlConf> [1..1] Indicator
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 186
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 CorrectionTransaction <CrrctnTx> [0..1]
4.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
4.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
4.3 CurrencyAmount <CcyAmt> [0..1] Amount
4.4 ValueDate <ValDt> [0..1] DateTime
Message Items DescriptionThe following section identifies the elements of the ResolutionOfInvestigation message.
1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Note: the Assigner must be the sender of this confirmation and the Assignee must be the receiver.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example:
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 187
<Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 ResolvedCase <RslvdCase>Presence: [1..1]Definition: Identifies a resolved case.Type: The ResolvedCase block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifier
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 188
Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Status <Sts>Presence: [0..1]Definition: Indicates the status of the investigation.Type: The Status block is composed of one of the following InvestigationStatusChoice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 {Or Confirmation <Conf> [1..1] Code
3.2 Or RejectedModification <RjctdMod> [1..14] Code
3.3 Or RejectedCancellation <RjctdCxl> [1..1]
3.6 Or DuplicateOf <DplctOf> [1..1]
3.10 Or} AssignmentCancellationConfirmation <AssgnmtCxlConf> [1..1] Indicator
3.1 Confirmation <Conf>Presence: [1..1]This message item is part of choice 3.0 Status.Definition: Indicates the status of an investigation.Data Type: CodeOne of the following InvestigationExecutionConfirmation1Code values must be used:
Code Name DefinitionACDA AcceptedDebitAuthorisation Returned when a creditor accepts the debit authorisation.
CNCL CancelledAsPerRequest Returned when a requested cancellation is successfull.
CONF ConfirmationOfPayment Returned when a payment has been checked and was correctly executed.
CWFW CancellationWillFollow Returned when a payment will be cancelled to solve an investigation case.
ICOV CoverInitiated Returned when a transfer of funds has been initiated (a cover payment) to resolve a case.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 189
Code Name DefinitionINFO AdditionalInformationSent Returned when additional information has been sent to the
beneficiary of a payment.
IPAY PaymentInitiated Returned when the result of an investigation is the initiation of payment instruction.
IPYI PaymentInstructionInitiated Returned when a payment instruction (eg. MT103) has been initiated to resolve a case.
MCOV CoverModified Returned when a transfer of funds has been modified (a cover payment) to resolve a case.
MODI ModifiedAsPerRequest Returned when a requested modification is successfull.
3.2 RejectedModification <RjctdMod>Presence: [1..14]This message item is part of choice 3.0 Status.Definition: Indicates the reason for rejecting a modification.Data Type: CodeOne of the following PaymentModificationRejection1Code values must be used:
Code Name DefinitionUM01 UnableToModifyRelatedRef
erenceRelatedReference cannot be modified.
UM02 UnableToModifyBankOperationCode
BankOperationCode cannot be modified.
UM03 UnableToModifyInstructionCode
InstructionCode cannot be modified.
UM04 UnableToModifyRequestedExecutionDate
RequestedExecutionDate cannot be modified.
UM05 UnableToModifyValueDate ValueDate cannot be modified.
UM06 UnableToModifyInterbankSettlementAccount
InterbankSettlementAccount cannot be modified.
UM07 UnableToModifyDebtor Debtor cannot be modified.
UM08 UnableToModifyDebtorAccount
DebtorAccount cannot be modified.
UM09 UnableToModifyReceiverCorrespondent
ReceiverCorrespondent cannot be modified.
UM10 UnableToModifyThirdReimbursementInstitution
ThirdReimbursementInstitution cannot be modified.
UM11 UnableToModifyPaymentScheme
PaymentScheme cannot be modified.
UM12 UnableToModifyAccountofBeneficiaryInstitution
AccountOfBeneficiaryInstitution cannot be modified.
UM13 UnableToModifyCreditor Creditor cannot be modified.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 190
Code Name DefinitionUM14 UnableToModifyCreditorAc
countCreditorAccount cannot be modified.
UM15 UnableToModifyRemittanceInformation
RemittanceInformation cannot be modified.
UM16 UnableToModifyPaymentPurpose
PaymentPurpose cannot be modified.
UM17 UnableToModifyDetailsOfCharges
DetailsOfCharges cannot be modified.
UM18 UnableToModifySenderToReceiverInformation
SenderToReceiver cannot be modified.
UM19 UnableToModifyInstructionForFinalAgent
InstructionForFinalAgent cannot be modified.
UM20 InstructionCancelledSubmitNewInstruction
Used to inform of cancellation and request a new payment instruction. This should only be used if an agent does not want to modify a pending payment.
UM21 UnableToModifySubmitCancellation
Modification is not possible and the cancellation is requested.
3.3 RejectedCancellation <RjctdCxl>Presence: [1..1]This message item is part of choice 3.0 Status.Definition: Explains the reason for rejecting a payment cancellation request.Type: This message item is composed of the following RejectedCancellationJustification element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.4 ReasonCode <RsnCd> [1..1] Code
3.5 Reason <Rsn> [0..1] Text
3.4 ReasonCode <RsnCd>Presence: [1..1]Definition: Justification for the rejection of the cancellation.Data Type: CodeOne of the following PaymentCancellationRejection1Code values must be used:
Code Name DefinitionAGNT AgentDecision Reported when the cancellation cannot be accepted because
of an agent refuses to cancel.
CUST CustomerDecision Reported when the cancellation cannot be accepted because of a customer decision (Creditor).
LEGL LegalDecision Reported when the cancellation cannot be accepted because of regulatory rules.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 191
3.5 Reason <Rsn>Presence: [0..1]Definition: Free text justification for rejecting a cancellation.Data Type: Max140TextFormat: maxLength: 140
minLength: 1
3.6 DuplicateOf <DplctOf>Presence: [1..1]This message item is part of choice 3.0 Status.Definition: Identifies a duplicated case. When present, the case identified in the message must be closed. The case
identified as duplicated (in this component) will be pursued.Type: This message item is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.7 Identification <Id> [1..1] Text
3.8 Creator <Cretr> [1..1] Identifier
3.9 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
3.7 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
3.8 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 192
3.9 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.10 AssignmentCancellationConfirmation <AssgnmtCxlConf>Presence: [1..1]This message item is part of choice 3.0 Status.Definition: If yes, it means the cancellation of the assignment is confirmed.
If no, it means the cancellation of the assignment is rejected and the investigation process will continue.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
4.0 CorrectionTransaction <CrrctnTx>Presence: [0..1]Definition: References a transaction intitiated to fix the case under investigation.Type: The CorrectionTransaction block is composed of the following PaymentInstructionExtract element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
4.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
4.3 CurrencyAmount <CcyAmt> [0..1] Amount
4.4 ValueDate <ValDt> [0..1] DateTime
4.1 AssignerInstructionIdentification <AssgnrInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.2 AssigneeInstructionIdentification <AssgneInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
4.3 CurrencyAmount <CcyAmt>Presence: [0..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 193
Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).
Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
4.4 ValueDate <ValDt>Presence: [0..1]Definition: Value date of the payment.Data Type: ISODateTime
Business Example
The following illustrates one scenario for the ResolutionOfInvestigation message. This secnario is based on an initial RequestToCancelPayment workflow. The ResolutionOfInvestigation message is shown in Step 2 below.
Scenario 1, resulting in a ResolutionOfInvestigation message There is no further assignment down the chain as the payment instruction is cancelled before execution by the case assignee.
Customer D (BEI DDDDDEFF) instructed Bank F, Frankfurt (FFFFDEFF) to execute a payment instruction.
Characteristics of the payment instruction are as follows:
Description Value
Sender Customer D (BEI DDDDDEFF)
Receiver Bank F, Frankfurt (FFFFDEFF)
Instruction Reference CDPAY20050423001
Transaction Reference 200504171234
Requested Execution Date 2005-04-23
Instructed Amount 175000.00 EUR
Final Agent Bank G, Frankfurt (GGGGDEFF)
Creditor Customer E (BEI EEEEDEFF)Hanswagen GmBH
NarrativeOn 22 April 2005, Customer D checks its accounts payables. The payment made under reference CDPAY20050423-001 should not have been sent to Bank F for execution on 17 April 2005. This should have been a end of the month payment.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 194
Customer D requests the cancellation of the payment instruction.
Step 1The following RequestToCancelPayment message is sent by Customer D to Bank F:XML Instance
<camt.008.002.01><Assgnmt>
<Id>CD20050423CANC</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>FFFFDEFF</Assgne><CreDtTm>2005-04-22T10:17:32</CreDtTm>
</Assgnmt><Case>
<Id>DDDD20050423001</Id><Cretr>DDDDDEFF</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>CDPAY20050423001</AssgnrInstrId><CcyAmt Ccy = "EUR">175000.00</CcyAmt><ValDt>2005-04-23T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 2Bank F assesses the RequestToCancelPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has not been processed yet and the cancellation can be performed. Bank F executes the cancellation and replies with a ResolutionOfInvestigation message to Customer D.
The following ResolutionOfInvestigation message is sent by Bank F to Customer D:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFFFFFCANC20050423001</Id><Assgnr>FFFFDEFF</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-04-22T10:23:42</CreDtTm>
</Assgnmt><RslvdCase>
<Id>DDDD20050423001</Id><Cretr>DDDDDEFF</Cretr>
</RslvdCase><Sts>
<Conf>CNCL</Conf></Sts>
</camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: ResolutionOfInvestigation <camt.029.001.01>
Page 195
Message: UnableToApply <camt.026.001.01>Message Scope and UsageScopeThe UnableToApply message is sent by a case creator/case assigner to a case assignee.This message is used to initiate an investigation of a payment instruction that cannot be executed or reconciled.
Usage
The unable to apply case occurs in two situations:- an agent cannot execute the payment instruction due to missing or incorrect information- a creditor/debtor cannot reconcile the payment entry as it is received unexpectedly, or missing or incorrect
information prevents reconciliation
The UnableToApply message always follows the reverse route of the original payment instruction.
The UnableToApply message must be forwarded to the preceding agents in the payment processing chain, as relevant.
The UnableToApply message covers one and only one payment instruction or payment entry at a time. If several payment instructions cannot be executed or several payment entries cannot be reconciled, then multiple UnableToApply messages must be sent.
Depending on the result of the analysis of the original payment instruction processing by a case assignee (incorrect routing, errors/omissions when processing the instruction, or no error) and the processing stage of the payment instruction, the unable to apply case may be viewed as a:- RequestToCancelPayment message, sent to the subsequent agent in the payment processing chain, if the original
payment instruction has been incorrectly routed through the chain of agents (this also entails a new corrected payment instruction is issued)
- RequestToModifyPayment message, sent to the subsequent agent in the payment processing chain, if a truncation or omission has occurred during the processing of the original payment instruction.
- DebitAuthorisationRequest message, sent to the case creator/case assigner, if the payment instruction has reached an incorrect creditor
- AdditionalPaymentInformation message, sent to the case creator/case assigner, if a truncation or omission in a payment instruction prevented reconciliation.
Main characteristicsThe UnableToApply message has the following main characteristics:
Case Identification and Reason CodeThe case creator (the instructed party/creditor of a payment instruction) assigns a unique case identification and optionally the reason code for the UnableToApply message. This information will be passed unchanged to all subsequent case assignee(s).
Underlying Payment Instruction IdentificationThe case creator specifies the identification of the underlying payment instruction.This identification needs to be updated by the subsequent case assigner(s) in order to match the one used with their case assignee(s).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 196
Unable To Apply JustificationThe UnableToApplyJustificationChoice element allows to indicate whether a specific element causes the unable to apply situation (incorrect element and/or mismatched element can be listed) or whether any supplementary information needs to be forwarded.
OutlineThe UnableToApply message is composed of four building blocks:
A.Case AssignmentThis building block is mandatory.
B.CaseThis building block is mandatory.
C.Payment Instruction ExtractThis building block is mandatory.
D.Unable to Apply Justification ChoiceThis building block is mandatory.
Message Structure
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.1.0 Assignment <Assgnmt> [1..1]
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.2.0 Case <Case> [1..1]
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 197
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.3.0 Underlying <Undrlyg> [1..1]
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
Index Or Message Item <XML Tag> Mult. Represent./Type
Rule/ Guid.
No.4.0 Justification <Justfn> [1..1]
4.1 {Or AnyInformation <AnyInf> [1..1] Indicator
4.2 Or} MissingOrIncorrectInformation <MssngOrIncrrctInf> [1..1]
4.3 MissingInformation <MssngInf> [0..10] Code
4.4 IncorrectInformation <IncrrctInf> [0..10] Code
Message Items DescriptionThe following section identifies the elements of the UnableToApply message.
1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
1.1 Identification <Id> [1..1] Text
1.2 Assigner <Assgnr> [1..1] Identifier
1.3 Assignee <Assgne> [1..1] Identifier
1.4 CreationDateTime <CreDtTm> [1..1] DateTime
1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 198
1.2 Assigner <Assgnr>Presence: [1..1]Definition: Party that assigns the case to another party. This is also the sender of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Assgnr>CORPBE22</Assgnr>
1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime
2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
2.1 Identification <Id> [1..1] Text
2.2 Creator <Cretr> [1..1] Identifier
2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator
2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 199
Data Type: Max35TextFormat: maxLength: 35
minLength: 1Example: <Id>Case001</Id>
2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.
Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: <Cretr>CORPUK33</Cretr>
2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: YesMeaningWhenFalse: No
3.0 Underlying <Undrlyg>Presence: [1..1]Definition: References the Payment Instruction that a Party is unable to execute or unable to reconcile.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text
3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text
3.3 CurrencyAmount <CcyAmt> [0..1] Amount
3.4 ValueDate <ValDt> [0..1] DateTime
3.1 AssignerInstructionIdentification <AssgnrInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner.Data Type: Max35TextFormat: maxLength: 35
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 200
minLength: 1
3.2 AssigneeInstructionIdentification <AssgneInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.3 CurrencyAmount <CcyAmt>Presence: [0..1]Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or
the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
3.4 ValueDate <ValDt>Presence: [0..1]Definition: Value date of the payment.Data Type: ISODateTime
4.0 Justification <Justfn>Presence: [1..1]Definition: Explains the reason why unable to apply.Type: The Justification block is composed of one of the following UnableToApplyJustificationChoice element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.1 {Or AnyInformation <AnyInf> [1..1] Indicator
4.2 Or} MissingOrIncorrectInformation <MssngOrIncrrctInf> [1..1]
4.1 AnyInformation <AnyInf>Presence: [1..1]This message item is part of choice 4.0 Justification.Definition: When set to yes, indicates that all available information about the underlying payment instruction shall be
sent.Data Type: One of the following YesNoIndicator values must be used:
MeaningWhenTrue: Yes
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 201
MeaningWhenFalse: No
4.2 MissingOrIncorrectInformation <MssngOrIncrrctInf>Presence: [1..1]This message item is part of choice 4.0 Justification.Definition: Missing or incorrect information.Type: This message item is composed of the following MissingOrIncorrectInformation element(s):
Index Or Message Item <XML Tag> Mult. Represent./Type
4.3 MissingInformation <MssngInf> [0..10] Code
4.4 IncorrectInformation <IncrrctInf> [0..10] Code
4.3 MissingInformation <MssngInf>Presence: [0..10]Definition: Indicates the missing information.Data Type: CodeWhen this message item is present, one of the following UnableToApplyMissingInfo1Code values must be used:
Code Name DefinitionMS01 MissingRemittanceInformati
onRemittanceInformation is missing.
MS02 MissingSenderToReceiverInformation
SenderToReceiverInformation is missing.
MS03 MissingDebtor Debtor is missing.
MS04 MissingDebtorAccount DebtorAccount is missing.
MS05 MissingFirstAgent FirstAgent is missing.
MS06 MissingAmount Amount is missing.
MS07 MissingNostroVostroAccount
Nostro_VostroAccount is missing.
MS08 MissingIntermediary Intermediary is missing.
MS09 MissingReimbursementAgent1
ReimbursementAgent (53) is missing.
MS10 MissingReimbursementAgent2
ReimbursementAgent (54) is missing.
MS11 MissingReimbursementAgent
ReimbursementAgent (55) is missing.
MS12 MissingCreditor Creditor is missing.
MS13 MissingCreditorAccount CreditorAccount is missing.
MS14 MissingInstruction Indicates the payment instruction (MT103) is missing.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 202
4.4 IncorrectInformation <IncrrctInf>Presence: [0..10]Definition: Indicates the incorrect information.Data Type: CodeWhen this message item is present, one of the following UnableToApplyIncorrectInfo1Code values must be used:
Code Name DefinitionIN01 IncorrectRelatedReference RelatedReference is incorrect.
IN02 IncorrectBankOperationCode
BankOperationCode is incorrect.
IN03 IncorrectInstructionCode InstructionCode is incorrect.
IN04 IncorrectRequestedExecutionDate
RequestedExecutionDate is incorrect.
IN05 IncorrectValueDate ValueDate is incorrect.
IN06 IncorrectInterbankSettledAmount
InterbankSettledAmount is incorrect.
IN07 IncorrectDebtor Debtor is incorrect.
IN08 IncorrectDebtorAccount DebtorAccount is incorrect.
IN09 IncorrectReceiverCorrespondent
ReceiverCorrespondent is incorrect.
IN10 IncorrectThirdReimbursementInstitution
ThirdReimbursementInstitution is incorrect.
IN11 IncorrectPaymentScheme PaymentScheme is incorrect.
IN12 IncorrectAccountOfBeneficiaryInstitution
AccountOfBeneficiaryInstitution is incorrect.
IN13 IncorrectCreditor Creditor is incorrect.
IN14 IncorrectCreditorAccount CreditorAccount is incorrect.
IN15 IncorrectRemittanceInformation
RemittanceInformation is incorrect.
IN16 IncorrectPaymentPurpose PaymentPurpose is incorrect.
IN17 IncorrectDetailsOfCharges DetailsOfCharges is incorrect.
IN18 IncorrectSenderToReceiverInformation
SenderToReceiverInformation is incorrect.
IN19 IncorrectInstructionForFinalAgent
InstructionForFinalAgent is incorrect.
MM20 MismatchCreditorNameAccount
Name and Account of Creditor mismatched.
MM21 MismatchDebtorNameAccount
Name and Account of Debtor mismatched.
MM22 MismatchFinalAgentNameAccount
Name and Account of FinalAgent mismatched.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 203
Business Example
The following illustrates four scenarios for the UnableToApply workflow.
Narrative for Scenarios 1, 2 and 3
Customer B (BBBBGB2L) receives a statement and cannot reconcile an entry with its accounts receivables. He issues an UnableToApply message to Bank M to get more information about the entry.
Characteristics of the payment entry are as follows:
Description Value
Value Date 050523
Debit/Credit Mark C (Credit)
Amount 52317.48 GBP
Transaction Type Identification Code S103 (SWIFT Message Type 103)
Reference for the Account Owner COMPAY12345050523001
Account Servicing Institution's Reference 2005052304217018
Parties involved in scenarios 1, 2 and 3Creditor's side: Customer B (BBBBGB2L), Bank M (MMMMGB2L)Debtor's side: Customer A (AAAAGB2L), Bank C (CCCCGB2L)
Scenario 1, resulting in a RequestToCancelPayment message
Step 1Customer B asks Bank M for more information about the entry.
The following UnableToApply message is sent by Customer B to Bank M:XML Instance
<camt.026.001.01><Assgnmt>
<Id>UTACOMPAY12345050523001</Id><Assgnr>BBBBGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T08:35:30</CreDtTm>
</Assgnmt><Case>
<Id>BBBBGB2L-20050523-001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>COMPAY12345050523001</AssgnrInstrId><AssgneInstrId>2005052304217018</AssgneInstrId><CcyAmt Ccy="GBP">52317.48</CcyAmt>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 204
<ValDt>2005-05-23T00:00:00</ValDt></Undrlyg><Justfn>
<AnyInf>true</AnyInf></Justfn>
</camt.026.001.01>
Step 2Bank M assesses the UnableToApply message and looks up the original payment instruction. The original payment instruction has been received via the domestic clearing system under reference 1030123456789 and Bank M does not have additional details concerning the instruction. Therefore, Bank M forwards the UnableToApply message to Bank C (Step 2.1). Bank M also informs Customer B about the case assignment (Step 2.2).
Step 2.1The following UnableToApply message is sent by Bank M to Bank C:XML Instance
<camt.026.001.01><Assgnmt>
<Id>UTABBBB050523-01</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T08:52:13</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>2005052304217018</AssgnrInstrId><AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>
</Undrlyg><Justfn>
<AnyInf>true</AnyInf></Justfn>
</camt.026.001.01>
Step 2.2Bank M informs Customer B of the case assignment to Bank C.
The following NotificationOfCaseAssignment message is sent by Bank M to Customer B:XML Instance
<camt.030.001.01><Hdr>
<Id>CABBBB050523001</Id><Fr>MMMMGB2L</Fr><To>BBBBGB2L</To><CreDtTm>2005-05-24T08:52:44</CreDtTm>
</Hdr><Case>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 205
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Assgnmt>
<Id>UTABBBB050523001</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-01-27T08:52:13</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank C receives the UnableToApply message from Bank M and checks the original payment instruction. The instruction has been correctly executed. Bank C does not have additional information that would allow the customer to reconcile the payment instruction. Therefore, Bank C forwards the UnableToApply message to its ordering customer (Customer A) (Step 3.1). Bank C also informs Bank M about the case assignment (Step 3.2). Bank M informs Customer B about the case assignment to Customer A (Step 3.2).
Step 3.1Bank C forwards the UnableToApply message to Customer A. It originally received the payment instruction with reference 200505219887234.
The following UnableToApply message is sent by Bank C to Customer A:XML Instance
<camt.026.001.01><Assgnmt>
<Id>UTA1030123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-05-24T09:10:31</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1030123456789</AssgnrInstrId><AssgneInstrId>200505219887234</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>
</Undrlyg><Justfn>
<AnyInf>true</AnyInf></Justfn>
</camt.026.001.01>
Step 3.2Bank C informs Bank M of the case assignment to Customer A.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 206
The following NotificationOfCaseAssignment message is sent by Bank C to Bank M:XML Instance
<camt.030.001.01><Hdr>
<Id>INF10301123456789</Id><Fr>CCCCGB2L</Fr><To>MMMMGB2L</To><CreDtTm>2005-05-24T09:22:44</CreDtTm>
</Hdr><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Assgnmt>
<Id>UTA10301123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T09:10:31</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3.3Upon receipt of the message from Bank C , Bank M forwards the case assignment information to Customer B, for information. The following NotificationOfCaseAssignment message is sent by Bank M to Customer B: XML Instance
<camt.030.001.01><Hdr>
<Id>INFCABBBB050523001</Id><Fr>MMMMGB2L</Fr><To>BBBBGB2L</To><CreDtTm>2005-05-24T09:25:12</CreDtTm>
</Hdr><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Assgnmt>
<Id>UTA10301123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T09:10:31</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 207
Step 4Upon receipt of the message from Bank C, Customer A looks up the original payment instruction. The payment instruction was not intended for Customer B and should be cancelled. Customer A initiates a cancellation request for the payment instruction to Bank C (Step 4.1). Bank C forwards the RequestToCancelPayment message to Bank M (Step 4.2). Bank M requests the debit authorisation from Customer B (Step 4.3).
Step 4.1Customer A requests the cancellation of the payment instruction.
The following RequestToCancelPayment message is sent by Customer A to Bank C:XML Instance
<camt.008.002.01><Assgnmt>
<Id>UTACANC10301123456789</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T11:19:23</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>200505219887234</AssgnrInstrId><AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 4.2Bank C forwards the RequestToCancelPayment message to Bank M.
The following RequestToCancelPayment message is sent by Bank C to Bank M:XML Instance
<camt.008.002.01><Assgnmt>
<Id>CANC10301123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:22:59</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 208
<AssgnrInstrId>1030123456789</AssgnrInstrId><AssgneInstrId>20050523-04217-018</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>
</Undrlyg><Justfn>
<CxlRsn>UPAY</CxlRsn></Justfn>
</camt.008.002.01>
Step 4.3Bank M requests the debit authorisation from Customer B.
The following DebitAuthorisationRequest message is sent by Bank M to Customer B:XML Instance
<camt.037.001.01><Assgnmt>
<Id>DARCOMPAY12345050523001</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>BBBBGB2L</Assgne><CreDtTm>2005-05-24T11:30:06</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgneInstrId>COMPAY12345050523001</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>
</Undrlyg><Dtl>
<CxlRsn>UPAY</CxlRsn><AmtToDbt Ccy = "GBP">52317.48</AmtToDbt>
</Dtl></camt.037.001.01>
Step 5Customer B accepts the debit request and informs Bank M (Step 5.1). Bank M will return the funds (under reference 00134789) via Bank C to Customer A (this step is not illustrated here). Bank M informs Bank C about the resolution of the investigation (Step 5.2). Bank C informs Customer A about the successful resolution of investigation (Step 5.3). The case is closed.
Step 5.1 Customer B accepts the debit request. The following DebitAuthorisationResponse message is sent by Customer B to Bank M:XML Instance
<camt.036.001.01><Assgnmt>
<Id>REPDARCOMPAY12345050523001</Id><Assgnr>BBBBGB2L</Assgnr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 209
<Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:45:06</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Conf>
<DbtAuthstn>true</DbtAuthstn></Conf>
</camt.036.001.01>
Step 5.2Bank M informs Bank C of the positive debit authorisation received from Customer B.
The following ResolutionOfInvestigation message is sent by Bank M to Bank C:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFCANC10301123456789</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T11:53:07</CreDtTm>
</Assgnmt><RslvdCase>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf></Sts>
</camt.029.001.01>
Step 5.3 Bank C informs Customer A of the successful resolution of the case.
The following ResolutionOfInvestigation message is sent by Bank C to Customer A:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFCANC10301123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-05-24T11:58:13</CreDtTm>
</Assgnmt><RslvdCase>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</RslvdCase><Sts>
<Conf>ACDA</Conf>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 210
</Sts></camt.029.001.01>
Scenario 2, resulting in an AdditionalPaymentInformation message The initial steps of this scenario (Steps 1, 2 and 3) replicate those described in scenario 1 above. Therefore the description of this scenario starts at Step 4, when Customer A provides additional payment information for Customer B to reconcile the payment entry.
Step 4Customer A provides additional payment information to Bank C in response to the UnabletoApply message. The payment has been made based on an invoice in euro, but paid in GBP, and the initiator of the invoice is the French subsidiary of Customer B.
The following AdditionalPaymentInformation message is sent by Bank A to Bank C:XML Instance
<camt.028.001.01><Assgnmt>
<Id>UTAINFO10301123456789</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T11:25:32</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>200505219887234</AssgnrInstrId><AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>
</Undrlyg><Inf>
<RmtChc><Ustrd>/INV/20050301/</Ustrd>
</RmtChc><Amt>
<InstdAmt Ccy = "EUR">75680.35</InstdAmt></Amt><Cdtr>
<Nm>Customer B</Nm><Id>
<OrgId><EANGLN>7265658971233</EANGLN>
</OrgId></Id>
</Cdtr></Inf>
</camt.028.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 211
Step 5 Bank C forwards the AdditionalPaymentInformation message to Bank M (Step 5.1) for further transmission to Customer B (Step 5.2). The additional information allows Customer B to reconcile the entry. The case is closed.
Step 5.1Bank C sends the additional payment information to Bank M.
The following AdditionalPaymentInformation message is sent by Bank C to Bank M:XML Instance
<camt.028.001.01><Assgnmt>
<Id>UTABBBB050523001INFO</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:27:54</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>200505219887234</AssgnrInstrId><AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>
</Undrlyg><Inf>
<RmtChc><Ustrd>/INV/20050301/</Ustrd>
</RmtChc><Amt>
<InstdAmt Ccy = "EUR">75680.35</InstdAmt></Amt><Cdtr>
<Nm>Customer B</Nm><Id>
<OrgId><EANGLN>7265658971233</EANGLN>
</OrgId></Id>
</Cdtr></Inf>
</camt.028.001.01>
Step 5.2Bank M forwards the AdditionalPaymentInformation message to Customer B. The reconciliation is successful and the case is closed.
The following AdditionalPaymentInformation message is sent by Bank M to Customer B:XML Instance
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 212
<camt.028.001.01><Assgnmt>
<Id>REPUTACOMPAY12345050523001</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>BBBBGB2L</Assgne><CreDtTm>2005-05-24T11:45:04</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>200505219887234</AssgnrInstrId><AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>
</Undrlyg><Inf>
<RmtChc><Ustrd>/INV/20050301/</Ustrd>
</RmtChc><Amt>
<InstdAmt Ccy = "EUR">75680.35</InstdAmt></Amt><Cdtr>
<Nm>Customer B</Nm><Id>
<OrgId><EANGLN>7265658971233</EANGLN>
</OrgId></Id>
</Cdtr></Inf>
</camt.028.001.01>
Scenario 3, resulting in a RequestForModification messageThe initial steps of this scenario (Steps 1, 2 and 3) replicate those described in scenario 1 above. Therefore, the description of this scenario starts at Step 4, when Customer A requests the modification of the payment instruction to Bank C.
Step 4Customer A decides to request the modification of the original payment instruction. The original payment instruction did not contain the remittance information which referenced the invoices settled by the payment. The remittance information should have referenced two commercial invoices: /INV/20050512/GBP23257./20050500104712//20050513/29060.48/20050100204712/Customer A requests the modification of the payment instruction (Step 4.1). Bank C forwards the modification request to Bank M (Step 4.2).
Step 4.1 The following RequestToModifyPayment message is sent by Customer A to Bank C:XML Instance
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 213
<camt.007.002.01><Assgnmt>
<Id>UTAMODI10301123456789</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T11:25:32</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<RmtInf><Ustrd>/INV/20050512/GBP23257./20050500104712//20050513/29060.48/20050100204712/</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 4.2Bank C forwards the request for modification to Bank M.
The following RequestToModifyPayment message is sent by Bank C to Bank M:XML Instance
<camt.007.002.01><Assgnmt>
<Id>UTAMODI10301123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:29:44</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<RmtInf><Ustrd>/INV/20050512/GBP23257./20050500104712//20050513/29060.48/20050100204712/</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 214
Step 5Upon receipt of the RequestToModifyPayment message, Bank M looks up the original payment instruction. There is no impact on the accounting entries made for this payment instruction and it has been correctly executed. Bank M forwards the request for modification to Customer B.
The following RequestToModifyPayment message is sent by Bank M to Customer B:XML Instance
<camt.007.002.01><Assgnmt>
<Id>MODICOMPAY12345050523001</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>BBBBGB2L</Assgne><CreDtTm>2005-05-24T11:35:42</CreDtTm>
</Assgnmt><Case>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</Case><Undrlyg>
<AssgneInstrId>COMPAY12345050523001</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>
</Undrlyg><Mod>
<RmtInf><Ustrd>/INV/20050512/GBP23257./20050500104712//20050513/29060.48/20050100204712/</Ustrd>
</RmtInf></Mod>
</camt.007.002.01>
Step 6The RequestToModifyPayment message received by Customer B allows reconciliation with its accounts receivables. Customer B closes the case and informs Bank M of the case resolution (Step 6.1). Bank M informs Bank C about the case resolution (Step 6.2). Bank C then informs Customer A of the case resolution (Step 6.3).
Step 6.1 Customer B informs Bank M of the resolution of the case.
The following ResolutionOfInvestigation message is sent by Customer B to Bank M:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFMODICOMPAY1234505052301</Id><Assgnr>BBBBGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:58:13</CreDtTm>
</Assgnmt><RslvdCase>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</RslvdCase>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 215
<Sts><Conf>MODI</Conf>
</Sts></camt.029.001.01>
Step 6.2Bank M informs Bank C of the resolution of the case.
The following ResolutionOfInvestigation message is sent by Bank M to Bank C:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFUTAMODI10301123456789</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T12:34:22</CreDtTm>
</Assgnmt><RslvdCase>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Step 6.3Bank B informs Bank C of the resolution of the case.
The following ResolutionOfInvestigation message is sent by Bank B to Bank C:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CONFUTAMODI10301123456789</Id><Assgnr>BBBBGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T12:43:58</CreDtTm>
</Assgnmt><RslvdCase>
<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>
</RslvdCase><Sts>
<Conf>MODI</Conf></Sts>
</camt.029.001.01>
Scenario 4The following illustrates the fourth scenario for the UnableToApply workflow. This scenario corresponds to a missing instruction case, ie, an agent has received a cover payment (MT 202) which cannot be reconciled with a pending instruction
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 216
to process (eg, an MT 103). The resolution of the investigation below relies upon the first agent issuing the missing payment instruction (eg, MT 103). The issuance of the payment instruction is not illustrated as it is outside the scope of the Exceptions and Investigations messages workflow.
NarrativeBank B, Munich (BBBBDEMM) receives the following statement line from its euro clearing institution (Bank D, Frankfurt DDDDDEFF).
Characteristics of the statement entry are as follows:
Description Value
Value Date 050116
Debit/Credit Mark C (Credit)
Amount 12439.57 EUR
Transaction Type Identification Code S202 (SWIFT Message Type 202)
Reference for the account owner 1239876540123 (this corresponds to the content of field 21 of the MT 202 instruction)
Account Servicing Institution's Reference 2005011602312003
Step 1 Bank B investigates the entry and cannot reconcile based on the elements attached to the entry. Bank B decides to request clarification to its account servicing institution (Bank D) using an UnableToApply message.
The following UnableToApply message is sent by Bank B to Bank D:XML Instance
<camt.026.001.01><Assgnmt>
<Id>UTA1239876540123050116</Id><Assgnr>BBBBDEMM</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-01-16T08:35:30</CreDtTm>
</Assgnmt><Case>
<Id>1239876540123050116001</Id><Cretr>BBBBDEMM</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>1239876540123</AssgnrInstrId><AssgneInstrId>2005011602312003</AssgneInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>
</Undrlyg><Justfn>
<AnyInf>true</AnyInf></Justfn>
</camt.026.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 217
Step 2Bank D looks up the original MT 202 instruction. The sender was Bank U, New York (UUUUUS33). The MT 202 contained reference 123458760501 (equivalent of field 20 of the MT 202). Bank D forwards the UnableToApply message to Bank U (Step 2.1) and informs Bank B of the case assignment to Bank U (Step 2.2).
Step 2.1Bank D forwards the UnableToApply to Bank U.
The following UnableToApply message is sent by Bank D to Bank U:XML Instance
<camt.026.001.01><Assgnmt>
<Id>UTA1239876540123050116</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>UUUUUS33</Assgne><CreDtTm>2005-01-16T08:44:23</CreDtTm>
</Assgnmt><Case>
<Id>1239876540123050116001</Id><Cretr>BBBBDEMM</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>2005011602312003</AssgnrInstrId><AssgneInstrId>123458760501</AssgneInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>
</Undrlyg><Justfn>
<AnyInf>true</AnyInf></Justfn>
</camt.026.001.01>
Step 2.2Bank D informs Bank B of the case assignment to Bank U.
The following NotificationOfCaseAssignment message is sent by Bank D to Bank B:XML Instance
<camt.030.001.01><Hdr>
<Id>REPUTA1239876540123050116</Id><Fr>DDDDDEFF</Fr><To>BBBBDEMM</To><CreDtTm>2005-01-16T08:48:30</CreDtTm>
</Hdr><Case>
<Id>1239876540123050116001</Id><Cretr>BBBBDEMM</Cretr>
</Case><Assgnmt>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 218
<Id>UTA1239876540123050116</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>UUUUUS33</Assgne><CreDtTm>2005-01-16T08:44:23</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3Bank U received the MT 202 instruction from Bank Z, New York (ZZZZUS33). The transfer was correctly executed. Bank U forwards the UnableToApply message to Bank Z for further information (Step 3.1). Bank U also informs Bank D that the case has been forwarded (Step 3.2). Bank D informs Bank B of the case assignment to Bank Z (Step 3.3).
Step 3.1Bank U asks Bank Z to investigate.
The following UnableToApply message is sent by Bank U to Bank Z:XML Instance
<camt.026.001.01><Assgnmt>
<Id>FWUTA1239876540123050116</Id><Assgnr>UUUUUS33</Assgnr><Assgne>ZZZZUS33</Assgne><CreDtTm>2005-01-16T09:02:45</CreDtTm>
</Assgnmt><Case>
<Id>1239876540123050116001</Id><Cretr>BBBBDEMM</Cretr>
</Case><Undrlyg>
<AssgnrInstrId>123458760501</AssgnrInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>
</Undrlyg><Justfn>
<AnyInf>true</AnyInf></Justfn>
</camt.026.001.01>
Step 3.2Bank U informs Bank D of the case assignment to Bank Z.
The following NotificationOfCaseAssignment message is sent by Bank U to Bank D:XML Instance
<camt.030.001.01><Hdr>
<Id>INFOUTA1239876540123050116</Id><Fr>UUUUUS33</Fr><To>DDDDDEFF</To>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 219
<CreDtTm>2005-01-16T09:05:43</CreDtTm></Hdr><Case>
<Id>1239876540123050116001</Id><Cretr>BBBBDEMM</Cretr>
</Case><Assgnmt>
<Id>FWUTA1239876540123050116</Id><Assgnr>UUUUUS33</Assgnr><Assgne>ZZZZUS33</Assgne><CreDtTm>2005-01-16T09:02:45</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
Step 3.3 Bank D informs Bank B of the case assignment to Bank Z.
The following NotificationOfCaseAssignment message is sent by Bank D to Bank B:XML Instance
<camt.030.001.01><Hdr>
<Id>FUREPUTA1239876540123050116</Id><Fr>DDDDDEFF</Fr><To>BBBBDEMM</To><CreDtTm>2005-01-16T09:13:23</CreDtTm>
</Hdr><Case>
<Id>1239876540123050116001</Id><Cretr>BBBBDEMM</Cretr>
</Case><Assgnmt>
<Id>FWUTA1239876540123050116</Id><Assgnr>UUUUUS33</Assgnr><Assgne>ZZZZUS33</Assgne><CreDtTm>2005-01-16T09:02:45</CreDtTm>
</Assgnmt><Ntfctn>
<Justfn>FTHI</Justfn></Ntfctn>
</camt.030.001.01>
Step 4Bank Z looks up the original MT 202. The message was sent as a cover to an MT 103 instruction. However, while reconciling the MT 103 instruction, it appears that it had been rejected. The reason code for rejection was beneficiary's account number missing. In the meantime, the payment instruction has been issued again under reference CORR1239876540123. The new payment instruction requests a back valuation (the value date is equivalent to the original value date).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 220
Bank Z informs Bank U that the case can be closed (Step 4.1) and indicates the new reference for the corrected transaction. Bank U informs Bank D (Step 4.2). Bank D informs Bank B (Step 4.3) that the investigation has been resolved.
Step 4.1Bank Z informs Bank U that the case can be closed.
The following ResolutionOfInvestigation message is sent by Bank Z to Bank U:XML Instance
<camt.029.001.01><Assgnmt>
<Id>ENDFWUTA1239876540123050116</Id><Assgnr>ZZZZUS33</Assgnr><Assgne>UUUUUS33</Assgne><CreDtTm>2005-01-16T11:03:48</CreDtTm>
</Assgnmt><RslvdCase>
<Id>1239876540123050116001</Id><Cretr>DDDDDEMM</Cretr>
</RslvdCase><Sts>
<Conf>IPYI</Conf></Sts><CrrctnTx>
<AssgnrInstrId>CORR1239876540123</AssgnrInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>
</CrrctnTx></camt.029.001.01>
Step 4.2Bank U forwards the information to Bank D.
The following ResolutionOfInvestigation message is sent by Bank U to Bank D:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSEUTA1239876540123050116</Id><Assgnr>UUUUUS33</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-01-16T11:25:46</CreDtTm>
</Assgnmt><RslvdCase>
<Id>1239876540123050116001</Id><Cretr>DDDDDEMM</Cretr>
</RslvdCase><Sts>
<Conf>IPYI</Conf></Sts><CrrctnTx>
<AssgnrInstrId>CORR1239876540123</AssgnrInstrId>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 221
<CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>
</CrrctnTx></camt.029.001.01>
Step 4.3Bank D forwards the resolution of investigation information to Bank B.
The following ResolutionOfInvestigation message is sent by Bank D to Bank B:XML Instance
<camt.029.001.01><Assgnmt>
<Id>CLOSEUTA1239876540123050116</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>BBBBDEMM</Assgne><CreDtTm>2005-01-16T11:34:26</CreDtTm>
</Assgnmt><RslvdCase>
<Id>1239876540123050116001</Id><Cretr>BBBBDEMM</Cretr>
</RslvdCase><Sts>
<Conf>IPYI</Conf></Sts><CrrctnTx>
<AssgnrInstrId>CORR1239876540123</AssgnrInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>
</CrrctnTx></camt.029.001.01>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message: UnableToApply <camt.026.001.01>
Page 222
Message Item TypesData TypesData Types Index
1 Amount1.1 CurrencyAndAmount1.2 ImpliedCurrencyAndAmount
2 Date Time2.1 ISODate2.2 ISODateTime
3 Identifier3.1 AnyBICIdentifier3.2 AustrianBankleitzahlIdentifier3.3 BBANIdentifier3.4 BEIIdentifier3.5 BICIdentifier3.6 CHIPSParticipantIdentifier3.7 CHIPSUniversalIdentifier3.8 CanadianPaymentsARNIdentifier3.9 CountryCode3.10 CurrencyCode3.11 DunsIdentifier3.12 EANGLNIdentifier3.13 ExtensiveBranchNetworkIdentifier3.14 FedwireRoutingNumberIdentifier3.15 GermanBankleitzahlIdentifier3.16 HongKongBankIdentifier3.17 IBANIdentifier3.18 IrishNSCIdentifier3.19 ItalianDomesticIdentifier3.20 LanguageCode3.21 MICIdentifier3.22 NationalityCode3.23 NewZealandNCCIdentifier3.24 PortugueseNCCIdentifier3.25 RussianCentralBankIdentificationCodeIdentifier3.26 SmallNetworkIdentifier3.27 SouthAfricanNCCIdentifier3.28 SpanishDomesticInterbankingIdentifier3.29 SwissBCIdentifier3.30 SwissSICIdentifier3.31 UKDomesticSortCodeIdentifier3.32 UPICIdentifier
4 Quantity: Number and Decimal Number4.1 Number
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 223
5 Rate5.1 PercentageRate
6 Text6.1 Max10Text6.2 Max128Text6.3 Max140Text6.4 Max16Text6.5 Max256Text6.6 Max350Text6.7 Max35Text6.8 Max70Text
Data Types Description
1 Amount
1.1 CurrencyAndAmount
Definition: Number of monetary units specified in a currency, where the unit of currency is explicit and compliant with ISO 4217. The decimal separator is a dot.Note: A zero amount is considered a positive amount.
XML Attribute: Currency (Ccy). This XML Attribute is typed by CurrencyCode.Format: CurrencyAndAmount
fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}
Rule(s): CurrencyCodeValidationByTable
Example: 100000 (Ccy='EUR')
1.2 ImpliedCurrencyAndAmount
Definition: Number of monetary units specified in a currency where the unit of currency is implied by the context and compliant with ISO 4217. The decimal separator is a dot.Note: a zero amount is considered a positive amount.
Format: fractionDigits: 5minInclusive: 0totalDigits: 18
Example: 500000
2 Date Time
2.1 ISODate
Definition: Date within a particular calendar year represented by YYYY-MM-DD (ISO 8601).
Example: 2002-02-25
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 224
2.2 ISODateTime
Definition: Date and time within a particular calendar year represented by YYYY-MM-DDThh :mm :ss (ISO 8601).
Example: 2002-07-21T08:35:30
3 Identifier
3.1 AnyBICIdentifier
Definition: A code allocated to a business entity or to a financial institution by a Registration Authority under an international identification scheme, as described in the latest edition of the international standard ISO 9362 "Banking - Banking telecommunication messages - Bank identifier codes".
Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}
Rule(s): AnyBICRule Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: CHASUS33
3.2 AustrianBankleitzahlIdentifier
Definition: Austrian Bankleitzahl. Identifies Austrian financial institutions on the Austrian national clearing system.
Format: AT[0-9]{5,5}
Example: AT12345
3.3 BBANIdentifier
Definition: Basic Bank Account Number (BBAN). Identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), which uniquely identifies the account of a customer.
Format: [a-zA-Z0-9]{1,30}
Example: BARC12345612345678
3.4 BEIIdentifier
Definition: Business Entity Identifier. Code allocated to non-financial institutions by the ISO 9362 Registration Authority. The Business Entity Identifier (BEI) has the same format as the BIC code (8 up to 11 characters) as stipulated in the standard ISO 9362 Banking (Banking Telecommunication Messages, Bank Identifier Codes, BIC).
Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}
Rule(s): BEI Only Business Entity Identifiers registered with the ISO 9362 Registration Authority and consisting of 8 or 11 contiguous characters comprising the first three or all four of the
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 225
following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE, are valid BEIs.
Example: USINFRPP
3.5 BICIdentifier
Definition: Bank Identifier Code. code allocated to a financial institution by a Registration Authority under an international identification scheme, as described in the latest edition of the international standard ISO 9362 "Banking - Banking telecommunication messages - Bank identifier codes".
Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}
Rule(s): BIC Valid BICs are registered with the ISO 9362 Registration Authority, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
Example: CHASUS33
3.6 CHIPSParticipantIdentifier
Definition: (United States) Clearing House Interbank Payment System (CHIPS) Participant Identifier (ID). Identifies financial institutions participating on CHIPS. The CHIPS Participant ID is assigned by the New York Clearing House.
Format: CP[0-9]{4,4}
Example: CP1234
3.7 CHIPSUniversalIdentifier
Definition: (United States) Clearing House Interbank Payments System (CHIPS) Universal Identification (UID). Identifies entities that own accounts at CHIPS participating financial institutions, through which CHIPS payments are effected. The CHIPS UID is assigned by the New York Clearing House.
Format: CH[0-9]{6,6}
Example: CH123456
3.8 CanadianPaymentsARNIdentifier
Definition: Canadian Payments Association Routing Number. Identifies Canadian financial institutions on the Canadian national clearing system.
Format: CA[0-9]{9,9}
Example: CA123456789
3.9 CountryCode
Definition: Code to identify a country, a dependency, or another area of particular geopolitical interest, on the basis of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 226
Format: [A-Z]{2,2}
Rule(s): Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
Example: BE
3.10 CurrencyCode
Definition: Code allocated to a currency, by a maintenance agency, under an international identification scheme as described in the latest edition of the international standard ISO 4217 "Codes for the representation of currencies and funds". Valid currency codes are registered with the ISO 4217 Maintenance Agency, and consist of three contiguous letters.
Format: [A-Z]{3,3}
Rule(s): ValidationByTable
Example: AWG
3.11 DunsIdentifier
Definition: Data Universal Numbering System. A unique identification number provided by Dun & Bradstreet to identify an organization.
Format: [0-9]{9,9}
Example: 578942538
3.12 EANGLNIdentifier
Definition: Global Location Number. A non-significant reference number used to identify legal entities, functional entities or physical entities according to the European Association for Numbering (EAN) numbering scheme rules. The number is used to retrieve the detailed information linked to it.
Format: [0-9]{13,13}
Example: 7265658971233
3.13 ExtensiveBranchNetworkIdentifier
Definition: The extensive branch network list of the Australian Bank State Branch (BSB) Code. The codes are used for identifying Australian financial institutions, as assigned by the Australian Payments Clearing Association (APCA).
Format: AU[0-9]{6,6}
Example: AU123456
3.14 FedwireRoutingNumberIdentifier
Definition: Fedwire Routing Number. Identifies financial institutions, in the US, on the FedWire system. The routing number is assigned by the American Bankers Association (ABA).
Format: FW[0-9]{9,9}
Example: FW123456789
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 227
3.15 GermanBankleitzahlIdentifier
Definition: German Bankleitzahl. Identifies German financial institutions on the German national clearing systems.
Format: BL[0-9]{8,8}
Example: BL12345678
3.16 HongKongBankIdentifier
Definition: Hong Kong Bank Code. Identifies Hong Kong financial institutions on the Hong Kong local clearing system.
Format: HK[0-9]{3,3}
Example: HK123
3.17 IBANIdentifier
Definition: An identifier used internationally by financial institutions to uniquely identify the account of a customer at a financial institution, as described in the latest edition of the international standard ISO 13616. "Banking and related financial services - International Bank Account Number (IBAN)".
Format: [a-zA-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}
Rule(s): IBAN A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.
Example: AT611904300234573201
3.18 IrishNSCIdentifier
Definition: Irish National Sorting Code. Identifies Irish financial institutions on the Irish national clearing system.
Format: IE[0-9]{6,6}
Example: IE123456
3.19 ItalianDomesticIdentifier
Definition: Italian Domestic Identification Code. Identifies Italian financial institutions on the Italian national clearing system. The code is assigned by the Associazione Bancaria Italiana (ABI).
Format: IT[0-9]{10,10}
Example: IT1234567890
3.20 LanguageCode
Definition: Specifies a language.
Rule(s): ValidationByTable
Example: ENG
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 228
3.21 MICIdentifier
Definition: Market Identifier Code. The identification of a financial market, as stipulated in the norm ISO 10383 'Codes for exchanges and market identifications'.
Format: [A-Z0-9]{4,4}
Example: XTKS
3.22 NationalityCode
Definition: Specifies the country where a person was born or is naturalised.
Rule(s): ValidationByTable
Example: US
3.23 NewZealandNCCIdentifier
Definition: New Zealand Bank/Branch Code. Identifies New Zealand institutions on the New Zealand national clearing system. The code is assigned by the New Zealand Bankers' Association (NZBA).
Format: NZ[0-9]{6,6}
Example: NZ123456
3.24 PortugueseNCCIdentifier
Definition: Portuguese National Clearing Code. Identifies Portuguese financial institutions on the Portuguese national clearing system.
Format: PT[0-9]{8,8}
Example: PT12345678
3.25 RussianCentralBankIdentificationCodeIdentifier
Definition: Russian Central Bank Identification Code. Identifies Russian financial institutions on the Russian national clearing system.
Format: RU[0-9]{9,9}
Example: RU123456789
3.26 SmallNetworkIdentifier
Definition: The small network list of the Australian Bank State Branch (BSB) Code. The codes are used for identifying Australian financial institutions, as assigned by the Australian Payments Clearing Association (APCA).
Format: AU[0-9]{6,6}
Example: AU123456
3.27 SouthAfricanNCCIdentifier
Definition: South African National Clearing Code (NCC). Identifies South African financial institutions on the South African national clearing system. The code is assigned by the South African Bankers Services Company Ltd. (BankServ).
Format: ZA[0-9]{6,6}
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 229
Example: ZA123456
3.28 SpanishDomesticInterbankingIdentifier
Definition: Spanish Domestic Interbanking Code. Identifies Spanish financial institutions on the Spanish national clearing system. The code is assigned by the Centro de Cooperacion Interbancaria (CCI).
Format: ES[0-9]{8,9}
Example: ES12345678
3.29 SwissBCIdentifier
Definition: Swiss Bank Code. Identifies Swiss institutions on the Swiss national clearing system.
Format: SW[0-9]{3,5}
Example: SW123
3.30 SwissSICIdentifier
Definition: Swiss Interbank Clearing (SIC) Code. Identifies Swiss financial institutions domestically, on the Swiss national clearing system.
Format: SW[0-9]{6,6}
Example: SW123456
3.31 UKDomesticSortCodeIdentifier
Definition: United Kingdom (UK) Sort Code. Identifies British financial institutions on the British national clearing systems. The sort code is assigned by the Association for Payments and Clearing Services (APACS).
Format: SC[0-9]{6,6}
Example: SC123456
3.32 UPICIdentifier
Definition: Universal Payment Identification Code (UPIC). Identifier used by the New York Clearing House to mask confidential data, such as bank accounts and bank routing numbers. UPIC numbers remain with business customers, regardless of banking relationship changes.
Format: [0-9]{8,17}
Example: 12345678
4 Quantity: Number and Decimal Number
4.1 Number
Definition: Number of objects represented as an integer.
Format: fractionDigits: 0totalDigits: 18
Example: 123456789012345678
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 230
5 Rate
5.1 PercentageRate
Definition: Rate expressed as a percentage, ie, in hundredths, eg, 0.7 is 7/10 of a percent, and 7.0 is 7%.
Format: fractionDigits: 10totalDigits: 11
Example: 35
6 Text
6.1 Max10Text
Definition: Specifies a character string with a maximum length of 10 characters.
Format: maxLength: 10minLength: 1
Example: AZERTGFDXC
6.2 Max128Text
Definition: Specifies a character string with a maximum length of 128 characters.
Format: maxLength: 128minLength: 1
Example: A string value of maximum 128 characters.
6.3 Max140Text
Definition: Specifies a character string with a maximum length of 140 characters.
Format: maxLength: 140minLength: 1
Example: ABCDEFGHIJKLMNOPQRST123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
6.4 Max16Text
Definition: Specifies a character string with a maximum length of 16 characters.
Format: maxLength: 16minLength: 1
Example: ABCdEFghIJKLMNO?
6.5 Max256Text
Definition: Specifies a character string with a maximum length of 256 characters.
Format: maxLength: 256minLength: 1
Example: ABCDEFGHIJKLMNOPQRST123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 231
6.6 Max350Text
Definition: Specifies a character string with a maximum length of 350 characters.
Format: maxLength: 350minLength: 1
Example: 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
6.7 Max35Text
Definition: Specifies a character string with a maximum length of 35 characters.
Format: maxLength: 35minLength: 1
Example: ABCDEFGHIJKLMNOPQRST123456789012345
6.8 Max70Text
Definition: Specifies a character string with a maximum length of 70characters.
Format: maxLength: 70minLength: 1
Example: A string value of maximum 70 characters.
End PointsEnd Points Index
1 Account identification1.1 CashAccount3
2 Financial institution identification2.1 BranchAndFinancialInstitutionIdentification
3 Party identification3.1 Intermediary13.2 PartyIdentification1
End Points Description
1 Account identification
1.1 CashAccount3CashAccount3 is used in message AdditionalPaymentInformation p.30, p.30, p.30, message RequestToModifyPayment p.156, p.156, p.156.
Definition: Information used for identifying an account.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 232
Type: The following CashAccount3 element(s) must be used:
Ref Or Message Item <XML Tag> Mult. Represent./Type
1.1.0 Identification <Id> [1..1]
1.1.1 {Or IBAN <IBAN> [1..1] Identifier
1.1.2 Or BBAN <BBAN> [1..1] Identifier
1.1.3 Or UPIC <UPIC> [1..1] Identifier
1.1.4 Or} DomesticAccount <DmstAcct> [1..1]
1.1.5 Identification <Id> [1..1] Text
1.1.6 Type <Tp> [0 ..1] Code
1.1.7 Currency <Ccy> [0..1] Code
1.1.8 Name <Nm> [0..1] Text
1.1.0 Identification <Id>Presence: [1..1]Definition: Unique and unambiguous identification of the account between the account owner and the account servicer.Type: This message item is composed of one of the following AccountIdentification1Choice element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
1.1.1 {Or IBAN <IBAN> [1..1] Identifier
1.1.2 Or BBAN <BBAN> [1..1] Identifier
1.1.3 Or UPIC <UPIC> [1..1] Identifier
1.1.4 Or} DomesticAccount <DmstAcct> [1..1]
1.1.1 IBAN <IBAN>Presence: [1..1]This message item is part of choice 1.1.0 Identification.Definition: International Bank Account Number (IBAN) - identifier used internationally by financial institutions to
uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 "Banking and related financial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions.
Data Type: IBANIdentifierFormat: [a-zA-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}Rule(s): IBAN
A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.
1.1.2 BBAN <BBAN>Presence: [1..1]This message item is part of choice 1.1.0 Identification.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 233
Definition: Basic Bank Account Number (BBAN) - identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), to uniquely identify the account of a customer.
Data Type: BBANIdentifierFormat: [a-zA-Z0-9]{1,30}
1.1.3 UPIC <UPIC>Presence: [1..1]This message item is part of choice 1.1.0 Identification.Definition: Universal Payment Identification Code (UPIC) - identifier used by the New York Clearing House to mask
confidential data, such as bank accounts and bank routing numbers. UPIC numbers remain with business customers, regardless of banking relationship changes.
Data Type: UPICIdentifierFormat: [0-9]{8,17}
1.1.4 DomesticAccount <DmstAcct>Presence: [1..1]This message item is part of choice 1.1.0 Identification.Definition: Account number used by financial institutions in individual countries to identify an account of a customer,
but not necessarily the bank and branch of the financial institution in which the account is held.Type: This message item is composed of the following SimpleIdentificationInformation element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
1.1.5 Identification <Id> [1..1] Text
1.1.5 Identification <Id>Presence: [1..1]Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
1.1.6 Type <Tp>Presence: [0 ..1]Definition: Nature, or use, of the account.Data Type: CodeWhen this message item is present, one of the following CashAccountType3Code values must be used:
Code Name DefinitionCACC Current Account used to post debits and credits when no specific
account has been nominated.
CASH CashPayment Account used for the payment of cash.
CHAR Charges Account used for charges if different from the account for payment.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 234
Code Name DefinitionSACC Settlement Account used to post debit and credit entries, as a result of
transactions cleared and settled through a specific clearing and settlement system.
SVGS Savings Account used for savings.
1.1.7 Currency <Ccy>Presence: [0..1]Definition: Identification of the currency in which the debtor's account is held.
Usage: Currency should only be used in case one and the same debtor's account number covers several currencies and the initiating party needs to identify which currency needs to be used for settlement on the account.
Data Type: CurrencyCodeFormat: [A-Z]{3,3}Rule(s): ValidationByTable
1.1.8 Name <Nm>Presence: [0..1]Definition: Name of the account, assigned by the account servicing institution in agreement with the account owner in
order to provide an additional means of identification of the account.
Usage : the account name is different from the account owner name. The account name is used in certain user communities to provide a means of identifying the account, in addition to the account owner's identity and the account number.
Data Type: Max70TextFormat: maxLength: 70
minLength: 1
2 Financial institution identification
2.1 BranchAndFinancialInstitutionIdentificationBranchAndFinancialInstitutionIdentification is used in message AdditionalPaymentInformation p.30, p.30, p.30, p.30, message RequestToModifyPayment p.156, p.156.
Definition: Organisation established primarily to provide financial services.Type: The following BranchAndFinancialInstitutionIdentification element(s) must be used:
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.0 FinancialInstitutionIdentification <FinInstnId> [1..1]
2.1.1 BIC <BIC> [0..1] Identifier
2.1.2 ClearingSystemMemberIdentification <ClrSysMmbId> [0..1]
2.1.3 {Or CHIPSUniversalIdentification <USCHU> [1..1] Identifier
2.1.4 Or NewZealandNCCIdentification <NZNCC> [1..1] Identifier
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 235
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.5 Or IrishNSCIdentification <IENSC> [1..1] Identifier
2.1.6 Or UKDomesticSortCode <GBSC> [1..1] Identifier
2.1.7 Or CHIPSParticipantIdentification <USCH> [1..1] Identifier
2.1.8 Or SwissBCIdentification <CHBC> [1..1] Identifier
2.1.9 Or FedwireRoutingNumberIdentification <USFW> [1..1] Identifier
2.1.10 Or PortugueseNCCIdentification <PTNCC> [1..1] Identifier
2.1.11 Or RussianCentralBankIdentificationCode <RUCB> [1..1] Identifier
2.1.12 Or ItalianDomesticIdentificationCode <ITNCC> [1..1] Identifier
2.1.13 Or AustrianBankleitzahlIdentification <ATBLZ> [1..1] Identifier
2.1.14 Or CanadianPaymentsAssociationRoutingNumberIdentification
<CACPA> [1..1] Identifier
2.1.15 Or SwissSICIdentification <CHSIC> [1..1] Identifier
2.1.16 Or GermanBankleitzahlIdentification <DEBLZ> [1..1] Identifier
2.1.17 Or SpanishDomesticInterbankingIdentification
<ESNCC> [1..1] Identifier
2.1.18 Or SouthAfricanNCCIdentification <ZANCC> [1..1] Identifier
2.1.19 Or HongKongBankCode <HKNCC> [1..1] Identifier
2.1.20 Or AustralianExtensiveBranchNetworkIdentification
<AUBSBx> [1..1] Identifier
2.1.21 Or} AustralianSmallNetworkIdentification <AUBSBs> [1..1] Identifier
2.1.22 Name <Nm> [0..1] Text
2.1.23 PostalAddress <PstlAdr> [0..1]
2.1.24 AddressType <AdrTp> [0..1] Code
2.1.25 AddressLine <AdrLine> [0..5] Text
2.1.26 StreetName <StrtNm> [0..1] Text
2.1.27 BuildingNumber <BldgNb> [0..1] Text
2.1.28 PostCode <PstCd> [0..1] Text
2.1.29 TownName <TwnNm> [0..1] Text
2.1.30 CountrySubDivision <CtrySubDvsn> [0..1] Text
2.1.31 Country <Ctry> [1..1] Code
2.1.32 ProprietaryIdentification <PrtryId> [0..1]
2.1.33 Identification <Id> [1..1] Text
2.1.34 Issuer <Issr> [0..1] Text
2.1.35 BranchIdentification <BrnchId> [0..1]
2.1.36 Identification <Id> [0..1] Text
2.1.37 Name <Nm> [0..1] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 236
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.38 PostalAddress <PstlAdr> [0..1]
2.1.39 AddressType <AdrTp> [0..1] Code
2.1.40 AddressLine <AdrLine> [0..5] Text
2.1.41 StreetName <StrtNm> [0..1] Text
2.1.42 BuildingNumber <BldgNb> [0..1] Text
2.1.43 PostCode <PstCd> [0..1] Text
2.1.44 TownName <TwnNm> [0..1] Text
2.1.45 CountrySubDivision <CtrySubDvsn> [0..1] Text
2.1.46 Country <Ctry> [1..1] Code
2.1.0 FinancialInstitutionIdentification <FinInstnId>Presence: [1..1]Definition: Unique and unambiguous identifier of a financial institution, as assigned under an internationally recognised
or proprietary identification scheme.Type: This message item is composed of the following FinancialInstitutionIdentification1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.1 BIC <BIC> [0..1] Identifier
2.1.2 ClearingSystemMemberIdentification <ClrSysMmbId> [0..1]
2.1.22 Name <Nm> [0..1] Text
2.1.23 PostalAddress <PstlAdr> [0..1]
2.1.32 ProprietaryIdentification <PrtryId> [0..1]
2.1.1 BIC <BIC>Presence: [0..1]Definition: Bank Identifier Code. Code allocated to financial institutions by the Registration Authority, under an
international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier Codes).
Data Type: BICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): BIC
Valid BICs are registered with the ISO 9362 Registration Authority, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
2.1.2 ClearingSystemMemberIdentification <ClrSysMmbId>Presence: [0..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 237
Definition: Unique and unambiguous identifier of a clearing system member, as assigned by the system or system administrator.
Type: This message item is composed of one of the following ClearingSystemMemberIdentificationChoice element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.3 {Or CHIPSUniversalIdentification <USCHU> [1..1] Identifier
2.1.4 Or NewZealandNCCIdentification <NZNCC> [1..1] Identifier
2.1.5 Or IrishNSCIdentification <IENSC> [1..1] Identifier
2.1.6 Or UKDomesticSortCode <GBSC> [1..1] Identifier
2.1.7 Or CHIPSParticipantIdentification <USCH> [1..1] Identifier
2.1.8 Or SwissBCIdentification <CHBC> [1..1] Identifier
2.1.9 Or FedwireRoutingNumberIdentification <USFW> [1..1] Identifier
2.1.10 Or PortugueseNCCIdentification <PTNCC> [1..1] Identifier
2.1.11 Or RussianCentralBankIdentificationCode <RUCB> [1..1] Identifier
2.1.12 Or ItalianDomesticIdentificationCode <ITNCC> [1..1] Identifier
2.1.13 Or AustrianBankleitzahlIdentification <ATBLZ> [1..1] Identifier
2.1.14 Or CanadianPaymentsAssociationRoutingNumberIdentification
<CACPA> [1..1] Identifier
2.1.15 Or SwissSICIdentification <CHSIC> [1..1] Identifier
2.1.16 Or GermanBankleitzahlIdentification <DEBLZ> [1..1] Identifier
2.1.17 Or SpanishDomesticInterbankingIdentification <ESNCC> [1..1] Identifier
2.1.18 Or SouthAfricanNCCIdentification <ZANCC> [1..1] Identifier
2.1.19 Or HongKongBankCode <HKNCC> [1..1] Identifier
2.1.20 Or AustralianExtensiveBranchNetworkIdentification
<AUBSBx> [1..1] Identifier
2.1.21 Or} AustralianSmallNetworkIdentification <AUBSBs> [1..1] Identifier
2.1.3 CHIPSUniversalIdentification <USCHU>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: (United States) Clearing House Interbank Payments System (CHIPS) Universal Identification (UID) -
identifies entities that own accounts at CHIPS participating financial institutions, through which CHIPS payments are effected. The CHIPS UID is assigned by the New York Clearing House.
Data Type: CHIPSUniversalIdentifierFormat: CH[0-9]{6,6}
2.1.4 NewZealandNCCIdentification <NZNCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: New Zealand Bank/Branch Code - identifies New Zealand institutions on the New Zealand national clearing
system. The code is assigned by the New Zealand Bankers' Association (NZBA).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 238
Data Type: NewZealandNCCIdentifierFormat: NZ[0-9]{6,6}
2.1.5 IrishNSCIdentification <IENSC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Irish National Sorting Code - identifies Irish financial institutions on the Irish national clearing system. The
code is assigned by the Irish Payments Services Organisation (IPSO).Data Type: IrishNSCIdentifierFormat: IE[0-9]{6,6}
2.1.6 UKDomesticSortCode <GBSC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: United Kingdom (UK) Sort Code - identifies British financial institutions on the British national clearing
systems. The sort code is assigned by the Association for Payments and Clearing Services (APACS).Data Type: UKDomesticSortCodeIdentifierFormat: SC[0-9]{6,6}
2.1.7 CHIPSParticipantIdentification <USCH>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: (United States) Clearing House Interbank Payment System (CHIPS) Participant Identifier (ID) - identifies
financial institutions participating on CHIPS. The CHIPS Participant ID is assigned by the New York Clearing House.
Data Type: CHIPSParticipantIdentifierFormat: CP[0-9]{4,4}
2.1.8 SwissBCIdentification <CHBC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Swiss Bank Code - identifies Swiss institutions on the Swiss national clearing system.Data Type: SwissBCIdentifierFormat: SW[0-9]{3,5}
2.1.9 FedwireRoutingNumberIdentification <USFW>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Fedwire Routing Number - identifies financial institutions, in the US, on the FedWire system. The routing
number is assigned by the American Bankers Association (ABA).Data Type: FedwireRoutingNumberIdentifierFormat: FW[0-9]{9,9}
2.1.10 PortugueseNCCIdentification <PTNCC>Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 239
This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Portuguese National Clearing Code - identifies Portuguese financial institutions on the Portuguese national
clearing system.Data Type: PortugueseNCCIdentifierFormat: PT[0-9]{8,8}
2.1.11 RussianCentralBankIdentificationCode <RUCB>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Russian Central Bank Identification Code - identifies Russian financial institutions on the Russian national
clearing system.Data Type: RussianCentralBankIdentificationCodeIdentifierFormat: RU[0-9]{9,9}
2.1.12 ItalianDomesticIdentificationCode <ITNCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Italian Domestic Identification Code - identifies Italian financial institutions on the Italian national clearing
system. The code is assigned by the Associazione Bancaria Italiana (ABI).Data Type: ItalianDomesticIdentifierFormat: IT[0-9]{10,10}
2.1.13 AustrianBankleitzahlIdentification <ATBLZ>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Austrian Bankleitzahl - identifies Austrian financial institutions on the Austrian national clearing system.Data Type: AustrianBankleitzahlIdentifierFormat: AT[0-9]{5,5}
2.1.14 CanadianPaymentsAssociationRoutingNumberIdentification <CACPA>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Canadian Payments Association Routing Number - identifies Canadian financial institutions on the Canadian
national clearing system.Data Type: CanadianPaymentsARNIdentifierFormat: CA[0-9]{9,9}
2.1.15 SwissSICIdentification <CHSIC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Swiss Interbank Clearing (SIC) Code - identifies Swiss financial institutions domestically, on the Swiss
national clearing system.Data Type: SwissSICIdentifierFormat: SW[0-9]{6,6}
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 240
2.1.16 GermanBankleitzahlIdentification <DEBLZ>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: German Bankleitzahl - identifies German financial institutions on the German national clearing systems.Data Type: GermanBankleitzahlIdentifierFormat: BL[0-9]{8,8}
2.1.17 SpanishDomesticInterbankingIdentification <ESNCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Spanish Domestic Interbanking Code - identifies Spanish financial institutions on the Spanish national
clearing system. The code is assigned by the Centro de Cooperacion Interbancaria (CCI).Data Type: SpanishDomesticInterbankingIdentifierFormat: ES[0-9]{8,9}
2.1.18 SouthAfricanNCCIdentification <ZANCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: South African National Clearing Code (NCC) - identifies South African financial institutions on the South
African national clearing system. The code is assigned by the South African Bankers Services Company Ltd. (BankServ).
Data Type: SouthAfricanNCCIdentifierFormat: ZA[0-9]{6,6}
2.1.19 HongKongBankCode <HKNCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Hong Kong Bank Code - identifies Hong Kong financial institutions on the Hong Kong local clearing system.Data Type: HongKongBankIdentifierFormat: HK[0-9]{3,3}
2.1.20 AustralianExtensiveBranchNetworkIdentification <AUBSBx>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Extensive branch network list of the Australian Bank State Branch (BSB) Code. The codes are used for
identifying Australian financial institutions, as assigned by the Australian Payments Clearing Association (APCA).
Data Type: ExtensiveBranchNetworkIdentifierFormat: AU[0-9]{6,6}
2.1.21 AustralianSmallNetworkIdentification <AUBSBs>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Small network list of the Australian Bank State Branch (BSB) Code. The codes are used for identifying
Australian financial institutions , as assigned by the Australian Payments Clearing Association (APCA).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 241
Data Type: SmallNetworkIdentifierFormat: AU[0-9]{6,6}
2.1.22 Name <Nm>Presence: [0..1]Definition: Name by which a party is known and which is usually used to identify that party.Data Type: Max70TextFormat: maxLength: 70
minLength: 1
2.1.23 PostalAddress <PstlAdr>Presence: [0..1]Definition: Information that locates and identifies a specific address, as defined by postal services.Type: This message item is composed of the following PostalAddress1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.24 AddressType <AdrTp> [0..1] Code
2.1.25 AddressLine <AdrLine> [0..5] Text
2.1.26 StreetName <StrtNm> [0..1] Text
2.1.27 BuildingNumber <BldgNb> [0..1] Text
2.1.28 PostCode <PstCd> [0..1] Text
2.1.29 TownName <TwnNm> [0..1] Text
2.1.30 CountrySubDivision <CtrySubDvsn> [0..1] Text
2.1.31 Country <Ctry> [1..1] Code
2.1.24 AddressType <AdrTp>Presence: [0..1]Definition: Identifies the nature of the postal address.Data Type: CodeWhen this message item is present, one of the following AddressType2Code values must be used:
Code Name DefinitionADDR Postal Address is the complete postal address.
BIZZ Business Address is the business address.
DLVY DeliveryTo Address is the address to which delivery is to take place.
HOME Residential Address is the home address.
MLTO MailTo Address is the address to which mail is sent.
PBOX POBox Address is a postal office (PO) box.
2.1.25 AddressLine <AdrLine>Presence: [0..5]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 242
Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in free format text.
Data Type: Max70TextFormat: maxLength: 70
minLength: 1
2.1.26 StreetName <StrtNm>Presence: [0..1]Definition: Name of a street or thoroughfare.Data Type: Max70TextFormat: maxLength: 70
minLength: 1
2.1.27 BuildingNumber <BldgNb>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
2.1.28 PostCode <PstCd>Presence: [0..1]Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting
of mail.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
2.1.29 TownName <TwnNm>Presence: [0..1]Definition: Name of a built-up area, with defined boundaries, and a local government.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
2.1.30 CountrySubDivision <CtrySubDvsn>Presence: [0..1]Definition: Identifies a subdivision of a country eg, state, region, county.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
2.1.31 Country <Ctry>Presence: [1..1]Definition: Nation with its own government.Data Type: CountryCode
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 243
Format: [A-Z]{2,2}Rule(s): Country
The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
2.1.32 ProprietaryIdentification <PrtryId>Presence: [0..1]Definition: Unique and unambiguous identifier, as assigned to a financial institution using a proprietary identification
scheme.Type: This message item is composed of the following GenericIdentification3 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.33 Identification <Id> [1..1] Text
2.1.34 Issuer <Issr> [0..1] Text
2.1.33 Identification <Id>Presence: [1..1]Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
2.1.34 Issuer <Issr>Presence: [0..1]Definition: Entity that assigns the identification.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
2.1.35 BranchIdentification <BrnchId>Presence: [0..1]Definition: Information identifying a specific branch of a financial institution.
Usage : this component should be used in case the identification information in the financial institution component does not provide identification up to branch level.
Type: This message item is composed of the following BranchData element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.36 Identification <Id> [0..1] Text
2.1.37 Name <Nm> [0..1] Text
2.1.38 PostalAddress <PstlAdr> [0..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 244
2.1.36 Identification <Id>Presence: [0..1]Definition: Unique and unambiguous identification of a branch of a financial institution.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
2.1.37 Name <Nm>Presence: [0..1]Definition: Name by which a party is known and which is usually used to identify that party.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
2.1.38 PostalAddress <PstlAdr>Presence: [0..1]Definition: Information that locates and identifies a specific address, as defined by postal services.Type: This message item is composed of the following PostalAddress1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
2.1.39 AddressType <AdrTp> [0..1] Code
2.1.40 AddressLine <AdrLine> [0..5] Text
2.1.41 StreetName <StrtNm> [0..1] Text
2.1.42 BuildingNumber <BldgNb> [0..1] Text
2.1.43 PostCode <PstCd> [0..1] Text
2.1.44 TownName <TwnNm> [0..1] Text
2.1.45 CountrySubDivision <CtrySubDvsn> [0..1] Text
2.1.46 Country <Ctry> [1..1] Code
2.1.39 AddressType <AdrTp>Presence: [0..1]Definition: Identifies the nature of the postal address.Data Type: CodeWhen this message item is present, one of the following AddressType2Code values must be used:
Code Name DefinitionADDR Postal Address is the complete postal address.
BIZZ Business Address is the business address.
DLVY DeliveryTo Address is the address to which delivery is to take place.
HOME Residential Address is the home address.
MLTO MailTo Address is the address to which mail is sent.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 245
Code Name DefinitionPBOX POBox Address is a postal office (PO) box.
2.1.40 AddressLine <AdrLine>Presence: [0..5]Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in
free format text.Data Type: Max70TextFormat: maxLength: 70
minLength: 1
2.1.41 StreetName <StrtNm>Presence: [0..1]Definition: Name of a street or thoroughfare.Data Type: Max70TextFormat: maxLength: 70
minLength: 1
2.1.42 BuildingNumber <BldgNb>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
2.1.43 PostCode <PstCd>Presence: [0..1]Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting
of mail.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
2.1.44 TownName <TwnNm>Presence: [0..1]Definition: Name of a built-up area, with defined boundaries, and a local government.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
2.1.45 CountrySubDivision <CtrySubDvsn>Presence: [0..1]Definition: Identifies a subdivision of a country eg, state, region, county.Data Type: Max35Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 246
Format: maxLength: 35minLength: 1
2.1.46 Country <Ctry>Presence: [1..1]Definition: Nation with its own government.Data Type: CountryCodeFormat: [A-Z]{2,2}Rule(s): Country
The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3 Party identification
3.1 Intermediary1Intermediary1 is used in message AdditionalPaymentInformation p.30.
Definition: Organised structure that is set up for a particular purpose, eg, a business, government body, department, charity, or financial institution.
Type: The following Intermediary1 element(s) must be used:
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.0 Identification <Id> [1..1]
3.1.1 {Or BICOrBEI <BICOrBEI> [1..1] Identifier
3.1.2 Or ProprietaryIdentification <PrtryId> [1..1]
3.1.3 Identification <Id> [1..1] Text
3.1.4 SchemeName <SchmeNm> [0..1] Text
3.1.5 Issuer <Issr> [0..1] Text
3.1.6 Or} NameAndAddress <NmAndAdr> [1..1]
3.1.7 Name <Nm> [1..1] Text
3.1.8 Address <Adr> [0..1]
3.1.9 {{Or Unstructured <Ustrd> [1..1] Text
3.1.10 Or}} Structured <Strd> [1..1]
3.1.11 BuildingName <BldgNm> [0..1] Text
3.1.12 StreetName <StrtNm> [0..1] Text
3.1.13 StreetBuildingIdentification <StrtBldgId> [0..1] Text
3.1.14 Floor <Flr> [0..1] Text
3.1.15 TownName <TwnNm> [1..1] Text
3.1.16 DistrictName <DstrctNm> [0..1] Text
3.1.17 RegionIdentification <RgnId> [0..1] Text
3.1.18 State <Stat> [0..1] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 247
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.19 CountyIdentification <CtyId> [0..1] Text
3.1.20 Country <Ctry> [1..1] Code
3.1.21 PostCodeIdentification <PstCdId> [1..1] Text
3.1.22 PostOfficeBox <POB> [0..1] Text
3.1.23 Account <Acct> [0..1]
3.1.24 Identification <Id> [0..1]
3.1.25 Proprietary <Prtry> [1..1]
3.1.26 Identification <Id> [1..1] Text
3.1.27 AccountServicer <AcctSvcr> [1..1]
3.1.28 {Or BICOrBEI <BICOrBEI> [1..1] Identifier
3.1.29 Or ProprietaryIdentification <PrtryId> [1..1]
3.1.30 Identification <Id> [1..1] Text
3.1.31 SchemeName <SchmeNm> [0..1] Text
3.1.32 Issuer <Issr> [0..1] Text
3.1.33 Or} NameAndAddress <NmAndAdr> [1..1]
3.1.34 Name <Nm> [1..1] Text
3.1.35 Address <Adr> [0..1]
3.1.36 {{Or Unstructured <Ustrd> [1..1] Text
3.1.37 Or}} Structured <Strd> [1..1]
3.1.38 BuildingName <BldgNm> [0..1] Text
3.1.39 StreetName <StrtNm> [0..1] Text
3.1.40 StreetBuildingIdentification <StrtBldgId> [0..1] Text
3.1.41 Floor <Flr> [0..1] Text
3.1.42 TownName <TwnNm> [1..1] Text
3.1.43 DistrictName <DstrctNm> [0..1] Text
3.1.44 RegionIdentification <RgnId> [0..1] Text
3.1.45 State <Stat> [0..1] Text
3.1.46 CountyIdentification <CtyId> [0..1] Text
3.1.47 Country <Ctry> [1..1] Code
3.1.48 PostCodeIdentification <PstCdId> [1..1] Text
3.1.49 PostOfficeBox <POB> [0..1] Text
3.1.50 Role <Role> [0..1] Text
3.1.0 Identification <Id>Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 248
Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution, eg, Dun & Bradstreet Identification.
Type: This message item is composed of one of the following PartyIdentification1Choice element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.1 {Or BICOrBEI <BICOrBEI> [1..1] Identifier
3.1.2 Or ProprietaryIdentification <PrtryId> [1..1]
3.1.6 Or} NameAndAddress <NmAndAdr> [1..1]
3.1.1 BICOrBEI <BICOrBEI>Presence: [1..1]This message item is part of choice 3.1.0 Identification.Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution, eg, Dun & Bradstreet
Identification.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
3.1.2 ProprietaryIdentification <PrtryId>Presence: [1..1]This message item is part of choice 3.1.0 Identification.Definition: Unique and unambiguous identifier, as assigned to a financial institution using a proprietary identification
scheme.Type: This message item is composed of the following GenericIdentification1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.3 Identification <Id> [1..1] Text
3.1.4 SchemeName <SchmeNm> [0..1] Text
3.1.5 Issuer <Issr> [0..1] Text
3.1.3 Identification <Id>Presence: [1..1]Definition: Identification assigned by an institution.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.4 SchemeName <SchmeNm>Presence: [0..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 249
Definition: Name of the identification scheme, eg, "UK National Insurance Number".Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.5 Issuer <Issr>Presence: [0..1]Definition: Entity that assigns the identification.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.6 NameAndAddress <NmAndAdr>Presence: [1..1]This message item is part of choice 3.1.0 Identification.Definition: Name by which a party is known and which is usually used to identify that party.Type: This message item is composed of the following NameAndAddress2 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.7 Name <Nm> [1..1] Text
3.1.8 Address <Adr> [0..1]
3.1.7 Name <Nm>Presence: [1..1]Definition: Name by which a party is known and which is usually used to identify that party.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.8 Address <Adr>Presence: [0..1]Definition: Information that locates and identifies a specific address, as defined by postal services.Type: This message item is composed of one of the following LongPostalAddress1Choice element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.9 {Or Unstructured <Ustrd> [1..1] Text
3.1.10 Or} Structured <Strd> [1..1]
3.1.9 Unstructured <Ustrd>Presence: [1..1]This message item is part of choice 3.1.8 Address.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 250
Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in free format text.
Data Type: Max140TextFormat: maxLength: 140
minLength: 1
3.1.10 Structured <Strd>Presence: [1..1]This message item is part of choice 3.1.8 Address.Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in
a formal structure.Type: This message item is composed of the following StructuredLongPostalAddress1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.11 BuildingName <BldgNm> [0..1] Text
3.1.12 StreetName <StrtNm> [0..1] Text
3.1.13 StreetBuildingIdentification <StrtBldgId> [0..1] Text
3.1.14 Floor <Flr> [0..1] Text
3.1.15 TownName <TwnNm> [1..1] Text
3.1.16 DistrictName <DstrctNm> [0..1] Text
3.1.17 RegionIdentification <RgnId> [0..1] Text
3.1.18 State <Stat> [0..1] Text
3.1.19 CountyIdentification <CtyId> [0..1] Text
3.1.20 Country <Ctry> [1..1] Code
3.1.21 PostCodeIdentification <PstCdId> [1..1] Text
3.1.22 PostOfficeBox <POB> [0..1] Text
Rule(s): StreetNameAndOrPostOfficeBoxRule If StreetName is not present, then PostOfficeBox is mandatory. If StreetName is present, then PostOfficeBox is optional.
3.1.11 BuildingName <BldgNm>Presence: [0..1]Definition: Name of the building or house.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.12 StreetName <StrtNm>Presence: [0..1]Definition: Name of a street or thoroughfare.Data Type: Max35TextFormat: maxLength: 35
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 251
minLength: 1
3.1.13 StreetBuildingIdentification <StrtBldgId>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.14 Floor <Flr>Presence: [0..1]Definition: Floor or storey within a building.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
3.1.15 TownName <TwnNm>Presence: [1..1]Definition: Name of a built-up area, with defined boundaries, and a local government.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.16 DistrictName <DstrctNm>Presence: [0..1]Definition: Name of a district, ie, a part of a town or region.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.17 RegionIdentification <RgnId>Presence: [0..1]Definition: Identification of an administrative division of a country, state, or territory.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.18 State <Stat>Presence: [0..1]Definition: Organised political community or area forming a part of a federation.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 252
3.1.19 CountyIdentification <CtyId>Presence: [0..1]Definition: Identifier of a county.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.20 Country <Ctry>Presence: [1..1]Definition: Nation with its own government.Data Type: CountryCodeFormat: [A-Z]{2,2}Rule(s): Country
The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.1.21 PostCodeIdentification <PstCdId>Presence: [1..1]Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting
of mail.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
3.1.22 PostOfficeBox <POB>Presence: [0..1]Definition: Numbered box in a post office, assigned to a person or organisation, where letters are kept until called for.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
3.1.23 Account <Acct>Presence: [0..1]Definition: Business relationship between two entities; one entity is the account owner, the other entity is the account
servicer.Type: This message item is composed of the following Account1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.24 Identification <Id> [0..1]
3.1.27 AccountServicer <AcctSvcr> [1..1]
3.1.24 Identification <Id>Presence: [0..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 253
Definition: Unique and unambiguous identification for the account between the account owner and the account servicer.Type: This message item is composed of the following AccountIdentification1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.25 Proprietary <Prtry> [1..1]
3.1.25 Proprietary <Prtry>Presence: [1..1]Definition: Unique identifier for an account. It is assigned by the account servicer using a proprietary identification
scheme.Type: This message item is composed of the following SimpleIdentificationInformation element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.26 Identification <Id> [1..1] Text
3.1.26 Identification <Id>Presence: [1..1]Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.27 AccountServicer <AcctSvcr>Presence: [1..1]Definition: Institution servicing an account and assigning the account identifier to the account owner.Type: This message item is composed of one of the following PartyIdentification1Choice element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.28 {Or BICOrBEI <BICOrBEI> [1..1] Identifier
3.1.29 Or ProprietaryIdentification <PrtryId> [1..1]
3.1.33 Or} NameAndAddress <NmAndAdr> [1..1]
3.1.28 BICOrBEI <BICOrBEI>Presence: [1..1]This message item is part of choice 3.1.27 AccountServicer.Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution, eg, Dun & Bradstreet
Identification.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 254
Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.
3.1.29 ProprietaryIdentification <PrtryId>Presence: [1..1]This message item is part of choice 3.1.27 AccountServicer.Definition: Unique and unambiguous identifier, as assigned to a financial institution using a proprietary identification
scheme.Type: This message item is composed of the following GenericIdentification1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.30 Identification <Id> [1..1] Text
3.1.31 SchemeName <SchmeNm> [0..1] Text
3.1.32 Issuer <Issr> [0..1] Text
3.1.30 Identification <Id>Presence: [1..1]Definition: Identification assigned by an institution.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.31 SchemeName <SchmeNm>Presence: [0..1]Definition: Name of the identification scheme, eg, "UK National Insurance Number".Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.32 Issuer <Issr>Presence: [0..1]Definition: Entity that assigns the identification.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.33 NameAndAddress <NmAndAdr>Presence: [1..1]This message item is part of choice 3.1.27 AccountServicer.Definition: Name by which a party is known and which is usually used to identify that party.Type: This message item is composed of the following NameAndAddress2 element(s):
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 255
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.34 Name <Nm> [1..1] Text
3.1.35 Address <Adr> [0..1]
3.1.34 Name <Nm>Presence: [1..1]Definition: Name by which a party is known and which is usually used to identify that party.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.35 Address <Adr>Presence: [0..1]Definition: Information that locates and identifies a specific address, as defined by postal services.Type: This message item is composed of one of the following LongPostalAddress1Choice element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.36 {Or Unstructured <Ustrd> [1..1] Text
3.1.37 Or} Structured <Strd> [1..1]
3.1.36 Unstructured <Ustrd>Presence: [1..1]This message item is part of choice 3.1.35 Address.Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in
free format text.Data Type: Max140TextFormat: maxLength: 140
minLength: 1
3.1.37 Structured <Strd>Presence: [1..1]This message item is part of choice 3.1.35 Address.Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in
a formal structure.Type: This message item is composed of the following StructuredLongPostalAddress1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.38 BuildingName <BldgNm> [0..1] Text
3.1.39 StreetName <StrtNm> [0..1] Text
3.1.40 StreetBuildingIdentification <StrtBldgId> [0..1] Text
3.1.41 Floor <Flr> [0..1] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 256
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.1.42 TownName <TwnNm> [1..1] Text
3.1.43 DistrictName <DstrctNm> [0..1] Text
3.1.44 RegionIdentification <RgnId> [0..1] Text
3.1.45 State <Stat> [0..1] Text
3.1.46 CountyIdentification <CtyId> [0..1] Text
3.1.47 Country <Ctry> [1..1] Code
3.1.48 PostCodeIdentification <PstCdId> [1..1] Text
3.1.49 PostOfficeBox <POB> [0..1] Text
Rule(s): StreetNameAndOrPostOfficeBoxRule If StreetName is not present, then PostOfficeBox is mandatory. If StreetName is present, then PostOfficeBox is optional.
3.1.38 BuildingName <BldgNm>Presence: [0..1]Definition: Name of the building or house.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.39 StreetName <StrtNm>Presence: [0..1]Definition: Name of a street or thoroughfare.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.40 StreetBuildingIdentification <StrtBldgId>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.41 Floor <Flr>Presence: [0..1]Definition: Floor or storey within a building.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 257
3.1.42 TownName <TwnNm>Presence: [1..1]Definition: Name of a built-up area, with defined boundaries, and a local government.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.43 DistrictName <DstrctNm>Presence: [0..1]Definition: Name of a district, ie, a part of a town or region.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.44 RegionIdentification <RgnId>Presence: [0..1]Definition: Identification of an administrative division of a country, state, or territory.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.45 State <Stat>Presence: [0..1]Definition: Organised political community or area forming a part of a federation.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.46 CountyIdentification <CtyId>Presence: [0..1]Definition: Identifier of a county.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.1.47 Country <Ctry>Presence: [1..1]Definition: Nation with its own government.Data Type: CountryCodeFormat: [A-Z]{2,2}Rule(s): Country
The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 258
3.1.48 PostCodeIdentification <PstCdId>Presence: [1..1]Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting
of mail.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
3.1.49 PostOfficeBox <POB>Presence: [0..1]Definition: Numbered box in a post office, assigned to a person or organisation, where letters are kept until called for.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
3.1.50 Role <Role>Presence: [0..1]Definition: Set of functions performed by an intermediary in a given situation.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2 PartyIdentification1PartyIdentification1 is used in message AdditionalPaymentInformation p.30, p.30, p.30, p.30, message RequestToModifyPayment p.156, p.156, p.156, p.156.
Definition: Entity involved in an activity.Type: The following PartyIdentification1 element(s) must be used:
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.0 Name <Nm> [0..1] Text
3.2.1 PostalAddress <PstlAdr> [0..1]
3.2.2 AddressType <AdrTp> [0..1] Code
3.2.3 AddressLine <AdrLine> [0..5] Text
3.2.4 StreetName <StrtNm> [0..1] Text
3.2.5 BuildingNumber <BldgNb> [0..1] Text
3.2.6 PostCode <PstCd> [0..1] Text
3.2.7 TownName <TwnNm> [0..1] Text
3.2.8 CountrySubDivision <CtrySubDvsn> [0..1] Text
3.2.9 Country <Ctry> [1..1] Code
3.2.10 Identification <Id> [0..1]
3.2.11 {Or OrganisationIdentification <OrgId> [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 259
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.12 BEI <BEI> [0..1] Identifier
3.2.13 EANGLN <EANGLN> [0..1] Identifier
3.2.14 CHIPSUniversalIdentification <USCHU> [0..1] Identifier
3.2.15 DUNS <DUNS> [0..1] Identifier
3.2.16 BankPartyIdentification <BkPtyId> [0..1] Text
3.2.17 TaxIdentificationNumber <TaxIdNb> [0..1] Text
3.2.18 ProprietaryIdentification <PrtryId> [0..1]
3.2.19 Identification <Id> [1..1] Text
3.2.20 Issuer <Issr> [0..1] Text
3.2.21 Or} PrivateIdentification <PrvtId> [1..2]
3.2.22 {{Or DriversLicenseNumber <DrvrsLicNb> [1..1] Text
3.2.23 Or SocialSecurityNumber <SclSctyNb> [1..1] Text
3.2.24 Or AlienRegistrationNumber <AlnRegnNb> [1..1] Text
3.2.25 Or PassportNumber <PsptNb> [1..1] Text
3.2.26 Or TaxIdentificationNumber <TaxIdNb> [1..1] Text
3.2.27 Or IdentityCardNumber <IdntyCardNb> [1..1] Text
3.2.28 Or EmployerIdentificationNumber <MplyrIdNb> [1..1] Text
3.2.29 Or}} OtherIdentification <OthrId> [1..1]
3.2.30 Identification <Id> [1..1] Text
3.2.31 IdentificationType <IdTp> [1..1] Text
3.2.32 Issuer <Issr> [0..1] Text
3.2.0 Name <Nm>Presence: [0..1]Definition: Name by which a party is known and which is usually used to identify that party.Data Type: Max70TextFormat: maxLength: 70
minLength: 1
3.2.1 PostalAddress <PstlAdr>Presence: [0..1]Definition: Postal address of a party.Type: This message item is composed of the following PostalAddress1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.2 AddressType <AdrTp> [0..1] Code
3.2.3 AddressLine <AdrLine> [0..5] Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 260
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.4 StreetName <StrtNm> [0..1] Text
3.2.5 BuildingNumber <BldgNb> [0..1] Text
3.2.6 PostCode <PstCd> [0..1] Text
3.2.7 TownName <TwnNm> [0..1] Text
3.2.8 CountrySubDivision <CtrySubDvsn> [0..1] Text
3.2.9 Country <Ctry> [1..1] Code
3.2.2 AddressType <AdrTp>Presence: [0..1]Definition: Identifies the nature of the postal address.Data Type: CodeWhen this message item is present, one of the following AddressType2Code values must be used:
Code Name DefinitionADDR Postal Address is the complete postal address.
BIZZ Business Address is the business address.
DLVY DeliveryTo Address is the address to which delivery is to take place.
HOME Residential Address is the home address.
MLTO MailTo Address is the address to which mail is sent.
PBOX POBox Address is a postal office (PO) box.
3.2.3 AddressLine <AdrLine>Presence: [0..5]Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in
free format text.Data Type: Max70TextFormat: maxLength: 70
minLength: 1
3.2.4 StreetName <StrtNm>Presence: [0..1]Definition: Name of a street or thoroughfare.Data Type: Max70TextFormat: maxLength: 70
minLength: 1
3.2.5 BuildingNumber <BldgNb>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max16Text
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 261
Format: maxLength: 16minLength: 1
3.2.6 PostCode <PstCd>Presence: [0..1]Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting
of mail.Data Type: Max16TextFormat: maxLength: 16
minLength: 1
3.2.7 TownName <TwnNm>Presence: [0..1]Definition: Name of a built-up area, with defined boundaries, and a local government.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.8 CountrySubDivision <CtrySubDvsn>Presence: [0..1]Definition: Identifies a subdivision of a country eg, state, region, county.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.9 Country <Ctry>Presence: [1..1]Definition: Nation with its own government.Data Type: CountryCodeFormat: [A-Z]{2,2}Rule(s): Country
The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
3.2.10 Identification <Id>Presence: [0..1]Definition: Unique and unambiguous identification of a party.Type: This message item is composed of one of the following Party1Choice element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.11 {Or OrganisationIdentification <OrgId> [1..1]
3.2.21 Or} PrivateIdentification <PrvtId> [1..2]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 262
3.2.11 OrganisationIdentification <OrgId>Presence: [1..1]This message item is part of choice 3.2.10 Identification.Definition: Unique and unambiguous way of identifying an organisation.Type: This message item is composed of the following NonFinancialInstitutionIdentification1 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.12 BEI <BEI> [0..1] Identifier
3.2.13 EANGLN <EANGLN> [0..1] Identifier
3.2.14 CHIPSUniversalIdentification <USCHU> [0..1] Identifier
3.2.15 DUNS <DUNS> [0..1] Identifier
3.2.16 BankPartyIdentification <BkPtyId> [0..1] Text
3.2.17 TaxIdentificationNumber <TaxIdNb> [0..1] Text
3.2.18 ProprietaryIdentification <PrtryId> [0..1]
3.2.12 BEI <BEI>Presence: [0..1]Definition: Business Entity Identifier. Code allocated to non-financial institutions by the ISO 9362 Registration
Authority. The Business Entity Identifier (BEI) has the same format as the BIC code (8 up to 11 characters) as stipulated in the standard ISO 9362 Banking (Banking Telecommunication Messages, Bank Identifier Codes, BIC).
Data Type: BEIIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): BEI
Only Business Entity Identifiers registered with the ISO 9362 Registration Authority and consisting of 8 or 11 contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE, are valid BEIs.
3.2.13 EANGLN <EANGLN>Presence: [0..1]Definition: Global Location Number. A non-significant reference number used to identify legal entities, functional
entities or physical entities according to the European Association for Numbering (EAN) numbering scheme rules. The number is used to retrieve detailed information linked to it.
Data Type: EANGLNIdentifierFormat: [0-9]{13,13}
3.2.14 CHIPSUniversalIdentification <USCHU>Presence: [0..1]Definition: (United States) Clearing House Interbank Payments System (CHIPS) Universal Identification (UID) -
identifies entities that own accounts at CHIPS participating financial institutions, through which CHIPS payments are effected. The CHIPS UID is assigned by the New York Clearing House.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 263
Data Type: CHIPSUniversalIdentifierFormat: CH[0-9]{6,6}
3.2.15 DUNS <DUNS>Presence: [0..1]Definition: Data Universal Numbering System. A unique identification number provided by Dun & Bradstreet to identify
an organization.Data Type: DunsIdentifierFormat: [0-9]{9,9}
3.2.16 BankPartyIdentification <BkPtyId>Presence: [0..1]Definition: Unique and unambiguous assignment made by a specific bank to identify a relationship as defined between
the bank and its client.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.17 TaxIdentificationNumber <TaxIdNb>Presence: [0..1]Definition: Number assigned by a tax authority to an entity.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.18 ProprietaryIdentification <PrtryId>Presence: [0..1]Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution.Type: This message item is composed of the following GenericIdentification3 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.19 Identification <Id> [1..1] Text
3.2.20 Issuer <Issr> [0..1] Text
3.2.19 Identification <Id>Presence: [1..1]Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.20 Issuer <Issr>Presence: [0..1]Definition: Entity that assigns the identification.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 264
Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.21 PrivateIdentification <PrvtId>Presence: [1..2]This message item is part of choice 3.2.10 Identification.Definition: Unique and unambiguous identification of a person, eg, passport.Type: This message item is composed of the following PersonIdentification2 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.22 {Or DriversLicenseNumber <DrvrsLicNb> [1..1] Text
3.2.23 Or SocialSecurityNumber <SclSctyNb> [1..1] Text
3.2.24 Or AlienRegistrationNumber <AlnRegnNb> [1..1] Text
3.2.25 Or PassportNumber <PsptNb> [1..1] Text
3.2.26 Or TaxIdentificationNumber <TaxIdNb> [1..1] Text
3.2.27 Or IdentityCardNumber <IdntyCardNb> [1..1] Text
3.2.28 Or EmployerIdentificationNumber <MplyrIdNb> [1..1] Text
3.2.29 Or} OtherIdentification <OthrId> [1..1]
3.2.32 Issuer <Issr> [0..1] Text
3.2.22 DriversLicenseNumber <DrvrsLicNb>Synonym(s): :95S::ALTE//DRLC (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a license authority to a driver's license.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.23 SocialSecurityNumber <SclSctyNb>Synonym(s): :95S::ALTE//SSNX (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a social security agency.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.24 AlienRegistrationNumber <AlnRegnNb>Synonym(s): :95S::ALTE//ARNU (ISO 15022)Presence: [1..1]
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 265
This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a government agency to identify foreign nationals.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.25 PassportNumber <PsptNb>Synonym(s): :95S::ALTE//CCPT (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a passport authority to a passport.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.26 TaxIdentificationNumber <TaxIdNb>Synonym(s): :95S::ALTE//TXID (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a tax authority to an entity.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.27 IdentityCardNumber <IdntyCardNb>Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a national authority to an identity card.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.28 EmployerIdentificationNumber <MplyrIdNb>Synonym(s): :95S::ALTE//EINX (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned to an employer by a registration authority.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.29 OtherIdentification <OthrId>Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Identifier issued to a person for which no specific identifier has been defined.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 266
Type: This message item is composed of the following GenericIdentification4 element(s):
Ref Or Message Item <XML Tag> Mult. Represent./Type
3.2.30 Identification <Id> [1..1] Text
3.2.31 IdentificationType <IdTp> [1..1] Text
3.2.30 Identification <Id>Presence: [1..1]Definition: Identifier issued to a person for which no specific identifier has been defined.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.31 IdentificationType <IdTp>Presence: [1..1]Definition: Specifies the nature of the identifier.
Usage: IdentificationType is used to specify what kind of identifier is used. It should be used in case the identifier is different from the identifiers listed in the pre-defined identifier list.
Data Type: Max35TextFormat: maxLength: 35
minLength: 1
3.2.32 Issuer <Issr>Presence: [0..1]Definition: Entity that assigns the identifier.Data Type: Max35TextFormat: maxLength: 35
minLength: 1
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Message Item Types
Page 267
IndexesIndex of Message ItemsAAccount: <Acct>
248
AccountServicer: <AcctSvcr>248
Address: <Adr>247, 248
AddressLine: <AdrLine>236, 237, 259
AddressType: <AdrTp>236, 237, 259
AlienRegistrationNumber: <AlnRegnNb>260
Amount: <Amt>Message AdditionalPaymentInformation 30, 30
AmountToDebit: <AmtToDbt>Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141
AnyInformation: <AnyInf>Message UnableToApply 198
Assignee: <Assgne>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
AssigneeInstructionIdentification: <AssgneInstrId>Message AdditionalPaymentInformation 29
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 268
Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198
Assigner: <Assgnr>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
AssignerInstructionIdentification: <AssgnrInstrId>Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198
Assignment: <Assgnmt>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
AssignmentCancellationConfirmation: <AssgnmtCxlConf>Message ResolutionOfInvestigation 186
AustralianExtensiveBranchNetworkIdentification: <AUBSBx>236
AustralianSmallNetworkIdentification: <AUBSBs>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 269
236
AustrianBankleitzahlIdentification: <ATBLZ>236
BBankOperationCode: <BkOprCd>
Message RequestToModifyPayment 155
BankPartyIdentification: <BkPtyId>260
BBAN: <BBAN>233
BEI: <BEI>260
BeneficiaryInstitutionAccount: <BnfcryInstnAcct>Message RequestToModifyPayment 156
BIC: <BIC>235
BICOrBEI: <BICOrBEI>247, 248
BranchIdentification: <BrnchId>236
BuildingName: <BldgNm>247, 248
BuildingNumber: <BldgNb>236, 237, 259
CCanadianPaymentsAssociationRoutingNumberIdentification: <CACPA>
236
CancellationReason: <CxlRsn>Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141
Case: <Case>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 270
Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message UnableToApply 197
CaseStatus: <CaseSts>Message CaseStatusReport 59
CHIPSParticipantIdentification: <USCH>236
CHIPSUniversalIdentification: <USCHU>235, 260
ClearingSystemMemberIdentification: <ClrSysMmbId>235
Code: <Cd>Message RequestToModifyPayment 156, 156, 156
Confirmation: <Conf>Message DebitAuthorisationResponse 105Message ResolutionOfInvestigation 186
CorrectionTransaction: <CrrctnTx>Message ResolutionOfInvestigation 187
Country: <Ctry>236, 237, 248, 248, 259
CountrySubDivision: <CtrySubDvsn>236, 237, 259
CountyIdentification: <CtyId>248, 248
CreationDateTime: <CreDtTm>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59, 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115, 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 271
Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
Creator: <Cretr>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197
CreditNoteAmount: <CdtNoteAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
Creditor: <Cdtr>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
CreditorAccount: <CdtrAcct>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
CreditorReference: <CdtrRef>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
Currency: <Ccy>233
CurrencyAmount: <CcyAmt>Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198
CurrencyOfTransfer: <CcyOfTrf>Message AdditionalPaymentInformation 30
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 272
DDateTime: <DtTm>
Message CaseStatusReport 59
DebitAuthorisation: <DbtAuthstn>Message DebitAuthorisationResponse 105
Debtor: <Dbtr>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
DebtorAccount: <DbtrAcct>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
Detail: <Dtl>Message DebitAuthorisationRequest 94
DetailsOfCharges: <DtlsOfChrgs>Message RequestToModifyPayment 156
DiscountAppliedAmount: <DscntApldAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
DistrictName: <DstrctNm>247, 248
DocumentReferenceNumber: <DocRefNb>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
DomesticAccount: <DmstAcct>233
DriversLicenseNumber: <DrvrsLicNb>260
DuePayableAmount: <DuePyblAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
DUNS: <DUNS>260
DuplicateOf: <DplctOf>Message ResolutionOfInvestigation 186
EEANGLN: <EANGLN>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 273
260
EmployerIdentificationNumber: <MplyrIdNb>260
EquivalentAmount: <EqvtAmt>Message AdditionalPaymentInformation 30
FFedwireRoutingNumberIdentification: <USFW>
236
FinancialInstitutionIdentification: <FinInstnId>235
FirstAgent: <FrstAgt>Message AdditionalPaymentInformation 30
FirstSettlementAgent: <FrstSttlmAgt>Message AdditionalPaymentInformation 30
Floor: <Flr>247, 248
From: <Fr>Message CaseStatusReport 59Message CaseStatusReportRequest 68Message NotificationOfCaseAssignment 115
GGermanBankleitzahlIdentification: <DEBLZ>
236
HHeader: <Hdr>
Message CaseStatusReport 58Message NotificationOfCaseAssignment 115
HongKongBankCode: <HKNCC>236
IIBAN: <IBAN>
233
Identification: <Id>233, 233, 236, 236, 247, 247, 248, 248, 248, 259, 260, 260
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 274
Message AdditionalPaymentInformation 29, 29Message CancelCaseAssignment 50, 50Message CaseStatusReport 59, 59, 59Message CaseStatusReportRequest 67, 68Message ClaimNonReceipt 74, 74Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 104, 105Message NotificationOfCaseAssignment 115, 115, 115Message RejectCaseAssignment 127, 127Message RequestForDuplicateInstruction 133, 134Message RequestToCancelPayment 140, 140Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 186, 186, 186Message UnableToApply 197, 197
IdentificationType: <IdTp>260
IdentityCardNumber: <IdntyCardNb>260
IncorrectInformation: <IncrrctInf>Message UnableToApply 198
Information: <Inf>Message AdditionalPaymentInformation 29
InstructedAmount: <InstdAmt>Message AdditionalPaymentInformation 30
InstructionCode: <InstrCd>Message RequestToModifyPayment 155
InstructionForFinalAgent: <InstrForFnlAgt>Message RequestToModifyPayment 156
InterbankSettledAmount: <IntrBkSttldAmt>Message RequestToModifyPayment 156
Intermediary: <Intrmy>Message AdditionalPaymentInformation 30
IntermediarySettlementAgent: <IntrmySttlmAgt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
InvestigationStatus: <InvstgtnSts>Message CaseStatusReport 59
Invoicee: <Invcee>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 275
Invoicer: <Invcr>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
IrishNSCIdentification: <IENSC>236
Issuer: <Issr>236, 247, 248, 260, 260
ItalianDomesticIdentificationCode: <ITNCC>236
JJustification: <Justfn>
Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestToCancelPayment 141Message UnableToApply 198
LLastSettlementAgent: <LastSttlmAgt>
Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
MMissingCover: <MssngCover>
Message ClaimNonReceipt 75
MissingCoverIndication: <MssngCoverIndctn>Message ClaimNonReceipt 75
MissingInformation: <MssngInf>Message UnableToApply 198
MissingOrIncorrectInformation: <MssngOrIncrrctInf>Message UnableToApply 198
Modification: <Mod>Message RequestToModifyPayment 155
NName: <Nm>
233, 236, 236, 247, 248, 259
NameAndAddress: <NmAndAdr>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 276
247, 248
NewAssignment: <NewAssgnmt>Message CaseStatusReport 59
NewZealandNCCIdentification: <NZNCC>235
NostroVostroAccount: <NstrVstrAcct>Message AdditionalPaymentInformation 30
Notification: <Ntfctn>Message NotificationOfCaseAssignment 115
OOrganisationIdentification: <OrgId>
259
OtherIdentification: <OthrId>260
PPassportNumber: <PsptNb>
260
PaymentScheme: <PmtSchme>Message RequestToModifyPayment 156
PortugueseNCCIdentification: <PTNCC>236
PostalAddress: <PstlAdr>236, 237, 259
PostCode: <PstCd>236, 237, 259
PostCodeIdentification: <PstCdId>248, 248
PostOfficeBox: <POB>248, 248
PrivateIdentification: <PrvtId>260
Proprietary: <Prtry>248Message RequestToModifyPayment 156, 156
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 277
ProprietaryIdentification: <PrtryId>236, 247, 248, 260
ProprietaryInformation: <PrtryInf>Message RequestToModifyPayment 156
Purpose: <Purp>Message RequestToModifyPayment 156
RReason: <Rsn>
Message CaseStatusReport 59Message DebitAuthorisationResponse 105Message ResolutionOfInvestigation 186
ReasonCode: <RsnCd>Message ResolutionOfInvestigation 186
ReferredDocumentAmount: <RfrdDocAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
ReferredDocumentRelatedDate: <RfrdDocRltdDt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
ReferredDocumentType: <RfrdDocTp>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
RegionIdentification: <RgnId>247, 248
RejectedCancellation: <RjctdCxl>Message ResolutionOfInvestigation 186
RejectedModification: <RjctdMod>Message ResolutionOfInvestigation 186
RejectionReason: <RjctnRsn>Message RejectCaseAssignment 127
RelatedReference: <RltdRef>Message RequestToModifyPayment 155
RemittanceChoice: <RmtChc>Message AdditionalPaymentInformation 29
RemittanceInformation: <RmtInf>Message RequestToModifyPayment 156
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 278
RemittedAmount: <RmtdAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
ReopenCaseIndication: <ReopCaseIndctn>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197
RequestedExecutionDate: <ReqdExctnDt>Message RequestToModifyPayment 155
RequestHeader: <ReqHdr>Message CaseStatusReportRequest 67
ResolvedCase: <RslvdCase>Message ResolutionOfInvestigation 186
Role: <Role>248
RussianCentralBankIdentificationCode: <RUCB>236
SSchemeName: <SchmeNm>
247, 248
SenderToReceiverInformation: <SndrToRcvrInf>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
SocialSecurityNumber: <SclSctyNb>260
SouthAfricanNCCIdentification: <ZANCC>236
SpanishDomesticInterbankingIdentification: <ESNCC>
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 279
236
State: <Stat>247, 248
Status: <Sts>Message CaseStatusReport 59Message ResolutionOfInvestigation 186
StreetBuildingIdentification: <StrtBldgId>247, 248
StreetName: <StrtNm>236, 237, 247, 248, 259
Structured: <Strd>247, 248Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
SwissBCIdentification: <CHBC>236
SwissSICIdentification: <CHSIC>236
TTaxAmount: <TaxAmt>
Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
TaxIdentificationNumber: <TaxIdNb>260, 260
To: <To>Message CaseStatusReport 59Message CaseStatusReportRequest 68Message NotificationOfCaseAssignment 115
TownName: <TwnNm>236, 237, 247, 248, 259
Type: <Tp>233
UUKDomesticSortCode: <GBSC>
236
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 280
Underlying: <Undrlyg>Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message UnableToApply 198
Unstructured: <Ustrd>247, 248Message AdditionalPaymentInformation 29Message RequestToModifyPayment 156
UPIC: <UPIC>233
VValueDate: <ValDt>
Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 187Message UnableToApply 198
ValueDateToDebit: <ValDtToDbt>Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141
Index of XML tagsA<Acct>: Account
248
<AcctSvcr>: AccountServicer248
<Adr>: Address247, 248
<AdrLine>: AddressLine236, 237, 259
<AdrTp>: AddressType236, 237, 259
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 281
<AlnRegnNb>: AlienRegistrationNumber260
<Amt>: AmountMessage AdditionalPaymentInformation 30, 30
<AmtToDbt>: AmountToDebitMessage DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141
<AnyInf>: AnyInformationMessage UnableToApply 198
<Assgne>: AssigneeMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
<AssgneInstrId>: AssigneeInstructionIdentificationMessage AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198
<Assgnmt>: AssignmentMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 282
<AssgnmtCxlConf>: AssignmentCancellationConfirmationMessage ResolutionOfInvestigation 186
<Assgnr>: AssignerMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
<AssgnrInstrId>: AssignerInstructionIdentificationMessage AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198
<ATBLZ>: AustrianBankleitzahlIdentification236
<AUBSBs>: AustralianSmallNetworkIdentification236
<AUBSBx>: AustralianExtensiveBranchNetworkIdentification236
B<BBAN>: BBAN
233
<BEI>: BEI260
<BIC>: BIC235
<BICOrBEI>: BICOrBEI247, 248
<BkOprCd>: BankOperationCodeMessage RequestToModifyPayment 155
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 283
<BkPtyId>: BankPartyIdentification260
<BldgNb>: BuildingNumber236, 237, 259
<BldgNm>: BuildingName247, 248
<BnfcryInstnAcct>: BeneficiaryInstitutionAccountMessage RequestToModifyPayment 156
<BrnchId>: BranchIdentification236
C<CACPA>: CanadianPaymentsAssociationRoutingNumberIdentification
236
<Case>: CaseMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message UnableToApply 197
<CaseSts>: CaseStatusMessage CaseStatusReport 59
<Ccy>: Currency233
<CcyAmt>: CurrencyAmountMessage AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198
<CcyOfTrf>: CurrencyOfTransfer
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 284
Message AdditionalPaymentInformation 30
<Cd>: CodeMessage RequestToModifyPayment 156, 156, 156
<CdtNoteAmt>: CreditNoteAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<Cdtr>: CreditorMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<CdtrAcct>: CreditorAccountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<CdtrRef>: CreditorReferenceMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<CHBC>: SwissBCIdentification236
<CHSIC>: SwissSICIdentification236
<ClrSysMmbId>: ClearingSystemMemberIdentification235
<Conf>: ConfirmationMessage DebitAuthorisationResponse 105Message ResolutionOfInvestigation 186
<CreDtTm>: CreationDateTimeMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59, 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115, 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
<Cretr>: CreatorMessage AdditionalPaymentInformation 29
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 285
Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197
<CrrctnTx>: CorrectionTransactionMessage ResolutionOfInvestigation 187
<Ctry>: Country236, 237, 248, 248, 259
<CtrySubDvsn>: CountrySubDivision236, 237, 259
<CtyId>: CountyIdentification248, 248
<CxlRsn>: CancellationReasonMessage DebitAuthorisationRequest 94Message RequestToCancelPayment 141
D<DbtAuthstn>: DebitAuthorisation
Message DebitAuthorisationResponse 105
<Dbtr>: DebtorMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<DbtrAcct>: DebtorAccountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<DEBLZ>: GermanBankleitzahlIdentification236
<DmstAcct>: DomesticAccount233
<DocRefNb>: DocumentReferenceNumberMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 286
<DplctOf>: DuplicateOfMessage ResolutionOfInvestigation 186
<DrvrsLicNb>: DriversLicenseNumber260
<DscntApldAmt>: DiscountAppliedAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<DstrctNm>: DistrictName247, 248
<Dtl>: DetailMessage DebitAuthorisationRequest 94
<DtlsOfChrgs>: DetailsOfChargesMessage RequestToModifyPayment 156
<DtTm>: DateTimeMessage CaseStatusReport 59
<DuePyblAmt>: DuePayableAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<DUNS>: DUNS260
E<EANGLN>: EANGLN
260
<EqvtAmt>: EquivalentAmountMessage AdditionalPaymentInformation 30
<ESNCC>: SpanishDomesticInterbankingIdentification236
F<FinInstnId>: FinancialInstitutionIdentification
235
<Flr>: Floor247, 248
<Fr>: FromMessage CaseStatusReport 59
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 287
Message CaseStatusReportRequest 68Message NotificationOfCaseAssignment 115
<FrstAgt>: FirstAgentMessage AdditionalPaymentInformation 30
<FrstSttlmAgt>: FirstSettlementAgentMessage AdditionalPaymentInformation 30
G<GBSC>: UKDomesticSortCode
236
H<Hdr>: Header
Message CaseStatusReport 58Message NotificationOfCaseAssignment 115
<HKNCC>: HongKongBankCode236
I<IBAN>: IBAN
233
<Id>: Identification233, 233, 236, 236, 247, 247, 248, 248, 248, 259, 260, 260Message AdditionalPaymentInformation 29, 29Message CancelCaseAssignment 50, 50Message CaseStatusReport 59, 59, 59Message CaseStatusReportRequest 67, 68Message ClaimNonReceipt 74, 74Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 104, 105Message NotificationOfCaseAssignment 115, 115, 115Message RejectCaseAssignment 127, 127Message RequestForDuplicateInstruction 133, 134Message RequestToCancelPayment 140, 140Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 186, 186, 186Message UnableToApply 197, 197
<IdntyCardNb>: IdentityCardNumber260
<IdTp>: IdentificationType260
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 288
<IENSC>: IrishNSCIdentification236
<IncrrctInf>: IncorrectInformationMessage UnableToApply 198
<Inf>: InformationMessage AdditionalPaymentInformation 29
<InstdAmt>: InstructedAmountMessage AdditionalPaymentInformation 30
<InstrCd>: InstructionCodeMessage RequestToModifyPayment 155
<InstrForFnlAgt>: InstructionForFinalAgentMessage RequestToModifyPayment 156
<IntrBkSttldAmt>: InterbankSettledAmountMessage RequestToModifyPayment 156
<Intrmy>: IntermediaryMessage AdditionalPaymentInformation 30
<IntrmySttlmAgt>: IntermediarySettlementAgentMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<Invcee>: InvoiceeMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<Invcr>: InvoicerMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<InvstgtnSts>: InvestigationStatusMessage CaseStatusReport 59
<Issr>: Issuer236, 247, 248, 260, 260
<ITNCC>: ItalianDomesticIdentificationCode236
J<Justfn>: Justification
Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestToCancelPayment 141Message UnableToApply 198
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 289
L<LastSttlmAgt>: LastSettlementAgent
Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
M<Mod>: Modification
Message RequestToModifyPayment 155
<MplyrIdNb>: EmployerIdentificationNumber260
<MssngCover>: MissingCoverMessage ClaimNonReceipt 75
<MssngCoverIndctn>: MissingCoverIndicationMessage ClaimNonReceipt 75
<MssngInf>: MissingInformationMessage UnableToApply 198
<MssngOrIncrrctInf>: MissingOrIncorrectInformationMessage UnableToApply 198
N<NewAssgnmt>: NewAssignment
Message CaseStatusReport 59
<Nm>: Name233, 236, 236, 247, 248, 259
<NmAndAdr>: NameAndAddress247, 248
<NstrVstrAcct>: NostroVostroAccountMessage AdditionalPaymentInformation 30
<Ntfctn>: NotificationMessage NotificationOfCaseAssignment 115
<NZNCC>: NewZealandNCCIdentification235
O<OrgId>: OrganisationIdentification
259
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 290
<OthrId>: OtherIdentification260
P<PmtSchme>: PaymentScheme
Message RequestToModifyPayment 156
<POB>: PostOfficeBox248, 248
<Prtry>: Proprietary248Message RequestToModifyPayment 156, 156
<PrtryId>: ProprietaryIdentification236, 247, 248, 260
<PrtryInf>: ProprietaryInformationMessage RequestToModifyPayment 156
<PrvtId>: PrivateIdentification260
<PsptNb>: PassportNumber260
<PstCd>: PostCode236, 237, 259
<PstCdId>: PostCodeIdentification248, 248
<PstlAdr>: PostalAddress236, 237, 259
<PTNCC>: PortugueseNCCIdentification236
<Purp>: PurposeMessage RequestToModifyPayment 156
R<ReopCaseIndctn>: ReopenCaseIndication
Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 291
Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197
<ReqdExctnDt>: RequestedExecutionDateMessage RequestToModifyPayment 155
<ReqHdr>: RequestHeaderMessage CaseStatusReportRequest 67
<RfrdDocAmt>: ReferredDocumentAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<RfrdDocRltdDt>: ReferredDocumentRelatedDateMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<RfrdDocTp>: ReferredDocumentTypeMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<RgnId>: RegionIdentification247, 248
<RjctdCxl>: RejectedCancellationMessage ResolutionOfInvestigation 186
<RjctdMod>: RejectedModificationMessage ResolutionOfInvestigation 186
<RjctnRsn>: RejectionReasonMessage RejectCaseAssignment 127
<RltdRef>: RelatedReferenceMessage RequestToModifyPayment 155
<RmtChc>: RemittanceChoiceMessage AdditionalPaymentInformation 29
<RmtdAmt>: RemittedAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<RmtInf>: RemittanceInformationMessage RequestToModifyPayment 156
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 292
<Role>: Role248
<RslvdCase>: ResolvedCaseMessage ResolutionOfInvestigation 186
<Rsn>: ReasonMessage CaseStatusReport 59Message DebitAuthorisationResponse 105Message ResolutionOfInvestigation 186
<RsnCd>: ReasonCodeMessage ResolutionOfInvestigation 186
<RUCB>: RussianCentralBankIdentificationCode236
S<SchmeNm>: SchemeName
247, 248
<SclSctyNb>: SocialSecurityNumber260
<SndrToRcvrInf>: SenderToReceiverInformationMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<Stat>: State247, 248
<Strd>: Structured247, 248Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<StrtBldgId>: StreetBuildingIdentification247, 248
<StrtNm>: StreetName236, 237, 247, 248, 259
<Sts>: StatusMessage CaseStatusReport 59Message ResolutionOfInvestigation 186
T<TaxAmt>: TaxAmount
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 293
Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
<TaxIdNb>: TaxIdentificationNumber260, 260
<To>: ToMessage CaseStatusReport 59Message CaseStatusReportRequest 68Message NotificationOfCaseAssignment 115
<Tp>: Type233
<TwnNm>: TownName236, 237, 247, 248, 259
U<Undrlyg>: Underlying
Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message UnableToApply 198
<UPIC>: UPIC233
<USCH>: CHIPSParticipantIdentification236
<USCHU>: CHIPSUniversalIdentification235, 260
<USFW>: FedwireRoutingNumberIdentification236
<Ustrd>: Unstructured247, 248Message AdditionalPaymentInformation 29Message RequestToModifyPayment 156
V<ValDt>: ValueDate
Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 294
Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 187Message UnableToApply 198
<ValDtToDbt>: ValueDateToDebitMessage DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141
Z<ZANCC>: SouthAfricanNCCIdentification
236
Index of Message Item TypesAAccount1
248
AccountIdentification1248
AccountIdentification1Choice233
AddressType2Code236, 237, 259
AmountType1ChoiceMessage AdditionalPaymentInformation 30
AnyBICIdentifier225, 247, 248Message AdditionalPaymentInformation 29, 29, 29Message CancelCaseAssignment 50, 50, 50Message CaseStatusReport 59, 59, 59, 59, 59Message CaseStatusReportRequest 68, 68, 68Message ClaimNonReceipt 74, 74, 74Message DebitAuthorisationRequest 94, 94, 94Message DebitAuthorisationResponse 104, 104, 105Message NotificationOfCaseAssignment 115, 115, 115, 115, 115Message RejectCaseAssignment 127, 127, 127Message RequestForDuplicateInstruction 133, 133, 134Message RequestToCancelPayment 140, 140, 140Message RequestToModifyPayment 155, 155, 155Message ResolutionOfInvestigation 186, 186, 186, 186Message UnableToApply 197, 197, 197
AustrianBankleitzahlIdentifier
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 295
225, 236
BBBANIdentifier
225, 233
BEIIdentifier225, 260
BICIdentifier226, 235
BranchAndFinancialInstitutionIdentification235Message AdditionalPaymentInformation 30, 30, 30, 30Message RequestToModifyPayment 156, 156
BranchData236
CCanadianPaymentsARNIdentifier
226, 236
CancellationReason1CodeMessage DebitAuthorisationRequest 94Message RequestToCancelPayment 141
CaseMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197
CaseAssignmentMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 296
Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197
CaseAssignmentRejection1CodeMessage RejectCaseAssignment 127
CaseAssignmentRejectionJustificationMessage RejectCaseAssignment 127
CaseForwardingNotificationMessage NotificationOfCaseAssignment 115
CaseForwardingNotification1CodeMessage NotificationOfCaseAssignment 115
CaseStatusMessage CaseStatusReport 59
CaseStatus1CodeMessage CaseStatusReport 59
CashAccount3232Message AdditionalPaymentInformation 30, 30, 30Message RequestToModifyPayment 156, 156, 156
CashAccountType3Code233
CashClearingSystem2CodeMessage RequestToModifyPayment 156
ChargeBearer1CodeMessage RequestToModifyPayment 156
CHIPSParticipantIdentifier226, 236
CHIPSUniversalIdentifier226, 235, 260
ClearingSystemMemberIdentificationChoice235
CountryCode
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 297
226, 236, 237, 248, 248, 259
CurrencyAndAmount224Message AdditionalPaymentInformation 29, 30, 30, 30, 30, 30, 30, 30Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141, 141Message RequestToModifyPayment 155, 156, 156, 156, 156, 156, 156Message ResolutionOfInvestigation 187Message UnableToApply 198
CurrencyCode227, 233Message AdditionalPaymentInformation 29, 30, 30, 30, 30, 30, 30, 30, 30Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141, 141Message RequestToModifyPayment 155, 156, 156, 156, 156, 156, 156Message ResolutionOfInvestigation 187Message UnableToApply 198
DDebitAuthorisationConfirmation
Message DebitAuthorisationResponse 105
DebitAuthorisationDetailsMessage DebitAuthorisationRequest 94Message RequestToCancelPayment 141
DocumentType1CodeMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156
DunsIdentifier227, 260
EEANGLNIdentifier
227, 260
EquivalentAmountMessage AdditionalPaymentInformation 30
ExtensiveBranchNetworkIdentifier227, 236
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 298
FFedwireRoutingNumberIdentifier
227, 236
FinancialInstitutionIdentification1235
GGenericIdentification1
247, 248
GenericIdentification3236, 260
GenericIdentification4260
GermanBankleitzahlIdentifier228, 236
HHongKongBankIdentifier
228, 236
IIBANIdentifier
228, 233
ImpliedCurrencyAndAmount224
Instruction1CodeMessage RequestToModifyPayment 155
Instruction3CodeMessage RequestToModifyPayment 156
InstructionForFinalAgentMessage RequestToModifyPayment 156
Intermediary1247Message AdditionalPaymentInformation 30
InvestigationExecutionConfirmation1CodeMessage CaseStatusReport 59Message ResolutionOfInvestigation 186
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 299
InvestigationStatusChoiceMessage ResolutionOfInvestigation 186
IrishNSCIdentifier228, 236
ISODate224Message AdditionalPaymentInformation 30Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141Message RequestToModifyPayment 155, 155, 156
ISODateTime225Message AdditionalPaymentInformation 29, 29Message CancelCaseAssignment 50Message CaseStatusReport 59, 59, 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74, 75Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115, 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140, 141Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 186, 187Message UnableToApply 197, 198
ItalianDomesticIdentifier228, 236
LLanguageCode
228
LongPostalAddress1Choice247, 248
MMax10Text
231
Max128Text231
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 300
Max140Text231, 247, 248Message AdditionalPaymentInformation 29Message CaseStatusReport 59Message DebitAuthorisationResponse 105Message RequestToModifyPayment 156, 156Message ResolutionOfInvestigation 186
Max16Text231, 236, 236, 237, 237, 247, 248, 248, 248, 248, 248, 259, 259
Max256Text231
Max350Text232
Max35Text232, 233, 236, 236, 236, 236, 236, 236, 237, 237, 247, 247, 247, 247, 247, 247, 247, 247, 247, 247, 247, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 259, 259, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260Message AdditionalPaymentInformation 29, 29, 29, 29, 30, 30, 30Message CancelCaseAssignment 50, 50Message CaseStatusReport 59, 59, 59Message CaseStatusReportRequest 67, 68Message ClaimNonReceipt 74, 74, 75, 75Message DebitAuthorisationRequest 94, 94, 94, 94Message DebitAuthorisationResponse 104, 105Message NotificationOfCaseAssignment 115, 115, 115Message RejectCaseAssignment 127, 127Message RequestForDuplicateInstruction 133, 134Message RequestToCancelPayment 140, 140, 141, 141Message RequestToModifyPayment 155, 155, 155, 155, 155, 156, 156, 156, 156, 156Message ResolutionOfInvestigation 186, 186, 186, 187, 187Message UnableToApply 197, 197, 198, 198
Max70Text232, 233, 236, 236, 236, 237, 237, 259, 259, 259
MICIdentifier229
MissingCoverMessage ClaimNonReceipt 75
MissingOrIncorrectInformationMessage UnableToApply 198
NNameAndAddress2
247, 248
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 301
NationalityCode229
NewZealandNCCIdentifier229, 235
NonFinancialInstitutionIdentification1259
Number230
PParty1Choice
259
PartyIdentification1259Message AdditionalPaymentInformation 30, 30, 30, 30Message RequestToModifyPayment 156, 156, 156, 156
PartyIdentification1Choice247, 248
PaymentCancellationRejection1CodeMessage ResolutionOfInvestigation 186
PaymentComplementaryInformationMessage AdditionalPaymentInformation 29
PaymentInstructionExtractMessage AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198
PaymentModificationRejection1CodeMessage ResolutionOfInvestigation 186
PaymentPurpose1CodeMessage RequestToModifyPayment 156
PaymentSchemeChoiceMessage RequestToModifyPayment 156
PercentageRate231
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 302
PersonIdentification2260
PortugueseNCCIdentifier229, 236
PostalAddress1236, 237, 259
PurposeChoiceMessage RequestToModifyPayment 156
RReferredDocumentAmount1Choice
Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
RejectedCancellationJustificationMessage ResolutionOfInvestigation 186
RemittanceInformation3ChoiceMessage AdditionalPaymentInformation 29Message RequestToModifyPayment 156
ReportHeaderMessage CaseStatusReport 58Message CaseStatusReportRequest 67Message NotificationOfCaseAssignment 115
RequestedModificationMessage RequestToModifyPayment 155
RussianCentralBankIdentificationCodeIdentifier229, 236
SSimpleIdentificationInformation
233, 248
SmallNetworkIdentifier229, 236
SouthAfricanNCCIdentifier229, 236
SpanishDomesticInterbankingIdentifier230, 236
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 303
StructuredLongPostalAddress1247, 248
StructuredRemittanceInformation2Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156
SWIFTServiceLevel2CodeMessage RequestToModifyPayment 155
SwissBCIdentifier230, 236
SwissSICIdentifier230, 236
UUKDomesticSortCodeIdentifier
230, 236
UnableToApplyIncorrectInfo1CodeMessage UnableToApply 198
UnableToApplyJustificationChoiceMessage UnableToApply 198
UnableToApplyMissingInfo1CodeMessage UnableToApply 198
UPICIdentifier230, 233
YYesNoIndicator
Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74, 75Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105, 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186, 186Message UnableToApply 197, 198
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Indexes
Page 304
ErrataDefinition for RejectionReason Code UKNWSee section Message: RejectCaseAssignment <camt.031.001.01> and subsection Message Items Description, 3.1. The Definition of the code UKNW in the table CaseAssignmentRejection1Code should read as follows.
Code Name Definition
UKNW UnknownCase Case has never been assigned before.
UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006
Errata
Page 305