Payments Standards - Exceptions and Investigations

UNIFI (ISO 20022) Message Definition Report

Approved by UNIFI Payments SEG on 25 July 2006

Edition August 2006 Table Of Contents Overview ...... 1 What does this document contain? ...... 1 Exceptions and Investigations messages ...... 1 Business rationale for the Exceptions and Investigations messages ...... 1 How to read ...... 2 How to use the exceptions and investigations messages ...... 3 Introduction ...... 3 Concepts ...... 3 Rules ...... 4 Case management main scenario ...... 5 Cancel case assignment scenario ...... 7 Request for duplicate instruction scenario ...... 8 Message Flows ...... 9 Request for cancellation scenario ...... 9 Request for modification scenario ...... 11 Claim non receipt scenario ...... 17 Unable to apply scenario ...... 22 Message: AdditionalPaymentInformation ...... 28 Message Scope and Usage ...... 28 Message Structure ...... 29 Message Items Description ...... 30 Business Example ...... 44 Message: CancelCaseAssignment ...... 49 Message Scope and Usage ...... 49 Message Structure ...... 49 Message Items Description ...... 50 Business Example ...... 52 Message: CaseStatusReport ...... 58 Message Scope and Usage ...... 58 Message Structure ...... 58 Message Items Description ...... 59 Business Example ...... 64 Message: CaseStatusReportRequest ...... 67 Message Scope and Usage ...... 67 Message Structure ...... 67 Message Items Description ...... 68 Business Example ...... 70 Message: ClaimNonReceipt ...... 73 Message Scope and Usage ...... 73 Message Structure ...... 74 Message Items Description ...... 75 Business Example ...... 79 Message: DebitAuthorisationRequest ...... 93 Message Scope and Usage ...... 93 Message Structure ...... 93 Message Items Description ...... 94 Business Example ...... 99 Message: DebitAuthorisationResponse ...... 104 Message Scope and Usage ...... 104 Message Structure ...... 104 Message Items Description ...... 105 Business Example ...... 108 Message: NotificationOfCaseAssignment ...... 114 Message Scope and Usage ...... 114 Message Structure ...... 115 Message Items Description ...... 115 Business Example ...... 119 Message: RejectCaseAssignment ...... 126 Message Scope and Usage ...... 126 Message Structure ...... 126 Message Items Description ...... 127 Business Example ...... 130 Message: RequestForDuplicateInstruction ...... 133 Message Scope and Usage ...... 133 Message Structure ...... 133 Message Items Description ...... 134 Business Example ...... 136 Message: RequestToCancelPayment ...... 139 Message Scope and Usage ...... 139 Message Structure ...... 140 Message Items Description ...... 141 Business Example ...... 145 Message: RequestToModifyPayment ...... 153 Message Scope and Usage ...... 153 Message Structure ...... 155 Message Items Description ...... 157 Business Example ...... 173 Message: ResolutionOfInvestigation ...... 185 Message Scope and Usage ...... 185 Message Structure ...... 186 Message Items Description ...... 187 Business Example ...... 194 Message: UnableToApply ...... 196 Message Scope and Usage ...... 196 Message Structure ...... 197 Message Items Description ...... 198 Business Example ...... 204 Message Item Types ...... 223 Data Types ...... 223 End Points ...... 232 Indexes ...... 268 Index of Message Items ...... 268 Index of XML tags ...... 281 Index of Message Item Types ...... 295 Errata ...... 305 Definition for RejectionReason Code UKNW ...... 305 Revision Record ...... 306 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Overview Overview What 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.

Page 1 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Overview

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 read In 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.

Page 2 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 How to use the exceptions and investigations messages 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 case An 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

Page 3 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 How to use the exceptions and investigations messages

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 identification The 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 identification The 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' rule Each 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 RequestToCancelPayment Instructing party Instructed party/creditor cancellation Request for RequestToModifyPayment Instructing party Instructed party/creditor modification 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:

Page 4 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 How to use the exceptions and investigations messages

- 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.CaseAssignment 2.CaseAssignment 3. NotificationOfAssignment 4. CaseAssignment

5. NotificationOfAssignment

6. NotificationOfAssignment

7.ResolutionOfInvestigation 8.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.

Page 5 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 How to use the exceptions and investigations messages

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 UnderlyingPaymentNotFoun The underlying payment instruction cannot be found. d 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.

Page 6 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 How to use the exceptions and investigations messages

Step 8: C forwards the ResolutionOfInvestigation to B.

Step 9: B forwards the ResolutionOfInvestigation to A.

Cancel case assignment scenario This 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 C 1. CaseAssignment 2. CaseAssignment

3. CancelAssignement 4. CancelAssignement

5. ResolutionOfInvestigation

6. 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.

Page 7 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 How to use the exceptions and investigations messages

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 scenario This 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, ...).

Page 8 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows Message Flows Request 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.

Page 9 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

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.

Page 10 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Request for cancellation

Debtor FirstAgent FinalAgent Creditor

RequestToCancelPayment

RequestToCancelPayment NotificationOfAssignment

NotificationOfAssignment DebitAuthorisationRequest NotificationOfAssignment

DebitAuthorisationResponse

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

Page 11 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

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.

Page 12 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

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.

Page 13 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Request for modification

Debtor : FirstAgent : FinalAgent : Creditor : CorporateApplication FinancialInstAppli... FinancialInstAppli... CorporateApplication

RequestToModifyPayment RequestToModifyPayment

NotificationOfCaseAssignment RequestToModifyPayment

NotificationOfCaseAssignment

ResolutionOfInvestigation

Modification of the payment instruction amount scenario

When the RequestToModifyPayment message concerns the payment instruction amount, the following actions must be taken:

Page 14 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

- 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

Creditor Debtor FirstAgent FinalAgent

RequestToModifyPayment RequestToModifyPayment DebitAuthorisationRequest

DebitAuthorisationResponse ResolutionOfInvestigation 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).

Page 15 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

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

RequestToModifyPayment RequestToCancelPayment DebitAuthorisationRequest NotificationOfAssignment

NotificationOfAssignment NotificationOfAssignment

ResolutionOfInvestigation ResolutionOfInvestigation DebitAuthorisationResponse

Page 16 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows 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).

Page 17 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Claim non receipt

Debtor : FirstAgent : FinalAgent : Creditor : CorporateApplication FinancialInstAppli... FinancialInstAppli... CorporateApplication

ClaimNonReceipt

ClaimNonReceipt NotificationOfAssignment

AdditionalPaymentInformation NotificationOfAssignment NotificationOfAssignment

ResolutionOfInvestigation

Page 18 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Claim non receipt followed by a modification

Debtor First Agent Final Agent Creditor

ClaimNonReceipt ClaimNonReceipt RequestToModifyPayment NotificationOfAssignment

NotificationOfAssignment NotificationOFAssignment

ResolutionOfInvestigation ResolutionOfInvestigation ResolutionOfInvestigation

Page 19 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Claim non receipt followed by a cancellation

Debtor First Agent Final Agent Creditor

ClaimNonReceipt

ClaimNonReceipt NotificationOfAssignment

ResolutionOfInvestigation ResolutionOfInvestigation

This party needs to cancel an instruction and initiates a new instruction.

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).

Page 20 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

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).

Page 21 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Missing cover

FirstAgent FirstSettlementAgent LastSettlementAgent FinalAgent ......

ClaimNonReceipt

2. ClaimNonReceipt

NotificationOfAssignment

ClaimNonReceipt

NotificationOfAssignment

ResolutionOfInvestigation ResolutionOfInvestigation

ResolutionOfInvestigation

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);

Page 22 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

- 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.

Page 23 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

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.

Page 24 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Unable to apply followed by sending additional information

Debtor : FirstAgent : FinalAgent : Creditor : CorporateApplication FinancialInstAppli... FinancialInstAppli... CorporateApplication

UnableToApply UnableToApply NotificationOfAssignment UnableToApply

NotificationOfAssignment NotificationOfAssignment

AdditionalPaymentInformation

Page 25 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Unable to apply followed by a request for cancellation

Debtor : FirstAgent : FinalAgent : Creditor : CorporateApplication FinancialInstAppli... FinancialInstAppli... CorporateApplication

UnableToApply UnableToApply NotificationOfAssignment UnableToApply

NotificationOfAssignment

RequestToCancelPayment RequestToCancelPayment DebitAuthorisationRequest

DebitAuthorisationResponse

ResolutionOfInvestigation

Page 26 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Flows

Unable to apply followed by a request for modification

Debtor FirstAgent FinalAgent Creditor

UnableToApply

UnableToApply UnableToApply NotificationOfAssignment

NotificationOfAssignment NotificationOfAssignment

RequestToModifyPayment RequestToModifyPayment RequestToModifyPayment

ResolutionOfInvestigation ResolutionOfInvestigation ResolutionOfInvestigation

Page 27 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation Message: AdditionalPaymentInformation Message Scope and Usage Scope

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.

Outline The AdditionalPaymentInformation message is composed of four building blocks. A.Case Assignment This building block is mandatory.

B.Case This building block is mandatory.

C.Payment Instruction Extract This building block is optional.

Page 28 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

D.Payment Complementary Information This building block is mandatory. Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 1.0 Assignment [1..1] 1.1 Identification [1..1] Text 1.2 Assigner [1..1] Identifier 1.3 Assignee [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 3.0 Underlying [1..1] 3.1 AssignerInstructionIdentification [0..1] Text 3.2 AssigneeInstructionIdentification [0..1] Text 3.3 CurrencyAmount [0..1] Amount 3.4 ValueDate [0..1] DateTime

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 Information [1..1] 4.1 RemittanceChoice [0..1] 4.2 {Or Unstructured [1..1] Text

Page 29 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.3 Or} Structured [1..1] 4.4 ReferredDocumentType [0..1] Code 4.5 ReferredDocumentRelatedDate [0..1] DateTime 4.6 ReferredDocumentAmount [0..n] 4.7 {{Or DuePayableAmount [1..1] Amount 4.8 Or DiscountAppliedAmount [1..1] Amount 4.9 Or RemittedAmount [1..1] Amount 4.10 Or CreditNoteAmount [1..1] Amount 4.11 Or}} TaxAmount [1..1] Amount 4.12 DocumentReferenceNumber [0..1] Text 4.13 CreditorReference [0..1] Text 4.14 Invoicer [0..1] + 4.15 Invoicee [0..1] + 4.16 Debtor [0..1] + 4.17 DebtorAccount [0..1] + 4.18 FirstAgent [0..1] + 4.19 Amount [0..1] 4.20 {Or InstructedAmount [1..1] Amount 4.21 Or} EquivalentAmount [1..1] 4.22 Amount [1..1] Amount 4.23 CurrencyOfTransfer [1..1] Code 4.24 NostroVostroAccount [0..1] + 4.25 Intermediary [0..1] + 4.26 FirstSettlementAgent [0..1] + 4.27 LastSettlementAgent [0..1] + 4.28 IntermediarySettlementAgent [0..1] + 4.29 Creditor [0..1] + 4.30 CreditorAccount [0..1] + 4.31 SenderToReceiverInformation [0..6] Text

Message Items Description

The following section identifies the elements of the AdditionalPaymentInformation message. 1.0 Assignment

Presence: [1..1]

Page 30 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Definition: Identifies the assignment. Type: The Assignment block is composed of the following CaseAssignment element(s): Index Or Message Item Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 Assigner [1..1] Identifier 1.3 Assignee [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Data Type: AnyBICIdentifier 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: CORPBE22 1.3 Assignee

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created.

Page 31 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Data Type: ISODateTime 2.0 Case

Presence: [1..1] Definition: Identifies the case. Type: The Case block is composed of the following Case element(s): Index Or Message Item Mult. Represent./ Type 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

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 MeaningWhenFalse: No 3.0 Underlying

Presence: [1..1]

Page 32 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Definition: Identifies the underlying payment instruction. Type: The Underlying block is composed of the following PaymentInstructionExtract element(s): Index Or Message Item Mult. Represent./ Type 3.1 AssignerInstructionIdentification [0..1] Text 3.2 AssigneeInstructionIdentification [0..1] Text 3.3 CurrencyAmount [0..1] Amount 3.4 ValueDate [0..1] DateTime

3.1 AssignerInstructionIdentification

Presence: [0..1] Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2 AssigneeInstructionIdentification

Presence: [0..1] Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.3 CurrencyAmount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 3.4 ValueDate

Presence: [0..1] Definition: Value date of the payment. Data Type: ISODateTime

Page 33 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

4.0 Information

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 Mult. Represent./ Type 4.1 RemittanceChoice [0..1] 4.16 Debtor [0..1] + 4.17 DebtorAccount [0..1] + 4.18 FirstAgent [0..1] + 4.19 Amount [0..1] 4.24 NostroVostroAccount [0..1] + 4.25 Intermediary [0..1] + 4.26 FirstSettlementAgent [0..1] + 4.27 LastSettlementAgent [0..1] + 4.28 IntermediarySettlementAgent [0..1] + 4.29 Creditor [0..1] + 4.30 CreditorAccount [0..1] + 4.31 SenderToReceiverInformation [0..6] Text

4.1 RemittanceChoice

Presence: [0..1] Definition: Remittance information. Type: This message item is composed of one of the following RemittanceInformation3Choice element(s): Index Or Message Item Mult. Represent./ Type 4.2 {Or Unstructured [1..1] Text 4.3 Or} Structured [1..1]

4.2 Unstructured

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: Max140Text Format: maxLength: 140 minLength: 1

Page 34 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

4.3 Structured

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 Mult. Represent./ Type 4.4 ReferredDocumentType [0..1] Code 4.5 ReferredDocumentRelatedDate [0..1] DateTime 4.6 ReferredDocumentAmount [0..n] 4.12 DocumentReferenceNumber [0..1] Text 4.13 CreditorReference [0..1] Text 4.14 Invoicer [0..1] + 4.15 Invoicee [0..1] +

4.4 ReferredDocumentType

Presence: [0..1] Definition: Specifies the nature of the referred document/transaction, eg, invoice or credit note. Data Type: Code When this message item is present, one of the following DocumentType1Code values must be used: Code Name Definition CINV 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 CreditNoteRelatedToFinanc Document is a credit note for the final amount settled for a ialAdjustment commercial transaction. CREN CreditNote Document is a credit note. DEBN DebitNote Document is a debit note. DNFA DebitNoteRelatedToFinanci Document is a debit note for the final amount settled for a alAdjustment commercial transaction. FXDR ForeignExchangeDealRefer Document is a pre-agreed or pre-arranged foreign exchange ence 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.

Page 35 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Code Name Definition 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.

4.5 ReferredDocumentRelatedDate

Presence: [0..1] Definition: Date associated with the referred document, eg, date of issue. Data Type: ISODate 4.6 ReferredDocumentAmount

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 Mult. Represent./ Type 4.7 {Or DuePayableAmount [1..1] Amount 4.8 Or DiscountAppliedAmount [1..1] Amount 4.9 Or RemittedAmount [1..1] Amount 4.10 Or CreditNoteAmount [1..1] Amount 4.11 Or} TaxAmount [1..1] Amount

4.7 DuePayableAmount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.8 DiscountAppliedAmount

Presence: [1..1]

Page 36 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.9 RemittedAmount

Presence: [1..1] This message item is part of choice 4.6 ReferredDocumentAmount. Definition: Amount of money remitted for the referred document. Data Type: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.10 CreditNoteAmount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.11 TaxAmount

Presence: [1..1] This message item is part of choice 4.6 ReferredDocumentAmount.

Page 37 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Definition: Quantity of cash resulting from the calculation of the tax. Data Type: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.12 DocumentReferenceNumber

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: Max35Text Format: maxLength: 35 minLength: 1 4.13 CreditorReference

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: Max35Text Format: maxLength: 35 minLength: 1 4.14 Invoicer

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 Mult. Represent./ Type Name [0..1] Text PostalAddress [0..1] Identification [0..1]

For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section

Page 38 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

4.15 Invoicee

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 Mult. Represent./ Type Name [0..1] Text PostalAddress [0..1] Identification [0..1]

For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section 4.16 Debtor

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 Mult. Represent./ Type Name [0..1] Text PostalAddress [0..1] Identification [0..1]

For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section 4.17 DebtorAccount

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 Mult. Represent./ Type Identification [1..1] Type [0 ..1] Code Currency [0..1] Code Name [0..1] Text

For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section 4.18 FirstAgent

Presence: [0..1] Definition: First Agent or Field 52 in Fin messages. Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):

Page 39 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Or Message Item Mult. Represent./ Type FinancialInstitutionIdentification [1..1] BranchIdentification [0..1]

For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section 4.19 Amount

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 Mult. Represent./ Type 4.20 {Or InstructedAmount [1..1] Amount 4.21 Or} EquivalentAmount [1..1]

4.20 InstructedAmount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.21 EquivalentAmount

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.

Page 40 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

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 Mult. Represent./ Type 4.22 Amount [1..1] Amount 4.23 CurrencyOfTransfer [1..1] Code

4.22 Amount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.23 CurrencyOfTransfer

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: CurrencyCode Format: [A-Z]{3,3} Rule(s): ValidationByTable 4.24 NostroVostroAccount

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 Mult. Represent./ Type Identification [1..1] Type [0 ..1] Code

Page 41 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Or Message Item Mult. Represent./ Type Currency [0..1] Code Name [0..1] Text

For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section 4.25 Intermediary

Presence: [0..1] Definition: Intermediary bank. Type: This message item is composed of the following Intermediary1 element(s): Or Message Item Mult. Represent./ Type Identification [1..1] Account [0..1] Role [0..1] Text

For additional Type information, please refer to Intermediary1 p.247 in 'Message Item Types' section 4.26 FirstSettlementAgent

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 Mult. Represent./ Type FinancialInstitutionIdentification [1..1] BranchIdentification [0..1]

For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section 4.27 LastSettlementAgent

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 Mult. Represent./ Type FinancialInstitutionIdentification [1..1] BranchIdentification [0..1]

For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section

Page 42 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

4.28 IntermediarySettlementAgent

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 Mult. Represent./ Type FinancialInstitutionIdentification [1..1] BranchIdentification [0..1]

For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section 4.29 Creditor

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 Mult. Represent./ Type Name [0..1] Text PostalAddress [0..1] Identification [0..1]

For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section 4.30 CreditorAccount

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 Mult. Represent./ Type Identification [1..1] Type [0 ..1] Code Currency [0..1] Code Name [0..1] Text

For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section 4.31 SenderToReceiverInformation

Presence: [0..6] Definition: Unformatted information from the sender to the receiver. Data Type: Max35Text

Page 43 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

Format: maxLength: 35 minLength: 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.

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 52317.48 GBP Currency Unstructured Remittance /INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/ Information Final Agent Bank K, London (KKKKGB2L) Creditor Customer S (ASUPGB2L) All Supplies and Co

Scenario 1, resulting in an AdditionalPaymentInformation message Narrative Customer A checks its accounts payables. The dates for the two invoices have been incorrectly reported in the remittance information.

Step 1 Customer 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 CUSTA20050003 CUASGB2L

Page 44 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

AAAAGB2L 2005-01-27T08:35:30 CUSTA20050003 CUSAGB2L CPAY0123456789 52317.48 /INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/ Step 2 Bank 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.1 Bank 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 C103AAAAKKKK20050127001 AAAAGB2L KKKKGB2L 2005-01-27T08:43:30 CUSTA20050003 CUSAGB2L 1030123456789 52317.48 /INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/

Page 45 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

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 RCUSTA20050001 AAAAGB2L CUSAGB2L 2005-01-27T08:50:22 CUSTA20050003 CUSAGB2L C103AAAAKKKK20050127001 AAAAGB2L KKKKGB2L 2005-01-27T08:43:30 MODI Step 3 Bank 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.1 Bank K forwards additional information about the payment to Customer S.

The following AdditionalPaymentInformation message is sent by Bank K to Customer S: XML Instance I103AAAAKKKK20050127001 KKKKGB2L ASUPGB2L 2005-01-27T08:52:30 CUSTA20050003 CUSAGB2L

Page 46 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

I1030123456789 /INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/ All Supplies and Co CUSBGB2L Step 3.2 Bank K informs Bank A of the resolution of the investigation.

The following ResolutionOfInvestigation message is sent by Bank K to Bank A. XML Instance RKKKKAAAA20050127004 KKKKGB2L AAAAGB2L 2005-01-27T09:08:23 CUSTA20050003 CUSAGB2L MODI Step 3.3 Upon 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 RAAAACUSA20050127004 AAAAGB2L CUSAGB2L

Page 47 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: AdditionalPaymentInformation

2005-01-27T09:18:23 CUSTA20050003 CUSAGB2L MODI

Page 48 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment Message: CancelCaseAssignment Message Scope and Usage Scope The 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.

Outline The CancelCaseAssignment message is composed of two building blocks: A.Case Assignment This building block is mandatory. B.Case This building block is mandatory. Message Structure

Page 49 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Message Items Description

The following section identifies the elements of the CancelCaseAssignment message. 1.0 Assignment

Presence: [1..1] Definition: Identifies the assignment. Type: The Assignment block is composed of the following CaseAssignment element(s): Index Or Message Item Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 Assigner [1..1] Identifier 1.3 Assignee [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1

Page 50 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment

1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Page 51 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

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)

Page 52 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment

General Plumbing and Co

Narrative Customer 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 1 Customer 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 AB20050417CANC EEEEUS33 NNNNUS33 2005-05-26T09:10:30 EEEE20050525001 EEEEUS33 CECOMSUP001003 10234.56 2005-05-25T00:00:00 CUST

Step 2 Bank 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 NNNNCANC0001200888 NNNNUS33

Page 53 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment

FFFFUS33 2005-05-26T10:07:23 EEEE20050525001 EEEEUS33 AFFFFUS4567 10234.56 2005-05-25T00:00:00 CUST

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 RESPAB20050417CANC NNNNUS33 EEEEUS33 2005-05-26T10:22:23 EEEE20050525001 EEEEUS33 NNNNCANC0001200888 NNNNUS33 FFFFUS33 2005-05-26T10:07:23 CANC Step 3 In 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.

Page 54 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment

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.1 Customer 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 CANCEEEE20050525001 EEEEUS33 NNNNUS33 2005-05-27T08:42:34 EEEE20050525001 EEEEUS33 Step 3.2 Bank 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.1 The following CancelCaseAssignment message is sent by Bank N to Bank F: XLM Instance CANCNNNN20050527004 NNNNUS33 FFFFUS33 2005-05-27T09:07:35 EEEE20050525001 EEEEUS33 Step 3.2.2 The following NotificationOfCaseAssignment message is sent by Bank N to Customer E: XML Instance RCANCEEEE20050525001 NNNNUS33

Page 55 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment

EEEEUS33 2005-05-27T10:21:23 EEEE20050525001 EEEEUS33 CANCNNNN20050527004 NNNNUS33 FFFFUS33 2005-05-27T09:07:35 CANC

Step 4 Bank 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.1 The following ResolutionOfInvestigation message is sent by Bank F to Bank N: XML Instance CONFCONFCANC20050527004 FFFFUS33 NNNNUS33 2005-05-27T10:27:21 EEEE20050525001 EEEEUS33 CNCL

Step 4.2 The following ResolutionOfInvestigation message is sent by Bank N to Customer E: XML Instance CONCANCEEEE20050525001

Page 56 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CancelCaseAssignment

NNNNUS33 EEEEUS33 2005-05-27T12:54:22 EEEE20050525001 EEEEUS33 CANC

Page 57 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport Message: CaseStatusReport Message Scope and Usage Scope The 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.

Outline The CaseStatusReport message is composed of four building blocks: A.Report Header This building block is mandatory. B.Case This building block is mandatory.

C.Case Status This building block is mandatory. D.New Assignment This building block is optional. Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 1.0 Header [1..1]

Page 58 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 1.1 Identification [1..1] Text 1.2 From [1..1] Identifier 1.3 To [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 3.0 Status [1..1] 3.1 DateTime [1..1] DateTime 3.2 CaseStatus [1..1] Code 3.3 InvestigationStatus [0..1] Code 3.4 Reason [0..1] Text

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 NewAssignment [0..1] 4.1 Identification [1..1] Text 4.2 Assigner [1..1] Identifier 4.3 Assignee [1..1] Identifier 4.4 CreationDateTime [1..1] DateTime

Message Items Description

The following section identifies the elements of the CaseStatusReport message.

Page 59 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport

1.0 Header

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 Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 From [1..1] Identifier 1.3 To [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of the report. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 From

Presence: [1..1] Definition: Party reporting the status of the case. Data Type: AnyBICIdentifier 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

Presence: [1..1] Definition: Party to which the status of the case is reported. Data Type: AnyBICIdentifier 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.4 CreationDateTime

Presence: [1..1] Definition: Creation date and time of the report generation.

Page 60 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport

Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

Presence: [1..1]

Page 61 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport

Definition: Defines the status of the case. Type: The Status block is composed of the following CaseStatus element(s): Index Or Message Item Mult. Represent./ Type 3.1 DateTime [1..1] DateTime 3.2 CaseStatus [1..1] Code 3.3 InvestigationStatus [0..1] Code 3.4 Reason [0..1] Text

3.1 DateTime

Presence: [1..1] Definition: Date and time of the status. Data Type: ISODateTime 3.2 CaseStatus

Presence: [1..1] Definition: Status of the case. Data Type: Code One of the following CaseStatus1Code values must be used: Code Name Definition ASGN 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

Presence: [0..1] Definition: Status of the investigation. Data Type: Code When this message item is present, one of the following InvestigationExecutionConfirmation1Code values must be used: Code Name Definition ACDA 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.

Page 62 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport

Code Name Definition INFO 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

Presence: [0..1] Definition: Free text justification of the status. Data Type: Max140Text Format: maxLength: 140 minLength: 1 4.0 NewAssignment

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 Mult. Represent./ Type 4.1 Identification [1..1] Text 4.2 Assigner [1..1] Identifier 4.3 Assignee [1..1] Identifier 4.4 CreationDateTime [1..1] DateTime

4.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 4.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Data Type: AnyBICIdentifier Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}

Page 63 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport

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: CORPBE22 4.3 Assignee

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

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

Page 64 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport

Narrative On 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 1 Customer 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 CUSGHKHHMODGCOMPAY0123456789 CUSGHKHH GGGGHKHH 2005-05-27T10:18:56 CUSGMOD050527001 CUSGHKHH GCOMPAY0123456789 1267988.00 2005-05-29T00:00:00 1331387.40 Step 2 On 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 CSRRCUSGMOD050527001 CUSGHKHH GGGGHKHH 2005-05-28T10:35:30 CUSGMOD050527001 CUSGHKHH

Page 65 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReport

Step 3 Bank 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 HSBCRCSRRCUSGMOD050527001 GGGGHKHH CUSGHKHH 2005-05-28T10:44:12 CUSGMOD050527001 CUSGHKHH 2005-05-27T10:23:43 CLOSE MODI

Page 66 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReportRequest Message: CaseStatusReportRequest Message Scope and Usage Scope The 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.

Outline The CaseStatusReportRequest message is composed of two building blocks: A.Report Header This building block is mandatory.

B.Case This building block is mandatory.

Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 1.0 RequestHeader [1..1] 1.1 Identification [1..1] Text

Page 67 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReportRequest

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 1.2 From [1..1] Identifier 1.3 To [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Message Items Description

The following section identifies the elements of the CaseStatusReportRequest message. 1.0 RequestHeader

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 Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 From [1..1] Identifier 1.3 To [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of the report. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 From

Presence: [1..1] Definition: Party reporting the status of the case. Data Type: AnyBICIdentifier

Page 68 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReportRequest

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

Presence: [1..1] Definition: Creation date and time of the report generation. Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1]

Page 69 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReportRequest

Definition: Party that created the case.

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.

Page 70 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReportRequest

Step 1 Customer 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 CaseStatusReportRequest message is sent by Customer G to Bank G: XML Instance CSRRCUSGMOD050527001 CUSGHKHH GGGGHKHH 2005-05-28T10:35:30 CUSGMOD050527001 CUSGHKHH Step 3 Bank 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.

Page 71 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: CaseStatusReportRequest

Page 72 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt Message: ClaimNonReceipt Message Scope and Usage Scope The 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 characteristics The ClaimNonReceipt message has the following main characteristics: Case Identification The case creator assigns a unique case identification. This information will be passed unchanged to subsequent case assignee(s).

Underlying Payment Instruction Identification The 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).

Page 73 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

MissingCoverIndication The MissingCoverIndication element distinguishes between a missing cover situation (when set to yes) or a missing funds situation (when set to no). Outline The ClaimNonReceipt message is composed of four building blocks: A.Case Assignment This building block is mandatory. B.Case This building block is mandatory. C. Payment Instruction Extract This building block is mandatory. D. Missing Cover Indicator This building block is optional. Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Page 74 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 MissingCover [0..1] 4.1 MissingCoverIndication [1..1] Indicator

Message Items Description

The following section identifies the elements of the ClaimNonReceipt message. 1.0 Assignment

Presence: [1..1] Definition: Identifies an assignment. Type: The Assignment block is composed of the following CaseAssignment element(s): Index Or Message Item Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 Assigner [1..1] Identifier 1.3 Assignee [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Page 75 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

Presence: [1..1] Definition: Identifies a case. Type: The Case block is composed of the following Case element(s): Index Or Message Item Mult. Represent./ Type 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example:

Page 76 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

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 Mult. Represent./ Type 3.1 AssignerInstructionIdentification [0..1] Text 3.2 AssigneeInstructionIdentification [0..1] Text 3.3 CurrencyAmount [0..1] Amount 3.4 ValueDate [0..1] DateTime

3.1 AssignerInstructionIdentification

Presence: [0..1] Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner. Data Type: Max35Text Format: maxLength: 35 minLength: 1

Page 77 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

3.2 AssigneeInstructionIdentification

Presence: [0..1] Definition: Value date of the payment. Data Type: ISODateTime 4.0 MissingCover

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 Mult. Represent./ Type 4.1 MissingCoverIndication [1..1] Indicator

4.1 MissingCoverIndication

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: Yes MeaningWhenFalse: No

Page 78 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt 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 message The 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 1 The following ClaimNonReceipt message is sent by Customer A to Bank F: XML Instance CNRVVVVGB2L200506020001 AAAAFRPP FFFFFRPP 2005-06-06T10:35:23 CNR0505PAY09876543 AAAAFRPP

Page 79 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

0505PAY09876543 13498.52 2005-06-01T00:00:00 Step 2 Bank 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.1 Bank 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 CNRVVVVGB2L200506020001 FFFFFRPP UUUUGB2L 2005-06-06T10:45:21 CNR0505PAY09876543 AAAAFRPP 345601234 13498.52 2005-06-01T00:00:00 Step 2.2 Bank 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 REPCNR0505PAY09876543 FFFFFRPP AAAAFRPP 2005-06-06T10:52:59 CNR0505PAY09876543 AAAAFRPP

Page 80 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

CNRVVVVGB2L200506020001 FFFFFRPP UUUUGB2L 2005-06-06T10:45:21 FTHI Step 3 Bank 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.1 Bank U, London informs Bank F that the investigation is resolved.

The following ResolutionOfInvestigation message is sent by Bank U to Bank F: XML Instance CLOSECNR200506020001 UUUUGB2L FFFFFRPP 2005-06-07T11:32:57 CNR0505PAY09876543 AAAAFRPP CONF Step 3.2 Bank F informs Customer A of the successful case resolution.

The following ResolutionOfInvestigation message is sent by Bank F to Customer A: XML Instance CLOSECNRVVVVGB2L200506020001 FFFFFRPP AAAAFRPP 2005-06-07T11:45:17

Page 81 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

CNR0505PAY09876543 AAAAFRPP CONF

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 3 Bank 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 INFOVVVVGB2L200506020001 UUUUGB2L VVVVGB2L 2005-06-06T10:53:42 CNR0505PAY09876543 AAAAFRPP 200506020001 13498.52 2005-06-01T00:00:00 /INV/20050516/GBP8257,43/20050500102356//20050412/GBP5241,09/20050500202356/ Customer A AAAAFRPP

Page 82 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

VVVVGB2L Step 4 Customer 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.1 Customer V solves the case.

The following ResolutionOfInvestigation message is sent by Customer V to Bank U: XML Instance CLOSEVVVVGB2L200506020001 VVVVGB2L UUUUGB2L 2005-06-07T11:45:47 CNR0505PAY09876543 AAAAFRPP CONF Step 4.2 Bank 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 CLOSECNR200506020001 UUUUGB2L FFFFFRPP 2005-06-07T11:54:54 CNR0505PAY09876543 AAAAFRPP

Page 83 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

CONF Step 4.3 Bank 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 CLOSECNR200506020001 FFFFFRPP AAAAFRPP 2005-06-07T12:15:15 CNR0505PAY09876543 AAAAFRPP CONF

Scenario 3, resulting in a RequestToModifyPayment 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 3 Bank 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.1 Bank U requests the modification of the payment instruction.

The following RequestToModifyPayment message is sent by Bank U to Customer V: XML Instance MODIVVVVGB2L200506020001 UUUUGB2L VVVVGB2L 2005-06-06T10:53:42

Page 84 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

CNR0505PAY09876543 AAAAFRPP 200506020001 13498.52 2005-06-01T00:00:00 /INV/20050516/GBP8257.43/20050500102356//20050412/GBP5241.09/20050500202356/ Step 3.2 Bank U informs Bank F of the case assignment.

The following NotificationOfCaseAssignment message is sent by Bank U to Bank F: XML Instance FORWFRAGB2L200506020001 UUUUGB2L FFFFFRPP 2005-06-06T10:55:23 CNR0505PAY09876543 AAAAFRPP MODIVVVVGB2L200506020001 UUUUGB2L VVVVGB2L 2005-06-06T10:53:42 MODI Step 3.3 Bank F informs Customer A of the case assignment.

The following NotificationOfCaseAssignment message is sent by Bank F to Customer A: XML Instance FF200506020001 FFFFFRPP

Page 85 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

AAAAFRPP 2005-06-06T11:05:25 CNR0505PAY09876543 AAAAFRPP MODIVVVVGB2L200506020001 UUUUGB2L VVVVGB2L 2005-06-06T10:53:42 MODI

Step 4 Based 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.1 Customer V informs Bank U of the resolution of the case.

The following ResolutionOfInvestigation message is sent by Customer V to Bank U: XML Instance CLOSEVVVVGB2L200506020001 VVVVGB2L UUUUGB2L 2005-06-07T12:05:43 CNR0505PAY09876543 AAAAFRPP MODI Step 4.2 Bank U informs Bank F of the resolution of the case.

The following ResolutionOfInvestigation message is sent by Bank U to Bank F: XML Instance

Page 86 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

CLOSEVVVVGB2L200506020001 UUUUGB2L FFFFFRPP 2005-06-07T12:12:03 CNR0505PAY09876543 AAAAFRPP MODI Step 4.3 Bank F informs Customer A of the resolution of the case.

The following ResolutionOfInvestigation message is sent by Bank F to Customer A: XML Instance CLOSEVVVVGB2L200506020001 FFFFFRPP AAAAFRPP 2005-06-07T12:17:04 CNR0505PAY09876543 AAAAFRPP MODI

Scenario 4, resulting in a successful case resolution The 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). Narrative Bank 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:

Page 87 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

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 1 Bank 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 20050505COV123456789012 JJJJJPJT FFFFFRPP 2005-05-05T06:35:23 MC123456789012 JJJJJPJT 123456789012 2756.22 2005-05-05T00:00:00 true Step 2 Bank 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.1 Bank F assigns the claim non receipt request to Bank H.

The following ClaimNonReceipt message is sent by Bank F to Bank H: XML Instance 20050505COV12345678

Page 88 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

FFFFFRPP HHHHFRPP 2005-05-05T09:35:23 MC123456789012 JJJJJPJT COV12345678 2756.22 2005-05-05T00:00:00 Step 2.2 Bank 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 INFOMC123456789012 FFFFFRPP JJJJJPJT 2005-05-05T09:54:22 MC123456789012 JJJJJPJT 20050505COV12345678 FFFFFRPP HHHHFRPP 2005-05-05T09:35:23 FTHI Step 3 Bank 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.1 Bank H assigns the case to Bank D.

The following ClaimNonReceipt message is sent by Bank H to Bank D:

Page 89 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

XML Instance 20050505COV12345678 HHHHFRPP DDDDDEFF 2005-05-05T09:55:23 MC123456789012 JJJJJPJT JJJJ1234567 2756.22 2005-05-05T00:00:00 Step 3.2 Bank 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 FUMC123456789012 HHHHFRPP FFFFFRPP 2005-05-05T09:59:18 MC123456789012 JJJJJPJT 20050505COV12345678 HHHHFRPP DDDDDEFF 2005-05-05T09:55:23 FTHI Step 4 Bank 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.

Page 90 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

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.1 Bank D informs Bank H of the successful case resolution.

The following ResolutionOfInvestigation message is sent by Bank D to Bank H: XML Instance REP20050505COV12345678 DDDDDEFF HHHHFRPP 2005-06-07T12:19:05 MC123456789012 JJJJJPJT MCOV 2756.22 2005-05-05T00:00:00 Scenario 4.2 Bank H informs Bank F of the successful case resolution.

The following ResolutionOfInvestigation message is sent by Bank H to Bank F: XML Instance FOLL20050505COV12345678 HHHHFRPP FFFFFRPP 2005-06-07T12:22:05 MC123456789012 JJJJJPJT MCOV 2756.22 2005-05-05T00:00:00

Page 91 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ClaimNonReceipt

Step 4.3 Bank F informs Bank J of the successful case resolution.

The following ResolutionOfInvestigation message is sent by Bank F to Bank J: XML Instance FOLL20050505COV12345678 FFFFFRPP JJJJJPJT 2005-06-07T12:25:05 MC123456789012 JJJJJPJT MCOV 2756.22 2005-05-05T00:00:00

Page 92 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest Message: DebitAuthorisationRequest Message Scope and Usage Scope The 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.

Outline The DebitAuthorisationRequest message is composed of four building blocks: A.Case Assignment This building block is mandatory. B.Case This building block is mandatory. C.Payment Instruction Extract This building block is mandatory. D. Debit Authorisation Details This building block is mandatory. Message Structure

Page 93 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 Detail [1..1] 4.1 CancellationReason [1..1] Code 4.2 AmountToDebit [0..1] Amount 4.3 ValueDateToDebit [0..1] DateTime

Message Items Description

The following section identifies the elements of the DebitAuthorisationRequest message.

Page 94 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

1.0 Assignment

Presence: [1..1] Definition: Identifies the case assignment. Type: The Assignment block is composed of the following CaseAssignment element(s): Index Or Message Item Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 Assigner [1..1] Identifier 1.3 Assignee [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Page 95 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

1.4 CreationDateTime

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

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

Page 96 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

MeaningWhenFalse: No 3.0 Underlying

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 Mult. Represent./ Type 3.1 AssignerInstructionIdentification [0..1] Text 3.2 AssigneeInstructionIdentification [0..1] Text 3.3 CurrencyAmount [0..1] Amount 3.4 ValueDate [0..1] DateTime

3.1 AssignerInstructionIdentification

Presence: [0..1]

Page 97 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

Definition: Value date of the payment. Data Type: ISODateTime 4.0 Detail

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 Mult. Represent./ Type 4.1 CancellationReason [1..1] Code 4.2 AmountToDebit [0..1] Amount 4.3 ValueDateToDebit [0..1] DateTime

4.1 CancellationReason

Presence: [1..1] Definition: Indicates the reason for cancellation. Data Type: Code One of the following CancellationReason1Code values must be used: Code Name Definition AGNT 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

Presence: [0..1] Definition: Amount of money to be transferred between the debtor and creditor, before charges. Data Type: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.3 ValueDateToDebit

Presence: [0..1] Definition: Value date for debiting the amount.

Page 98 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

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 52317.48 GBP Currency Unstructured Remittance /INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/ Information Final Agent Bank K, London (KKKKGB2L) Creditor Customer S (ASUPGB2L) All Supplies and Co

Scenario 1, resulting in a DebitAuthorisationRequest message Narrative Customer 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 CUSTA20050001 CUASGB2L

Page 99 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

AAAAGB2L 2005-01-27T08:35:30 CUSTA20050001 CUASGB2L CPAY0123456789 52317.48 48573.96 /INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/ 20041215/GBP3743.52/20041208304712 Step 2 Bank 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.1 Bank A forwards the RequestToModifyPayment message to Bank K: XML Instance

CUSTA20050001 AAAAGB2L KKKKGB2L 2005-01-27T08:43:30 CUSTA20050001 CUASGB2L 1030123456789 52317.48 48573.96 /INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/ 20041215/GBP3743.52/20041208304712

Page 100 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

Step 2.2 Bank 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 AAAACUSA20050127003 AAAAGB2L CUSAGB2L 2005-01-27T08:45:30 CUSTA20050001 CUSAGB2L Q103AAAAKKKK20050127001 AAAAGB2L KKKKGB2L 2005-01-27T08:43:30 MODI Step 3 Bank 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.1 Bank K requests debit authorisation from Customer S.

The following DebitAuthorisationRequest message is sent by Bank K to Customer S: XML Instance 103KKKKSUPPLIES1234567890 KKKKGB2L ASUPGB2L 2005-01-27T08:50:30 CUSTA20050001 CUSAGB2L

Page 101 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

1030123456789 52317.48 CUST 3743.52 Step 3.2 Bank K informs Bank A of the case assignment.

The following NotificationOfAssignment message is sent by Bank K to Bank A: XML Instance KKKKAAAA20050127004 KKKKGB2L AAAAGB2L 2005-01-27T08:55:00 CUSTA20050001 CUSAGB2L 103KKKKSUPPLIES12345678901 KKKKGB2L ASUPGB2L 2005-01-27T08:50:30 DTAU Step 4 Customer 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 REP103KKKKSUPPLIES12345678901 ASUPGB2L KKKKGB2L 2005-01-27T10:55:23 CUSTA20050001

Page 102 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationRequest

CUSAGB2L true Step 5 Upon 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 R103AAAAKKKK20050127001 KKKKGB2L AAAAGB2L 2005-01-27T10:59:42 CUSTA20050001 CUSAGB2L ACDA Step 6 Upon 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 RCUSTA20050001 AAAAGB2L CUSAGB2L 2005-01-27T11:04:27 CUSTA20050001 CUSAGB2L ACDA

Page 103 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse Message: DebitAuthorisationResponse Message Scope and Usage Scope The 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. Usage The 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.

Outline The DebitAuthorisationResponse message is composed of three building blocks: A.Case Assignment This building block is mandatory. B.Case This building block is mandatory. C.Debit Authorisation Confirmation This building block is mandatory. Message Structure

Page 104 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 3.0 Confirmation [1..1] 3.1 DebitAuthorisation [1..1] Indicator 3.2 AmountToDebit [0..1] Amount 3.3 ValueDateToDebit [0..1] DateTime 3.4 Reason [0..1] Text

Message Items Description

The following section identifies the elements of the DebitAuthorisationResponse message. 1.0 Assignment

Presence: [1..1] Type: The Assignment block is composed of the following CaseAssignment element(s): Index Or Message Item Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 Assigner [1..1] Identifier 1.3 Assignee [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1

Page 105 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

Presence: [1..1] Type: The Case block is composed of the following Case element(s): Index Or Message Item Mult. Represent./ Type 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Page 106 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

Presence: [1..1] Type: The Confirmation block is composed of the following DebitAuthorisationConfirmation element(s): Index Or Message Item Mult. Represent./ Type 3.1 DebitAuthorisation [1..1] Indicator 3.2 AmountToDebit [0..1] Amount 3.3 ValueDateToDebit [0..1] DateTime 3.4 Reason [0..1] Text

3.1 DebitAuthorisation

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: Yes MeaningWhenFalse: No

Page 107 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

3.2 AmountToDebit

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 3.3 ValueDateToDebit

Presence: [0..1] Definition: Value date for debiting the amount. Data Type: ISODate 3.4 Reason

Presence: [0..1] Definition: Justification for partial authorisation of debit. Data Type: Max140Text Format: 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.

Page 108 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

Instructed Amount and 52317.48 GBP Currency Unstructured Remittance /INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/ Information Final Agent Bank K, London (KKKKGB2L) Creditor Customer S (ASUPGB2L) All Supplies and Co

The following RequestToModifyPayment message is sent by Customer A to Bank A: XML Instance CUSTA20050001 CUASGB2L AAAAGB2L 2005-01-27T08:35:30 CUSTA20050001 CUASGB2L CPAY0123456789 52317.48 48573.96 /INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/ 20041215/GBP3743.52/20041208304712

Page 109 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

Step 2 Bank 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.1 Bank A forwards the RequestToModifyPayment message to Bank K: XML Instance

The following NotificationOfCaseAssignment message is sent to Customer A by Bank A: XML Instance AAAACUSA20050127003 AAAAGB2L CUSAGB2L 2005-01-27T08:45:30 CUSTA20050001 CUSAGB2L

Page 110 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

Q103AAAAKKKK20050127001 AAAAGB2L KKKKGB2L 2005-01-27T08:43:30 MODI Step 3 Bank 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.1 Bank K requests debit authorisation from Customer S.

The following DebitAuthorisationRequest message is sent by Bank K to Customer S: XML Instance 103KKKKSUPPLIES1234567890 KKKKGB2L ASUPGB2L 2005-01-27T08:50:30 CUSTA20050001 CUSAGB2L 1030123456789 52317.48 CUST 3743.52 Step 3.2 Bank K informs Bank A of the case assignment.

The following NotificationOfAssignment message is sent by Bank K to Bank A: XML Instance KKKKAAAA20050127004 KKKKGB2L

Page 111 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

AAAAGB2L 2005-01-27T08:55:00 CUSTA20050001 CUSAGB2L 103KKKKSUPPLIES12345678901 KKKKGB2L ASUPGB2L 2005-01-27T08:50:30 DTAU Step 4 Customer 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 REP103KKKKSUPPLIES12345678901 ASUPGB2L KKKKGB2L 2005-01-27T10:55:23 CUSTA20050001 CUSAGB2L true Step 5 Upon 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 R103AAAAKKKK20050127001 KKKKGB2L AAAAGB2L

Page 112 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: DebitAuthorisationResponse

2005-01-27T10:59:42 CUSTA20050001 CUSAGB2L ACDA Step 6 Upon 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 RCUSTA20050001 AAAAGB2L CUSAGB2L 2005-01-27T11:04:27 CUSTA20050001 CUSAGB2L ACDA

Page 113 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment Message: NotificationOfCaseAssignment Message Scope and Usage Scope The 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.

Outline The NotificationOfCaseAssignment message is composed of four building blocks: A.Case Assignment This building block is mandatory.

B.Case This building block is mandatory.

C.Report Header This building block is mandatory.

D.Case Forwarding Notification This building block is mandatory.

Page 114 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 1.0 Header [1..1] 1.1 Identification [1..1] Text 1.2 From [1..1] Identifier 1.3 To [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 3.0 Assignment [1..1] 3.1 Identification [1..1] Text 3.2 Assigner [1..1] Identifier 3.3 Assignee [1..1] Identifier 3.4 CreationDateTime [1..1] DateTime

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 Notification [1..1] 4.1 Justification [1..1] Code

Message Items Description

The following section identifies the elements of the NotificationOfCaseAssignment message.

Page 115 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

1.0 Header

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 Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 From [1..1] Identifier 1.3 To [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of the report. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 From

Presence: [1..1] Definition: Creation date and time of the report generation.

Page 116 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

Presence: [1..1]

Page 117 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

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 Mult. Represent./ Type 3.1 Identification [1..1] Text 3.2 Assigner [1..1] Identifier 3.3 Assignee [1..1] Identifier 3.4 CreationDateTime [1..1] DateTime

3.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Page 118 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

3.4 CreationDateTime

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 4.0 Notification

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 Mult. Represent./ Type 4.1 Justification [1..1] Code

4.1 Justification

Presence: [1..1] Definition: Justification for the forward action. Data Type: Code One of the following CaseForwardingNotification1Code values must be used: Code Name Definition CANC 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

Page 119 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

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

Narrative Customer 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 1 Customer 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 AB20050417CANC AAAAFRPP BBBBFRPP 2005-04-19T10:09:30 AAAA200504001 AAAAFRPP CBPAY09876543 12347.56 2005-04-17T00:00:00 UPAY Step 2 Bank 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).

Page 120 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

Step 2.1 Bank 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 BBBBCANC0001200504 BBBBFRPP CCCCFRPP 2005-04-19T10:13:42 AAAA200504001 AAAAFRPP O1234598760 12347.56 2005-04-17T00:00:00 UPAY Step 2.2 Bank B notifies the case assignment to Customer A.

The following NotificationOfCaseAssignment message is sent by Bank B to Customer A. XML Instance RCUSTB20050419 BBBBFRPP AAAAFRPP 2005-04-19T10:22:23 AAAA200504001 AAAAFRPP BBBBCANC0001200504 BBBBFRPP CCCCFRPP 2005-04-19T10:13:42 CANC

Page 121 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

Step 3 Bank 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.1 Bank C requests a debit authorisation from Customer D.

The following DebitAuthorisationRequest message is sent by Bank C to Customer D: XML Instance BNPRFDA20050419001 CCCCFRPP DDDDFRPP 2005-04-19T10:19:02 AAAA200504001 AAAAFRPP E20050418027 12347.56 2005-04-18T00:00:00 CUST 12347.56 Step 3.2 Bank 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 RCCCCBBBB20050419004 CCCCFRPP BBBBFRPP 2005-01-27T10:21:23

Page 122 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

AAAA200504001 AAAAFRPP CCCCFDA20050419001 CCCCFRPP DDDDFRPP 2005-04-19T10:19:02 DTAU Step 3.3 Upon 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 RBBBBAAAA20050419012 BBBBFRPP AAAAFRPP 2005-01-27T10:25:42 AAAA200504001 AAAAFRPP CCCCFDA20050419001 CCCCFRPP DDDDFRPP 2005-04-19T10:19:02 DTAU Step 4 Customer 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 RCCCCFDA20050419001 DDDDFRPP

Page 123 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

CCCCFRPP 2005-04-19T12:17:43 AAAA200504001 AAAAFRPP true Step 5 Bank 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.1 The following ResolutionOfInvestigation message is sent by Bank C to Bank B: XML Instance CONFCCCCFDA20050419001 CCCCFRPP BBBBFRPP 2005-04-19T12:35:22 AAAA200504001 AAAAFRPP ACDA Step 5.2 The following ResolutionOfInvestigation message is sent by Bank B to Customer A: XML Instance CONFBBBBCANC20050419013 BBBBFRPP AAAAFRPP 2005-04-19T12:43:11 AAAA200504001 AAAAFRPP

Page 124 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: NotificationOfCaseAssignment

ACDA

Page 125 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RejectCaseAssignment Message: RejectCaseAssignment Message Scope and Usage Scope The 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.

Outline The RejectCaseAssignment message is composed of three building blocks: A.Case Assignment This building block is mandatory.

B.Case This building block is mandatory.

C.Case Assignment Rejection Justification This building block is mandatory.

Message Structure

Page 126 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RejectCaseAssignment

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 3.0 Justification [1..1] 3.1 RejectionReason [1..1] Code

Message Items Description

The following section identifies the elements of the RejectCaseAssignment message. 1.0 Assignment

Page 127 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RejectCaseAssignment

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

Presence: [1..1] Definition: Identifies the case. Type: The Case block is composed of the following Case element(s): Index Or Message Item Mult. Represent./ Type 2.1 Identification [1..1] Text

Page 128 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RejectCaseAssignment

Index Or Message Item Mult. Represent./ Type 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

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 Mult. Represent./ Type 3.1 RejectionReason [1..1] Code

Page 129 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RejectCaseAssignment

3.1 RejectionReason

Presence: [1..1] Definition: Reason for rejecting a case assignment. Data Type: Code One of the following CaseAssignmentRejection1Code values must be used: Code Name Definition CNCL 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 UnderlyingPaymentNotFou Underlying instruction can not be found. nd 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

Page 130 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RejectCaseAssignment

Narrative On 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 1 Customer 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 ABCDEFGHIJKLMNOPQRST123456789012345 CCCCJPJT VVVVJPJT 2005-01-25T10:35:43 MOD123JPY20050123 CCCCJPJT 123JPY20050123 4257567 2005-01-27T00:00:00 LLLLJPJT Step 2 Upon 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 ABCDEFGHIJKLMNOPQRST123456789012345 VVVVJPJT CCCCJPJT 2005-01-25T11:07:38

Page 131 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RejectCaseAssignment

MOD123JPY20050123 CCCCJPJT NFND

Page 132 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestForDuplicateInstruction Message: RequestForDuplicateInstruction Message Scope and Usage Scope The 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.

Outline The RequestForDuplicateInstruction message is composed of two blocks: A.Case Assignment This building block is mandatory. B.Case This building block is mandatory. Message Structure

Page 133 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestForDuplicateInstruction

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Message Items Description

The following section identifies the elements of the RequestForDuplicateInstruction message. 1.0 Assignment

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Page 134 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestForDuplicateInstruction

1.3 Assignee

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

Data Type: AnyBICIdentifier Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1} Rule(s): AnyBICRule

Page 135 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestForDuplicateInstruction

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: CORPUK33 2.3 ReopenCaseIndication

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

Narrative Customer 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 1 Customer B sends a request for cancellation of the payment to Bank F, Paris.

Page 136 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestForDuplicateInstruction

The following RequestToCancelPayment message is sent by Customer B to Bank F: XML Instance AB20050417CANC CUSBFRPP FFFFFRPP 2005-04-19T10:09:30 CUSB200504001 CUSBFRPP 12347.56 2005-04-17T00:00:00 UPAY Step 2 Bank 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 REPAB20050417 FFFFFRPP CUSBFRPP 2005-04-19T11:02:23 CUSB200504001 CUSBFRPP Step 3 Customer 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:

Page 137 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestForDuplicateInstruction

XML Instance DUPLAB20050417CANC CUSBFRPP FFFFFRPP 2005-04-19T11:08:32 CUSB200504001 CUSBFRPP 103 :20:CBPAY09876543//:32A:050417EUR12347.56//:33B:EUR12347.56//:50A:CUSBFRPP//:59:Tristan Recording Studios //239 Bld Haussmann//75009 Paris//:71A:SHA

Page 138 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment Message: RequestToCancelPayment Message Scope and Usage Scope The 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 characteristics The RequestToCancelPayment message has the following main characteristics:

Case Identification and Reason Code The case creator assigns a unique case identification and the reason code for the cancellation request. This information will be passed unchanged to all subsequent case assignee(s). Cancellation of a cover payment The cancellation of a payment instruction for which cover is provided by a separate instruction always results in the cancellation of the whole transaction, including the cover. The case assignee performing the cancellation must initiate the return of funds to the case creator. The case assigner must not request the cancellation of the cover separately.

Page 139 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

Cancellation request initiators The cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain. Outline The RequestToCancelPayment message is composed of four building blocks: A.Case Assignment This building block is mandatory. B.Case This building block is mandatory. C.Payment Instruction Extract This building block is mandatory. D.Debit Authorisation Details This building block is optional.

Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Page 140 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 Justification [1..1] 4.1 CancellationReason [1..1] Code 4.2 AmountToDebit [0..1] Amount 4.3 ValueDateToDebit [0..1] DateTime

Message Items Description

The following section identifies the elements of the RequestToCancelPayment message. 1.0 Assignment

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 Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 Assigner [1..1] Identifier 1.3 Assignee [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1

Page 141 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Page 142 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

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 Mult. Represent./ Type 3.1 AssignerInstructionIdentification [0..1] Text 3.2 AssigneeInstructionIdentification [0..1] Text 3.3 CurrencyAmount [0..1] Amount 3.4 ValueDate [0..1] DateTime

3.1 AssignerInstructionIdentification

Presence: [0..1] Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner. Data Type: Max35Text Format: maxLength: 35

Page 143 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

minLength: 1 3.2 AssigneeInstructionIdentification

Presence: [0..1] Definition: Value date of the payment. Data Type: ISODateTime 4.0 Justification

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 Mult. Represent./ Type 4.1 CancellationReason [1..1] Code 4.2 AmountToDebit [0..1] Amount 4.3 ValueDateToDebit [0..1] DateTime

4.1 CancellationReason

Presence: [1..1] Definition: Indicates the reason for cancellation. Data Type: Code One of the following CancellationReason1Code values must be used:

Page 144 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

Code Name Definition AGNT 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

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.

Page 145 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

Instructed Amount 175000.00 EUR Final Agent Bank G, Frankfurt (GGGGDEFF) Creditor Customer E (BEI EEEEDEFF) Hanswagen GmBH

Narrative On 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 1 The following RequestToCancelPayment message is sent by Customer D to Bank F: XML Instance CD20050423CANC DDDDDEFF FFFFDEFF 2005-04-22T10:17:32 DDDD20050423001 DDDDDEFF CDPAY20050423001 175000.00 2005-04-23T00:00:00 UPAY Step 2 Bank 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 CONFFFFFCANC20050423001 FFFFDEFF DDDDDEFF 2005-04-22T10:23:42

Page 146 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

DDDD20050423001 DDDDDEFF CNCL Scenario 2, resulting in a DebitAuthorisationRequest message

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

The following RequestToCancelPayment message is sent by Customer A to Bank B: XML Instance AB20050417CANC AAAAFRPP BBBBFRPP 2005-04-19T10:09:30

Page 147 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

AAAA200504001 AAAAFRPP CBPAY09876543 12347.56 2005-04-17T00:00:00 UPAY Step 2 Bank 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.1 Bank B forwards the request to cancel the payment to Bank C.

The following NotificationOfCaseAssignment message is sent by Bank B to Customer A. XML Instance

Page 148 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

RCUSTB20050419 BBBBFRPP AAAAFRPP 2005-04-19T10:22:23 AAAA200504001 AAAAFRPP BBBBCANC0001200504 BBBBFRPP CCCCFRPP 2005-04-19T10:13:42 CANC Step 3 Bank 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.1 Bank C requests a debit authorisation from Customer D.

Page 149 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

CUST 12347.56 Step 3.2 Bank 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 RCCCCBBBB20050419004 CCCCFRPP BBBBFRPP 2005-01-27T10:21:23 AAAA200504001 AAAAFRPP CCCCFDA20050419001 CCCCFRPP DDDDFRPP 2005-04-19T10:19:02 DTAU Step 3.3 Upon receipt of the message from Bank C, Bank B confirms the case assignment to Customer A.

Page 150 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

DDDDFRPP 2005-04-19T10:19:02 DTAU Step 4 Customer 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 RCCCCFDA20050419001 DDDDFRPP CCCCFRPP 2005-04-19T12:17:43 AAAA200504001 AAAAFRPP true Step 5 Bank 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.1 The following ResolutionOfInvestigation message is sent by Bank C to Bank B: XML Instance CONFCCCCFDA20050419001 CCCCFRPP BBBBFRPP 2005-04-19T12:35:22 AAAA200504001 AAAAFRPP

Page 151 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToCancelPayment

ACDA Step 5.2 The following ResolutionOfInvestigation message is sent by Bank B to Customer A: XML Instance CONFBBBBCANC20050419013 BBBBFRPP AAAAFRPP 2005-04-19T12:43:11 AAAA200504001 AAAAFRPP ACDA

Page 152 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment Message: RequestToModifyPayment Message Scope and Usage Scope

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

Page 153 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

- 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 characteristics The RequestToModifyPayment message has the following main characteristics: Case Identification The case creator assigns a unique case identification. This information will be passed unchanged to all subsequent case assignee(s). Modification of a cover payment Lowering 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 modified The 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).

Outline The RequestToModifyPayment message is composed of four building blocks: A. Case Assignment This building block is mandatory. B. Case This building block is mandatory. C. Payment Instruction Extract This building block is mandatory. D. Requested Modification This building block is mandatory.

Page 154 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 Modification [1..1] 4.1 RelatedReference [0..1] Text 4.2 BankOperationCode [0..1] Code 4.3 InstructionCode [0..1] Code 4.4 RequestedExecutionDate [0..1] DateTime 4.5 ValueDate [0..1] DateTime

Page 155 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.6 InterbankSettledAmount [0..1] Amount 4.7 Debtor [0..1] + 4.8 DebtorAccount [0..1] + 4.9 IntermediarySettlementAgent [0..1] + 4.10 LastSettlementAgent [0..1] + 4.11 PaymentScheme [0..1] 4.12 {Or Code [1..1] Code 4.13 Or} ProprietaryInformation [1..1] Text 4.14 BeneficiaryInstitutionAccount [0..1] + 4.15 Creditor [0..1] + 4.16 CreditorAccount [0..1] + 4.17 RemittanceInformation [0..1] 4.18 {Or Unstructured [1..1] Text 4.19 Or} Structured [1..1] 4.20 ReferredDocumentType [0..1] Code 4.21 ReferredDocumentRelatedDate [0..1] DateTime 4.22 ReferredDocumentAmount [0..n] 4.23 {{Or DuePayableAmount [1..1] Amount 4.24 Or DiscountAppliedAmount [1..1] Amount 4.25 Or RemittedAmount [1..1] Amount 4.26 Or CreditNoteAmount [1..1] Amount 4.27 Or}} TaxAmount [1..1] Amount 4.28 DocumentReferenceNumber [0..1] Text 4.29 CreditorReference [0..1] Text 4.30 Invoicer [0..1] + 4.31 Invoicee [0..1] + 4.32 Purpose [0..1] 4.33 {Or Proprietary [1..1] Text 4.34 Or} Code [1..1] Code 4.35 InstructionForFinalAgent [0..1] 4.36 Code [0..2] Code 4.37 Proprietary [0..1] Text 4.38 DetailsOfCharges [0..1] Code 4.39 SenderToReceiverInformation [0..6] Text

Page 156 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment Message Items Description

The following section identifies the elements of the RequestToModifyPayment message. 1.0 Assignment

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Data Type: AnyBICIdentifier Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1} Rule(s): AnyBICRule

Page 157 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

Page 158 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

2.3 ReopenCaseIndication

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 Mult. Represent./ Type 3.1 AssignerInstructionIdentification [0..1] Text 3.2 AssigneeInstructionIdentification [0..1] Text 3.3 CurrencyAmount [0..1] Amount 3.4 ValueDate [0..1] DateTime

3.1 AssignerInstructionIdentification

Page 159 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Rule(s): CurrencyCode ValidationByTable 3.4 ValueDate

Presence: [0..1] Definition: Value date of the payment. Data Type: ISODateTime 4.0 Modification

Presence: [1..1] Type: The Modification block is composed of the following RequestedModification element(s): Index Or Message Item Mult. Represent./ Type 4.1 RelatedReference [0..1] Text 4.2 BankOperationCode [0..1] Code 4.3 InstructionCode [0..1] Code 4.4 RequestedExecutionDate [0..1] DateTime 4.5 ValueDate [0..1] DateTime 4.6 InterbankSettledAmount [0..1] Amount 4.7 Debtor [0..1] + 4.8 DebtorAccount [0..1] + 4.9 IntermediarySettlementAgent [0..1] + 4.10 LastSettlementAgent [0..1] + 4.11 PaymentScheme [0..1] 4.14 BeneficiaryInstitutionAccount [0..1] + 4.15 Creditor [0..1] + 4.16 CreditorAccount [0..1] + 4.17 RemittanceInformation [0..1] 4.32 Purpose [0..1] 4.35 InstructionForFinalAgent [0..1] 4.38 DetailsOfCharges [0..1] Code 4.39 SenderToReceiverInformation [0..6] Text

4.1 RelatedReference

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: Max35Text Format: maxLength: 35 minLength: 1

Page 160 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

4.2 BankOperationCode

Presence: [0..1] Definition: SWIFT defined service level applies to the payment instruction. Data Type: Code When this message item is present, one of the following SWIFTServiceLevel2Code values must be used: Code Name Definition SPAY 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

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: Code When this message item is present, one of the following Instruction1Code values must be used: Code Name Definition PBEN 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

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

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

Presence: [0..1] Definition: Amount of money transferred between the instructing agent and instructed agent. Data Type: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.

Page 161 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.7 Debtor

For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section 4.8 DebtorAccount

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 Mult. Represent./ Type Identification [1..1] Type [0 ..1] Code Currency [0..1] Code Name [0..1] Text

For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section 4.9 IntermediarySettlementAgent

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 Mult. Represent./ Type FinancialInstitutionIdentification [1..1] BranchIdentification [0..1]

Page 162 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section 4.10 LastSettlementAgent

For additional Type information, please refer to BranchAndFinancialInstitutionIdentification p.235 in 'Message Item Types' section 4.11 PaymentScheme

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 Mult. Represent./ Type 4.12 {Or Code [1..1] Code 4.13 Or} ProprietaryInformation [1..1] Text

4.12 Code

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: Code One of the following CashClearingSystem2Code values must be used: Code Name Definition ACH 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.

Page 163 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Code Name Definition RTG RTGS Real Time Gross Settlement System. Payment system that simultaneously clears individual transfers and settles them in central bank money.

4.13 ProprietaryInformation

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: Max35Text Format: maxLength: 35 minLength: 1 4.14 BeneficiaryInstitutionAccount

For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section 4.15 Creditor

Presence: [0..1] Definition: Entity involved in an activity. Type: This message item is composed of the following PartyIdentification1 element(s): Or Message Item Mult. Represent./ Type Name [0..1] Text PostalAddress [0..1] Identification [0..1]

For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section

Page 164 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

4.16 CreditorAccount

For additional Type information, please refer to CashAccount3 p.232 in 'Message Item Types' section 4.17 RemittanceInformation

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 Mult. Represent./ Type 4.18 {Or Unstructured [1..1] Text 4.19 Or} Structured [1..1]

4.18 Unstructured

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: Max140Text Format: maxLength: 140 minLength: 1 4.19 Structured

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 Mult. Represent./ Type 4.20 ReferredDocumentType [0..1] Code

Page 165 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Index Or Message Item Mult. Represent./ Type 4.21 ReferredDocumentRelatedDate [0..1] DateTime 4.22 ReferredDocumentAmount [0..n] 4.28 DocumentReferenceNumber [0..1] Text 4.29 CreditorReference [0..1] Text 4.30 Invoicer [0..1] + 4.31 Invoicee [0..1] +

4.20 ReferredDocumentType

Page 166 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

4.21 ReferredDocumentRelatedDate

Presence: [0..1] Definition: Date associated with the referred document, eg, date of issue. Data Type: ISODate 4.22 ReferredDocumentAmount

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 Mult. Represent./ Type 4.23 {Or DuePayableAmount [1..1] Amount 4.24 Or DiscountAppliedAmount [1..1] Amount 4.25 Or RemittedAmount [1..1] Amount 4.26 Or CreditNoteAmount [1..1] Amount 4.27 Or} TaxAmount [1..1] Amount

4.23 DuePayableAmount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.24 DiscountAppliedAmount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18

Page 167 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.25 RemittedAmount

Presence: [1..1] This message item is part of choice 4.22 ReferredDocumentAmount. Definition: Amount of money remitted for the referred document. Data Type: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.26 CreditNoteAmount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.27 TaxAmount

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3}

Page 168 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Rule(s): CurrencyCode ValidationByTable 4.28 DocumentReferenceNumber

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.

For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section 4.31 Invoicee

Page 169 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Or Message Item Mult. Represent./ Type PostalAddress [0..1] Identification [0..1]

For additional Type information, please refer to PartyIdentification1 p.259 in 'Message Item Types' section 4.32 Purpose

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 Mult. Represent./ Type 4.33 {Or Proprietary [1..1] Text 4.34 Or} Code [1..1] Code

4.33 Proprietary

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: Max35Text Format: maxLength: 35 minLength: 1 4.34 Code

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: Code One of the following PaymentPurpose1Code values must be used: Code Name Definition ADVA 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 UnemploymentDisabilityBe Transaction is related to a payment to a person who is nefit unemployed/disabled. BONU BonusPayment. Transaction is related to payment of a bonus. CASH CashManagementTransfer Transaction is a general cash management instruction.

Page 170 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Code Name Definition CBFF 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 ConsumerThirdPartyConsoli Payment used by a third party who can collect funds to pay datedPayment 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 InstalmentHirePurchaseAgr Transaction is payment for an installment/hire-purchase eement 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.

Page 171 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Code Name Definition SSBE 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

4.36 Code

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: Code When this message item is present, one of the following Instruction3Code values must be used: Code Name Definition CHQB 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

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.

Page 172 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

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: Max140Text Format: maxLength: 140 minLength: 1 4.38 DetailsOfCharges

Presence: [0..1] Definition: Party(ies) liable for a charge associated with the transfer of cash. Data Type: Code When this message item is present, one of the following ChargeBearer1Code values must be used: Code Name Definition BEN 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

Presence: [0..6] Definition: Unformatted information from the sender to the receiver. Data Type: Max35Text Format: 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.

Page 173 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Unstructured Remittance /INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/ Information Final Agent Bank K, London (KKKKGB2L) Creditor Customer S (ASUPGB2L) All Supplies and Co

The following RequestToModifyPayment message is sent by Customer A to Bank A: XML Instance CUSTA20050003 CUASGB2L AAAAGB2L 2005-01-27T08:35:30 CUSTA20050003 CUSAGB2L CPAY0123456789 52317.48 /INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/ Step 2 Bank 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).

Page 174 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Step 2.1 Bank A requests the modification of the original payment instruction to Bank K.

Page 175 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Step 3 Bank 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.1 Bank K forwards additional information about the payment to Customer S.

The following AdditionalPaymentInformation message is sent by Bank K to Customer S: XML Instance I103AAAAKKKK20050127001 KKKKGB2L ASUPGB2L 2005-01-27T08:52:30 CUSTA20050003 CUSAGB2L I1030123456789 /INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/ All Supplies and Co CUSBGB2L Step 3.2 Bank K informs Bank A of the resolution of the investigation.

The following ResolutionOfInvestigation message is sent by Bank K to Bank A. XML Instance

Page 176 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

RKKKKAAAA20050127004 KKKKGB2L AAAAGB2L 2005-01-27T09:08:23 CUSTA20050003 CUSAGB2L MODI Step 3.3 Upon 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 RAAAACUSA20050127004 AAAAGB2L CUSAGB2L 2005-01-27T09:18:23 CUSTA20050003 CUSAGB2L MODI Scenario 2, resulting in a RequestToCancelPayment message Narrative Customer A checks its accounts payables. The invoices are payable to the account of Customer C with Bank W (WWWWGB2L) instead of Bank K.

Step 1 Customer 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

Page 177 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

CUSTA20050001 CUSAGB2L AAAAGB2L 2005-01-27T08:35:30 CUSTA20050002 CUSAGB2L CPAY0123456789 52317.48 WWWWGB2L Step 2 Bank 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.1 Bank 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 C103AAAAKKKK20050127001 AAAAGB2L KKKKGB2L 2005-01-27T08:43:30 CUSTA20050002 CUSAGB2L 1030123456789 52317.48

Page 178 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

AGNT 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 RCUSTA20050001 AAAAGB2L CUSAGB2L 2005-01-27T08:50:22 CUSTA20050002 CUSAGB2L C103AAAAKKKK20050127001 AAAAGB2L KKKKGB2L 2005-01-27T08:43:30 CANC Step 3 Bank 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 RC103AAAAKKKK20050127001 KKKKGB2L AAAAGB2L 2005-01-27T08:54:30 CUSTA20050002 CUSAGB2L

Page 179 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

CNCL Step 4 Upon 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 RCUSTA20050001 AAAAGB2L CUSAGB2L 2005-01-27T11:04:27 CUSTA20050002 CUSAGB2L MODI Scenario 3, resulting in a DebitAuthorisationRequest message Narrative Customer 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.

The following RequestToModifyPayment message is sent by Customer A to Bank A: XML Instance CUSTA20050001 CUASGB2L AAAAGB2L 2005-01-27T08:35:30 CUSTA20050001 CUASGB2L

Page 180 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

CPAY0123456789 52317.48 48573.96 /INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/ 20041215/GBP3743.52/20041208304712 Step 2 Bank 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.1 Bank A forwards the RequestToModifyPayment message to Bank K: XML Instance

Page 181 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Page 182 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

3743.52 Step 3.2 Bank K informs Bank A of the case assignment.

The following DebitAuthorisationResponse message is sent by Customer S to Bank K: XML Instance REP103KKKKSUPPLIES12345678901 ASUPGB2L KKKKGB2L 2005-01-27T10:55:23 CUSTA20050001 CUSAGB2L true

Page 183 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: RequestToModifyPayment

Step 5 Upon 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 A to Customer A: XML Instance RCUSTA20050001 AAAAGB2L CUSAGB2L 2005-01-27T11:04:27 CUSTA20050001 CUSAGB2L ACDA

Page 184 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation Message: ResolutionOfInvestigation Message Scope and Usage Scope The 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.

Outline The ResolutionOfInvestigation message is composed of four building blocks: A.Case Assignment This building block is mandatory. B.Case This building block is mandatory. C.Payment Instruction Extract This building block is optional.

Page 185 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

D. Investigation Status Choice This building block is optional. Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 ResolvedCase [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 3.0 Status [0..1] 3.1 {Or Confirmation [1..1] Code 3.2 Or RejectedModification [1..14] Code 3.3 Or RejectedCancellation [1..1] 3.4 ReasonCode [1..1] Code 3.5 Reason [0..1] Text 3.6 Or DuplicateOf [1..1] 3.7 Identification [1..1] Text 3.8 Creator [1..1] Identifier 3.9 ReopenCaseIndication [0..1] Indicator 3.10 Or} AssignmentCancellationConfirmation [1..1] Indicator

Page 186 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 CorrectionTransaction [0..1] 4.1 AssignerInstructionIdentification [0..1] Text 4.2 AssigneeInstructionIdentification [0..1] Text 4.3 CurrencyAmount [0..1] Amount 4.4 ValueDate [0..1] DateTime

Message Items Description

The following section identifies the elements of the ResolutionOfInvestigation message. 1.0 Assignment

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 Mult. Represent./ Type 1.1 Identification [1..1] Text 1.2 Assigner [1..1] Identifier 1.3 Assignee [1..1] Identifier 1.4 CreationDateTime [1..1] DateTime

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Page 187 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

CORPBE22 1.3 Assignee

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 ResolvedCase

Presence: [1..1] Definition: Identifies a resolved case. Type: The ResolvedCase block is composed of the following Case element(s): Index Or Message Item Mult. Represent./ Type 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

Data Type: AnyBICIdentifier

Page 188 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

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 Mult. Represent./ Type 3.1 {Or Confirmation [1..1] Code 3.2 Or RejectedModification [1..14] Code 3.3 Or RejectedCancellation [1..1] 3.6 Or DuplicateOf [1..1] 3.10 Or} AssignmentCancellationConfirmation [1..1] Indicator

3.1 Confirmation

Presence: [1..1] This message item is part of choice 3.0 Status. Definition: Indicates the status of an investigation. Data Type: Code One of the following InvestigationExecutionConfirmation1Code values must be used: Code Name Definition ACDA 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.

Page 189 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

3.2 RejectedModification

Presence: [1..14] This message item is part of choice 3.0 Status. Definition: Indicates the reason for rejecting a modification. Data Type: Code One of the following PaymentModificationRejection1Code values must be used: Code Name Definition UM01 UnableToModifyRelatedRef RelatedReference cannot be modified. erence UM02 UnableToModifyBankOpera BankOperationCode cannot be modified. tionCode UM03 UnableToModifyInstruction InstructionCode cannot be modified. Code UM04 UnableToModifyRequested RequestedExecutionDate cannot be modified. ExecutionDate UM05 UnableToModifyValueDate ValueDate cannot be modified. UM06 UnableToModifyInterbankS InterbankSettlementAccount cannot be modified. ettlementAccount UM07 UnableToModifyDebtor Debtor cannot be modified. UM08 UnableToModifyDebtorAcc DebtorAccount cannot be modified. ount UM09 UnableToModifyReceiverC ReceiverCorrespondent cannot be modified. orrespondent UM10 UnableToModifyThirdReim ThirdReimbursementInstitution cannot be modified. bursementInstitution UM11 UnableToModifyPaymentSc PaymentScheme cannot be modified. heme UM12 UnableToModifyAccountof AccountOfBeneficiaryInstitution cannot be modified. BeneficiaryInstitution UM13 UnableToModifyCreditor Creditor cannot be modified.

Page 190 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

Code Name Definition UM14 UnableToModifyCreditorAc CreditorAccount cannot be modified. count UM15 UnableToModifyRemittance RemittanceInformation cannot be modified. Information UM16 UnableToModifyPaymentPu PaymentPurpose cannot be modified. rpose UM17 UnableToModifyDetailsOfC DetailsOfCharges cannot be modified. harges UM18 UnableToModifySenderToR SenderToReceiver cannot be modified. eceiverInformation UM19 UnableToModifyInstruction InstructionForFinalAgent cannot be modified. ForFinalAgent UM20 InstructionCancelledSubmit Used to inform of cancellation and request a new payment NewInstruction instruction. This should only be used if an agent does not want to modify a pending payment. UM21 UnableToModifySubmitCan Modification is not possible and the cancellation is cellation requested.

3.3 RejectedCancellation

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 Mult. Represent./ Type 3.4 ReasonCode [1..1] Code 3.5 Reason [0..1] Text

3.4 ReasonCode

Presence: [1..1] Definition: Justification for the rejection of the cancellation. Data Type: Code One of the following PaymentCancellationRejection1Code values must be used: Code Name Definition AGNT 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.

Page 191 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

3.5 Reason

Presence: [0..1] Definition: Free text justification for rejecting a cancellation. Data Type: Max140Text Format: maxLength: 140 minLength: 1 3.6 DuplicateOf

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 Mult. Represent./ Type 3.7 Identification [1..1] Text 3.8 Creator [1..1] Identifier 3.9 ReopenCaseIndication [0..1] Indicator

3.7 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 3.8 Creator

Presence: [1..1] Definition: Party that created the case.

Page 192 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

3.9 ReopenCaseIndication

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: Yes MeaningWhenFalse: No 4.0 CorrectionTransaction

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 Mult. Represent./ Type 4.1 AssignerInstructionIdentification [0..1] Text 4.2 AssigneeInstructionIdentification [0..1] Text 4.3 CurrencyAmount [0..1] Amount 4.4 ValueDate [0..1] DateTime

4.1 AssignerInstructionIdentification

Presence: [0..1]

Page 193 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

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: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode. Format: CurrencyAndAmount fractionDigits: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 4.4 ValueDate

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

Page 194 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: ResolutionOfInvestigation

The following ResolutionOfInvestigation message is sent by Bank F to Customer D: XML Instance CONFFFFFCANC20050423001 FFFFDEFF DDDDDEFF 2005-04-22T10:23:42 DDDD20050423001 DDDDDEFF CNCL

Page 195 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply Message: UnableToApply Message Scope and Usage Scope The 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 characteristics The UnableToApply message has the following main characteristics: Case Identification and Reason Code The 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 Identification The 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).

Page 196 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

Unable To Apply Justification The 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. Outline The UnableToApply message is composed of four building blocks: A.Case Assignment This building block is mandatory. B.Case This building block is mandatory. C.Payment Instruction Extract This building block is mandatory. D.Unable to Apply Justification Choice This building block is mandatory. Message Structure

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 2.0 Case [1..1] 2.1 Identification [1..1] Text 2.2 Creator [1..1] Identifier 2.3 ReopenCaseIndication [0..1] Indicator

Page 197 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

Index Or Message Item Mult. Represent./ Rule/ Type Guid. No. 4.0 Justification [1..1] 4.1 {Or AnyInformation [1..1] Indicator 4.2 Or} MissingOrIncorrectInformation [1..1] 4.3 MissingInformation [0..10] Code 4.4 IncorrectInformation [0..10] Code

Message Items Description

The following section identifies the elements of the UnableToApply message. 1.0 Assignment

1.1 Identification

Presence: [1..1] Definition: Identification of an assignment within a case. Data Type: Max35Text Format: maxLength: 35 minLength: 1

Page 198 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

1.2 Assigner

Presence: [1..1] Definition: Party that assigns the case to another party. This is also the sender of the message.

Presence: [1..1] Definition: Party that the case is assigned to. This is also the receiver of the message.

Presence: [1..1] Definition: Date and time at which the assignment was created. Data Type: ISODateTime 2.0 Case

2.1 Identification

Presence: [1..1] Definition: Unique id assigned by the case creator.

Page 199 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

Data Type: Max35Text Format: maxLength: 35 minLength: 1 Example: Case001 2.2 Creator

Presence: [1..1] Definition: Party that created the case.

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 Mult. Represent./ Type 3.1 AssignerInstructionIdentification [0..1] Text 3.2 AssigneeInstructionIdentification [0..1] Text 3.3 CurrencyAmount [0..1] Amount 3.4 ValueDate [0..1] DateTime

3.1 AssignerInstructionIdentification

Presence: [0..1] Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner. Data Type: Max35Text Format: maxLength: 35

Page 200 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

minLength: 1 3.2 AssigneeInstructionIdentification

Presence: [0..1] Definition: Value date of the payment. Data Type: ISODateTime 4.0 Justification

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 Mult. Represent./ Type 4.1 {Or AnyInformation [1..1] Indicator 4.2 Or} MissingOrIncorrectInformation [1..1]

4.1 AnyInformation

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

Page 201 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

MeaningWhenFalse: No 4.2 MissingOrIncorrectInformation

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 Mult. Represent./ Type 4.3 MissingInformation [0..10] Code 4.4 IncorrectInformation [0..10] Code

4.3 MissingInformation

Presence: [0..10] Definition: Indicates the missing information. Data Type: Code When this message item is present, one of the following UnableToApplyMissingInfo1Code values must be used: Code Name Definition MS01 MissingRemittanceInformati RemittanceInformation is missing. on MS02 MissingSenderToReceiverIn SenderToReceiverInformation is missing. formation MS03 MissingDebtor Debtor is missing. MS04 MissingDebtorAccount DebtorAccount is missing. MS05 MissingFirstAgent FirstAgent is missing. MS06 MissingAmount Amount is missing. MS07 MissingNostroVostroAccou Nostro_VostroAccount is missing. nt MS08 MissingIntermediary Intermediary is missing. MS09 MissingReimbursementAge ReimbursementAgent (53) is missing. nt1 MS10 MissingReimbursementAge ReimbursementAgent (54) is missing. nt2 MS11 MissingReimbursementAge ReimbursementAgent (55) is missing. nt MS12 MissingCreditor Creditor is missing. MS13 MissingCreditorAccount CreditorAccount is missing. MS14 MissingInstruction Indicates the payment instruction (MT103) is missing.

Page 202 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

4.4 IncorrectInformation

Presence: [0..10] Definition: Indicates the incorrect information. Data Type: Code When this message item is present, one of the following UnableToApplyIncorrectInfo1Code values must be used: Code Name Definition IN01 IncorrectRelatedReference RelatedReference is incorrect. IN02 IncorrectBankOperationCod BankOperationCode is incorrect. e IN03 IncorrectInstructionCode InstructionCode is incorrect. IN04 IncorrectRequestedExecutio RequestedExecutionDate is incorrect. nDate IN05 IncorrectValueDate ValueDate is incorrect. IN06 IncorrectInterbankSettledA InterbankSettledAmount is incorrect. mount IN07 IncorrectDebtor Debtor is incorrect. IN08 IncorrectDebtorAccount DebtorAccount is incorrect. IN09 IncorrectReceiverCorrespon ReceiverCorrespondent is incorrect. dent IN10 IncorrectThirdReimburseme ThirdReimbursementInstitution is incorrect. ntInstitution IN11 IncorrectPaymentScheme PaymentScheme is incorrect. IN12 IncorrectAccountOfBenefici AccountOfBeneficiaryInstitution is incorrect. aryInstitution IN13 IncorrectCreditor Creditor is incorrect. IN14 IncorrectCreditorAccount CreditorAccount is incorrect. IN15 IncorrectRemittanceInforma RemittanceInformation is incorrect. tion IN16 IncorrectPaymentPurpose PaymentPurpose is incorrect. IN17 IncorrectDetailsOfCharges DetailsOfCharges is incorrect. IN18 IncorrectSenderToReceiverI SenderToReceiverInformation is incorrect. nformation IN19 IncorrectInstructionForFinal InstructionForFinalAgent is incorrect. Agent MM20 MismatchCreditorNameAcc Name and Account of Creditor mismatched. ount MM21 MismatchDebtorNameAcco Name and Account of Debtor mismatched. unt MM22 MismatchFinalAgentName Name and Account of FinalAgent mismatched. Account

Page 203 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply 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 3 Creditor'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 1 Customer B asks Bank M for more information about the entry.

The following UnableToApply message is sent by Customer B to Bank M: XML Instance UTACOMPAY12345050523001 BBBBGB2L MMMMGB2L 2005-05-24T08:35:30 BBBBGB2L-20050523-001 BBBBGB2L COMPAY12345050523001 2005052304217018 52317.48

Page 204 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

2005-05-23T00:00:00 true Step 2 Bank 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.1 The following UnableToApply message is sent by Bank M to Bank C: XML Instance UTABBBB050523-01 MMMMGB2L CCCCGB2L 2005-05-24T08:52:13 20050523001 BBBBGB2L 2005052304217018 1030123456789 52317.48 2005-05-23T00:00:00 true Step 2.2 Bank 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 CABBBB050523001 MMMMGB2L BBBBGB2L 2005-05-24T08:52:44

Page 205 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

20050523001 BBBBGB2L UTABBBB050523001 MMMMGB2L CCCCGB2L 2005-01-27T08:52:13 FTHI Step 3 Bank 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.1 Bank 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 UTA1030123456789 CCCCGB2L AAAAGB2L 2005-05-24T09:10:31 20050523001 BBBBGB2L 1030123456789 200505219887234 52317.48 2005-05-23T00:00:00 true Step 3.2 Bank C informs Bank M of the case assignment to Customer A.

Page 206 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

The following NotificationOfCaseAssignment message is sent by Bank C to Bank M: XML Instance INF10301123456789 CCCCGB2L MMMMGB2L 2005-05-24T09:22:44 20050523001 BBBBGB2L UTA10301123456789 CCCCGB2L AAAAGB2L 2005-01-27T09:10:31 FTHI Step 3.3 Upon 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 INFCABBBB050523001 MMMMGB2L BBBBGB2L 2005-05-24T09:25:12 20050523001 BBBBGB2L UTA10301123456789 CCCCGB2L AAAAGB2L 2005-01-27T09:10:31 FTHI

Page 207 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

Step 4 Upon 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.1 Customer A requests the cancellation of the payment instruction.

The following RequestToCancelPayment message is sent by Customer A to Bank C: XML Instance UTACANC10301123456789 AAAAGB2L CCCCGB2L 2005-05-24T11:19:23 20050523001 BBBBGB2L 200505219887234 1030123456789 52317.48 2005-05-23T00:00:00 UPAY Step 4.2 Bank C forwards the RequestToCancelPayment message to Bank M.

The following RequestToCancelPayment message is sent by Bank C to Bank M: XML Instance CANC10301123456789 CCCCGB2L MMMMGB2L 2005-05-24T11:22:59 20050523001 BBBBGB2L

Page 208 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

1030123456789 20050523-04217-018 52317.48 2005-05-23T00:00:00 UPAY Step 4.3 Bank M requests the debit authorisation from Customer B.

The following DebitAuthorisationRequest message is sent by Bank M to Customer B: XML Instance DARCOMPAY12345050523001 MMMMGB2L BBBBGB2L 2005-05-24T11:30:06 20050523001 BBBBGB2L COMPAY12345050523001 52317.48 2005-05-23T00:00:00 UPAY 52317.48 Step 5 Customer 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 REPDARCOMPAY12345050523001 BBBBGB2L

Page 209 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

MMMMGB2L 2005-05-24T11:45:06 20050523001 BBBBGB2L true Step 5.2 Bank 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 CONFCANC10301123456789 MMMMGB2L CCCCGB2L 2005-05-24T11:53:07 20050523001 BBBBGB2L ACDA 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 CONFCANC10301123456789 CCCCGB2L AAAAGB2L 2005-05-24T11:58:13 20050523001 BBBBGB2L ACDA

Page 210 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

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 4 Customer 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 UTAINFO10301123456789 AAAAGB2L CCCCGB2L 2005-05-24T11:25:32 20050523001 BBBBGB2L 200505219887234 1030123456789 52317.48 2005-05-23T00:00:00 /INV/20050301/ 75680.35 Customer B 7265658971233

Page 211 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

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.1 Bank C sends the additional payment information to Bank M.

The following AdditionalPaymentInformation message is sent by Bank C to Bank M: XML Instance UTABBBB050523001INFO CCCCGB2L MMMMGB2L 2005-05-24T11:27:54 20050523001 BBBBGB2L 200505219887234 1030123456789 52317.48 2005-05-23T00:00:00 /INV/20050301/ 75680.35 Customer B 7265658971233 Step 5.2 Bank 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

Page 212 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

REPUTACOMPAY12345050523001 MMMMGB2L BBBBGB2L 2005-05-24T11:45:04 20050523001 BBBBGB2L 200505219887234 1030123456789 52317.48 2005-05-23T00:00:00 /INV/20050301/ 75680.35 Customer B 7265658971233

Scenario 3, resulting in a RequestForModification 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 requests the modification of the payment instruction to Bank C. Step 4 Customer 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

Page 213 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

UTAMODI10301123456789 AAAAGB2L CCCCGB2L 2005-05-24T11:25:32 20050523001 BBBBGB2L 1030123456789 52317.48 /INV/20050512/GBP23257./20050500104712//20050513/29060.48/20050100204712/ Step 4.2 Bank C forwards the request for modification to Bank M.

The following RequestToModifyPayment message is sent by Bank C to Bank M: XML Instance UTAMODI10301123456789 CCCCGB2L MMMMGB2L 2005-05-24T11:29:44 20050523001 BBBBGB2L 1030123456789 52317.48 /INV/20050512/GBP23257./20050500104712//20050513/29060.48/20050100204712/

Page 214 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

Step 5 Upon 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 MODICOMPAY12345050523001 MMMMGB2L BBBBGB2L 2005-05-24T11:35:42 20050523001 BBBBGB2L COMPAY12345050523001 52317.48 /INV/20050512/GBP23257./20050500104712//20050513/29060.48/20050100204712/ Step 6 The 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 CONFMODICOMPAY1234505052301 BBBBGB2L MMMMGB2L 2005-05-24T11:58:13 20050523001 BBBBGB2L

Page 215 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

MODI Step 6.2 Bank M informs Bank C of the resolution of the case.

The following ResolutionOfInvestigation message is sent by Bank M to Bank C: XML Instance CONFUTAMODI10301123456789 MMMMGB2L CCCCGB2L 2005-05-24T12:34:22 20050523001 BBBBGB2L MODI Step 6.3 Bank B informs Bank C of the resolution of the case.

The following ResolutionOfInvestigation message is sent by Bank B to Bank C: XML Instance CONFUTAMODI10301123456789 BBBBGB2L CCCCGB2L 2005-05-24T12:43:58 20050523001 BBBBGB2L MODI

Scenario 4 The 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

Page 216 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply 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. Narrative Bank 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 UTA1239876540123050116 BBBBDEMM DDDDDEFF 2005-01-16T08:35:30 1239876540123050116001 BBBBDEMM 1239876540123 2005011602312003 12439.57 2005-01-16T00:00:00 true

Page 217 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

Step 2 Bank 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.1 Bank D forwards the UnableToApply to Bank U.

The following UnableToApply message is sent by Bank D to Bank U: XML Instance UTA1239876540123050116 DDDDDEFF UUUUUS33 2005-01-16T08:44:23 1239876540123050116001 BBBBDEMM 2005011602312003 123458760501 12439.57 2005-01-16T00:00:00 true Step 2.2 Bank 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 REPUTA1239876540123050116 DDDDDEFF BBBBDEMM 2005-01-16T08:48:30 1239876540123050116001 BBBBDEMM

Page 218 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

UTA1239876540123050116 DDDDDEFF UUUUUS33 2005-01-16T08:44:23 FTHI Step 3 Bank 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.1 Bank U asks Bank Z to investigate.

The following UnableToApply message is sent by Bank U to Bank Z: XML Instance FWUTA1239876540123050116 UUUUUS33 ZZZZUS33 2005-01-16T09:02:45 1239876540123050116001 BBBBDEMM 123458760501 12439.57 2005-01-16T00:00:00 true Step 3.2 Bank 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 INFOUTA1239876540123050116 UUUUUS33 DDDDDEFF

Page 219 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

2005-01-16T09:05:43 1239876540123050116001 BBBBDEMM FWUTA1239876540123050116 UUUUUS33 ZZZZUS33 2005-01-16T09:02:45 FTHI 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 FUREPUTA1239876540123050116 DDDDDEFF BBBBDEMM 2005-01-16T09:13:23 1239876540123050116001 BBBBDEMM FWUTA1239876540123050116 UUUUUS33 ZZZZUS33 2005-01-16T09:02:45 FTHI Step 4 Bank 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).

Page 220 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

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.1 Bank Z informs Bank U that the case can be closed.

The following ResolutionOfInvestigation message is sent by Bank Z to Bank U: XML Instance

ENDFWUTA1239876540123050116 ZZZZUS33 UUUUUS33 2005-01-16T11:03:48 1239876540123050116001 DDDDDEMM IPYI CORR1239876540123 12439.57 2005-01-16T00:00:00 Step 4.2 Bank U forwards the information to Bank D.

The following ResolutionOfInvestigation message is sent by Bank U to Bank D: XML Instance CLOSEUTA1239876540123050116 UUUUUS33 DDDDDEFF 2005-01-16T11:25:46 1239876540123050116001 DDDDDEMM IPYI CORR1239876540123

Page 221 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message: UnableToApply

12439.57 2005-01-16T00:00:00 Step 4.3 Bank D forwards the resolution of investigation information to Bank B.

The following ResolutionOfInvestigation message is sent by Bank D to Bank B: XML Instance CLOSEUTA1239876540123050116 DDDDDEFF BBBBDEMM 2005-01-16T11:34:26 1239876540123050116001 BBBBDEMM IPYI CORR1239876540123 12439.57 2005-01-16T00:00:00

Page 222 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types Message Item Types Data Types Data Types Index 1 Amount 1.1 CurrencyAndAmount 1.2 ImpliedCurrencyAndAmount 2 Date Time 2.1 ISODate 2.2 ISODateTime 3 Identifier 3.1 AnyBICIdentifier 3.2 AustrianBankleitzahlIdentifier 3.3 BBANIdentifier 3.4 BEIIdentifier 3.5 BICIdentifier 3.6 CHIPSParticipantIdentifier 3.7 CHIPSUniversalIdentifier 3.8 CanadianPaymentsARNIdentifier 3.9 CountryCode 3.10 CurrencyCode 3.11 DunsIdentifier 3.12 EANGLNIdentifier 3.13 ExtensiveBranchNetworkIdentifier 3.14 FedwireRoutingNumberIdentifier 3.15 GermanBankleitzahlIdentifier 3.16 HongKongBankIdentifier 3.17 IBANIdentifier 3.18 IrishNSCIdentifier 3.19 ItalianDomesticIdentifier 3.20 LanguageCode 3.21 MICIdentifier 3.22 NationalityCode 3.23 NewZealandNCCIdentifier 3.24 PortugueseNCCIdentifier 3.25 RussianCentralBankIdentificationCodeIdentifier 3.26 SmallNetworkIdentifier 3.27 SouthAfricanNCCIdentifier 3.28 SpanishDomesticInterbankingIdentifier 3.29 SwissBCIdentifier 3.30 SwissSICIdentifier 3.31 UKDomesticSortCodeIdentifier 3.32 UPICIdentifier 4 Quantity: Number and Decimal Number 4.1 Number

Page 223 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

5 Rate 5.1 PercentageRate 6 Text 6.1 Max10Text 6.2 Max128Text 6.3 Max140Text 6.4 Max16Text 6.5 Max256Text 6.6 Max350Text 6.7 Max35Text 6.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: 5 minInclusive: 0 totalDigits: 18 CurrencyCode [A-Z]{3,3} Rule(s): CurrencyCode ValidationByTable 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: 5 minInclusive: 0 totalDigits: 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

Page 224 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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

Page 225 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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).

Page 226 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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

Page 227 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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

Page 228 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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}

Page 229 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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: 0 totalDigits: 18 Example: 123456789012345678

Page 230 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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: 10 totalDigits: 11 Example: 35 6 Text 6.1 Max10Text

Definition: Specifies a character string with a maximum length of 10 characters. Format: maxLength: 10 minLength: 1 Example: AZERTGFDXC 6.2 Max128Text

Definition: Specifies a character string with a maximum length of 128 characters. Format: maxLength: 128 minLength: 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: 140 minLength: 1 Example: ABCDEFGHIJKLMNOPQRST1234567890123456789012345678901234567890123456 789012345678901234567890123456789012345678901234567890123456789012345678 90 6.4 Max16Text

Definition: Specifies a character string with a maximum length of 16 characters. Format: maxLength: 16 minLength: 1 Example: ABCdEFghIJKLMNO? 6.5 Max256Text

Definition: Specifies a character string with a maximum length of 256 characters. Format: maxLength: 256 minLength: 1 Example: ABCDEFGHIJKLMNOPQRST1234567890123456789012345678901234567890123456 789012345678901234567890123456789012345678901234567890123456789012345678 90

Page 231 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

6.6 Max350Text

Definition: Specifies a character string with a maximum length of 350 characters. Format: maxLength: 350 minLength: 1 Example: 123456789012345678901234567890123456789012345678901234567890123456789012 345678901234567890123456789012345678901234567890123456789012345678901234 567890123456789012345678901234567890123456789012345678901234567890123456 789012345678901234567890123456789012345678901234567890123456789012345678 90123456789012345678901234567890123456789012345678901234567890 6.7 Max35Text

Definition: Specifies a character string with a maximum length of 35 characters. Format: maxLength: 35 minLength: 1 Example: ABCDEFGHIJKLMNOPQRST123456789012345 6.8 Max70Text

Definition: Specifies a character string with a maximum length of 70characters. Format: maxLength: 70 minLength: 1 Example: A string value of maximum 70 characters. End Points End Points Index 1 Account identification 1.1 CashAccount3 2 Financial institution identification 2.1 BranchAndFinancialInstitutionIdentification 3 Party identification 3.1 Intermediary1 3.2 PartyIdentification1 End Points Description 1 Account identification 1.1 CashAccount3

CashAccount3 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.

Page 232 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Type: The following CashAccount3 element(s) must be used: Ref Or Message Item Mult. Represent./ Type 1.1.0 Identification [1..1] 1.1.1 {Or IBAN [1..1] Identifier 1.1.2 Or BBAN [1..1] Identifier 1.1.3 Or UPIC [1..1] Identifier 1.1.4 Or} DomesticAccount [1..1] 1.1.5 Identification [1..1] Text 1.1.6 Type [0 ..1] Code 1.1.7 Currency [0..1] Code 1.1.8 Name [0..1] Text

1.1.0 Identification

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 Mult. Represent./ Type 1.1.1 {Or IBAN [1..1] Identifier 1.1.2 Or BBAN [1..1] Identifier 1.1.3 Or UPIC [1..1] Identifier 1.1.4 Or} DomesticAccount [1..1]

1.1.1 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: IBANIdentifier 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.

1.1.2 BBAN

Presence: [1..1] This message item is part of choice 1.1.0 Identification.

Page 233 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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: BBANIdentifier Format: [a-zA-Z0-9]{1,30} 1.1.3 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: UPICIdentifier Format: [0-9]{8,17} 1.1.4 DomesticAccount

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 Mult. Represent./ Type 1.1.5 Identification [1..1] Text

1.1.5 Identification

Presence: [1..1] Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier. Data Type: Max35Text Format: maxLength: 35 minLength: 1 1.1.6 Type

Presence: [0 ..1] Definition: Nature, or use, of the account. Data Type: Code When this message item is present, one of the following CashAccountType3Code values must be used: Code Name Definition CACC 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.

Page 234 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Code Name Definition SACC 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

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: CurrencyCode Format: [A-Z]{3,3} Rule(s): ValidationByTable 1.1.8 Name

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: Max70Text Format: maxLength: 70 minLength: 1 2 Financial institution identification 2.1 BranchAndFinancialInstitutionIdentification

BranchAndFinancialInstitutionIdentification 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 Mult. Represent./ Type 2.1.0 FinancialInstitutionIdentification [1..1] 2.1.1 BIC [0..1] Identifier 2.1.2 ClearingSystemMemberIdentification [0..1] 2.1.3 {Or CHIPSUniversalIdentification [1..1] Identifier 2.1.4 Or NewZealandNCCIdentification [1..1] Identifier

Page 235 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Ref Or Message Item Mult. Represent./ Type 2.1.5 Or IrishNSCIdentification [1..1] Identifier 2.1.6 Or UKDomesticSortCode [1..1] Identifier 2.1.7 Or CHIPSParticipantIdentification [1..1] Identifier 2.1.8 Or SwissBCIdentification [1..1] Identifier 2.1.9 Or FedwireRoutingNumberIdentification [1..1] Identifier 2.1.10 Or PortugueseNCCIdentification [1..1] Identifier 2.1.11 Or RussianCentralBankIdentificationCode [1..1] Identifier 2.1.12 Or ItalianDomesticIdentificationCode [1..1] Identifier 2.1.13 Or AustrianBankleitzahlIdentification [1..1] Identifier 2.1.14 Or CanadianPaymentsAssociationRoutingN [1..1] Identifier umberIdentification 2.1.15 Or SwissSICIdentification [1..1] Identifier 2.1.16 Or GermanBankleitzahlIdentification [1..1] Identifier 2.1.17 Or SpanishDomesticInterbankingIdentificati [1..1] Identifier on 2.1.18 Or SouthAfricanNCCIdentification [1..1] Identifier 2.1.19 Or HongKongBankCode [1..1] Identifier 2.1.20 Or AustralianExtensiveBranchNetworkIdent [1..1] Identifier ification 2.1.21 Or} AustralianSmallNetworkIdentification [1..1] Identifier 2.1.22 Name [0..1] Text 2.1.23 PostalAddress [0..1] 2.1.24 AddressType [0..1] Code 2.1.25 AddressLine [0..5] Text 2.1.26 StreetName [0..1] Text 2.1.27 BuildingNumber [0..1] Text 2.1.28 PostCode [0..1] Text 2.1.29 TownName [0..1] Text 2.1.30 CountrySubDivision [0..1] Text 2.1.31 Country [1..1] Code 2.1.32 ProprietaryIdentification [0..1] 2.1.33 Identification [1..1] Text 2.1.34 Issuer [0..1] Text 2.1.35 BranchIdentification [0..1] 2.1.36 Identification [0..1] Text 2.1.37 Name [0..1] Text

Page 236 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Ref Or Message Item Mult. Represent./ Type 2.1.38 PostalAddress [0..1] 2.1.39 AddressType [0..1] Code 2.1.40 AddressLine [0..5] Text 2.1.41 StreetName [0..1] Text 2.1.42 BuildingNumber [0..1] Text 2.1.43 PostCode [0..1] Text 2.1.44 TownName [0..1] Text 2.1.45 CountrySubDivision [0..1] Text 2.1.46 Country [1..1] Code

2.1.0 FinancialInstitutionIdentification

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 Mult. Represent./ Type 2.1.1 BIC [0..1] Identifier 2.1.2 ClearingSystemMemberIdentification [0..1] 2.1.22 Name [0..1] Text 2.1.23 PostalAddress [0..1] 2.1.32 ProprietaryIdentification [0..1]

2.1.1 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: BICIdentifier 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.

2.1.2 ClearingSystemMemberIdentification

Presence: [0..1]

Page 237 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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 Mult. Represent./ Type 2.1.3 {Or CHIPSUniversalIdentification [1..1] Identifier 2.1.4 Or NewZealandNCCIdentification [1..1] Identifier 2.1.5 Or IrishNSCIdentification [1..1] Identifier 2.1.6 Or UKDomesticSortCode [1..1] Identifier 2.1.7 Or CHIPSParticipantIdentification [1..1] Identifier 2.1.8 Or SwissBCIdentification [1..1] Identifier 2.1.9 Or FedwireRoutingNumberIdentification [1..1] Identifier 2.1.10 Or PortugueseNCCIdentification [1..1] Identifier 2.1.11 Or RussianCentralBankIdentificationCode [1..1] Identifier 2.1.12 Or ItalianDomesticIdentificationCode [1..1] Identifier 2.1.13 Or AustrianBankleitzahlIdentification [1..1] Identifier 2.1.14 Or CanadianPaymentsAssociationRoutingNumbe [1..1] Identifier rIdentification 2.1.15 Or SwissSICIdentification [1..1] Identifier 2.1.16 Or GermanBankleitzahlIdentification [1..1] Identifier 2.1.17 Or SpanishDomesticInterbankingIdentification [1..1] Identifier 2.1.18 Or SouthAfricanNCCIdentification [1..1] Identifier 2.1.19 Or HongKongBankCode [1..1] Identifier 2.1.20 Or AustralianExtensiveBranchNetworkIdentificat [1..1] Identifier ion 2.1.21 Or} AustralianSmallNetworkIdentification [1..1] Identifier

2.1.3 CHIPSUniversalIdentification

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: CHIPSUniversalIdentifier Format: CH[0-9]{6,6} 2.1.4 NewZealandNCCIdentification

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).

Page 238 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Data Type: NewZealandNCCIdentifier Format: NZ[0-9]{6,6} 2.1.5 IrishNSCIdentification

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: IrishNSCIdentifier Format: IE[0-9]{6,6} 2.1.6 UKDomesticSortCode

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: UKDomesticSortCodeIdentifier Format: SC[0-9]{6,6} 2.1.7 CHIPSParticipantIdentification

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: CHIPSParticipantIdentifier Format: CP[0-9]{4,4} 2.1.8 SwissBCIdentification

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: SwissBCIdentifier Format: SW[0-9]{3,5} 2.1.9 FedwireRoutingNumberIdentification

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: FedwireRoutingNumberIdentifier Format: FW[0-9]{9,9} 2.1.10 PortugueseNCCIdentification

Presence: [1..1]

Page 239 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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: PortugueseNCCIdentifier Format: PT[0-9]{8,8} 2.1.11 RussianCentralBankIdentificationCode

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: RussianCentralBankIdentificationCodeIdentifier Format: RU[0-9]{9,9} 2.1.12 ItalianDomesticIdentificationCode

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: ItalianDomesticIdentifier Format: IT[0-9]{10,10} 2.1.13 AustrianBankleitzahlIdentification

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: AustrianBankleitzahlIdentifier Format: AT[0-9]{5,5} 2.1.14 CanadianPaymentsAssociationRoutingNumberIdentification

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: CanadianPaymentsARNIdentifier Format: CA[0-9]{9,9} 2.1.15 SwissSICIdentification

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: SwissSICIdentifier Format: SW[0-9]{6,6}

Page 240 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

2.1.16 GermanBankleitzahlIdentification

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: GermanBankleitzahlIdentifier Format: BL[0-9]{8,8} 2.1.17 SpanishDomesticInterbankingIdentification

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: SpanishDomesticInterbankingIdentifier Format: ES[0-9]{8,9} 2.1.18 SouthAfricanNCCIdentification

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: SouthAfricanNCCIdentifier Format: ZA[0-9]{6,6} 2.1.19 HongKongBankCode

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: HongKongBankIdentifier Format: HK[0-9]{3,3} 2.1.20 AustralianExtensiveBranchNetworkIdentification

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: ExtensiveBranchNetworkIdentifier Format: AU[0-9]{6,6} 2.1.21 AustralianSmallNetworkIdentification

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).

Page 241 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Data Type: SmallNetworkIdentifier Format: AU[0-9]{6,6} 2.1.22 Name

Presence: [0..1] Definition: Name by which a party is known and which is usually used to identify that party. Data Type: Max70Text Format: maxLength: 70 minLength: 1 2.1.23 PostalAddress

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 Mult. Represent./ Type 2.1.24 AddressType [0..1] Code 2.1.25 AddressLine [0..5] Text 2.1.26 StreetName [0..1] Text 2.1.27 BuildingNumber [0..1] Text 2.1.28 PostCode [0..1] Text 2.1.29 TownName [0..1] Text 2.1.30 CountrySubDivision [0..1] Text 2.1.31 Country [1..1] Code

2.1.24 AddressType

Presence: [0..1] Definition: Identifies the nature of the postal address. Data Type: Code When this message item is present, one of the following AddressType2Code values must be used: Code Name Definition ADDR 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

Presence: [0..5]

Page 242 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in free format text. Data Type: Max70Text Format: maxLength: 70 minLength: 1 2.1.26 StreetName

Presence: [0..1] Definition: Name of a street or thoroughfare. Data Type: Max70Text Format: maxLength: 70 minLength: 1 2.1.27 BuildingNumber

Presence: [0..1] Definition: Number that identifies the position of a building on a street. Data Type: Max16Text Format: maxLength: 16 minLength: 1 2.1.28 PostCode

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: Max16Text Format: maxLength: 16 minLength: 1 2.1.29 TownName

Presence: [0..1] Definition: Name of a built-up area, with defined boundaries, and a local government. Data Type: Max35Text Format: maxLength: 35 minLength: 1 2.1.30 CountrySubDivision

Presence: [0..1] Definition: Identifies a subdivision of a country eg, state, region, county. Data Type: Max35Text Format: maxLength: 35 minLength: 1 2.1.31 Country

Presence: [1..1] Definition: Nation with its own government. Data Type: CountryCode

Page 243 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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

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 Mult. Represent./ Type 2.1.33 Identification [1..1] Text 2.1.34 Issuer [0..1] Text

2.1.33 Identification

Presence: [1..1] Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier. Data Type: Max35Text Format: maxLength: 35 minLength: 1 2.1.34 Issuer

Presence: [0..1] Definition: Entity that assigns the identification. Data Type: Max35Text Format: maxLength: 35 minLength: 1 2.1.35 BranchIdentification

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 Mult. Represent./ Type 2.1.36 Identification [0..1] Text 2.1.37 Name [0..1] Text 2.1.38 PostalAddress [0..1]

Page 244 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

2.1.36 Identification

Presence: [0..1] Definition: Unique and unambiguous identification of a branch of a financial institution. Data Type: Max35Text Format: maxLength: 35 minLength: 1 2.1.37 Name

Presence: [0..1] Definition: Name by which a party is known and which is usually used to identify that party. Data Type: Max35Text Format: maxLength: 35 minLength: 1 2.1.38 PostalAddress

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 Mult. Represent./ Type 2.1.39 AddressType [0..1] Code 2.1.40 AddressLine [0..5] Text 2.1.41 StreetName [0..1] Text 2.1.42 BuildingNumber [0..1] Text 2.1.43 PostCode [0..1] Text 2.1.44 TownName [0..1] Text 2.1.45 CountrySubDivision [0..1] Text 2.1.46 Country [1..1] Code

2.1.39 AddressType

Page 245 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Code Name Definition PBOX POBox Address is a postal office (PO) box.

2.1.40 AddressLine

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: Max70Text Format: maxLength: 70 minLength: 1 2.1.41 StreetName

Presence: [0..1] Definition: Name of a street or thoroughfare. Data Type: Max70Text Format: maxLength: 70 minLength: 1 2.1.42 BuildingNumber

Presence: [0..1] Definition: Number that identifies the position of a building on a street. Data Type: Max16Text Format: maxLength: 16 minLength: 1 2.1.43 PostCode

Presence: [0..1] Definition: Name of a built-up area, with defined boundaries, and a local government. Data Type: Max35Text Format: maxLength: 35 minLength: 1 2.1.45 CountrySubDivision

Presence: [0..1] Definition: Identifies a subdivision of a country eg, state, region, county. Data Type: Max35Text

Page 246 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Format: maxLength: 35 minLength: 1 2.1.46 Country

Presence: [1..1] Definition: Nation with its own government. Data Type: CountryCode 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).

3 Party identification 3.1 Intermediary1

Intermediary1 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 Mult. Represent./ Type 3.1.0 Identification [1..1] 3.1.1 {Or BICOrBEI [1..1] Identifier 3.1.2 Or ProprietaryIdentification [1..1] 3.1.3 Identification [1..1] Text 3.1.4 SchemeName [0..1] Text 3.1.5 Issuer [0..1] Text 3.1.6 Or} NameAndAddress [1..1] 3.1.7 Name [1..1] Text 3.1.8 Address [0..1] 3.1.9 {{Or Unstructured [1..1] Text 3.1.10 Or}} Structured [1..1] 3.1.11 BuildingName [0..1] Text 3.1.12 StreetName [0..1] Text 3.1.13 StreetBuildingIdentification [0..1] Text 3.1.14 Floor [0..1] Text 3.1.15 TownName [1..1] Text 3.1.16 DistrictName [0..1] Text 3.1.17 RegionIdentification [0..1] Text 3.1.18 State [0..1] Text

Page 247 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Ref Or Message Item Mult. Represent./ Type 3.1.19 CountyIdentification [0..1] Text 3.1.20 Country [1..1] Code 3.1.21 PostCodeIdentification [1..1] Text 3.1.22 PostOfficeBox [0..1] Text 3.1.23 Account [0..1] 3.1.24 Identification [0..1] 3.1.25 Proprietary [1..1] 3.1.26 Identification [1..1] Text 3.1.27 AccountServicer [1..1] 3.1.28 {Or BICOrBEI [1..1] Identifier 3.1.29 Or ProprietaryIdentification [1..1] 3.1.30 Identification [1..1] Text 3.1.31 SchemeName [0..1] Text 3.1.32 Issuer [0..1] Text 3.1.33 Or} NameAndAddress [1..1] 3.1.34 Name [1..1] Text 3.1.35 Address [0..1] 3.1.36 {{Or Unstructured [1..1] Text 3.1.37 Or}} Structured [1..1] 3.1.38 BuildingName [0..1] Text 3.1.39 StreetName [0..1] Text 3.1.40 StreetBuildingIdentification [0..1] Text 3.1.41 Floor [0..1] Text 3.1.42 TownName [1..1] Text 3.1.43 DistrictName [0..1] Text 3.1.44 RegionIdentification [0..1] Text 3.1.45 State [0..1] Text 3.1.46 CountyIdentification [0..1] Text 3.1.47 Country [1..1] Code 3.1.48 PostCodeIdentification [1..1] Text 3.1.49 PostOfficeBox [0..1] Text 3.1.50 Role [0..1] Text

3.1.0 Identification

Presence: [1..1]

Page 248 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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 Mult. Represent./ Type 3.1.1 {Or BICOrBEI [1..1] Identifier 3.1.2 Or ProprietaryIdentification [1..1] 3.1.6 Or} NameAndAddress [1..1]

3.1.1 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: AnyBICIdentifier 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. 3.1.2 ProprietaryIdentification

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 Mult. Represent./ Type 3.1.3 Identification [1..1] Text 3.1.4 SchemeName [0..1] Text 3.1.5 Issuer [0..1] Text

3.1.3 Identification

Presence: [1..1] Definition: Identification assigned by an institution. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.4 SchemeName

Presence: [0..1]

Page 249 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Definition: Name of the identification scheme, eg, "UK National Insurance Number". Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.5 Issuer

Presence: [0..1] Definition: Entity that assigns the identification. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.6 NameAndAddress

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 Mult. Represent./ Type 3.1.7 Name [1..1] Text 3.1.8 Address [0..1]

3.1.7 Name

Presence: [1..1] Definition: Name by which a party is known and which is usually used to identify that party. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.8 Address

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 Mult. Represent./ Type 3.1.9 {Or Unstructured [1..1] Text 3.1.10 Or} Structured [1..1]

3.1.9 Unstructured

Presence: [1..1] This message item is part of choice 3.1.8 Address.

Page 250 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in free format text. Data Type: Max140Text Format: maxLength: 140 minLength: 1 3.1.10 Structured

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 Mult. Represent./ Type 3.1.11 BuildingName [0..1] Text 3.1.12 StreetName [0..1] Text 3.1.13 StreetBuildingIdentification [0..1] Text 3.1.14 Floor [0..1] Text 3.1.15 TownName [1..1] Text 3.1.16 DistrictName [0..1] Text 3.1.17 RegionIdentification [0..1] Text 3.1.18 State [0..1] Text 3.1.19 CountyIdentification [0..1] Text 3.1.20 Country [1..1] Code 3.1.21 PostCodeIdentification [1..1] Text 3.1.22 PostOfficeBox [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

Presence: [0..1] Definition: Name of the building or house. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.12 StreetName

Presence: [0..1] Definition: Name of a street or thoroughfare. Data Type: Max35Text Format: maxLength: 35

Page 251 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

minLength: 1 3.1.13 StreetBuildingIdentification

Presence: [0..1] Definition: Number that identifies the position of a building on a street. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.14 Floor

Presence: [0..1] Definition: Floor or storey within a building. Data Type: Max16Text Format: maxLength: 16 minLength: 1 3.1.15 TownName

Presence: [1..1] Definition: Name of a built-up area, with defined boundaries, and a local government. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.16 DistrictName

Presence: [0..1] Definition: Name of a district, ie, a part of a town or region. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.17 RegionIdentification

Presence: [0..1] Definition: Identification of an administrative division of a country, state, or territory. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.18 State

Presence: [0..1] Definition: Organised political community or area forming a part of a federation. Data Type: Max35Text Format: maxLength: 35 minLength: 1

Page 252 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

3.1.19 CountyIdentification

Presence: [0..1] Definition: Identifier of a county. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.20 Country

3.1.21 PostCodeIdentification

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: Max16Text Format: maxLength: 16 minLength: 1 3.1.22 PostOfficeBox

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: Max16Text Format: maxLength: 16 minLength: 1 3.1.23 Account

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 Mult. Represent./ Type 3.1.24 Identification [0..1] 3.1.27 AccountServicer [1..1]

3.1.24 Identification

Presence: [0..1]

Page 253 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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 Mult. Represent./ Type 3.1.25 Proprietary [1..1]

3.1.25 Proprietary

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 Mult. Represent./ Type 3.1.26 Identification [1..1] Text

3.1.26 Identification

Presence: [1..1] Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.27 AccountServicer

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 Mult. Represent./ Type 3.1.28 {Or BICOrBEI [1..1] Identifier 3.1.29 Or ProprietaryIdentification [1..1] 3.1.33 Or} NameAndAddress [1..1]

3.1.28 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: AnyBICIdentifier Format: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1} Rule(s): AnyBICRule

Page 254 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

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 Mult. Represent./ Type 3.1.30 Identification [1..1] Text 3.1.31 SchemeName [0..1] Text 3.1.32 Issuer [0..1] Text

3.1.30 Identification

Presence: [1..1] Definition: Identification assigned by an institution. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.31 SchemeName

Presence: [0..1] Definition: Name of the identification scheme, eg, "UK National Insurance Number". Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.32 Issuer

Presence: [0..1] Definition: Entity that assigns the identification. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.33 NameAndAddress

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):

Page 255 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Ref Or Message Item Mult. Represent./ Type 3.1.34 Name [1..1] Text 3.1.35 Address [0..1]

3.1.34 Name

Presence: [1..1] Definition: Name by which a party is known and which is usually used to identify that party. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.35 Address

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 Mult. Represent./ Type 3.1.36 {Or Unstructured [1..1] Text 3.1.37 Or} Structured [1..1]

3.1.36 Unstructured

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 Mult. Represent./ Type 3.1.38 BuildingName [0..1] Text 3.1.39 StreetName [0..1] Text 3.1.40 StreetBuildingIdentification [0..1] Text 3.1.41 Floor [0..1] Text

Page 256 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Ref Or Message Item Mult. Represent./ Type 3.1.42 TownName [1..1] Text 3.1.43 DistrictName [0..1] Text 3.1.44 RegionIdentification [0..1] Text 3.1.45 State [0..1] Text 3.1.46 CountyIdentification [0..1] Text 3.1.47 Country [1..1] Code 3.1.48 PostCodeIdentification [1..1] Text 3.1.49 PostOfficeBox [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

Presence: [0..1] Definition: Name of the building or house. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.39 StreetName

Presence: [0..1] Definition: Name of a street or thoroughfare. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.40 StreetBuildingIdentification

Presence: [0..1] Definition: Number that identifies the position of a building on a street. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.41 Floor

Presence: [0..1] Definition: Floor or storey within a building. Data Type: Max16Text Format: maxLength: 16 minLength: 1

Page 257 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

3.1.42 TownName

Presence: [1..1] Definition: Name of a built-up area, with defined boundaries, and a local government. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.43 DistrictName

Presence: [0..1] Definition: Name of a district, ie, a part of a town or region. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.44 RegionIdentification

Presence: [0..1] Definition: Identification of an administrative division of a country, state, or territory. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.45 State

Presence: [0..1] Definition: Organised political community or area forming a part of a federation. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.46 CountyIdentification

Presence: [0..1] Definition: Identifier of a county. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.1.47 Country

Page 258 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

3.1.48 PostCodeIdentification

Presence: [0..1] Definition: Set of functions performed by an intermediary in a given situation. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2 PartyIdentification1

PartyIdentification1 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 Mult. Represent./ Type 3.2.0 Name [0..1] Text 3.2.1 PostalAddress [0..1] 3.2.2 AddressType [0..1] Code 3.2.3 AddressLine [0..5] Text 3.2.4 StreetName [0..1] Text 3.2.5 BuildingNumber [0..1] Text 3.2.6 PostCode [0..1] Text 3.2.7 TownName [0..1] Text 3.2.8 CountrySubDivision [0..1] Text 3.2.9 Country [1..1] Code 3.2.10 Identification [0..1] 3.2.11 {Or OrganisationIdentification [1..1]

Page 259 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Ref Or Message Item Mult. Represent./ Type 3.2.12 BEI [0..1] Identifier 3.2.13 EANGLN [0..1] Identifier 3.2.14 CHIPSUniversalIdentification [0..1] Identifier 3.2.15 DUNS [0..1] Identifier 3.2.16 BankPartyIdentification [0..1] Text 3.2.17 TaxIdentificationNumber [0..1] Text 3.2.18 ProprietaryIdentification [0..1] 3.2.19 Identification [1..1] Text 3.2.20 Issuer [0..1] Text 3.2.21 Or} PrivateIdentification [1..2] 3.2.22 {{Or DriversLicenseNumber [1..1] Text 3.2.23 Or SocialSecurityNumber [1..1] Text 3.2.24 Or AlienRegistrationNumber [1..1] Text 3.2.25 Or PassportNumber [1..1] Text 3.2.26 Or TaxIdentificationNumber [1..1] Text 3.2.27 Or IdentityCardNumber [1..1] Text 3.2.28 Or EmployerIdentificationNumber [1..1] Text 3.2.29 Or}} OtherIdentification [1..1] 3.2.30 Identification [1..1] Text 3.2.31 IdentificationType [1..1] Text 3.2.32 Issuer [0..1] Text

3.2.0 Name

Presence: [0..1] Definition: Name by which a party is known and which is usually used to identify that party. Data Type: Max70Text Format: maxLength: 70 minLength: 1 3.2.1 PostalAddress

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 Mult. Represent./ Type 3.2.2 AddressType [0..1] Code 3.2.3 AddressLine [0..5] Text

Page 260 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Ref Or Message Item Mult. Represent./ Type 3.2.4 StreetName [0..1] Text 3.2.5 BuildingNumber [0..1] Text 3.2.6 PostCode [0..1] Text 3.2.7 TownName [0..1] Text 3.2.8 CountrySubDivision [0..1] Text 3.2.9 Country [1..1] Code

3.2.2 AddressType

3.2.3 AddressLine

Presence: [0..1] Definition: Name of a street or thoroughfare. Data Type: Max70Text Format: maxLength: 70 minLength: 1 3.2.5 BuildingNumber

Presence: [0..1] Definition: Number that identifies the position of a building on a street. Data Type: Max16Text

Page 261 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Format: maxLength: 16 minLength: 1 3.2.6 PostCode

Presence: [0..1] Definition: Name of a built-up area, with defined boundaries, and a local government. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2.8 CountrySubDivision

Presence: [0..1] Definition: Identifies a subdivision of a country eg, state, region, county. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2.9 Country

3.2.10 Identification

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 Mult. Represent./ Type 3.2.11 {Or OrganisationIdentification [1..1] 3.2.21 Or} PrivateIdentification [1..2]

Page 262 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

3.2.11 OrganisationIdentification

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 Mult. Represent./ Type 3.2.12 BEI [0..1] Identifier 3.2.13 EANGLN [0..1] Identifier 3.2.14 CHIPSUniversalIdentification [0..1] Identifier 3.2.15 DUNS [0..1] Identifier 3.2.16 BankPartyIdentification [0..1] Text 3.2.17 TaxIdentificationNumber [0..1] Text 3.2.18 ProprietaryIdentification [0..1]

3.2.12 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: BEIIdentifier 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 following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE, are valid BEIs.

3.2.13 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: EANGLNIdentifier Format: [0-9]{13,13} 3.2.14 CHIPSUniversalIdentification

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.

Page 263 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Data Type: CHIPSUniversalIdentifier Format: CH[0-9]{6,6} 3.2.15 DUNS

Presence: [0..1] Definition: Data Universal Numbering System. A unique identification number provided by Dun & Bradstreet to identify an organization. Data Type: DunsIdentifier Format: [0-9]{9,9} 3.2.16 BankPartyIdentification

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: Max35Text Format: maxLength: 35 minLength: 1 3.2.17 TaxIdentificationNumber

Presence: [0..1] Definition: Number assigned by a tax authority to an entity. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2.18 ProprietaryIdentification

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 Mult. Represent./ Type 3.2.19 Identification [1..1] Text 3.2.20 Issuer [0..1] Text

3.2.19 Identification

Presence: [1..1] Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2.20 Issuer

Presence: [0..1] Definition: Entity that assigns the identification.

Page 264 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2.21 PrivateIdentification

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 Mult. Represent./ Type 3.2.22 {Or DriversLicenseNumber [1..1] Text 3.2.23 Or SocialSecurityNumber [1..1] Text 3.2.24 Or AlienRegistrationNumber [1..1] Text 3.2.25 Or PassportNumber [1..1] Text 3.2.26 Or TaxIdentificationNumber [1..1] Text 3.2.27 Or IdentityCardNumber [1..1] Text 3.2.28 Or EmployerIdentificationNumber [1..1] Text 3.2.29 Or} OtherIdentification [1..1] 3.2.32 Issuer [0..1] Text

3.2.22 DriversLicenseNumber

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: Max35Text Format: maxLength: 35 minLength: 1 3.2.23 SocialSecurityNumber

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: Max35Text Format: maxLength: 35 minLength: 1 3.2.24 AlienRegistrationNumber

Synonym(s): :95S::ALTE//ARNU (ISO 15022) Presence: [1..1]

Page 265 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

This message item is part of choice 3.2.21 PrivateIdentification. Definition: Number assigned by a government agency to identify foreign nationals. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2.25 PassportNumber

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: Max35Text Format: maxLength: 35 minLength: 1 3.2.26 TaxIdentificationNumber

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: Max35Text Format: maxLength: 35 minLength: 1 3.2.27 IdentityCardNumber

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: Max35Text Format: maxLength: 35 minLength: 1 3.2.28 EmployerIdentificationNumber

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: Max35Text Format: maxLength: 35 minLength: 1 3.2.29 OtherIdentification

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.

Page 266 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Message Item Types

Type: This message item is composed of the following GenericIdentification4 element(s): Ref Or Message Item Mult. Represent./ Type 3.2.30 Identification [1..1] Text 3.2.31 IdentificationType [1..1] Text

3.2.30 Identification

Presence: [1..1] Definition: Identifier issued to a person for which no specific identifier has been defined. Data Type: Max35Text Format: maxLength: 35 minLength: 1 3.2.31 IdentificationType

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: Max35Text Format: maxLength: 35 minLength: 1 3.2.32 Issuer

Presence: [0..1] Definition: Entity that assigns the identifier. Data Type: Max35Text Format: maxLength: 35 minLength: 1

Page 267 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes Indexes Index of Message Items A Account: 248

AccountServicer: 248

Address: 247, 248

AddressLine: 236, 237, 259

AddressType: 236, 237, 259

AlienRegistrationNumber: 260

Amount: Message AdditionalPaymentInformation 30, 30

AmountToDebit: Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message RequestToCancelPayment 141

AnyInformation: Message UnableToApply 198

Assignee: Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

AssigneeInstructionIdentification: Message AdditionalPaymentInformation 29

Page 268 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

Assigner: Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

AssignerInstructionIdentification: Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

Assignment: Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

AssignmentCancellationConfirmation: Message ResolutionOfInvestigation 186

AustralianExtensiveBranchNetworkIdentification: 236

AustralianSmallNetworkIdentification:

Page 269 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

236

AustrianBankleitzahlIdentification: 236

B BankOperationCode: Message RequestToModifyPayment 155

BankPartyIdentification: 260

BBAN: 233

BEI: 260

BeneficiaryInstitutionAccount: Message RequestToModifyPayment 156

BIC: 235

BICOrBEI: 247, 248

BranchIdentification: 236

BuildingName: 247, 248

BuildingNumber: 236, 237, 259

C CanadianPaymentsAssociationRoutingNumberIdentification: 236

CancellationReason: Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141

Case: Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message CaseStatusReportRequest 68

Page 270 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 134 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message UnableToApply 197

CaseStatus: Message CaseStatusReport 59

CHIPSParticipantIdentification: 236

CHIPSUniversalIdentification: 235, 260

ClearingSystemMemberIdentification: 235

Code: Message RequestToModifyPayment 156, 156, 156

Confirmation: Message DebitAuthorisationResponse 105 Message ResolutionOfInvestigation 186

CorrectionTransaction: Message ResolutionOfInvestigation 187

Country: 236, 237, 248, 248, 259

CountrySubDivision: 236, 237, 259

CountyIdentification: 248, 248

CreationDateTime: Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59, 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115, 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133

Page 271 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

Creator: Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 134 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186, 186 Message UnableToApply 197

CreditNoteAmount: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

Creditor: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

CreditorAccount: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

CreditorReference: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

Currency: 233

CurrencyAmount: Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

CurrencyOfTransfer: Message AdditionalPaymentInformation 30

Page 272 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

D DateTime: Message CaseStatusReport 59

DebitAuthorisation: Message DebitAuthorisationResponse 105

Debtor: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

DebtorAccount: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

Detail: Message DebitAuthorisationRequest 94

DetailsOfCharges: Message RequestToModifyPayment 156

DiscountAppliedAmount: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

DistrictName: 247, 248

DocumentReferenceNumber: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

DomesticAccount: 233

DriversLicenseNumber: 260

DuePayableAmount: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

DUNS: 260

DuplicateOf: Message ResolutionOfInvestigation 186

E EANGLN:

Page 273 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

260

EmployerIdentificationNumber: 260

EquivalentAmount: Message AdditionalPaymentInformation 30

F FedwireRoutingNumberIdentification: 236

FinancialInstitutionIdentification: 235

FirstAgent: Message AdditionalPaymentInformation 30

FirstSettlementAgent: Message AdditionalPaymentInformation 30

Floor: 247, 248

From: Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message NotificationOfCaseAssignment 115

G GermanBankleitzahlIdentification: 236

H Header: Message CaseStatusReport 58 Message NotificationOfCaseAssignment 115

HongKongBankCode: 236

I IBAN: 233

Identification: 233, 233, 236, 236, 247, 247, 248, 248, 248, 259, 260, 260

Page 274 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message AdditionalPaymentInformation 29, 29 Message CancelCaseAssignment 50, 50 Message CaseStatusReport 59, 59, 59 Message CaseStatusReportRequest 67, 68 Message ClaimNonReceipt 74, 74 Message DebitAuthorisationRequest 94, 94 Message DebitAuthorisationResponse 104, 105 Message NotificationOfCaseAssignment 115, 115, 115 Message RejectCaseAssignment 127, 127 Message RequestForDuplicateInstruction 133, 134 Message RequestToCancelPayment 140, 140 Message RequestToModifyPayment 155, 155 Message ResolutionOfInvestigation 186, 186, 186 Message UnableToApply 197, 197

IdentificationType: 260

IdentityCardNumber: 260

IncorrectInformation: Message UnableToApply 198

Information: Message AdditionalPaymentInformation 29

InstructedAmount: Message AdditionalPaymentInformation 30

InstructionCode: Message RequestToModifyPayment 155

InstructionForFinalAgent: Message RequestToModifyPayment 156

InterbankSettledAmount: Message RequestToModifyPayment 156

Intermediary: Message AdditionalPaymentInformation 30

IntermediarySettlementAgent: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

InvestigationStatus: Message CaseStatusReport 59

Invoicee: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

Page 275 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Invoicer: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

IrishNSCIdentification: 236

Issuer: 236, 247, 248, 260, 260

ItalianDomesticIdentificationCode: 236

J Justification: Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestToCancelPayment 141 Message UnableToApply 198

L LastSettlementAgent: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

M MissingCover: Message ClaimNonReceipt 75

MissingCoverIndication: Message ClaimNonReceipt 75

MissingInformation: Message UnableToApply 198

MissingOrIncorrectInformation: Message UnableToApply 198

Modification: Message RequestToModifyPayment 155

N Name: 233, 236, 236, 247, 248, 259

NameAndAddress:

Page 276 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

247, 248

NewAssignment: Message CaseStatusReport 59

NewZealandNCCIdentification: 235

NostroVostroAccount: Message AdditionalPaymentInformation 30

Notification: Message NotificationOfCaseAssignment 115

O OrganisationIdentification: 259

OtherIdentification: 260

P PassportNumber: 260

PaymentScheme: Message RequestToModifyPayment 156

PortugueseNCCIdentification: 236

PostalAddress: 236, 237, 259

PostCode: 236, 237, 259

PostCodeIdentification: 248, 248

PostOfficeBox: 248, 248

PrivateIdentification: 260

Proprietary: 248 Message RequestToModifyPayment 156, 156

Page 277 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

ProprietaryIdentification: 236, 247, 248, 260

ProprietaryInformation: Message RequestToModifyPayment 156

Purpose: Message RequestToModifyPayment 156

R Reason: Message CaseStatusReport 59 Message DebitAuthorisationResponse 105 Message ResolutionOfInvestigation 186

ReasonCode: Message ResolutionOfInvestigation 186

ReferredDocumentAmount: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

ReferredDocumentRelatedDate: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

ReferredDocumentType: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

RegionIdentification: 247, 248

RejectedCancellation: Message ResolutionOfInvestigation 186

RejectedModification: Message ResolutionOfInvestigation 186

RejectionReason: Message RejectCaseAssignment 127

RelatedReference: Message RequestToModifyPayment 155

RemittanceChoice: Message AdditionalPaymentInformation 29

RemittanceInformation: Message RequestToModifyPayment 156

Page 278 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

RemittedAmount: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

ReopenCaseIndication: Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 134 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186, 186 Message UnableToApply 197

RequestedExecutionDate: Message RequestToModifyPayment 155

RequestHeader: Message CaseStatusReportRequest 67

ResolvedCase: Message ResolutionOfInvestigation 186

Role: 248

RussianCentralBankIdentificationCode: 236

S SchemeName: 247, 248

SenderToReceiverInformation: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

SocialSecurityNumber: 260

SouthAfricanNCCIdentification: 236

SpanishDomesticInterbankingIdentification:

Page 279 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

236

State: 247, 248

Status: Message CaseStatusReport 59 Message ResolutionOfInvestigation 186

StreetBuildingIdentification: 247, 248

StreetName: 236, 237, 247, 248, 259

Structured: 247, 248 Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

SwissBCIdentification: 236

SwissSICIdentification: 236

T TaxAmount: Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

TaxIdentificationNumber: 260, 260

To: Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message NotificationOfCaseAssignment 115

TownName: 236, 237, 247, 248, 259

Type: 233

U UKDomesticSortCode: 236

Page 280 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Underlying: Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message UnableToApply 198

Unstructured: 247, 248 Message AdditionalPaymentInformation 29 Message RequestToModifyPayment 156

UPIC: 233

V ValueDate: Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155, 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

ValueDateToDebit: Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message RequestToCancelPayment 141

Index of XML tags A : Account 248

: AccountServicer 248

: Address 247, 248

: AddressLine 236, 237, 259

: AddressType 236, 237, 259

Page 281 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

: AlienRegistrationNumber 260

: Amount Message AdditionalPaymentInformation 30, 30

: AmountToDebit Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message RequestToCancelPayment 141

: AnyInformation Message UnableToApply 198

: Assignee Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

: AssigneeInstructionIdentification Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

: Assignment Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

Page 282 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

: AssignmentCancellationConfirmation Message ResolutionOfInvestigation 186

: Assigner Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

: AssignerInstructionIdentification Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

: AustrianBankleitzahlIdentification 236

: AustralianSmallNetworkIdentification 236

: AustralianExtensiveBranchNetworkIdentification 236

B : BBAN 233

: BEI 260

: BIC 235

: BICOrBEI 247, 248

: BankOperationCode Message RequestToModifyPayment 155

Page 283 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

: BankPartyIdentification 260

: BuildingNumber 236, 237, 259

: BuildingName 247, 248

: BeneficiaryInstitutionAccount Message RequestToModifyPayment 156

: BranchIdentification 236

C : CanadianPaymentsAssociationRoutingNumberIdentification 236

: Case Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 134 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message UnableToApply 197

: CaseStatus Message CaseStatusReport 59

: Currency 233

: CurrencyAmount Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

: CurrencyOfTransfer

Page 284 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message AdditionalPaymentInformation 30

: Code Message RequestToModifyPayment 156, 156, 156

: CreditNoteAmount Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: Creditor Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: CreditorAccount Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: CreditorReference Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: SwissBCIdentification 236

: SwissSICIdentification 236

: ClearingSystemMemberIdentification 235

: Confirmation Message DebitAuthorisationResponse 105 Message ResolutionOfInvestigation 186

: CreationDateTime Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59, 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115, 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

: Creator Message AdditionalPaymentInformation 29

Page 285 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 134 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186, 186 Message UnableToApply 197

: CorrectionTransaction Message ResolutionOfInvestigation 187

: Country 236, 237, 248, 248, 259

: CountrySubDivision 236, 237, 259

: CountyIdentification 248, 248

: CancellationReason Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141

D : DebitAuthorisation Message DebitAuthorisationResponse 105

: Debtor Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: DebtorAccount Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: GermanBankleitzahlIdentification 236

: DomesticAccount 233

: DocumentReferenceNumber Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

Page 286 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

: DuplicateOf Message ResolutionOfInvestigation 186

: DriversLicenseNumber 260

: DiscountAppliedAmount Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: DistrictName 247, 248

: Detail Message DebitAuthorisationRequest 94

: DetailsOfCharges Message RequestToModifyPayment 156

: DateTime Message CaseStatusReport 59

: DuePayableAmount Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: DUNS 260

E : EANGLN 260

: EquivalentAmount Message AdditionalPaymentInformation 30

: SpanishDomesticInterbankingIdentification 236

F : FinancialInstitutionIdentification 235

: Floor 247, 248

: From Message CaseStatusReport 59

Page 287 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message CaseStatusReportRequest 68 Message NotificationOfCaseAssignment 115

: FirstAgent Message AdditionalPaymentInformation 30

: FirstSettlementAgent Message AdditionalPaymentInformation 30

G : UKDomesticSortCode 236

H : Header Message CaseStatusReport 58 Message NotificationOfCaseAssignment 115

: HongKongBankCode 236

I : IBAN 233

: Identification 233, 233, 236, 236, 247, 247, 248, 248, 248, 259, 260, 260 Message AdditionalPaymentInformation 29, 29 Message CancelCaseAssignment 50, 50 Message CaseStatusReport 59, 59, 59 Message CaseStatusReportRequest 67, 68 Message ClaimNonReceipt 74, 74 Message DebitAuthorisationRequest 94, 94 Message DebitAuthorisationResponse 104, 105 Message NotificationOfCaseAssignment 115, 115, 115 Message RejectCaseAssignment 127, 127 Message RequestForDuplicateInstruction 133, 134 Message RequestToCancelPayment 140, 140 Message RequestToModifyPayment 155, 155 Message ResolutionOfInvestigation 186, 186, 186 Message UnableToApply 197, 197

: IdentityCardNumber 260

: IdentificationType 260

Page 288 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

: IrishNSCIdentification 236

: IncorrectInformation Message UnableToApply 198

: Information Message AdditionalPaymentInformation 29

: InstructedAmount Message AdditionalPaymentInformation 30

: InstructionCode Message RequestToModifyPayment 155

: InstructionForFinalAgent Message RequestToModifyPayment 156

: InterbankSettledAmount Message RequestToModifyPayment 156

: Intermediary Message AdditionalPaymentInformation 30

: IntermediarySettlementAgent Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: Invoicee Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: Invoicer Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: InvestigationStatus Message CaseStatusReport 59

: Issuer 236, 247, 248, 260, 260

: ItalianDomesticIdentificationCode 236

J : Justification Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestToCancelPayment 141 Message UnableToApply 198

Page 289 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

L : LastSettlementAgent Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

M : Modification Message RequestToModifyPayment 155

: EmployerIdentificationNumber 260

: MissingCover Message ClaimNonReceipt 75

: MissingCoverIndication Message ClaimNonReceipt 75

: MissingInformation Message UnableToApply 198

: MissingOrIncorrectInformation Message UnableToApply 198

N : NewAssignment Message CaseStatusReport 59

: Name 233, 236, 236, 247, 248, 259

: NameAndAddress 247, 248

: NostroVostroAccount Message AdditionalPaymentInformation 30

: Notification Message NotificationOfCaseAssignment 115

: NewZealandNCCIdentification 235

O : OrganisationIdentification 259

Page 290 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

: OtherIdentification 260

P : PaymentScheme Message RequestToModifyPayment 156

: PostOfficeBox 248, 248

: Proprietary 248 Message RequestToModifyPayment 156, 156

: ProprietaryIdentification 236, 247, 248, 260

: ProprietaryInformation Message RequestToModifyPayment 156

: PrivateIdentification 260

: PassportNumber 260

: PostCode 236, 237, 259

: PostCodeIdentification 248, 248

: PostalAddress 236, 237, 259

: PortugueseNCCIdentification 236

: Purpose Message RequestToModifyPayment 156

R : ReopenCaseIndication Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74

Page 291 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 134 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186, 186 Message UnableToApply 197

: RequestedExecutionDate Message RequestToModifyPayment 155

: RequestHeader Message CaseStatusReportRequest 67

: ReferredDocumentAmount Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: ReferredDocumentRelatedDate Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: ReferredDocumentType Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: RegionIdentification 247, 248

: RejectedCancellation Message ResolutionOfInvestigation 186

: RejectedModification Message ResolutionOfInvestigation 186

: RejectionReason Message RejectCaseAssignment 127

: RelatedReference Message RequestToModifyPayment 155

: RemittanceChoice Message AdditionalPaymentInformation 29

: RemittedAmount Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: RemittanceInformation Message RequestToModifyPayment 156

Page 292 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

: Role 248

: ResolvedCase Message ResolutionOfInvestigation 186

: Reason Message CaseStatusReport 59 Message DebitAuthorisationResponse 105 Message ResolutionOfInvestigation 186

: ReasonCode Message ResolutionOfInvestigation 186

: RussianCentralBankIdentificationCode 236

S : SchemeName 247, 248

: SocialSecurityNumber 260

: SenderToReceiverInformation Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: State 247, 248

: Structured 247, 248 Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: StreetBuildingIdentification 247, 248

: StreetName 236, 237, 247, 248, 259

: Status Message CaseStatusReport 59 Message ResolutionOfInvestigation 186

T : TaxAmount

Page 293 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

: TaxIdentificationNumber 260, 260

: To Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message NotificationOfCaseAssignment 115

: Type 233

: TownName 236, 237, 247, 248, 259

U : Underlying Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message UnableToApply 198

: UPIC 233

: CHIPSParticipantIdentification 236

: CHIPSUniversalIdentification 235, 260

: FedwireRoutingNumberIdentification 236

: Unstructured 247, 248 Message AdditionalPaymentInformation 29 Message RequestToModifyPayment 156

V : ValueDate Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141

Page 294 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message RequestToModifyPayment 155, 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

: ValueDateToDebit Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message RequestToCancelPayment 141

Z : SouthAfricanNCCIdentification 236

Index of Message Item Types A Account1 248

AccountIdentification1 248

AccountIdentification1Choice 233

AddressType2Code 236, 237, 259

AmountType1Choice Message AdditionalPaymentInformation 30

AnyBICIdentifier 225, 247, 248 Message AdditionalPaymentInformation 29, 29, 29 Message CancelCaseAssignment 50, 50, 50 Message CaseStatusReport 59, 59, 59, 59, 59 Message CaseStatusReportRequest 68, 68, 68 Message ClaimNonReceipt 74, 74, 74 Message DebitAuthorisationRequest 94, 94, 94 Message DebitAuthorisationResponse 104, 104, 105 Message NotificationOfCaseAssignment 115, 115, 115, 115, 115 Message RejectCaseAssignment 127, 127, 127 Message RequestForDuplicateInstruction 133, 133, 134 Message RequestToCancelPayment 140, 140, 140 Message RequestToModifyPayment 155, 155, 155 Message ResolutionOfInvestigation 186, 186, 186, 186 Message UnableToApply 197, 197, 197

AustrianBankleitzahlIdentifier

Page 295 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

225, 236

B BBANIdentifier 225, 233

BEIIdentifier 225, 260

BICIdentifier 226, 235

BranchAndFinancialInstitutionIdentification 235 Message AdditionalPaymentInformation 30, 30, 30, 30 Message RequestToModifyPayment 156, 156

BranchData 236

C CanadianPaymentsARNIdentifier 226, 236

CancellationReason1Code Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141

Case Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 134 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186, 186 Message UnableToApply 197

CaseAssignment Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message ClaimNonReceipt 74

Page 296 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186 Message UnableToApply 197

CaseAssignmentRejection1Code Message RejectCaseAssignment 127

CaseAssignmentRejectionJustification Message RejectCaseAssignment 127

CaseForwardingNotification Message NotificationOfCaseAssignment 115

CaseForwardingNotification1Code Message NotificationOfCaseAssignment 115

CaseStatus Message CaseStatusReport 59

CaseStatus1Code Message CaseStatusReport 59

CashAccount3 232 Message AdditionalPaymentInformation 30, 30, 30 Message RequestToModifyPayment 156, 156, 156

CashAccountType3Code 233

CashClearingSystem2Code Message RequestToModifyPayment 156

ChargeBearer1Code Message RequestToModifyPayment 156

CHIPSParticipantIdentifier 226, 236

CHIPSUniversalIdentifier 226, 235, 260

ClearingSystemMemberIdentificationChoice 235

CountryCode

Page 297 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

226, 236, 237, 248, 248, 259

CurrencyAndAmount 224 Message AdditionalPaymentInformation 29, 30, 30, 30, 30, 30, 30, 30 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94, 94 Message DebitAuthorisationResponse 105 Message RequestToCancelPayment 141, 141 Message RequestToModifyPayment 155, 156, 156, 156, 156, 156, 156 Message ResolutionOfInvestigation 187 Message UnableToApply 198

CurrencyCode 227, 233 Message AdditionalPaymentInformation 29, 30, 30, 30, 30, 30, 30, 30, 30 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94, 94 Message DebitAuthorisationResponse 105 Message RequestToCancelPayment 141, 141 Message RequestToModifyPayment 155, 156, 156, 156, 156, 156, 156 Message ResolutionOfInvestigation 187 Message UnableToApply 198

D DebitAuthorisationConfirmation Message DebitAuthorisationResponse 105

DebitAuthorisationDetails Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141

DocumentType1Code Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

DunsIdentifier 227, 260

E EANGLNIdentifier 227, 260

EquivalentAmount Message AdditionalPaymentInformation 30

ExtensiveBranchNetworkIdentifier 227, 236

Page 298 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

F FedwireRoutingNumberIdentifier 227, 236

FinancialInstitutionIdentification1 235

G GenericIdentification1 247, 248

GenericIdentification3 236, 260

GenericIdentification4 260

GermanBankleitzahlIdentifier 228, 236

H HongKongBankIdentifier 228, 236

I IBANIdentifier 228, 233

ImpliedCurrencyAndAmount 224

Instruction1Code Message RequestToModifyPayment 155

Instruction3Code Message RequestToModifyPayment 156

InstructionForFinalAgent Message RequestToModifyPayment 156

Intermediary1 247 Message AdditionalPaymentInformation 30

InvestigationExecutionConfirmation1Code Message CaseStatusReport 59 Message ResolutionOfInvestigation 186

Page 299 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

InvestigationStatusChoice Message ResolutionOfInvestigation 186

IrishNSCIdentifier 228, 236

ISODate 224 Message AdditionalPaymentInformation 30 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155, 155, 156

ISODateTime 225 Message AdditionalPaymentInformation 29, 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59, 59, 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74, 75 Message DebitAuthorisationRequest 94, 94 Message DebitAuthorisationResponse 104 Message NotificationOfCaseAssignment 115, 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 133 Message RequestToCancelPayment 140, 141 Message RequestToModifyPayment 155, 155 Message ResolutionOfInvestigation 186, 187 Message UnableToApply 197, 198

ItalianDomesticIdentifier 228, 236

L LanguageCode 228

LongPostalAddress1Choice 247, 248

M Max10Text 231

Max128Text 231

Page 300 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

Max140Text 231, 247, 248 Message AdditionalPaymentInformation 29 Message CaseStatusReport 59 Message DebitAuthorisationResponse 105 Message RequestToModifyPayment 156, 156 Message ResolutionOfInvestigation 186

Max16Text 231, 236, 236, 237, 237, 247, 248, 248, 248, 248, 248, 259, 259

Max256Text 231

Max350Text 232

Max35Text 232, 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, 260 Message AdditionalPaymentInformation 29, 29, 29, 29, 30, 30, 30 Message CancelCaseAssignment 50, 50 Message CaseStatusReport 59, 59, 59 Message CaseStatusReportRequest 67, 68 Message ClaimNonReceipt 74, 74, 75, 75 Message DebitAuthorisationRequest 94, 94, 94, 94 Message DebitAuthorisationResponse 104, 105 Message NotificationOfCaseAssignment 115, 115, 115 Message RejectCaseAssignment 127, 127 Message RequestForDuplicateInstruction 133, 134 Message RequestToCancelPayment 140, 140, 141, 141 Message RequestToModifyPayment 155, 155, 155, 155, 155, 156, 156, 156, 156, 156 Message ResolutionOfInvestigation 186, 186, 186, 187, 187 Message UnableToApply 197, 197, 198, 198

Max70Text 232, 233, 236, 236, 236, 237, 237, 259, 259, 259

MICIdentifier 229

MissingCover Message ClaimNonReceipt 75

MissingOrIncorrectInformation Message UnableToApply 198

N NameAndAddress2 247, 248

Page 301 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

NationalityCode 229

NewZealandNCCIdentifier 229, 235

NonFinancialInstitutionIdentification1 259

Number 230

P Party1Choice 259

PartyIdentification1 259 Message AdditionalPaymentInformation 30, 30, 30, 30 Message RequestToModifyPayment 156, 156, 156, 156

PartyIdentification1Choice 247, 248

PaymentCancellationRejection1Code Message ResolutionOfInvestigation 186

PaymentComplementaryInformation Message AdditionalPaymentInformation 29

PaymentInstructionExtract Message AdditionalPaymentInformation 29 Message ClaimNonReceipt 75 Message DebitAuthorisationRequest 94 Message RequestToCancelPayment 141 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 187 Message UnableToApply 198

PaymentModificationRejection1Code Message ResolutionOfInvestigation 186

PaymentPurpose1Code Message RequestToModifyPayment 156

PaymentSchemeChoice Message RequestToModifyPayment 156

PercentageRate 231

Page 302 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

PersonIdentification2 260

PortugueseNCCIdentifier 229, 236

PostalAddress1 236, 237, 259

PurposeChoice Message RequestToModifyPayment 156

R ReferredDocumentAmount1Choice Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

RejectedCancellationJustification Message ResolutionOfInvestigation 186

RemittanceInformation3Choice Message AdditionalPaymentInformation 29 Message RequestToModifyPayment 156

ReportHeader Message CaseStatusReport 58 Message CaseStatusReportRequest 67 Message NotificationOfCaseAssignment 115

RequestedModification Message RequestToModifyPayment 155

RussianCentralBankIdentificationCodeIdentifier 229, 236

S SimpleIdentificationInformation 233, 248

SmallNetworkIdentifier 229, 236

SouthAfricanNCCIdentifier 229, 236

SpanishDomesticInterbankingIdentifier 230, 236

Page 303 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Indexes

StructuredLongPostalAddress1 247, 248

StructuredRemittanceInformation2 Message AdditionalPaymentInformation 30 Message RequestToModifyPayment 156

SWIFTServiceLevel2Code Message RequestToModifyPayment 155

SwissBCIdentifier 230, 236

SwissSICIdentifier 230, 236

U UKDomesticSortCodeIdentifier 230, 236

UnableToApplyIncorrectInfo1Code Message UnableToApply 198

UnableToApplyJustificationChoice Message UnableToApply 198

UnableToApplyMissingInfo1Code Message UnableToApply 198

UPICIdentifier 230, 233

Y YesNoIndicator Message AdditionalPaymentInformation 29 Message CancelCaseAssignment 50 Message CaseStatusReport 59 Message CaseStatusReportRequest 68 Message ClaimNonReceipt 74, 75 Message DebitAuthorisationRequest 94 Message DebitAuthorisationResponse 105, 105 Message NotificationOfCaseAssignment 115 Message RejectCaseAssignment 127 Message RequestForDuplicateInstruction 134 Message RequestToCancelPayment 140 Message RequestToModifyPayment 155 Message ResolutionOfInvestigation 186, 186, 186 Message UnableToApply 197, 198

Page 304 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Errata Errata Definition for RejectionReason Code UKNW See section Message: RejectCaseAssignment 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.

Page 305 UNIFI (ISO 20022) - Payments Standards - Exceptions and Investigations August 2006 Revision Record Revision Record

Revision Date Author Description Sections affected 1.0 11/08/2006 ISO 20022 RA Initial version All

Page 306